What do I have to consider in an exploratory test charter?

Question

I am currently trying to build a test charter for my exploratory test within a timebox. But what exactly should this charter contain?

Session Charter: This includes a mission statement, a short definition, which goal should be followed with the test of the current session. This can be, for example, the Strategy / Tour [Discovery, BugFinding, Bug Retest, "Just Going There"] and the session duration: [short: 60 minutes; normal: 90 minutes; long: 120 minutes]

Explore with to find Objective - function, requirement or module Tools - tools, datasets, techniquesInformations - Does it work? Safety, performance, reliability.

What else should I consider?

Answer 1

You should consider to keep them simple and use any data for analysis during the timebox to see where to explore next. The charter is just a mission to get you started, not a detailed work assignment and reporting tool.

I like the format ckenst proposes in his writing exploratory charters:

How to Write Exploratory Charters

This is based on "A simple charter template" from Elisabeth Hendrickson's awesome book Explore It!, Chapter 2, page 67 of 502 (ebook).

Explore (target) With (resources) To discover (information)

• Target: What are you exploring? It could be a feature, a requirement, or a module.
• Resources: What resources will you bring with you? Resources can be anything: a tool, a data set, a technique, a configuration, or perhaps an interdependent feature.
• Information: What kind of information are you hoping to find? Are you characterizing the security, performance, reliability, capability, usability or some other aspect of the system? Are you looking for consistency of design or violations of a standard?

Read more and examples at: https://github.com/ckenst/testing-guides/blob/master/test%20design/writing_exploratory_charters.md

Answer 2

I think that the parameters you have stated should be definitely included along with the people that will participate in the session (testers or managers) and the certain areas on which the session would focus. I really liked the explanation offered on this exploratory testing for optimum coverage resource.

Answer 3

Your start I think was really good, I would suggest to add the following:

• the format of the charter should be the same as the bug name
• which areas will be included
• test notes
• testers who are included in the testing charter
• optional - references or files

I hope this helps!

Answer 4

Consider creating Mind Maps/Modeling your app as you test. One of the most powerful techniques I've used is Mind Mapping. (I know not everyone gets Mind Mapping, but don't write me off yet.) Essentially what I would do is start trying to identify the larger components of the system, and the key sub components/modules, all the way down to even feature calls. For example if I had a system for registration, there might be a ReserveSlot, CancelReservation as possible operations. (When in doubt fall back on CRUD: Create, Remove, Update, and Display alternatively: Create, Read, Update, Delete)

Once you start getting maps of the system, you can then look at what component you are testing, and start creating charters to cover the functionality you know of beneath it, and also to explore for other parts that have not yet been mapped or documented in the model. Eventually you may reach a point where you don't do much adding to the mind map. One thing to look for are pieces of functionality that are reused in multiple places. These are places where redundant testing might be taking place, or it may be that the components are instantiated differently, and thus look different. Those are key things to model as well. Then from there along with the other advice in this thread, build your charters around the areas you know you want to test, the parts it may interact with directly, or be part of a longer process, and anywhere else where they may rub up against each other.