Quality Hunting: Testing for Information Instead of Bugs - Rik Marselis

Stakeholders want to know if the system is good enough, and a bug list rarely says so

Quality hunting grew out of Rik Marselis's frustration with bug hunting, and I wanted to know how it works when the goal is information about quality. Rik walks me through a session: teams of about four people, three hours of exploratory testing and a goal agreed up front by asking stakeholders what would help them sleep well at night. He explains why the report structure comes first, why the prize should stay small and why the point just before several sprints go to production suits a hunt well.

"Testing is not about finding bugs. Testing is about getting information about the quality level of your system." - Rik Marselis

Rik Marselis is principal quality consultant at Sogeti in the Netherlands. He is a highly regarded presenter, trainer, author, consultant and coach who has supported many organizations and people in improving their quality engineering and testing practice.

Highlights:

• Rik Marselis developed quality hunting out of frustration with bug hunting, because for him testing means getting information about the quality level of a system.
• At the first quality hunt in a EuroSTAR test lab, one team found about eight problems and could still judge how well the system works for disabled users.
• A quality hunting team has about four people, half the size of an average agile team, and a session lasts three hours or at most half a day.
• Teams should sketch the structure of their report at the start, so the session fills that structure with the information their stakeholders need.
• Shortly before a release that bundles several sprints is a good moment for a quality hunt; teams that ship every user story right away cannot fit it in.

More Links with Insights:

• TMAP

📘 Tool migration ahead? Teamscale playbook: migrate only 20% of tests, keep nearly all bug detection. Download for free