When I think about doing a session debrief, I always include reviewing the session notes, having the tester tell a story of their testing, and me asking questions about what was/wasn't tested as part of the debrief. So a typical debrief for an experienced tester on my team might take five to ten minutes. For a junior tester, it might take ten to twenty minutes. If I'm doing them well (and that's a big if), than they take time. Ideally both of us (the tester and myself) are getting something out of the debrief.
Trinity Testing combines the knowledge and skills of the team to improve the quality of the software, and the testing. It consists of a short session, of around 90 minutes per feature, where the feature owner, the developer and the test engineer work interactively through the software to share knowledge and ideas. In particular, test engineers are able to provide immediate feedback, identify areas of concern, and devise useful testing strategies per feature.
Each person benefits: the tester knows where to focus their testing, the engineer can correct issues identified during the session while the code is fresh rather than waiting for bug reports, and the feature owner gets a better feature :) Retrospectives are included at the end of each cycle to help improve the process and practices.
A similar concept - called the 'power of three' is described in Agile Testing, a book by Lisa Crispin and Janet Gregory see http://www.agiletester.ca/ for more information.
Each person benefits: the tester knows where to focus their testing, the engineer can correct issues identified during the session while the code is fresh rather than waiting for bug reports, and the feature owner gets a better feature :) Retrospectives are included at the end of each cycle to help improve the process and practices.
A similar concept - called the 'power of three' is described in Agile Testing, a book by Lisa Crispin and Janet Gregory see http://www.agiletester.ca/ for more information.
Here are some quick tips to keep in mind when debriefing an exploratory test session:
- The more important the setup and configuration of your software is to your testing, the more you should describe it.
- The areas of the system that are less frequented and/or are the newest require additional details for clarity.
- Talk about how you felt about your testing and the software as you describe the steps you took.
- Avoid "info dumps." Keep those in your session notes, and focus your face-to-face debrief time on patterns, feelings, and overall results.
- Avoid saying the same thing over and over again as you debrief similar tests, or even across several different debriefs. When the notes and data speak for themselves, go beyond the obvious.
When exploratory testing, we sometimes run out of ideas and get blocked. One trick Michael Bolton showed me was to use Oblique Strategies to kickstart my brain. I was surprised that the fifth oblique strategy I selected triggered my brain into a completely new class of test ideas. It's now part of my heuristic tool box for test idea generation.
Try it online here or here.
Try it online here or here.
I've seen session-based test management implemented a number of ways. I have a general rule that a charter isn't "done" until the debrief happens. It's easy to fall into the habit of queuing up debriefs and not doing them. This rule prevents that from happening.