Quality Hunting ist eine Alternative zum Bug Hunting, bei der kleine Teams in einer kurzen explorativen Session gezielt Informationen über die Qualität eines Systems sammeln. Vorher wird festgelegt, welche Information gebraucht wird, etwa zur Usability. Der Bericht verdichtet die Rohdaten zu Wissen, mit dem die Stakeholder entscheiden, ob das System live geht.
Das Wichtigste in Kürze
- Rik Marselis hat Quality Hunting aus Frust über Bug Hunting entwickelt, denn Testen heißt für ihn, Informationen über das Qualitätsniveau eines Systems zu bekommen.
- Beim allerersten Durchlauf im Testlab der EuroSTAR-Konferenz fand ein Team nur etwa acht Probleme, konnte aber beurteilen, wie gut das System für Menschen mit Behinderung funktioniert.
- Ein Quality-Hunting-Team hat rund vier Leute, halb so viele wie ein durchschnittliches agiles Team, und eine Session dauert etwa drei Stunden, höchstens einen halben Tag.
- Teams sollten die Struktur ihres Reports gleich zu Beginn skizzieren, damit die Session sie mit den Informationen füllt, die ihre Stakeholder brauchen.
- Ein guter Zeitpunkt liegt kurz vor einem Release, das mehrere Sprints bündelt; wer jede User Story sofort in Produktion bringt, findet dafür keinen Platz.
Was ist Quality Hunting?
Quality Hunting ist eine kurze, zeitlich begrenzte explorative Session, in der kleine Teams Informationen über ein System sammeln, damit Stakeholder seine Qualität beurteilen können. Rik Marselis hat die Methode als Alternative zum Bug Hunting entwickelt. Vom Bug Hunting übernimmt sie den spielerischen Wettbewerb; die Teams sammeln dabei Belege zu Qualitätsmerkmalen.
Im Ablauf ähnelt Quality Hunting einem sitzungsbasierten explorativen Test, wie ihn die Testentwurfsverfahren kennen, mit festem Zeitrahmen und klarem Auftrag. Am Ende eines Quality Hunts steht eine Aussage, die den Entscheidern eine Frage beantwortet: Ist das System gut genug? Rik beschreibt die Methode im Buch Amplified Quality Engineering, und der neue ISTQB-Lehrplan Quality in DevOps führt sie als einen seiner Ansätze.
Eine Bugliste sagt wenig über Qualität
Bug Hunting geht von der Prämisse aus, dass Tester Bugs finden sollen. Aus Riks Frust über genau diese Prämisse ist die ganze Idee entstanden. Ein Bug ist für ihn ein Signal: Die Qualität liegt unter dem, was man erwartet hat, und jemand kann etwas dagegen tun. Die eigentliche Aufgabe des Testens ist, das Qualitätsniveau zu kennen.
„Beim Testen geht es darum, Informationen über das Qualitätsniveau deines Systems zu bekommen.“
(Rik Marselis)
Ihre Form bekam die Methode in einem Testlab auf der EuroSTAR-Konferenz. Rik und seine Kollegen organisierten dort das allererste Quality Hunting als Hands-on-Übung, und es funktionierte überraschend gut. Einige Teams arbeiteten trotzdem im Bug-Hunting-Modus und kamen mit einem riesigen Haufen Probleme zurück. Ob das System gut genug war, ließ sich daraus nicht ablesen.
Ein anderes Team meldete nur etwa acht Probleme, hatte aber geschaut, wie sich das System benutzen lässt. Sein Urteil: Für ein allgemeines Publikum funktioniert es gut genug, für Menschen mit Behinderung nicht, weil ihnen manche Auswahlmöglichkeiten fehlen. Dieses Team lieferte eine Bewertung der Qualität. Danach beschrieb Rik die Methode formaler.
Am Anfang steht die Frage des Stakeholders
Beim Bug Hunting ist das Ziel klar: Bugs finden. Quality Hunting braucht etwas Vorbereitung, weil das Ziel erst festgelegt werden muss: Welche Information brauchen wir, und für wen? Das klärt das Team selbst, oder es bekommt die Vorgabe von dem, der den Auftrag vergibt.
Wer zum ersten Mal einen Quality Hunt plant, fragt am besten die Stakeholder, welche Information ihnen helfen würde, nachts gut zu schlafen. Wer die Entscheidung trägt, ob Product Owner, Nutzer oder Management, soll die Information bekommen, die ihm die Sorge um das System nimmt. Der Hunt sammelt dann die Inputs für genau diese Information.
Inhaltlich hilft der Blick auf die Qualitätsmerkmale. Ob das System tut, was es soll, bleibt wichtig. Aufschlussreicher ist oft, wie es das tut. Manche nicht-funktionalen Merkmale eignen sich besser als andere. Ein Performancetest passt schlecht in eine dreistündige Teamsession. Usability lässt sich vorab schwer spezifizieren und in kurzer Zeit gut erkunden, deshalb ist sie ein guter Kandidat für einen Quality Hunt.
Wie läuft eine Quality-Hunting-Session ab?
Ein Quality Hunt ist wie ein Spiel organisiert. Mehrere Teams treten gegeneinander an, der Stakeholder kürt den Sieger, und es gibt einen Preis. Rik rät zu einem kleinen Preis, denn es geht um gute Informationen. Der Wettbewerb lohnt sich trotzdem, weil die Teams sich gegenseitig anspornen, weiterzuschauen.
Den Rahmen beschreibt Rik typischerweise so:
- etwa vier Leute je Team, ungefähr halb so viele wie in einem durchschnittlichen agilen Team mit sieben
- höchstens ein halber Tag, rund drei Stunden
- vier bis sechs Teams parallel, die zusammen in sehr kurzer Zeit sehr viele Informationen liefern
Innerhalb dieses Zeitrahmens entscheidet jedes Team, wie es den Auftrag angeht und was in der verfügbaren Zeit machbar ist. Dann arbeitet es wie ein explorativer Tester: einen Test überlegen, ausführen, daraus lernen, prüfen, ob das näher an die gesuchte Information bringt. Vorbereitet wird wenig. Den nächsten Schritt löst aus, was das Team im System passieren sieht. Zwischendurch tritt es einen Schritt zurück und erinnert sich an das eigentliche Ziel, eine bestimmte Art von Information für die Stakeholder.
Wie ein Team dorthin kommt, entscheidet es selbst. Fest steht nur das Ziel: die bestmögliche Information in diesem Zeitrahmen.
Gleicher Auftrag, verschiedene Richtungen
Bekommen mehrere Teams denselben Auftrag, schlagen sie trotzdem völlig unterschiedliche Richtungen ein. Riks Usability-Beispiel zeigt das. Manche Teams prüfen, ob das System gut aussieht und zu den Richtlinien oder dem Stil des Unternehmens passt. Andere denken an Barrierefreiheit und fragen, wie Menschen mit Behinderung das System nutzen können.
Für den Stakeholder wird es dadurch schwer, einen Sieger zu bestimmen, weil in jeder Richtung ein Wert steckt. Rik schlägt deshalb ein paar kleinere Preise vor, keinen großen. Oft gewinnen die Teams am Ende gemeinsam, denn zusammen liefern sie dem Stakeholder in kurzer Zeit eine Menge Informationen.
Wie berichten Teams ihre Ergebnisse?
Ein Bug Hunt endet mit einer Liste von Bugs. Welche Form der Report eines Quality Hunts hat, hängt vom Team ab. Rik empfiehlt, und das gilt fürs Testen allgemein, gleich zu Beginn über die Struktur des Reports nachzudenken. Welche Botschaft willst du vermitteln, und an wen? Steht die Struktur, muss die Session sie nur noch füllen. Während des Hunts prüft das Team, welche Informationen schon da sind und welche noch fehlen.
Rik verbindet das mit der Hierarchie aus Daten, Information, Wissen und Weisheit. Testen liefert zuerst Daten, die das Team zu Informationen zusammensetzt. Bei den Stakeholdern soll Wissen ankommen, damit sie das Qualitätsniveau wirklich kennen. Die Weisheit, über den Go-live zu entscheiden, bleibt bei ihnen. Ein Report voller Rohdaten darüber, was das Team getan hat, überspringt den Schritt, auf den es ankommt.
Der beste Zeitpunkt liegt kurz vor dem Release
Wie oft ein Quality Hunt sinnvoll ist, hängt von der Situation ab. Eine praktikable Regel lautet, vor jedem Release in Produktion etwas Quality Hunting zu machen. Wer im echten DevOps-Stil jede einzelne User Story sofort in Produktion bringt, findet dafür keinen Platz. Die meisten Teams arbeiten aber in Sprints und bringen das Ergebnis mehrerer Sprints gemeinsam in Produktion. Die Zeit kurz vor einem solchen Release hält Rik für den idealen Moment.
Weil jeder in einem Team mitmachen kann, ergänzt ein Hunt an dieser Stelle auch den Abnahmetest. Endnutzer, Manager und andere Beteiligte bekommen einen Eindruck aus erster Hand von der Qualität des Systems.
Auch dort, wo Automatisierung dominiert, hält der Ansatz Menschen im Spiel. In DevOps-Umgebungen mit dem Motto „automatisiere alles“ bewahrt Quality Hunting die menschliche Neugier und den kritischen Blick, deshalb steht es im ISTQB-Lehrplan. Bei KI im Testen gilt dasselbe: Menschen müssen weiter fragen, was das Ziel war und ob sie wirklich bekommen, was sie brauchen.
