Intuitive testing and exploratory testing are techniques that rely on a tester's skills, experience, and knowledge to design test cases. Exploratory testing is useful when documentation is poor or time is limited. It involves exploring the system to determine test cases and allowing results to influence further testing. Checklist-based testing uses lists of items or rules to verify a product. Intuitive, exploratory, and checklist-based testing work best to supplement other techniques when documentation is limited or time is short, and when testers are experienced in the domain or technology.

1. Software Testing Foundations #6
Intuitive & Experience-based Testing
Nikita Knysh
nknysh@gmail.com
http://www.facebook.com/groups/istqb/

2. Agenda
• Intuitive Testing
• Exploratory Testing
• Beyond the Two

3. Intuitive Testing
• (Aka error guessing).
• Can uncover faults overlooked by systematic testing.
• Basis of this method is the skill, experience and
knowledge of the tester.
• Should NOT be applied as the primary testing
technique.
• Instead, this technique should be used to support
and complete the choice of test cases through
systematic testing techniques.

4. Exploratory Testing
• One of the intuitive testing techniques.
• Helps if the documents, which form the basis for test
design, are of very low quality or do not exist at all.
• The technique is also applicable when time is severely
restricted because it uses much less time than other
techniques.
• The test object is explored and new test cases are
determined and executed when knowledge about the
object is collected. Results of one test case influence the
design and execution of further test cases.
• Makes sense for testing small objects for hour or two.

5. Test Completion Criteria
• The criterion is coverage of the list of possible errors.
• Intensity and completeness of intuitive and
exploratory test design cannot be measured.

6. Checklist-based Testing
• Uses a high-level list of items to be noted, checked or
remembered, or set of rules to verify the product
against.
• Checklists are built based on standards, experience
or other considerations.
• Examples: checklists of UI standards, checklist of
core functionalities of the system.

7. Attacks
• Direct focused evaluation by attempt to force
specific failures to occur.
• Principle of attack is based on interaction between
software and its environment, including UI, OS with
kernel, APIs and file systems.
• Interactions are based on data exchanges, and
misalignment in those can be the cause of a failure.

8. When to Use
• No specifications are available.
• There is poor documentation of the system under
test.
• Insufficient time to design and create test
procedures.
• Testers are experienced in the domain and/or the
technology.
• Seek diversity from scripted testing.
• Analyze operational failures.

9. Thank you!
http://www.facebook.com/groups/istqb/