Gamification in software testing means using game mechanics on purpose to come up with new and varied test cases that testers wouldn’t think of in their day-to-day work. A game board, shopping basket mechanics and event cards take the place of classic test case lists. The point is not to play for its own sake but to have a concrete tool for better test coverage.
Key Takeaways
- Building a game as a testing tool only works if testing is the goal from day one, not the game itself.
- Diverse teams with a requirements engineer, a tester, marketing and domain developers write better game rules, because each role exposes the others’ blind spots.
- Playtesting with real users inevitably leads to simplification: gimmicks that make the game more complicated have to go so players aren’t overwhelmed.
- Each round of the game produces around 24 test cases that can go straight into the next release as a basis for testing.
Gamification in Testing: Why a Board Game Helps
Gamification can lead testers to test cases nobody thinks of in a normal working day. That was the starting point for a board game Gbit Solutions built for testing its checkout software.
The problem: standard cases are covered quickly. Ralf Somplatzki sums it up. The standard cases have all been tested, or they show up on the first day of operation at the latest. The special cases are the hard part.
In checkout software, every item comes with a whole range of workflows. Nobody knows today which item a grandmother will put on the conveyor belt at Aldi tomorrow. So the question was how a team finds varied, new test cases. The answer was not supposed to come from AI but from natural intelligence: from people who play and test at the same time.
The Goal Was a Tool, Not a Game
The design started with a clear objective so the game wouldn’t become an end in itself. The team didn’t set out to invent a game. They wanted a tool that supports specific aspects of testing. That it ended up being a game was simply the means.
That order is the heart of it: first the benefit for testing, then the mechanics. Management gave the green light for the same reason, because the concept would help the projects. If you want to bring gamification into your own testing, answer this question first: which testing problem is the game supposed to solve?
Setting Up a Testing Game like a Project
The design work ran like a classic project, complete with a kickoff and a stakeholder round. On board were a business analyst (or requirements engineer), someone from marketing and a tester, a lineup that deliberately echoes the Three Amigos principle from testing.
The team makeup carried the result. Ralf and his marketing colleague were the creative drivers. The requirements engineer took care of the details: without him, the game would have no clean rules. And a tester kept pointing at the weak spots. There was friction, but it was constructive.
A lucky coincidence helped. A new marketing colleague had come from a games publisher and brought practical tips. Some useful knowledge is freely available anyway, because game publishers explain on their websites how to design games. They are looking for new talent for the next Game of the Year.
The process itself was deliberately low-key:
- A retreat over four half days, in blocks of two to three hours
- Brainstorming ideas, with game collections and favorite games brought along for inspiration
- Cardboard, markers and sticky notes instead of ready-made tools
- Playtesting with scissors, glue and tape, roughly three rounds
Keep It Simple: The Most Important Design Principle
The main lesson from playtesting: keep the rules and mechanics simple. Several clever gimmicks the team was proud of got thrown out again because they made the game more complicated.
The reason is practical. Too many special rules scatter the team’s focus and overwhelm the players. Ongoing feedback from the company’s sites showed that the rules could be made even simpler than first thought.
How the Game Works
At its core, the game produces test cases while you play. Players move across a board, take a few steps and can then go shopping. What they buy are items, which is to say exactly the test data that later gets scanned at the checkout.
Shopping lists that work like mission cards make it fun. In the middle of shopping, someone calls from home: pick up this and that on your way. Complete a mission, and the items go into your shopping basket. Once the basket is full and gets emptied, a test case is done: exactly the combination of items you then scan at a real checkout in the test lab.
Over one round, a whole set of test cases comes together. Ralf puts it at around 24 test cases per round, enough for a release. At the end of a sprint, the team plays a round and then goes testing together.
The Checkout Phase Covers Promotions
The checkout phase at the end of a round covers the tricky promotions. Promotions make checkout software complicated, because every customer brings their own algorithms and ideas, and the system has to handle all of them.
The game solves this with event cards. One card says, for example: buy three specific items and take a fourth one for free. That is how promotions make it into the test scenario, and for the players, the checkout phase is the most exciting moment of the round.
Bringing Your Own Test Data into the Game via Barcode
To let the game work with real data, there is an add-on option with a label printer. It prints barcodes that go on the items, so each site brings in its own item data.
That is the first thing testers ask: how do I get my data in there? Labels and barcodes keep the answer deliberately simple.
The Real Test Is Still to Come
The game has only just been produced, so its practical trial is only beginning. So far it has only been played at the Düsseldorf site, where the groundwork was done. The other sites are just receiving it and can then play it live.
The testers’ community of practice has responded with curiosity and enthusiasm. The decisive proof is still open: whether testers really work with it and get useful test cases out of it. For Ralf, that would be the biggest confirmation, more so than any interest from outside.
The first adjustments mostly concern the rules. There are situations nobody had thought of, such as two players landing on the same square. From the team’s point of view, though, the game already feels mature.
“The biggest confirmation would be if our testers really work with it. I’d find that a good challenge, in our own sandbox.”
(Ralf Somplatzki)
Can Other Teams Use a Game like This?
Partly, because the game is closely tailored to Gbit’s own business. Two other companies have already shown interest. In one case it could fit, because that provider, much like Gbit, works with large retailers whose projects have very different needs.
The game idea itself is abstract and detached from testing. So it could work outside the test department too, for example at home with the family. One thought is to approach a games publisher at some point. If the game works there as well, there would be a market. For now, the focus stays on using it in-house.
Frequently Asked Questions
Why are standard test cases insufficient for software with many variations, such as point-of-sale systems?
Standard cases are quickly covered and become apparent by the first day of operation at the latest. The challenge lies in the edge cases: Behind every item lie highly varied workflows, and no one knows in advance which combination of items a customer will place on the checkout conveyor belt tomorrow. It is precisely for these unforeseen combinations that a test team seeks out new sources.
When does gamification in software testing become an end in itself?
As soon as the game itself becomes the goal. At Gbit Solutions, the objective was clear from the start: a tool that supports specific aspects of testing. The fact that it turned into a board game was merely a means to an end. Anyone who wants to introduce gamification should first identify which testing problem the game is meant to solve, and only then consider the mechanics.
Which roles should be involved in developing a testing game?
A cross-functional team drives the outcome. The team included a business analyst or requirements engineer, someone from marketing, and a tester, based on the Three Amigos principle. The creative minds provided ideas, the requirements engineer established clear rules, and the tester consistently pointed out the weak spots. The friction was intentional and constructive.
How much effort does it take to design a board game as a testing tool?
The effort remained manageable. The team worked in a retreat over four half-days, in blocks of two to three hours each. They worked with cardboard, markers, and sticky notes, not with ready-made tools. In addition, there were about three trial rounds using scissors, glue, and tape. Favorite games that team members brought along served as inspiration.
How many test cases does one round of such a game yield?
About 24 test cases per round, which is sufficient for a release. The players “shop” for items, which become the test data later on. Once the shopping cart is full and emptied, a test case is created: this exact combination of items is then scanned at the checkout in the real-world test environment. At the end of a sprint, the team plays a round and tests the results together afterward.
How can complex special cases, such as discount promotions, be incorporated into a test game?
Through event cards in a separate game phase. Promotions make checkout software complicated because each customer brings their own algorithms and ideas that the system must handle. For example, one card might state: “If you have three specific items, you get a fourth one for free.” For the players, this checkout phase is the most exciting moment of the round.
How can you tell if a gamification approach is truly effective during testing?
Only by seeing whether the testers use it in their day-to-day work and derive useful test cases from it. So far, the game has only been played at the Düsseldorf location, where the preliminary work took place; the other locations received it later. The response within the Community of Practice was curious and positive, but practical proof was still pending at that point.
