I attended weekend testing America’s session number 18 on Saturday. It was my first WTA session, and I must say it was a good learning experience. There was an interesting exercise given by James Bach. The exercise was about Test Charters.
As part of the exercise, we had to critique existing test charters and improve them. I went through the definition of test charter given in the exercise to understand more about test charters. I tried to critique and improve the example charters, based on the definition given in the exercise. I was not satisfied with the outcome and wanted someone to critique my (improved /modified) charters.
My (improved :-)/modified) test charter was discussed during the briefing session, and Michael Larsen, Wade, Shrink, and Lalit gave interesting feedback on my charter. During that briefing session, I realized that I could draw an analogy of writing test charters to writing user stories in Agile. I wonder, would it be easier to write charters if they are treated as user stories? If we write user stories as test charter, end user, in this case, is probably the tester who will become responsible for the charter, well that’s the thought anyway.
So what made me think on these lines?
- Test Charter is a contract between client and tester.
>>>Similarly a story is a form of contract with the customer.
- Test charter indicates a reasonable common understanding of a testing problem to be solved, actions to be taken and results to be delivered
>>>Similarly a story represents a clear understanding of the problem to be solved. Sometimes, tasks of a story represent actions needed to solve that problem. Acceptance criteria of the story represent results expected to be delivered.
- A test charter should be focused, have a well-defined objective and unambiguous.
>>>So does a story. A story should also be clear, have some purpose and deliver some result.
- Test charter’s progress is usually recorded / shared in the debriefing sessions
>>>For stories, progress is usually recorded / shared by acceptance criteria.
- Good test charters don’t have too many questions or assumptions. If they are not clear to testers, usually they ask questions and charters are refined to provide clarity.
>>>On the same lines, story is also treated as a point of negotiation and usually discussed in sprint planning meetings and refined as needed.
So as I understand, the main purpose of the test charter is to:
- Keep test session focused.
- Promote questioning about the session
- Deliver something meaningful at the end of a test session.
A story, just like test charters needs to be focused, refined by asking the right questions and deliver something useful.
A user story delivers, and a test charter tries to validate whatever is delivered. Test charters (or test story) should probably become an integral part of user stories in Agile, i.e., charters related to the story should be finished before that story can be marked as complete.
Just like we INVEST in stories, we can INVEST in test charters to get better results from test sessions. So my question is – Is this analogy over simplifies the concept of test charters? What arguments am I missing in this analogy? I would welcome your feedback.