We have been reviewing how we structure exploratory testing in my team and have initially agreed on Testing Tours and incorporating ideas from the Session Based Test Management approach by James Bach.
I found lots of useful posts on here, but would like to know more about how you run your debriefs. I would appreciate any feedback on what you do, and things that work or don’t work. One question that has come up is who raises the bug tickets and is it during the debrief?
I had the pleasure of consulting with James on this topic when we introduced session based testing in my company. If I recall correctly he initially only used it to check that the session report was done in accordance with the required format so the tool could extract the information needed to generate the needed report for management. Occasionally he also used it to reject sessions saying that the coverage of the testing was not sufficient for that charter to be considered completed. That was only applicable if the tester was junior and needed some pointers. And it resulted in the tester doing the another session on the same charter.
Right now we use it more as a peer review (similar to the review process for pull requests and code) where you can look more towards the knowledge transfer aspects. Both in terms of how you do testing of a specific thing as well as between the testers (we are two for each project) to sync what have been done and not. For me not the most valuable use of our time.
As for your question regarding the bugs I have always raised them as part of the session. One time we added time it took to report bugs as a metric to investigate is we needed to speed up that process or not. At the time most of the time went to deal with test environment and test data (i.e. time not spent testing) so speeding up the bug process was not a concern of ours.
If you, like me, work in iterative environments where you plan and release every two weeks I would suggest you have a look at thread based test management instead since I have found that to be easier in those environments.
Thank you @ola.sundin This is really useful and I will be discussing your ideas with the team. We have 6 week milestones made up of 3 sprints. I will check out the other threads you suggest as well.
It varies. We have run whole-team, “formal” debriefs where we book a meeting room and talk through the findings of a number of sessions, but we also do more “ad hoc” ones where the tester will sit with a relevant developer and run them through what they’ve found. Generally we are more on the informal side of things, but we frequently look to include the PO in the debrief as it avoids duplication of effort in communicating things with them, plus good to have them on-hand to answer questions which arise.
Who raises the bugs? For us, this is a tester responsibility and an outcome of the testing process. We encourage both dev and PO to have input on the bug tickets, for example adding any insights they have (may not be them who works on the fix). Ordinarily we’d look to do this immediately after debrief, to avoid wasting anyone’s time - once a defect is agreed, it’s a one-person job to get the ticket itself raised.
@wildtests thank you for your comments!