Gamification in software testing refers to the targeted use of playful elements in quality assurance processes to promote motivation, creativity and learning. Concrete formats include riskstorming for risk analysis, bingo-bongo sessions for finding errors before the end of a sprint and maturity poker for joint process maturity assessment. Reward, voluntariness and competition without devaluation are the central design principles.
Key Takeaways
- Gamification in software testing not only increases motivation, but also promotes the swarm intelligence and creativity needed to uncover unexpected risks and edge cases.
- In the Bingo Bongo format, testers shout “Bingo Bongo” when they find a bug, present it to the team and receive a point as soon as the team evaluates the bug ticket as valid.
- Riskstorming combines a board game with ISO quality characteristics and test design methods to help teams identify risks of a test object together instead of having individuals fill FMEA tables alone.
- Maturity Poker transfers the principle of Planning Poker to process improvement: teams assess their own maturity level and set themselves targets, which leads to greater commitment than external assessments.
What gamification means in quality assurance
Gamification brings playful elements into the normal software development process, from requirements analysis to implementation and testing. In the field of quality assurance, it is about motivating people and making their everyday work more varied.
The approach solves two problems at the same time. Firstly, the fun factor: manual testing and deadlocked processes are no fun for anyone in the long run. When work is motivating, it is easier to do and the team works more effectively.
Secondly, gamification makes a contribution in terms of content. Complexity in software systems is growing, interfaces and dependencies are becoming unmanageable. Playful methods promote creativity and swarm intelligence and draw attention to test cases that an individual would not have thought of on their own.
Then there is the learning effect. Children learn by playing, and adults do too. When developers and testers use playful formats to see how someone else works, this knowledge sticks better.
Why creativity prevents real mistakes
Playful thinking uncovers edge cases that get lost in standard planning. An example from the media: A Spanish railroad company ordered fast trains. After delivery, it turned out that the trains did not fit through two tunnels in northern Spain. As a result, the project was postponed for two years and many personnel changes were made, right up to ministry level.
The question is: which test design process makes you think about train size and tunnel size together as early as the design phase? This is exactly the thinking process that happens in gaming: where to go left, where to go right, where to bump into things to reach a certain level. Software testing also needs this creativity.
Riskstorming: risk analysis as a board game
Riskstorming is a board game that structures the risk analysis for a test object. The test object, be it a small module or a large IT system with many interfaces, is placed in the middle of the board. This creates a common understanding of what is being discussed.
Traditionally, risks would be recorded using an FMEA method: a large table with risk, probability and extent of damage. This is dry and everyone fills their own table.
Instead, the game provides a systematic approach and a set of cards based on the ISO quality model. It runs in several phases:
| Phase | Content |
|---|---|
| Selection | Define up to six quality characteristics using cards |
| Analysis | Collect risk ideas for these characteristics |
| Measures | Find suitable test techniques using card material |
For the card material, the game suggests test design methods that are known from the ISTQB context: Equivalence partitions, A/B testing, test automation, performance testing. Even if you don’t have a technique to hand, the cards will give you ideas and get you talking about heuristics.
The playful element is in the risk collection phase. It becomes a challenge: who has identified the best risk? This is exactly what motivates the players to get creative and think of the two tunnels in northern Spain.
Reward is not the most important part of the game
A reward should not be missing in gamification, but it is secondary. What is effective is the winning aspect itself. Finding the biggest risk prevents the project from running into that risk, and that is already reward enough.
If something is added, a little something is enough: a voucher, a meal together, a trophy or, in the past, a surprise egg for the best tester in a session. The greater effect is created by the feeling of having found a mistake and receiving recognition for it.
It is important that the competition unites rather than divides. Teams should work together, not against each other. The team that has contributed the most is highlighted. The others are not worse, they have just contributed less, and every team moves forward.
How a bingo-bongo session raises product quality
In a bingo bongo session, the team tests together for an hour at the end of a sprint to improve product quality. All participants work on the same features in the same environment. Participation is voluntary.
Anyone who finds or suspects a bug calls out “Bingo Bongo” and presents their finding to everyone. They explain why they think it is a bug and the team votes. Only those who create a bug ticket that is not a known problem and that the team wants to fix together get the point.
The format primarily uncovers error clusters. Where one person finds a bug, the others take a closer look and often find more. By presenting them, everyone can see how someone else is testing and incorporate edge cases into their automated tests.
Ideally, the session takes place in every sprint, scheduled shortly before the end of the sprint. If the delivery is on Monday, a session on Thursday is suitable, then there is still time to fix the serious problems.
The increase in efficiency is evident when compared to the traditional approach. In the past, a tester found a defect, created a ticket and assigned it to the developer. Then the back and forth began: log files were missing, screenshots were missing, the path to the error was unclear. With Bingo Bongo, the developer is there live, sees the defect and can tell you where to click.
People, come together, put your heads together, think about it and have a bit of fun.
- Baris Güldali
Maturity Poker: Process quality without an external auditor
Maturity Poker transfers the principle of Planning Poker to process quality. In Planning Poker, a team agrees on the complexity of a requirement using Fibonacci numbers or T-shirt sizes. Maturity Poker uses the same internal coordination to assess its own level of maturity and plan improvement steps.
The advantage over an external assessment lies in the self-determination. An assessment has negative connotations, the assessor requests documents and e-mails, and the result often ends up in a drawer. In Maturity Poker, the team evaluates itself and sets its own goals.
The process follows several steps. First, the team clarifies its pain points and areas for action. Anyone introducing agile practices should know why: if you want shorter release cycles, you can introduce sprints; if you want to integrate customers more closely, involve them in reviews.
The team then evaluates itself. Poker cards are used to ask: How good are we at refining user stories, estimating and test automation? The scale is based on CMMI-like models, from Initiated to Managed to Optimized. Where the views of the team members differ, a point of discussion arises: Why does one person see the practice as lived, while the other does not?
In the third step, the team sets itself goals and prioritizes them again using cards. Those who analyze themselves and set their own goals are more committed than those who are forced to do so.
Making maturity levels visible in team competition
In an offshore project with several teams, Maturity Poker was used to close large gaps in test methods, test automation and CI/CD pipelines. The teams competed against each other across defined levels: Level 1 meant test automation in place but no code coverage measured; higher levels required coverage and good code quality.
The teams were sent trophies from Germany, and some even entered the Quality Challenge they had achieved in their LinkedIn profile. The maturity board is part of the team charter and remains visible so that the team can see where they were six months ago and where they are today.
The Optimized Level is reached when a practice becomes a no-brainer. Nobody questions it anymore, the team sees clear benefits, works faster and more predictably and no longer wants to do without it.
Game fatigue is real, and you should react to it
If a format itself becomes a deadlocked process, it has missed its target. Criticism comes from two directions: Team members lose interest, or management asks how capacity is being burned here. In the end, a format must have a recognizable added value for the product and the work.
The solution is to be tactful rather than rigid. A scrum master, quality coach or agile expert should observe the energy in the team and react in a similar way to how a speaker recognizes when the audience’s attention is shifting.
A practical example: In one project, fewer and fewer people were taking part in the bingo-bongo sessions because developing was more important to them. The format was paused. After two or three months, the first developers came back of their own accord and wanted another session, and the enthusiasm was back.
Sometimes gamification can also be introduced through the back door. In a retrospective based on disruptor cards, each team member secretly picked a card and tried to play the meeting disruptor described on it. The retro leader had to guess who was being disruptive. Some played along, others found no opportunity, and the meeting was immediately interrupted with the first disruptor card played.
What you need to pay attention to when introducing
Gamification formats need a suitable environment, and the framework conditions determine their success. Three stumbling blocks are particularly common in large corporations.
- Management: It must accept such formats, give them freedom and value them. It is best if a department or division manager playstest it themselves. Senior managers often know the systems amazingly well in detail and bring real added value.
- Works council: As soon as a game generates personal evaluations, such as points per person, the works council can have a say. You should ask for permission in advance.
- Regulation: In highly regulated environments such as large banks, processes and supervisory authorities set limits that you need to be aware of.
Even if the team agrees to a personal evaluation, further constraints may come from above. Anyone introducing gamification should therefore first check their environment before handing out points.
Where you can find and contribute ideas
There is not yet a ready-made collection of gamification games for quality assurance. As a basis, there is a three-part series of articles in Java magazine on the three aspects of product quality, process quality and risk management.
In addition, there is a set of slides with around ten to twelve games, each explained on four to five slides with visualizations. It has grown over several presentations at German Testing Day, IT-Tage, OOP and TAV. A book project as a lean pub project has been created, but has not yet been completed.
Such formats thrive on interaction. The idea of combining the riskstorming element with his co-innovation approach arose from an exchange with the inventor of the QA Navigation Board at Zeiss. Anyone who has tried out their own games or wants to contribute new ideas can write to Dehla Sokenou and Baris Güldali directly and receive the set of slides in return.
