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?

  • Note: The above is actually a question I asked over at the old Software Testing Club Exchange (as best I can remember it). It gained a lot of very valuable answers there - if I could migrate it over I would, but the site no longer exists.
    – testerab
    Commented Jan 1, 2012 at 19:49

4 Answers 4


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.

  • Thanks Ben, good advice again. I like the two heuristics :). I'd agree it's a better use of time to pair a novice tester with someone more experienced rather than trying to make charters for a novice.
    – testerab
    Commented Jan 6, 2012 at 0:33

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


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.

  • I really like diagramming to uncover new testing ideas, reveal areas that I don't understand well enough yet (when I discover I don't know how a couple of entities are related, for example). However, I'm not sure how that relates to test charters specifically?
    – testerab
    Commented Jan 6, 2012 at 0:38

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.

  • 2
    This doesn't answer the question. You reference an article, with no links to that article. Can you summarize what it said here? Please see sqa.stackexchange.com/help/how-to-answer and the section "provide context for links"
    – Lee Jensen
    Commented Apr 27, 2021 at 13:56
  • 1
    I'll admit, this is the first "link only answer" I've had flagged in the 10 years I've been modding the site that didn't actually have a link! But Lee is correct, all the information in there still applies - in particular that answers should stand on their own and reference external material for further research, but only after a useful answer has been composed. Thanks!
    – corsiKa
    Commented Apr 27, 2021 at 14:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.