Here I’m looking at the challenges logged in the previous post.

I wasn’t the first one saying that it might be good to have certain expansions of Weekend Testing format. What if we have longer sessions? What if we do follow-up sessions? I think these expansions help addressing challenges like “complexity of a mission” on an individual level.

However:

• any knowledge learned by a participant remains encapsulated – there is no contribution towards product coverage;
• the testing approach is not organized and is not systematic at the team level.

What about organizing into a team doing exploratory testing?
The immediate questions are:

• how to distribute and coordinate the testing effort?
• how to qualitatively communicate and store the knowledge?
• how to qualitatively retrieve and visualize it?

Michael Larsen and I had a few discussions on the subject, as well as we brought it up during session debriefings and discussed with the participants.

As for the first question, Session-Based Test Management methodology fits greatly here.

• Charters help to identify individual testing missions.
• Charter notes help to capture and communicate the knowledge.
• Debriefing allows plugging in the new pieces of knowledge into the picture (information about the product and the process) being built.

But here’s the problem. If the picture is in facilitator’s mind then effectively sharing and maintaining it in a distributed team is hardly possible. And the whole process depends on the one, initial, facilitator. We wanted to make the process more open and more self-sustainable. We didn’t want to “manage resources” or oblige the participants with some strict rules.

And here’s what we have about that.

• Test ideas appear as a result of the team brainstorming in the group chat
• Test ideas are to be shaped into charters with ‘short’ (30 minutes) and ‘standard’ (1 hour) time boxes
• Anybody can test out the charter but in order to have a debriefing conducted the results have to be written following a certain structure, so this knowledge can be shared

Important to mention that “test results” are not equal to “bug reports”. The latter is only a part of the information about the product; hence the notes must contain everything learnt about the product during execution of a charter.

But what structure and what medium should be used to store product characteristics?

– So far, we found that James Bach’s “SFDPOT” in a form of a mind map works very well.

• Mind map makes the information visual and structured
• Mind map can be fairly rapidly created and easily maintained
• Mind map can be expanded at any node and in any point of time
• Session logs, screenprints, and other files can be easily linked to the mind map nodes
• Mind maps can be cross-linked

With all the above said, we’re getting product testing oriented series of sessions of four types.

• Exploring and mapping product elements (format: common chat and mindmapping of the main elements in real-time)
• Charter design (format: common chat and attachment of charters to the mindmap)
• Individual and paired charter-based testing sessions. Note that individually some participants may work on charters even offline, not during the Weekend Testing session. This greatly increases flexibility and allow differentiated contribution.
• Charter debriefing. This has to be done online and must be immediately followed by “admin” work – updating the mind map, logging bugs, uploading charter logs.

To sum up. Taking on the bigger tasks requires transformation from “crowd mode” to “team mode”. Team means takeaway from facilitator-participant roles, and a bigger variety of roles. And to effectively share knowledge across a distributed team there must be a dedicated medium. We’re looking into putting in use mind maps as knowledge transfer and communication tools.