Gamification im Softwaretest bedeutet, Spielmechaniken gezielt einzusetzen, um neue und vielfältige Testfälle zu erzeugen, an die Tester im Alltag nicht denken würden. Ein Spielfeld, Einkaufskorb-Mechaniken und Ereigniskarten ersetzen dabei klassische Testfall-Listen. Ziel ist kein Spiel um des Spielens willen, sondern ein konkretes Hilfsmittel für mehr Testabdeckung.
Das Wichtigste in Kürze
- Ein Spiel als Testwerkzeug zu entwickeln funktioniert nur, wenn das Ziel von Anfang an das Testen ist, nicht das Spiel selbst.
- Diverse Teams aus Requirements Engineer, Tester, Marketing und Fachentwicklung produzieren bessere Spielregeln, weil jede Rolle blinde Flecken der anderen aufdeckt.
- Probespielen mit echten Nutzern führt zwingend zum Vereinfachen: Gimmicks, die das Spiel komplizierter machen, müssen raus, damit Spieler nicht überfordert werden.
- Das Spiel erzeugt pro Runde rund 24 Testfälle, die direkt als Grundlage für das nächste Release genutzt werden können.
Warum ein Brettspiel beim Testen hilft
Gamification kann Testern dabei helfen, auf Testfälle zu kommen, an die im normalen Arbeitsalltag niemand denkt. Genau das war der Auslöser für ein Brettspiel, das bei der Gbit Solutions für den Test von Kassensoftware entstanden ist.
Die Ausgangslage: Standardfälle sind schnell abgedeckt. Ralf Somplatzki bringt es auf den Punkt: Die Standards hat man alle abgetestet, oder sie fallen spätestens vor der Inbetriebnahme am ersten Tag auf. Schwieriger sind die Sonderfälle.
Bei Kassensoftware hängt hinter jedem Artikel eine Menge variantenreicher Workflows. Niemand weiß heute, welchen Artikel die Oma morgen bei Aldi aufs Kassenband legt. Die Frage war also, wie ein Team an vielfältige, neuere Testfälle kommt. Die Antwort sollte nicht aus KI kommen, sondern aus natürlicher Intelligenz: aus Menschen, die spielen und dabei testen.
Das Ziel war ein Hilfsmittel, kein Spiel
Der Entwurf begann mit einer klaren Zielvorgabe, damit die Spielidee nicht zum Selbstzweck wird. Das Team wollte kein Spiel erfinden, sondern ein Hilfsmittel, das beim Testen bestimmte Aspekte unterstützt. Dass am Ende ein Spiel dabei herauskam, war Mittel zum Zweck.
Diese Reihenfolge ist der Kern: erst der Nutzen fürs Testen, dann die Mechanik. Auch die Geschäftsleitung gab grünes Licht mit der Begründung, das Konzept werde den Projekten helfen. Wer Gamification im eigenen Test einführen will, sollte diese Frage zuerst beantworten: Welches Testproblem soll das Spiel lösen?
Wie man ein Test-Spiel wie ein Projekt aufsetzt
Der Entwurf lief wie ein klassisches Projekt, inklusive Kick-off und Stakeholder-Runde. Mit dabei waren ein Business Analyst beziehungsweise Requirements Engineer, jemand aus dem Marketing und ein Tester. Das erinnert bewusst an das Re-Amigo-Prinzip aus dem Testen.
Die Teamzusammensetzung trug das Ergebnis. Ralf und der Marketing-Kollege waren die initiativ-kreativen Köpfe. Der Requirements Engineer sorgte für die Details: Ohne ihn hätte das Spiel keine sauberen Regeln. Und ein Tester legte konsequent den Finger in die Wunde. Reibung im Miteinander, aber konstruktiv.
Ein glücklicher Zufall half: Eine neue Mitarbeiterin im Marketing kam aus einem Spieleverlag und gab praktische Tipps. Brauchbares Wissen liegt teils offen herum, denn Spielehersteller erklären auf ihren Webseiten, wie man Spiele entwirft. Sie wollen Nachwuchs für das nächste Spiel des Jahres.
Das Vorgehen selbst war bewusst niedrigschwellig:
- Klausur über vier halbe Tage, in Zeitblöcken von zwei bis drei Stunden
- Brainstorming der Ideen, dazu mitgebrachte Spielesammlungen und Lieblingsspiele als Inspiration
- Arbeit mit Pappe, Edding und Klebezetteln statt mit fertigen Tools
- Probespielen mit Schere, Klebstoff und Tesafilm, ungefähr drei Runden
Keep it simple: das wichtigste Designprinzip
Die zentrale Lektion aus dem Probespielen lautet, Regeln und Mechanik einfach zu halten. Mehrere clevere Gimmicks, auf die das Team stolz war, flogen wieder raus, weil sie das Spiel komplizierter machten.
Der Grund ist praktisch. Zu viele Sonderregeln verzetteln das Team und überfordern die Spieler. Im laufenden Feedback aus den Standorten zeigte sich, dass die Regeln sogar noch einfacher gemacht werden konnten, als zunächst gedacht.
So funktioniert das Spiel
Im Kern produziert das Spiel Testfälle, während man es spielt. Spieler bewegen sich über ein Spielfeld, machen ein paar Schritte und können dann einkaufen. Gekauft werden Artikel, also genau die Testdaten, die später an der Kasse gescannt werden.
Den spielerischen Reiz liefern Einkaufszettel, die wie Missionskarten funktionieren. Mitten im Einkauf kommt der Anruf von zu Hause: bring noch dies und das mit. Wer eine Mission erfüllt, legt die Artikel in seinen Einkaufskorb. Ist der Korb voll und wird geleert, ist ein Testfall fertig: genau die Artikelkombination, die man danach im realen Testraum an der Kasse scannt.
Über eine Spielrunde sammelt sich so ein ganzes Set an Testfällen. Ralf nennt eine Größenordnung von rund 24 Testfällen pro Runde, was für ein Release reicht. Am Ende eines Sprints dreht das Team eine Runde durch das Spiel und geht dann gemeinsam testen.
Die Checkout-Phase bildet Promotionen ab
Die Wettbewerbsphase am Ende einer Runde deckt die kniffligen Werbeaktionen ab. Promotionen machen die Kassensoftware kompliziert, weil jeder Kunde eigene Algorithmen und Ideen mitbringt, die das System alle beherrschen muss.
Das löst das Spiel über Ereigniskarten. Eine Karte sagt zum Beispiel: Wer drei bestimmte Artikel hat, nimmt einen vierten gratis mit. So wandert das Thema Promotion ins Testszenario, und für die Spieler ist diese Checkout-Phase der heiße, spannende Moment der Runde.
Eigene Testdaten kommen per Barcode ins Spiel
Damit das Spiel mit realen Daten arbeitet, gibt es eine Zusatzoption mit einem Label-Printer. Damit werden Barcodes gedruckt, die man auf die Artikel klebt. So bringt jeder Standort seine eigenen Artikeldaten ein.
Genau das fragen die Tester als Erstes: Wie kriege ich meine Daten da rein? Die Antwort über Label und Barcode ist bewusst einfach gehalten.
Echte Bewährung steht noch aus
Das Spiel ist erst seit kurzem produziert und damit am Anfang seiner praktischen Erprobung. Bisher wurde es nur am Standort Düsseldorf gespielt, wo die Vorarbeit lief. Die übrigen Standorte erhalten es gerade erst und können dann live spielen.
Die Resonanz in der Community of Practice der Tester ist neugierig und positiv. Offen ist der entscheidende Beweis: ob die Tester real damit arbeiten und daraus brauchbare Testfälle ziehen. Für Ralf wäre genau das die größte Bestätigung, mehr noch als Anfragen von außen.
Erste Nachjustierungen betreffen vor allem die Spielregeln. Es gibt Fälle, an die niemand gedacht hatte, etwa wenn zwei Spieler auf demselben Feld landen. Das Spiel selbst macht aus Sicht des Teams aber bereits einen ausgereiften Eindruck.
Die größte Bestätigung wäre, wenn unsere Tester richtig damit arbeiten. Das fände ich eine gute Herausforderung, im eigenen Sandkasten.
Ralf Somplatzki
Lässt sich so ein Spiel auf andere Teams übertragen?
Teilweise, denn das Spiel ist stark auf das eigene Geschäft zugeschnitten. Zwei andere Firmen haben bereits Interesse angemeldet. In einem Fall könnte es passen, weil dieser Anbieter ähnlich wie Gbit mit unterschiedlichen Projektbedarfen großer Retailer arbeitet.
Die Spielidee selbst ist abstrahiert und vom Testkontext gelöst. Dadurch könnte sie auch außerhalb der Testabteilung funktionieren, etwa zu Hause mit der Familie. Ein Gedanke ist deshalb, einmal bei einem Spieleverlag nachzufragen. Funktioniert das Spiel auch dort, gäbe es einen Markt. Vorerst bleibt der Fokus aber auf dem eigenen Einsatz.
