How do you organise and manage testing charters?

Question

There appear to be very few tools out there specifically aimed at managing charters for exploratory testing sessions. If you're using SBTM or TBTM, how do you manage your charters?

Some of the things I'd expect to gain from organising our test charters would be:

• easily track what charters have been completed
• track how many new charters have been added as a result of discoveries from previous sessions
• enable both testers, and others to add new charters covering new areas of risk, or add potential resources to existing charters.
• show type of session (e.g. is it a reconnaissance session, bug finding, etc)
• visible to the rest of the project team (not just testers)
• enable clear prioritisation of test charters, with input from stakeholders

What tools have you found useful, what did you gain from them, and what factors do you think affected how useful they were (i.e. would you have found the same benefits in a different context)?

Answer 1

I like to keep things simple.

I work with a small team of testers and programmers. We like to keep things lightweight.

For managing charters and information flow, I use a spreadsheet and a whiteboard.

I categorize charters by product area. I haven't found getting more detailed than that to be useful to me (or others). I name charter files by their product area and a number. Sometimes I'll add 'recon', especially if in the early stages of a project where the useful deliniations of product area may not yet be clear.

e.g.

• ProjectRecon-01
• ProductAreaA-01
• ProductAreaA-02
• ProductAreaB-01
• ProdcutAreaC-01

etc

The excel file I keep has the following columns:

• Charter name
• Charter (I paste the actual charter description here so it's clear what the intention - of the charter is)
• Priority (High, Normal, Low)
• Date Executed
• Executed by (testers name and anyone else involved goes here)
• Debriefed by (generally my name goes here)

I follow a rule of thumb that a charter description should be short enough to tweet. That helps me keep in mind how much can be covered in a 2-hour period and has the added benefit of helping it fit neatly in the spreadsheet.

I keep the spreadsheet and charters on a shared network drive. I don't bother with version control, but I suppose you could if you wanted to.

I don't force developers or management to read charters, though I certainly invite them to. I will often mail completed charters to specific programmers if the testers have found something they would be interested in knowing about.

I do encourage testers to approach developers immediately upon finding an issue to see if we can resolve it on the spot. Anything that can be, is. Anything else goes in the bug tracker. Either way it gets recorded in the session log. This works for us. YMMV.

I use the whiteboard along the lines of James Bach's low-tech dashboard. I divide the project into logical areas and summarize the findings of testing so far in each of them. The whiteboard is in a visible place so that at any time, anyone interested can get a drive-by update of testing progress. I update management and our product team verbally and occasionally via email whenever there is anything noteworthy to report.

I haven't found any need to do anything more complex than this. I think it would add extra overhead for no gain that I can see.

My testers are in constant communication about what they are working on. We communicate regularly about priorities and any changes that crop up.

I suppose that if I had a much larger team that I might need to modify things a bit, but probably not all that much.