Take the 2-minute tour ×
Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It's 100% free, no registration required.

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?

share|improve this question
    
Hi folks, this is the start of my New Year challenge. Fancy joining me? meta.sqa.stackexchange.com/questions/149/… –  testerab Jan 1 '12 at 19:48
    
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 Jan 1 '12 at 19:49
add comment

3 Answers 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.

share|improve this answer
    
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 Jan 6 '12 at 0:38
add comment

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.

share|improve this answer
    
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 Jan 6 '12 at 0:33
add comment

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

share|improve this answer
    
Thanks Todd! Noting limitations is a useful one. –  testerab Jan 6 '12 at 0:37
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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