How do you write clear, succinct test charters for exploratory testing sessions?

Question

Session-based exploratory testing depends on creating good test charters at the right level of detail to guide the tester, without directing them.

You need to make the goal of the session clear, without being either too generic (so it's not clear what the intended focus of the session should be), or being overly directive, thus limiting the tester's ability to design their own tests in response to what they're discovering. For testers who have primarily worked in a script-heavy environment, it's often difficult to avoid falling into the trap of creating "fake" charters that are really just test cases in disguise. To me, writing clear, succinct test charters for sessions is one of the hardest skills I've had to learn with exploratory testing.

If you are an experienced exploratory tester, what attributes make a good test charter for you?

Do you use any common patterns to help you to structure your charters? Are there any common failure patterns you notice in bad test charters?

Answer 1

You may find yourself tempted to write out a bunch of charters early on to show management types so that it doesn't look like you're sitting on your hands. Resist this urge if you find it upon you.

There's no real need to overcomplicate charters. If start a session and you realize the scope is overambitious, modify the scope and note down whatever new charters that you think may be necessary based on the new information you've discovered as a result of your testing.

I've found in practice that it's tougher to create charters early on in a project (especially a greenfield project), so I look at recon charters up-front to discover which areas are

1. complex
2. buggy
3. incomplete or otherwise diverge greatly from what we expect

I also like to use mindmaps to put together a checklist of areas of the product we want to explore, as well as types of testing that we might want to employ.

Based on the answers to these, combined with whatever other risk analysis we've done, you can start to nail down what your divisions should be and what charters you may need to create for the moment and prioritize those as appropriate.

Heuristics that I use to guide charter creation:

• A charter should be brief enough to tweet.
• Do recon until you know specifically what you want to explore further.

Other factors that may affect how you put your charters together is the experience of your testers. If you have inexperienced testers though, you're probably better off pairing them with a more experienced tester and have them guide the novice tester through the charter. That's getting a little off topic though.

Answer 2

I've just started using session based testing in place of scripted test cases. My charters have been fairly simple so far:

• The area of the feature to be tested, and how I plan to test. (Functional, performance..)
• Any changes to this area since last session. (Has a bug been corrected? Could it impact other areas?)
• Limitations, ie. I know of a piece that is still in progress, so anything in that area may not be complete, and bugs should be evaluated with that in mind.

Structuring my charters in this manner has allowed me to follow any bread crumb trail that might occur, while also guiding me in a 'user story' manner. I document what I actually did in far more detail than I previously did using this approach

Answer 3

I like to diagram the entities and relationships of the system (or aspect of the system) I plan to test.

Sometimes when I am stuck on a problem, the act of explaining it to someone else allows me to become unstuck. The other person may not need to say a word; it is my presenting the problem that causes the solution to reveal itself. Similarly, diagramming can uncover new testing ideas.

Answer 4

As per the demand of question we can go through this very useful article. "Exploratory Testing, A Guide Towards Better Test Coverage", which could answer your doubt.