What do you put in your exploratory testing charters?

There was a question recently on Slack which sparked some insight for me. Depending on the company and the situation people are in or even the audience, they may structure their charters very differently.

@deborahreid added that

the charter should give all the guidance with the freedom to explore I think

This is a mantra that I’ve followed myself while creating charters. Reading the replies, it seems that when it came to more complex features, knowing exactly what to put in and leave out of a charter could cause a conundrum.

What do you put into your charters? Can you give an example of a charter that you’d use for something a bit more complex than a landing page?

I haven’t done much exploratory testing at new job yet so the examples here are not very exciting but here is the format I follow (not very strictly, I am always adding/removing sections and changing for suitability to a particular case).


Example at top is empty, followed by slightly sanitised examples of two time-boxed sessions I did in the last month. I’m not an expert of anything, so it’s just what I’ve found useful for testing things out. They’re also both solo but I did some pairing/thairing ones at my old workplace which were much nicer. xD

The second example, I don’t think it really counts as exploratory testing since I was checking something extremely specific using a spreadsheet but I was asked by someone else to do some exploratory testing on the subject and it was my choice to make it so structured. I mean, exploratory doesn’t mean unstructured I suppose, so I have left it up as an example in case it’s useful. Have not linked the sheet because it contains company info. xD

I hope that’s in any way useful.

Oh, and I did write a blog post on the subject which includes me learning about exploratory testing and charters last year:



I like the format Elizabeth Hendrickson describes in her book Explore It! - there’s a few examples in this slideshare of a talk of hers but basically it’s:

Explore area/feature [ with resources/conditions, or constraints ] to discover information.

So that could be “explore the design for the new contract functionality using state transition diagrams/tables to discover missed scenarios that could end up with a customer in an irretrievable condition and/or loss of revenue”. (Yep, I deliberately picked an example that doesn’t even need code to be written yet. You can explore with a whiteboard or pen and paper as well as a keyboard.)

1 Like

Interesting, I never thought of using charters on features where code hadn’t been written yet :thinking: