In this post I share experience on how we’re building and using the process model; it’s an expansion of ideas from the previous post.

The picture above is based on the sketching we made with Michael Larsen while conferring on Skype. However, the elements and solutions used in there are rooted in Rapid Testing and BBST methodologies.

We have started with longer than regular sessions (4 hours instead of 2), and have done two of such kind.
While the initial exploration of the product goes very well (at pace much faster than I could map it :) ), further breakdown is slower and slower. This is where we came to the conclusion that charter design and charter execution better be separate activities if you don’t want the whole group working on a single charter. However, and a comment by Thomas Ponnet emphasizes that, it brings a challenge of having  numerous debriefing sessions, which can only be addressed by having more facilitators, which is a challenge itself. For example, I am, personally, only learning the skills of debriefing.

The next thing we encountered that, once ramped up into the brainstorming mode, the group works with an awesome productivity generating vast amount of test ideas. However, if you don’t want them to get lost, somebody has to take care of them, and also frame and shape test ideas into charters fitting the timeboxes.

The ‘charter’ thing. Pretty much, any and every test execution is a charter. Charters produce test ideas for new charters. Charters produce information about application’s behavior and product elements. Last but not least, charters result in bugs and issues found… But how to frame and categorize the charters? On the diagram above, you can see sample charters called like “explore”, “inspect”, “investigate”, “question”, and “examine”. I’ve been learning charter-based exploratory testing mainly through Michael Kelly’s materials, here’s one short and sweet example. Since we agreed to build our process around the product coverage model, charters directly related to that fit very well here. But not everything is about product elements. Here’s how we got the list of charter categories:

• Explore <coverage element, functionality, UI>. The most ‘generic’ type.
• Inspect <claim, statement>. Could be a documentation claim. But could be a charter to re-test a bug fix. Or clarify information from the previous execution of the same charter.
• Investigate <problem, bug, issue>. It’s a “drill-down” and “explore around” charter. Often is a follow up on the results brought by other charters.
• Question <functionality, outcome>. It’s a mix of exploration and investigation guided by the questions “did it solve the problem?”, “does it add value?”
• Examine <operation, data>. Exploration from the end-user perspective.

One might ask why there’s a need to categorize at all. At the end, all charters result in producing information of the all kinds. The answer is in the need to land the charters in a certain structure. If you let them hanging – you lose the big amount of them after a session ends. And since you store them – you better do it in organized fashion. In terms of mindmapping – how do you want to visualize a charter and where do you want to attach or link it?

One important thing I want to mention. Findings of all types – bugs, issues, product’s behavior, test ideas, etc. – are getting produced at any time and during any activity – and they are the most valuable process artifacts. Even if it’s not an actual charter execution there’s always time and place to log your findings.