Gamification im Test

Gamification im Software-Testing bezeichnet den gezielten Einsatz spielerischer Elemente in Qualitätssicherungsprozessen, um Motivation, Kreativität und Lernen zu fördern. Konkrete Formate sind Riskstorming zur Risikoanalyse, Bingo-Bongo-Sessions zum Fehler­finden vor Sprint-Ende und Maturity Poker zur gemeinsamen Prozessreifebewertung. Belohnung, Freiwilligkeit und Wettbewerb ohne Abwertung gelten dabei als zentrale Gestaltungsprinzipien.

Das Wichtigste in Kürze

• Gamification im Softwaretest steigert nicht nur die Motivation, sondern fördert gezielt Schwarmintelligenz und Kreativität, die nötig sind, um unerwartete Risiken und Randfälle aufzudecken.
• Beim Bingo-Bongo-Format rufen Tester “Bingo Bongo”, wenn sie einen Fehler finden, präsentieren ihn dem Team und bekommen einen Punkt, sobald das Team das Bug-Ticket als gültig bewertet.
• Riskstorming kombiniert ein Brettspiel mit ISO-Qualitätsmerkmalen und Testentwurfsmethoden, damit Teams gemeinsam Risiken eines Testobjekts identifizieren, anstatt Einzelpersonen einsam FMEA-Tabellen befüllen zu lassen.
• Maturity Poker überträgt das Prinzip des Planning Poker auf Prozessverbesserung: Teams bewerten ihren eigenen Reifegrad und setzen sich selbst Ziele, was zu stärkerem Commitment führt als externe Assessments.

Was Gamification in der Qualitätssicherung bedeutet

Gamification bringt spielerische Elemente in den normalen Softwareentwicklungsprozess, von der Anforderungsanalyse über die Implementierung bis zum Testen. Im Bereich Qualitätssicherung geht es darum, Menschen zu motivieren und ihren Arbeitsalltag abwechslungsreicher zu gestalten.

Der Ansatz löst zwei Probleme gleichzeitig. Erstens den Spaßfaktor: Manuelles Testen und festgefahrene Prozesse machen auf Dauer niemandem Freude. Wenn Arbeit motiviert, geht sie leichter von der Hand, und das Team arbeitet effektiver.

Zweitens leistet Gamification einen inhaltlichen Beitrag. Komplexität in Softwaresystemen wächst, Schnittstellen und Abhängigkeiten werden unüberschaubar. Spielerische Methoden fördern Kreativität und Schwarmintelligenz und lenken die Aufmerksamkeit auf Testfälle, auf die ein Einzelner allein nicht gekommen wäre.

Dazu kommt der Lerneffekt. Kinder lernen durch Spielen, und auch Erwachsene tun das. Wenn Entwickler und Tester über spielerische Formate voneinander sehen, wie jemand anders vorgeht, bleibt dieses Wissen besser hängen.

Warum Kreativität echte Fehler verhindert

Spielerisches Denken deckt Randfälle auf, die in der Standardplanung untergehen. Ein Beispiel aus den Medien: Eine spanische Bahngesellschaft gab schnelle Züge in Auftrag. Nach der Lieferung stellte sich heraus, dass die Züge durch zwei Tunnel in Nordspanien nicht passten. Die Folge waren zwei Jahre Projektverschiebung und viele Personalwechsel bis hinauf zur Ministeriumsebene.

Die Frage lautet: Welches Testentwurfsverfahren bringt einen schon in der Designphase dazu, Zuggröße und Tunnelgröße zusammen zu denken? Beim Zocken passiert genau dieser Denkprozess, wo links, wo rechts, wo stößt man an, damit ein Level erreicht wird. Diese Kreativität braucht auch das Software-Testen.

Riskstorming: Risikoanalyse als Brettspiel

Riskstorming ist ein Brettspiel, das die Risikoanalyse für ein Testobjekt strukturiert. In die Mitte des Bretts kommt das Testobjekt, sei es ein kleines Modul oder ein großes IT-System mit vielen Schnittstellen. So entsteht ein gemeinsames Verständnis darüber, worüber überhaupt gesprochen wird.

Klassisch würde man Risiken über eine FMEA-Methode erfassen: eine große Tabelle mit Risiko, Wahrscheinlichkeit und Schadensausmaß. Das ist trocken, und jeder füllt seine Tabelle für sich allein.

Das Spiel bringt stattdessen Systematik und ein Kartenset auf Basis des ISO-Qualitätsmodells mit. Es läuft in mehreren Phasen ab:

Beim Kartenmaterial schlägt das Spiel Testentwurfsmethoden vor, die aus dem ISTQB-Kontext bekannt sind: Äquivalenzklassen, A/B-Testing, Testautomatisierung, Performance-Test. Auch wer eine Technik nicht parat hat, bekommt durch die Karten Impulse und kommt über Heuristiken ins Gespräch.

Das spielerische Element steckt in der Risikosammelphase. Sie wird zur Challenge: Wer hat das beste Risiko erkannt? Genau das motiviert die Spieler, kreativ zu werden und an die zwei Tunnel in Nordspanien zu denken.

Belohnung ist nicht das Wichtigste am Spiel

Eine Belohnung sollte bei Gamification nicht fehlen, ist aber zweitrangig. Wirksam ist der Gewinneraspekt selbst. Wer das größte Risiko findet, verhindert damit, dass das Projekt in dieses Risiko hineinläuft, und das ist bereits Belohnung genug.

Wenn etwas dazukommt, reicht eine Kleinigkeit: ein Gutschein, ein gemeinsames Essen, ein Pokal oder früher ein Überraschungsei für den besten Tester einer Session. Den größeren Effekt erzeugt das Gefühl, einen Fehler gefunden und dafür Anerkennung bekommen zu haben.

Wichtig ist, dass der Wettbewerb verbindet statt trennt. Teams sollten miteinander arbeiten, nicht gegeneinander. Hervorgehoben wird das Team, das am meisten beigetragen hat. Die anderen sind nicht schlechter, sie haben nur weniger beigetragen, und jedes Team geht vorwärts.

Wie eine Bingo-Bongo-Session die Produktqualität hebt

Bei einer Bingo-Bongo-Session testet das Team gemeinsam eine Stunde lang am Ende eines Sprints, um die Produktqualität zu verbessern. Alle Teilnehmer arbeiten auf derselben Umgebung an denselben Features. Die Teilnahme ist freiwillig.

Wer einen Fehler findet oder vermutet, ruft “Bingo Bongo” und präsentiert sein Finding vor allen. Er erklärt, warum er es für einen Fehler hält, und das Team stimmt ab. Den Punkt bekommt nur, wer ein Bug-Ticket anlegt, das kein bekanntes Problem ist und das das Team gemeinsam beheben will.

Das Format deckt vor allem Fehlercluster auf. Wo einer einen Fehler findet, schauen die anderen genauer hin und finden dort oft weitere. Durch das Präsentieren sehen alle, wie jemand anders testet, und übernehmen Randfälle in ihre automatisierten Tests.

Idealerweise findet die Session in jedem Sprint statt, terminiert kurz vor dem Sprintende. Liegt die Auslieferung am Montag, passt eine Session am Donnerstag, dann bleibt noch Zeit, die schwerwiegenden Probleme zu beheben.

Der Effizienzgewinn zeigt sich im Vergleich zum klassischen Vorgehen. Früher fand ein Tester einen Defekt, legte ein Ticket an und wies es dem Entwickler zu. Dann begann das Hin und Her: Logfiles fehlten, Screenshots fehlten, der Weg zum Fehler war unklar. Beim Bingo Bongo ist der Entwickler live dabei, sieht den Fehlerzustand und kann selbst sagen, wo man hinklicken soll.

Leute, kommt zusammen, steckt Köpfe zusammen, macht euch Gedanken und habt ein bisschen Spaß dabei.

— Baris Güldali

Maturity Poker: Prozessqualität ohne externen Auditor

Maturity Poker überträgt das Prinzip von Planning Poker auf die Prozessqualität. Beim Planning Poker einigt sich ein Team über Fibonacci-Zahlen oder T-Shirt-Größen auf die Komplexität einer Anforderung. Maturity Poker nutzt dieselbe interne Abstimmung, um den eigenen Reifegrad zu bewerten und Verbesserungsschritte zu planen.

Der Vorteil gegenüber einem externen Assessment liegt in der Selbstbestimmung. Ein Assessment ist negativ belegt, der Assessor fordert Dokumente und E-Mails an, und das Ergebnis landet oft in der Schublade. Beim Maturity Poker bewertet sich das Team selbst und setzt sich selbst Ziele.

Der Ablauf folgt mehreren Schritten. Zuerst klärt das Team seine Pain Points und Handlungsfelder. Wer agile Praktiken einführt, sollte wissen warum: Wer kürzere Release-Zyklen will, kann Sprints einführen; wer Kunden näher anbinden will, bindet sie in Reviews ein.

Danach bewertet sich das Team selbst. Über Pokerkarten wird gefragt: Wie gut sind wir bei der Verfeinerung von User Stories, beim Schätzen, bei der Testautomatisierung? Die Skala lehnt sich an CMMI-ähnliche Modelle an, von Initiated über Managed bis Optimized. Wo die Sichten der Teammitglieder auseinandergehen, entsteht ein Diskussionspunkt: Warum sieht der eine die Praktik als gelebt, der andere nicht?

Im dritten Schritt setzt sich das Team Ziele und priorisiert sie wieder per Karten. Wer sich selbst analysiert und selbst Ziele gesetzt hat, committet sich stärker, als wenn er dazu genötigt wird.

Reifegrade im Teamwettbewerb sichtbar machen

In einem Offshore-Projekt mit mehreren Teams diente Maturity Poker dazu, große Lücken in Testmethoden, Testautomatisierung und CI/CD-Pipelines zu schließen. Über definierte Levels traten die Teams gegeneinander an: Level 1 bedeutete Testautomatisierung vorhanden, aber keine Code Coverage messen; höhere Level erforderten Coverage und gute Codequalität.

Die Teams bekamen Pokale aus Deutschland zugeschickt, und einige trugen die erreichte Quality Challenge sogar in ihr LinkedIn-Profil ein. Das Maturity-Board gehört zum Team-Charter und bleibt sichtbar, damit das Team sieht, wo es vor einem halben Jahr stand und wo es heute steht.

Das Optimized Level ist erreicht, wenn eine Praktik zum Selbstläufer wird. Niemand stellt sie mehr in Frage, das Team sieht klare Vorteile, arbeitet schneller und planbarer und will nicht mehr darauf verzichten.

Spielmüdigkeit ist real, und du solltest darauf reagieren

Wenn ein Format selbst zum festgefahrenen Prozess wird, hat es sein Ziel verfehlt. Kritik kommt aus zwei Richtungen: Teammitglieder verlieren die Lust, oder das Management fragt, wie hier Kapazität verbrannt wird. Ein Format muss am Ende einen erkennbaren Mehrwert für Produkt und Arbeit haben.

Die Lösung ist Fingerspitzengefühl statt Festhalten. Ein Scrum Master, Quality Coach oder Agile Experte sollte die Energie im Team beobachten und reagieren, ähnlich wie ein Speaker an den Augen des Publikums erkennt, wann die Aufmerksamkeit kippt.

Ein praktisches Beispiel: In einem Projekt nahmen immer weniger Leute an den Bingo-Bongo-Sessions teil, weil ihnen das Entwickeln wichtiger war. Das Format wurde pausiert. Nach zwei, drei Monaten kamen die ersten Entwickler von selbst zurück und wollten wieder eine Session, und der Elan war zurück.

Manchmal lässt sich Gamification auch durch die Hintertür einbringen. In einer Retrospektive auf Basis von Störerkarten suchte sich jedes Teammitglied heimlich eine Karte und versuchte, den darauf beschriebenen Meeting-Störer zu spielen. Der Retro-Leiter musste erraten, wer gerade stört. Einige spielten mit, andere fanden keine Gelegenheit, und das Meeting wurde sofort mit der ersten ausgespielten Störerkarte unterbrochen.

Worauf du beim Einführen achten musst

Gamification-Formate brauchen ein passendes Umfeld, und die Rahmenbedingungen entscheiden über den Erfolg. Drei Stolpersteine treten besonders in großen Konzernen auf.

• Management: Es muss solche Formate akzeptieren, Freiraum geben und sie wertschätzen. Am besten spielt ein Abteilungs- oder Bereichsleiter selbst einmal mit. Höhere Manager kennen die Systeme oft erstaunlich gut im Detail und bringen echten Mehrwert ein.
• Betriebsrat: Sobald ein Spiel persönliche Auswertungen erzeugt, etwa Punkte pro Person, kann der Betriebsrat ein Wort mitreden. Hier sollte man vorab um Erlaubnis bitten.
• Regulatorik: In stark regulierten Umfeldern wie bei Großbanken setzen Prozesse und Aufsichtsbehörden Grenzen, die man kennen muss.

Selbst wenn das Team einer persönlichen Auswertung zustimmt, können von oben weitere Constraints kommen. Wer Gamification einführt, prüft daher zuerst sein Umfeld, bevor er Punkte verteilt.

Wo du Ideen findest und beitragen kannst

Eine fertige Sammlung von Gamification-Spielen für die Qualitätssicherung gibt es bislang nicht. Als Grundlage existiert eine dreiteilige Artikelserie im Java-Magazin zu den drei Aspekten Produktqualität, Prozessqualität und Risikomanagement.

Dazu kommt ein Foliensatz mit rund zehn bis zwölf Spielen, jeweils auf vier bis fünf Folien mit Visualisierungen erläutert. Er ist über mehrfache Vorträge auf German Testing Day, IT-Tagen, OOP und TAV gewachsen. Ein Buchprojekt als Lean-Pub-Vorhaben ist angelegt, aber noch nicht gefüllt.

Solche Formate leben von Interaktion. Aus dem Austausch mit dem Erfinder des QA Navigation Boards der Firma Zeiss entstand die Idee, das Riskstorming-Element mit dessen Co-Innovation-Ansatz zu verbinden. Wer eigene Spiele erprobt hat oder neue Ideen beitragen will, kann Dehla Sokenou und Baris Güldali direkt anschreiben und bekommt im Gegenzug den Foliensatz zugeschickt.