An introduction to Tester Merit Badges can be found on my blog at aclairefication.com.

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)

Web resources:

• Session-based testing
• Scenario testing
• Exploratory testing in agile

Books:

• Agile Testing by Lisa Crispin and Janet Gregory
• Exploratory Software Testing by James Whittaker

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 turns off when you begin to execute it. As you work 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, 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 available), 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 the time required to 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 guesstimate. 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 with no more explicit structure than a time box. Give yourself fifteen 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. Using the trail metaphor, you want to provide indications of the way out of the woods, but 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 James Whittaker's landmark tour is particularly apt for this example, so I recommend picking a part of your application from which 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. 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. If you lack a user manual for this particular product, try a description of some similar or competing product. Again, you'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 when testing bores me, I'm really doing it wrong! There is always too much testing to complete, so I certainly need to go exploring more often.

Comment below 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)