Personally, I really like exploratory testing based on the following three ingredients:
- The amount of time a tester gets
- Makes planning possible
- Team decides per sprint/week/day etc.
- Allows lean manual testing for others (e.g. developers or domain experts), too
- Testers are extremely focused (higher chance of finding bugs)
Example: usually between 30 – 60 minutes.
- So we know what has been tested
- Helps to continuously improve manual testing skills
- What worked in the past, what not?
- Go back in time and see why we didn't find a particular bug
- Reuse powerful test cases or automate them
- Helps to onboard new team members
Scope: XYZ creation wizard
Timebox: 60 minutes
1) open wizard - object selection dialog opens - C
2) go through all steps in order (1, 2, 3, 4) - arrived at final step - C
3) jump around on navigation bar: 3, 5, 2 - crash - B
Opportunities: (C)orrect, (B)ug, (?) open question
- Describe how the SUT should be tested
- Developed at Microsoft, used by many others
- Distinct and catchy names to improve communication
- Allows testers to come up with new test cases on the fly
- Would be too open without tours (less focus, less control)
- Become quickly part of the team vocabulary
- Landmark: Most important features in different orders
- Anti-social: Always do the opposite
- Garbage collector: Go street by street, house by house
- Supermodel: UI only
Note that this are just loose guidelines. For instance, some teams may like Git-versioned Markdown files for their protocols, whereas others may prefer Excel sheets in a private cloud. Feel free to adapt the whole process to your team's/department's/company's needs, while keeping the basic idea in mind.
For further reading, I can recommend the following literature: