Heuristic Test Strategy Model (James Bach Model) By Nadeeshani Aththanagoda
Heuristic Test Strategy Model A set of patterns for designing a test strategy. what to think about when creating tests. self-directed learning fully conscious testing among professional testers.
What is it? resources, constraints, and other forces things that intend to test rules, values, and sources
Con’t…… Project Environment - Resources, constraints, and other forces in the project that enable us to test Product Elements- Things that intend to test Quality Criteria- Rules, values, and sources that allow you as a tester to determine if the product has problems. Test Techniques- Strategies for creating tests. Perceived Quality- The result of testing
Heuristic Test Strategy Model categories General Test Techniques Project Environment Product Elements Quality criteria categories Operational criteria Development criteria
General Test Techniques F unction Testing D omain Testing S tress Testing F low Testing S cenario Testing C laims Testing U ser Testing R isk Testing A utomatic Testing
1.Functional Testing Test what it can do Identify things that the product can do Determine how you’d know if a function was capable of working Test each function, one at a time See that each function does what it’s supposed to do and not what it isn’t supposed to do
2.Domain T estin g Divide and conquer the data Look for any data processed by the product Look at outputs as well as inputs Decide which particular data to test with Consider combinations of data worth testing together
3.Stress Testing Overwhelm the product Look for sub-systems and functions that are vulnerable to being overloaded or “broken”. Select or generate challenging data, or resource constraint conditions to test with: e.g., large or complex data structures, high loads, long test runs, many test cases, low memory conditions.
4.Flow Testing Do one thing after another Define test procedures or high level cases that incorporate multiple activities connected end-to-end. Don’t reset the system between tests. Vary timing and sequencing, and try parallel threads.
5.Scenario Testing Test to a compelling story Begin by thinking about everything going on around the product. Design tests that involve meaningful and complex interactions with the product. A good scenario test is a compelling story of how someone who matters might do something that matters with the product.
6.Clams Testing Verify every claim Identify reference materials that include claims about the product (implicit or explicit). Analyze individual claims, and clarify vague claims. Verify that each claim about the product is true. If you’re testing from an explicit specification, expect it and the product to be brought into alignment.
7.User Testing Involve the users Identify categories and roles of users. Determine what each category of user will do (use cases), how they will do it, and what they value. Get real user data, or bring real users in to test. Otherwise, systematically simulate a user Powerful user testing is that which involves a variety of users and user roles, not just one.
8.Risk Testing Imagine a problem, then look for it. What kinds of problems could the product have? Which kinds matter most? How would you detect them if they were there? Make a list of interesting problems and design tests specifically to reveal them.
9.Automatic Testing Run a million different tests Look for opportunities to automatically generate a lot of tests. Develop an automated, high speed evaluation mechanism. Write a program to generate, execute, and evaluate the tests.
Project Environment C ustomers I nformation D eveloper Relations T est Team E quipment & Tools S chedule T est terms D eliverables
Project Environment Cust omers -Anyone who is a client of the test project. Information -Information about the product or project that is needed for testing. Developer Relations -How you get along with the programmers. Test Team - Anyone who will perform or support testing.
Project Environment Equipment & Tools - Hardware, software, or documents required to testing Schedule - The sequence, duration, and synchronization of project events ‰ Test Items - The product to be tested ‰ Deliverables - The observable products of the test project
Product Elements S tructure F unction D ata P latform O perations. T ime.
Product Elements Structure - Everything that comprises the physical product. Function - Everything that the product does Data - Everything that the product processes Platform - Everything on which the product depends Operations - How the product will be used. Time - Any relationship between the product and time
Quality criteria categories A quality criterion is some requirement that defines what the product should be. By looking thinking about different kinds of criteria, Operational criteria Development criteria
Operational criteria C apability U sability. S ecurity S calability. P erformance I nstallability C ompatibility.
Operational criteria Capability - Can it perform the required functions? Reliability - Will it work well and resist failure in all required situations? Usability - How easy is it for a real user to use the product? Security - How well is the product protected against unauthorized use or intrusion?
Operational criteria Scalability - How well does the deployment of the product scale up or down? Performance - How speedy and responsive is it? Installability - How easily can it be installed onto its target platform(s)? Compatibility - How well does it work with external components & configurations ?
Development criteria S upportability. T estability. M aintainability P ortability L ocalizability
Development criteria Supportability - How economical will it be to provide support to users of the product? Testability - How effectively can the product be tested? Maintainability - How economical is it to build, fix or enhance the product? Portability - How economical will it be to port or reuse the technology elsewhere? Localizability - How economical will it be to adapt the product for other places?
36 Letters…………….. FDSFSCURA -general test techniques CIDTESTD -project environment SFDPOT -product elements CUUSSPICSTMPL -quality criteria