Weekend Testing: Focusing
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.
One response to "Weekend Testing: Focusing"
Hello,
some interesting approaches you have here, some which we tried to tackle in the European weekend testing chapter quite some time ago as well – and didn’t get very far.
One such approach was to try and create a project team within one mission. We had several roles, for example project manager, product sponsor, tester, etc and people would volunteer for the roles.
Setting up a team within the short time span of a weekend testing session was challenging to say the least and I’m not sure that it was very successful. It more resembled the reality of holdups at various stages, i.e. between project manager and product manager, people not knowing what to do, etc.
In short, your approach is better, IF you usually have the same people attending so they’ll bring some knowledge from the previous session.
SBTM is great approach and I implemented it in the last two companies, it makes too much sense not to. But it also needs quite a substantial amount of management which I believe is the challenge here.
Coming up with test ideas and writing the charters should be achievable in a distributed environment, I’m not so sure about the charter execution and debriefing.
I believe what you’d want to do is that before a charter is done that the tester reads the charter notes and any charters that have already been executed that touch the area. That’s a good bit of time gone already here. If the tester doesn’t also check the MindMap with charter ideas they’re likely to miss dependencies on other areas. For some charters that’s a problem but maybe not for all.
The charter execution and debriefing is challenging to put into one session but if you allow 1.5 hours instead of one should be doable IF you keep the sessions small half an hour max I believe because of the familiarisation period upfront, then the actual testing, then the debrief.
From experience I’d always try and do the ET sessions and debrief on the same day, otherwise too much information is lost – that also means that offline work doesn’t work very well.
To me the debriefing in any WT session is always the most useful part and delaying that would take a big part of it away imo.
I’m looking forward to your next part and how you’ll tackle the challenges outlined. Get in touch if you’d like to discuss, it’s a subject that I take great interest in.
Thomas
[ Albert’s reply.
Hi, Thomas!
Your feedback and ideas are greatly appreciated.
Thanks for your involvement, and I hope our experience will be useful for the Europe Chapter. ]