With only a week left in February, I’ll be wrapping up my own trial of the first Tester Merit Badge and posting my results, so I encourage you to try it for yourself. Do let me know if you’re playing along at home!
For reference, here is the introduction and here is the motivation.
Originally posted on the Techwell blog, the badge description is reposted here for convenience:
Tester Merit Badge: Explorer
Skill challenge: Try exploratory testing
Requirements
1. Know Your Maps.
Be able to explain different approaches to exploratory testing (e.g. testing tours, chartered session-based testing, freestyle)
Some web resources:
Session-based testing
Scenario testing
Exploratory testing in agile
Some books:
Crispin, Lisa; Gregory, Janet (2009). Agile Testing
Whittaker, James (2009). Exploratory Software Testing
2. North, South, East, West.
Who says scripted test cases can’t be exploratory? Just because you have a protocol written down doesn’t mean your brain turned off when you began to execute it. As you go along working through a set of instructions, perhaps drawing from a user manual if you lack test scripts or specific test cases, keep your eyes open for what is going on around you, not just what fits the happy path of the case. Make notes of testing ideas and chase down something that’s off-script and keep track of what you do as you go along. If no test scripts or highly structured test cases exist for a particular aspect you want to test, skip ahead to requirement #3.
3. How Long and How Far.
Using an existing reference (if any) estimate the time to exploratory test an aspect of a feature of a software product. If you have been using test cases or test scripts for this testing, then use those as jumping off points for your exploration but don’t follow them. I tend to make a list of some test ideas and then pick and choose which ones to attempt during a particular exploratory session. If no ready-made resources exist for a particular aspect you want to test, skip ahead to requirement #4.
4. Walk the Distance.
Estimate time exploratory test an aspect of a feature of a software product without the aid of any existing materials. Use your knowledge and experience to take an educated guess at what needs to be done and build up a guess-timate. We’re going for ballpark and not precision here. Then, try it and see how close you were. That’s the beauty of iterative learning.
5. Map Maker. Map of the Place. Make a Model.
I see these physical representations of travel as essentially the same when it comes to software testing. This one is about precisely describing what you observe, which makes it a perfect artifact of your exploratory session. This could be a site map, a pairing of requirements description snippets with implemented user interface components, or even a sketch of different paths through a block of code (if you’re doing some white box preparation for your exploratory testing). We want to show what we observed rather than what we expect, so you can explicitly record your expectations if that helps you to clear your mind for the road ahead.
6. Finding Your Way Without Map or Compass.
Freestyle! Do some testing without any more explicit structure than a time box. Give yourself 15 minutes to wander around in an application without stating a particular agenda. You might even try accessing a piece of software through a less favored access point (e.g. a traditional website viewed from a smart phone).
7. Trail Signs Traffic.
This is an opportunity to write a different kind of test guide for another tester to follow. If we stick to the trail metaphor, you want to provide indications of the way out of the woods but you don’t dictate how the hiker travels between the boles of the trees bearing the blaze (or if you’re a big nature nerd the piles of rocks and sticks with their encoded messages about the trail ahead). I think Whittaker’s landmark tour is particularly apt for this example, so I recommend picking a part of your app to extract some landmarks. Avoid step-by-step instructions about how to wander between these milestones! You want to recognize the variation in execution that naturally occurs, even in the presence of a test script. In this case, doing it differently is a strength since you collectively will cover more of the application over time, although you may not encounter exactly the same scenery along the way.
8. Bus and Train Maps.
Use a publicly available source to map out a test. If you have a user manual for the application under test, that would be a good source for producing an expected route through an application. Just like a driver stuck in traffic, you don’t need to adhere to the planned route, so feel free to follow any detours that seem like better alternatives if you are feeling blocked or just want to take a more scenic route. Lacking a user manual for this particular product, try a description of some similar or competing product. Again, we’re exploring here, so having an inexact guide is no barrier to the experiment.
When you complete any or all parts of these badge “requirements” take a moment to reflect on whether the technique could be helpful to you in your regular testing work. You don’t have to migrate away from your current approach, but having some options always helps me to switch it up a bit when testing starts to feel monotonous – and I really think I’m doing it wrong when testing bores me! There is always too much testing to complete, so I certainly need to go exploring more often.
Drop me a line or post a comment here to let me know how the experiment went for you and I’ll post my own results here within the month.
Happy testing!
Image source (embroidered version of this image)
