Using the board game for test design

How do you come up with test cases that you wouldn’t otherwise think of? A team has developed a board game in which players use shopping lists and item combinations to automatically generate real test scenarios for complex checkout software. From the brainstorming session with scissors and glue to the finished prototype, the project shows how gamification can actually work in software testing - without buzzwords, but with test games, feedback loops and the realization that sometimes natural intelligence is more effective than artificial intelligence.

Podcast Episode: Using the board game for test design

In this episode, I talk to Ralf Somplatzki about a game for software testers. Ralf and his team have turned an idea into a board game that generates real test cases. Stakeholders, notes, eddings, prototypes, test games. Then fine-tuning in the community of practice. The core: shopping list missions, shopping basket, event cards and a tricky checkout phase with promotions. At the end, there are around 24 test cases for the checkout software, ready for Sprint. The game is freshly produced, curiosity is high.

In this industry, who doesn’t like to play? Otherwise you get lost, I think.” - Ralf Somplatzki

After more than twenty years as a software developer and architect, Ralf Somplatzki found his passion, software testing, via the path of requirements engineering. He is enthusiastic about discovering new things and finding solutions to challenges. In this sense, it is precisely the area of software quality assurance that awakens a pioneering spirit, as in the early years of information technology: “We have so much to discover and conquer!”. His focus is on (automated) system testing and functional testing. At Gebit Solutions GmbH, he works as a QA manager and coach. He supports teams and customers in developing test strategies and optimizing development and test processes in terms of productivity and quality.

Highlights der Episode

• Gamification in testing works best when the game creates real test cases, not just motivates them.
• Interdisciplinary teams of testers, requirements engineers and marketing build better tools than silos of specialists alone.
• Four half-days of closed sessions with cardboard and a sharpie are enough to develop a functional test game.
• Keep it simple: Remove cool gimmicks if they overtax players instead of supporting them.
• Playtesting in communities of practice provides more honest feedback than internal development rounds.

Playful testing - How a board game improves software quality

Playing in software development

When it comes to software testing, many people think of checklists, standards and routines. Ralf and his team wanted to get away from the familiar. They asked themselves: Can a game help to find new test cases? As there are many variants and special cases in their POS software, the testers have to keep thinking in new ways. Of course, there are scripts for the standard cases. But what about the special cases, the creative errors that become expensive later on?

Ralf explains that gamification is a fashionable topic in the software sector, but often remains superficial. His approach was to build a tool that really helps. So not just motivating points, but a game that encourages you to think differently and thus find new weak points.

From the idea to the prototype: everyone plays along

The team got off to a classic start: defining the goal, involving stakeholders, a kick-off like a real project. One advantage: a new colleague from marketing came fresh from the games industry and contributed valuable knowledge. Everyone brought along their favorite games and everything was discussed - a real brainstorming session.

They reserved a week and divided it into blocks of time. The prototype was created with sharpies on cardboard and lots of sticky notes. The mix of personalities helped: creative ideas, scrutinizing detailed work, critical questions. Everyone got involved. It was important that the game was not too complicated in the end - the principle of “keep it simple” was a core learning in the process.

The game: From shopping cart to test case

Ralf describes the game as follows: “It’s about shopping in retail. The playing field is somewhat reminiscent of Trivial Pursuit. The players move through the store, buy items and are given tasks via mission cards (like a shopping list). The items end up in their own basket.

The clever thing is that each completed mission is also a new test case for the software. In the course of a round, around two dozen different test cases are created - enough to creatively test a development cycle. At the end, there is a “promotion phase” in which special actions are simulated - what makes real cash register software so complex.

Test run in practice: Testers become players

After the prototype, the team started test games. Not only the developers, but also other testers in the company tried out the game. The rules were simplified and unnecessary gimmicks were eliminated. The team collected feedback at various locations. Acceptance is high, many are curious and immediately see the benefits: Those who play think through new combinations and are more likely to recognize unusual test cases that would otherwise slip through.

A clever trick: real product barcodes can be printed on the playing cards using a label printer. This means that the test data is always up to date.

Looking ahead: From the company idea to the market?

Other companies have taken notice. Whether the game also works in other companies depends on their own products. The plan is to expand the experience and test the game even further. Perhaps it will one day become a commercial board game. Ralf remains cautiously optimistic. The main thing is that the company’s own testers have fun and test better.

Why playful testing takes us further

Creativity and curiosity are often the best tools for making complex software stable. Ralf and his team’s board game shows this: Those who test in a playful way discover more. The method combines fun with serious testing practice. Maybe you’ll play a round at the next sprint - and find errors that you would never have discovered otherwise.