Wenn Sie einen Weg finden möchten, negative Stimmung zwischen Testern und Entwicklern in etwas Positives zu verwandeln, haben wir hier eine tolle Lösung. Die Idee, die ich vorstellen möchte, ist zwar schon recht alt, aber auch heute noch in unserer schönen neuen DevOps-Welt ein Dauerbrenner.
Vor vielen Jahren stieß ich im Internet auf eine PDF-Datei namens „Bug Fix Bingo“. Ein nettes, lustiges Spiel für IT-Profis. Ursprünglich wurde dieses kleine, witzige Spiel von der Softwaretestfirma K. J. Ross & Associates entwickelt. Leider ist die Originalseite längst verschwunden, daher habe ich beschlossen, diese tolle Idee in diesem Blogbeitrag festzuhalten.
Ich kann dieses Spiel auch Leuten empfehlen, die sich nicht so intensiv mit Tests beschäftigen, aber an vielen IT-Meetings teilnehmen müssen. Drucken Sie einfach die Datei aus, bringen Sie ein paar Kopien zum nächsten Meeting mit und freuen Sie sich auf das Geschehen. Ich habe es mehrmals gespielt. Neben dem Spaß, den wir hatten, hat es etwas verändert. Schauen wir uns also das Konzept und die Regeln an.
Bug Fix Bingo basiert auf einem traditionellen Bingo, nur mit ein paar Anpassungen. Jeder kann ohne große Vorbereitung mitmachen, denn es ist ganz einfach. Anstelle von Zahlen werden beim Bingo Aussagen von Entwicklern in Defect-Review-Meetings verwendet, um Felder zu markieren.
Regeln:
- Bingo-Felder werden markiert, wenn ein Entwickler während der Fehlerbehebungssitzungen die passende Aussage macht.
- Tester müssen sofort „Bingo“ rufen, sobald sie eine Reihe von fünf Feldern horizontal, vertikal oder diagonal vervollständigt haben.
- Aussagen, die aufgrund eines Fehlers entstehen, der später als „verzögert“, „wie vorgesehen“ oder „nicht zu beheben“ eingestuft wird, sollten als nicht markiert klassifiziert werden.
- Fehler, die nicht in einem Vorfallsbericht gemeldet werden, können nicht verwendet werden.
- Aussagen sollten zur späteren Bestätigung zusätzlich zum Fehler im Fehlerverfolgungssystem erfasst werden.
- Jeder Tester, der alle 25 Aussagen markiert, erhält umgehend zwei Wochen Stressurlaub.
- Jeder Entwickler, der alle 25 Aussagen verwendet, sollte für mindestens sechs Monate zur Umschulung in die Testgruppe abgeordnet werden.
| “Auf meinem Rechner funktioniert es.” | “Wo waren Sie, als das Programm explodierte?” | “Warum willst du das auf diese Art machen?” | “Sie können diese Version nicht auf Ihrem System verwenden.” | “Auch wenn es nicht funktioniert, wie fühlt es sich an?” |
| “Haben Sie Ihr System auf Viren überprüft?” | “Jemand muss meinen Code geändert haben.” | “Es funktioniert, wurde aber nicht getestet.” | “DAS kann nicht die Quelle dieses Moduls in Wochen sein!” | “Ich kann nichts testen!” |
| “Es ist nur ein unglücklicher Zufall.” | “Sie müssen die falsche Version haben.” | “Ich habe dieses Modul seit Wochen nicht mehr berührt.” | “Irgendetwas stimmt nicht mit Ihren Daten.” | “Was hast du falsch eingegeben, dass es abgestürzt ist?” |
| “Es muss ein Hardwareproblem sein.” | “Wie ist das möglich?” | “Gestern hat es geklappt.” | “Das ist noch nie zuvor passiert.” | “Das ist komisch …” |
| “Dies soll in der nächsten Version behoben werden.” | “Ja, wir wussten, dass das passieren würde.” | “Vielleicht unterstützen wir diese Plattform einfach nicht.” | “Es ist eine Funktion. Wir haben die Spezifikationen lediglich nicht aktualisiert.” | “Sicherlich wird niemand das Programm auf diese Weise verwenden.” |
Übrigens haben auch Entwickler ein solches Spiel. Sie erhalten jedes Mal Punkte, wenn ein QA-Mitarbeiter versucht, einen Defekt an einer Funktion zu melden, die wie angegeben funktioniert.
