Mit dem Brettspiel zum Testentwurf

Wie kommt man an Testfälle, an die man sonst nicht denkt? Ein Team hat ein Brettspiel entwickelt, bei dem Spieler durch Einkaufszettel und Artikelkombinationen automatisch reale Testszenarien für komplexe Kassensoftware generieren. Von der Brainstorming-Session mit Schere und Klebstoff bis zum fertigen Prototyp zeigt das Projekt, wie Gamification im Software Testing konkret funktionieren kann – ohne Buzzwords, dafür mit Probespielen, Feedback-Schleifen und der Erkenntnis, dass manchmal natürliche Intelligenz mehr bringt als künstliche.

Podcast Episode: Mit dem Brettspiel zum Testentwurf

In dieser Episode spreche ich mit Ralf Somplatzki über ein Spiel für Softwaretester. Ralf und sein Team haben aus einer Idee ein Brettspiel gemacht, das echte Testfälle erzeugt. Stakeholder ran, Zettel, Eddings, Prototypen, Probespiele. Danach Feinschliff in der Community of Practice. Der Kern: Einkaufszettel Missionen, Einkaufskorb, Ereigniskarten und eine knifflige Checkout Phase mit Promotionen. Am Ende liegen rund 24 Testfälle für die Kassensoftware bereit, Sprint tauglich. Das Spiel ist frisch produziert, die Neugier groß.

In dieser Branche, wer spielt da nicht gerne? Sonst hat man sich verlaufen, glaube ich.” - Ralf Somplatzki

Nach mehr als zwanzig Jahren als Software Entwickler und Architekt fand Ralf Somplatzki über den Weg des Requirements Engineerings zu seiner Passion, dem Software Test. Ihn begeistert es, Neues zu entdecken und Lösungen für Herausforderungen zu finden. In diesem Sinne ist es gerade der Bereich der Software-Qualitätssicherung, der Pioniergeist weckt, wie in den ersten Jahren der Informationstechnologie: “Wir haben so viel zu entdecken und erobern!”. Sein Schwerpunkt liegt auf dem (automatisierten) Systemtest und funktionalem Testen. In der Gebit Solutions GmbH arbeitet er als QA Manager und Coach. Er unterstützt Teams und Kunden dabei, Teststrategien zu entwickeln, sowie Entwicklungs- und Testprozesse im Hinblick auf Produktivität und Qualität zu optimieren.

Highlights der Episode

• Gamification im Testing funktioniert am besten, wenn das Spiel echte Testfälle erzeugt, nicht nur motiviert.
• Interdisziplinäre Teams aus Testern, Requirements Engineers und Marketing bauen bessere Tools als Fachsilos allein.
• Vier halbe Tage Klausur mit Pappe und Edding reichen, um ein funktionsfähiges Testspiel zu entwickeln.
• Keep it simple: Coole Gimmicks wieder rausstreichen, wenn sie Spieler überfordern statt unterstützen.
• Probespielen in Communities of Practice liefert ehrlicheres Feedback als interne Entwicklerrunden.

Spielerisch testen – Wie ein Brettspiel die Softwarequalität verbessert

Spielen in der Softwareentwicklung

Viele denken bei Softwaretests an Checklisten, Standards und Routinen. Ralf und sein Team wollten weg vom Gewohnten. Sie fragten sich: Kann ein Spiel helfen, neue Testfälle zu finden? Gerade da in ihrer Kassen-Software viele Varianten und Sonderfälle auftreten, müssen die Tester immer wieder neu denken. Für die Standardfälle gibt es natürlich Skripte. Doch was ist mit den Besonderheiten, mit den kreativen Fehlern, die später teuer werden?

Ralf erzählt, dass Gamification im Softwarebereich ein Modethema ist, oft aber oberflächlich bleibt. Sein Ansatz war, ein Werkzeug zu bauen, das wirklich hilft. Also nicht nur motivierende Punkte, sondern ein Spiel, das dazu anregt, anders zu denken und so neue Schwachstellen zu finden.

Von der Idee zum Prototyp: Alle spielen mit

Das Team startete klassisch: Ziel definieren, Stakeholder einbeziehen, einen Kick-Off wie bei einem echten Projekt. Ein Vorteil: Eine neue Kollegin aus dem Marketing kam frisch aus der Spielebranche und brachte wertvolles Wissen ein. Jeder brachte seine Lieblingsspiele mit, alles wurde diskutiert – ein echtes Brainstorming.

Sie reservierten eine Woche, teilten sie in Zeitblöcke. Mit Edding auf Pappe und vielen Klebezetteln entstand der Prototyp. Die Mischung der Persönlichkeiten half: Kreative Ideen, prüfende Detailarbeit, kritische Fragen. Alle brachten sich ein. Wichtig war, dass das Spiel am Ende nicht zu kompliziert ist – das Prinzip „Keep it simple“ war ein Kern-Learning im Prozess.

Das Spiel: Vom Einkaufswagen zum Testfall

Ralf beschreibt das Spiel so: Es geht um den Einkauf im Einzelhandel. Das Spielfeld erinnert ein wenig an Trivial Pursuit. Die Spieler ziehen durchs Geschäft, kaufen Artikel, bekommen per Missionskarten (wie ein Einkaufszettel) Aufgaben. Die Artikel landen im eigenen Korb.

Das Clevere: Jede abgeschlossene Mission ist gleichzeitig ein neuer Testfall für die Software. Im Laufe einer Runde entstehen so ungefähr zwei Dutzend verschiedene Testfälle – genug, um einen Entwicklungszyklus kreativ zu prüfen. Am Ende gibt es eine „Promotion-Phase“, in der Sonderaktionen simuliert werden – das, was echte Kassen-Software so komplex macht.

Testlauf in der Praxis: Tester werden zu Spielern

Nach dem Prototyp startete das Team Probepartien. Nicht nur die Entwickler, auch andere Tester im Unternehmen haben das Spiel ausprobiert. Die Regeln wurden vereinfacht, unnötige Gimmicks aussortiert. In verschiedenen Standorten sammelte das Team Feedback. Die Akzeptanz ist groß, viele sind neugierig und sehen direkt den Nutzen: Wer spielt, denkt neue Kombinationen durch und erkennt eher ausgefallene Testfälle, die sonst durchrutschen.

Ein schlauer Trick: Mit einem Labelprinter können reale Produktbarcodes auf die Spielkarten gedruckt werden. So sind die Testdaten immer aktuell.

Blick nach vorn: Von der Firmenidee zum Markt?

Andere Unternehmen wurden aufmerksam. Ob das Spiel auch in anderen Firmen funktioniert, hängt von den eigenen Produkten ab. Geplant ist, die Erfahrungen auszuweiten und das Spiel noch weiter zu testen. Vielleicht wird daraus mal ein kommerzielles Brettspiel. Ralf bleibt vorsichtig optimistisch. Im Vordergrund steht, dass die eigenen Tester Spaß haben und besser testen.

Warum spielerisches Testen uns weiter bringt

Oft sind Kreativität und Neugier die besten Werkzeuge, um komplexe Software stabil zu machen. Das Brettspiel von Ralf und seinem Team zeigt: Wer spielerisch testet, entdeckt mehr. Die Methode verbindet Spaß mit ernstzunehmender Testpraxis. Vielleicht spielt ihr ja beim nächsten Sprint auch eine Runde – und findet Fehler, die ihr anders nie entdeckt hättet.