Gamification in software testing means using game mechanics in a targeted way to create new and varied test cases that testers would not think of in everyday life. A playing field, shopping basket mechanics and event cards replace classic test case lists. The aim is not a game for the sake of playing, but a concrete tool for more test coverage.
Key Takeaways
- Developing a game as a testing tool only works if the goal is testing from the start, not the game itself.
- Diverse teams of requirements engineers, testers, marketing and specialist developers produce better game rules because each role uncovers blind spots of the others.
- Trying out the game with real users inevitably leads to simplification: Gimmicks that make the game more complicated must be removed so that players are not overwhelmed.
- The game generates around 24 test cases per round, which can be used directly as the basis for the next release.
Why a board game helps with testing
Gamification can help testers come up with test cases that no one thinks of in their normal working day. This was the trigger for a board game that was created at Gbit Solutions for testing checkout software.
The initial situation: standard cases are quickly covered. Ralf Somplatzki puts it in a nutshell: “The standards have all been tested, or they become apparent before the first day of operation at the latest. The special cases are more difficult.
With checkout software, there are a lot of different workflows behind each item. Nobody knows today which article grandma will put on the checkout conveyor belt at Aldi tomorrow. So the question was how a team can get hold of diverse, new test cases. The answer should not come from AI, but from natural intelligence: from people playing and testing.
The goal was a tool, not a game
The design began with a clear objective so that the game idea would not become an end in itself. The team did not want to invent a game, but a tool that would support certain aspects of testing. The fact that the end result was a game was a means to an end.
This order is the core: first the benefit for testing, then the mechanics. The management also gave the green light on the grounds that the concept would help the projects. Anyone who wants to introduce gamification into their own testing should answer this question first: What testing problem is the game supposed to solve?
How to set up a testing game like a project
The design ran like a classic project, including a kick-off and stakeholder meeting. A business analyst or requirements engineer, someone from marketing and a tester were involved. This is deliberately reminiscent of the Re-Amigo principle from testing.
The composition of the team bore fruit. Ralf and the marketing colleague were the proactive and creative minds. The requirements engineer took care of the details: without him, the game would have no clear rules. And a tester consistently put his finger in the wound. Friction in cooperation, but constructive.
A lucky coincidence helped: a new employee in marketing came from a games publisher and gave practical tips. Some of the useful knowledge is out in the open, as game publishers explain how to design games on their websites. They want new talent for the next Game of the Year.
The approach itself was deliberately low-threshold:
- Retreat over four half days, in time blocks of two to three hours
- Brainstorming ideas, using game collections and favorite games brought along as inspiration
- Work with cardboard, sharpies and sticky notes instead of ready-made tools
- Test play with scissors, glue and tape, approximately three rounds
Keep it simple: the most important design principle
The key lesson from the trial game is to keep the rules and mechanics simple. Several clever gimmicks that the team was proud of were thrown out because they made the game more complicated.
The reason is practical. Too many special rules bog down the team and overwhelm the players. Ongoing feedback from the locations showed that the rules could be made even simpler than initially thought.
How the game works
At its core, the game produces test cases as you play it. Players move across a playing field, take a few steps and can then make purchases. Items are purchased, i.e. exactly the test data that is later scanned at the checkout.
Shopping lists, which function like mission cards, provide the playful appeal. In the middle of shopping, a call comes from home: bring this and that. If you complete a mission, you put the items in your shopping basket. Once the basket is full and emptied, a test case is ready: exactly the combination of items that you then scan at the checkout in the real test room.
A whole set of test cases is collected over a round of the game. Ralf gives an order of magnitude of around 24 test cases per round, which is enough for a release. At the end of a sprint, the team takes a spin through the game and then goes testing together.
The checkout phase maps promotions
The competition phase at the end of a round covers the tricky promotions. Promotions make the checkout software complicated because every customer brings their own algorithms and ideas, all of which the system has to master.
The game solves this using event cards. One card says, for example: If you have three specific items, you take a fourth for free. In this way, the topic of promotion moves into the test scenario, and for the players, this checkout phase is the hot, exciting moment of the round.
Your own test data comes into play via barcode
To ensure that the game works with real data, there is an additional option with a label printer. This is used to print barcodes that are stuck onto the items. In this way, each location contributes its own item data.
This is exactly what the testers ask first: How do I get my data in there? The answer via label and barcode is deliberately kept simple.
Real testing is still pending
The game has only recently been produced and is therefore at the beginning of its practical testing. So far, it has only been played at the Düsseldorf site, where the preliminary work was carried out. The other locations are only just receiving it and will then be able to play it live.
The response from the community of practice of testers has been curious and positive. The decisive proof remains to be seen: whether the testers actually work with it and draw useful test cases from it. For Ralf, this would be the greatest confirmation, even more so than requests from outside.
Initial readjustments mainly concern the rules of the game. There are cases that nobody had thought of, such as when two players end up on the same field. From the team’s point of view, however, the game itself already makes a mature impression.
The biggest validation would be if our testers work with it properly. I think that would be a good challenge in our own sandbox.
Ralf Somplatzki
Can a game like this be transferred to other teams?
Partly, because the game is strongly tailored to our own business. Two other companies have already expressed interest. In one case, it could be a good fit because this provider works with different project requirements of large retailers in a similar way to Gbit.
The game idea itself is abstracted and detached from the test context. This means it could also work outside the test department, for example at home with the family. One idea is therefore to ask a games publisher. If the game also works there, there would be a market. For the time being, however, the focus remains on our own use.
