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