I've heard of people organizing their testing around charters. What is a test charter, how do you create one and how can they help you test?
There are at least two common ways I've seen charters described in testing: team charters and test charters. Let's take them one at a time.
Some test teams I have worked with went through the effort to come up with a team charter. The charter is what the team does and is often negotiated with management. This avoids confusion when, for example, a new executive assumes that the quality assurance team is responsible for security testing, usability or some other function it may not do.
In general, charters are an abstract concept, a placeholder to represent how a tester might spend a unit of time.
When you say "organizing testing around charters," I think you mean something else such as a block of work, something like a test case.
Well, actually, not like a test case at all -- but it is similar in the sense that a test charter is a holding place for a block of work, called a session. The charter is how you plan to invest the next 30 minutes (or an hour, or 90 minutes). Here are a few high-level examples:
Rendering on the spreadsheet under old versions of IE
Moving items in and out of the cart while losing signal
The basic trick here is to scope the work to fit the size of the charter, probably by combining functionality, platform, scenario and data. (Robert Sabourin’s ten test ideas is a great reference for setting up charters.)
The most well-known way to use charters to organize your testing is probably with session-based test management. You start by making a list of charters, then sorting by the riskiest and most important -- the ones you'd do first. Put the charters on cards, pull one card at a time and use that charter to find bugs.
At any time, a manager who walks by can change the order of the cards, and you can add more as necessary.
The goal here isn't to test everything. Start by admitting that you can't test everything. Instead, the goal is to spend the time you have as wisely as possible, mostly by focusing on testing instead of creating documentation.
Session-based test management isn't the only sort of testing charter, though. Another common tactic on Agile teams is to create a "story" to find information about the software. The goal of the story is not to fix the problem, just to do investigative work -- and those can often be framed as charters.
There's a lot more to say about test charters than I can fit in this one short article. In general, charters are an abstract concept, a placeholder to represent how a tester might spend a unit of time. They're less about making repeatable tests and more about focusing on value and information gathering.
If you want more specific information about charters for test teams, you might enjoy this video by Michael Kelly.
This was first published in May 2014