You hear this word pretty often these days „Gamification“. It basically means to awaken the joy of buried lightheartedness of childhood, where you just learn by playing. Well, there are other definitions out there, for example in Wikipedia: “Gamification is the application of game-design elements and game principles in non-game contexts.[1][2] Gamification commonly employs game design elements[1][2][3][4] which are used in non-game contexts to improve (…) user engagement and learning.” Another definition has been formulated in an article by Cognizant as “it is a fun, outcome-based process of employing “game” elements and techniques to engage employees, reward and recognize individuals and keep people motivated to achieve end results.” Cognizant has put up a framework for gamification in the above-mentioned article – which is supposed to help to understand when gamification can be successfully used and which elements would be relevant for the situation. One of the gamification tools often implemented involves badges and levels and other extrinsic stipulation to keep players motivated to continue playing and to also compete with each other.
You will be able to find very many different approaches, and many companies have started employing gamification techniques in order to achieve results of many different kinds. Most of the time you will find “innovation” as one of the targets, but also “learning” is commonly mentioned.
As quality assurance is all about learning, we were wondering at the StugHH (Software test user group Hamburg) if you can also improve your QA learning using gamification techniques. As we were exploring the possibilities, we went to try out different games with different objectives.
The QA Games
In preparation, the moderation team of the StugHH (Lars Scharrenberg, Maik Nogens and myself) picked a few games with different learning objectives and also different approaches. We found most games on different websites where also the details are explained. So please go there for further reference. We started the evening with a joint game (Jargon Bust) and then players (overall 13 people) were free to select which game to play out of the offered.
| Name and source | Approach | Learning Objective | My personal evaluation |
| Jargon Bust | Create a pile of cards with often misused testing terms and then try to explain one of the cards of the pile without using the term (like the family game “Tabu”) | Exact use of testing terms | Used that as an opener with two naturally formed teams, with the result of a positive atmosphere and getting into the mood. I guess, nobody learned anything new. Learning: almost nil, Fun Factor: Great! |
| ArcAgimino | Similar to good old children domino games, but trying to connect two words (instead of numbers) and explaining why | Understand use and connectivity of concepts in testing and architecture | We played this game after having played the testsphere card deck game – the other one is much nicer and really gets you into more discussions. The connections built with ArcAgimino sometimes were a bit artificial. Learning: ok, Fun Factor: a bit boring |
| Test Driven Drawing | Try to draw a picture of simple geometrical shapes based on requirements only and then using acceptance criteria on top | Understand the value of test driven design | A real fun game to find out what everybody knew: Having better acceptance criteria helps. And the players also could evaluate their own requirements engineering skills. Learning: very hands on, Fun Factor: for laughing out loud! |
| Testsphere Card Deck | Two cards a drawn and a player needs to tell a story on how these could connect. | In the rule set we used: learn from others facilitated by using the testsphere card deck | This definitely was the game that got most people into talking about their experience in Quality Assurance. For me the game with highest learning factor. For more details see Christian Kram’s Blog. Learning: a lot of serious knowledge transfer, Fun Factor: ok, but interesting to keep on playing. |
| Agile Jenga Testing Game | Build a construction using Jenga stones once in waterfall, iterative and agile approach. In all three approaches, bugs had to be eliminated | Understand why agile makes life nicer not only for QA | This was the most selected game, amazing for a group of people who already know a lot about agile. Learning: very hands on, Fun Factor: high because of the fun of building with Jenga blocks |
| Black Stories | User standard “Black Stories” cards and play the game, but add a retrospective on problem resolution abilities after each story | Improve problem resolution techniques | This was selected with second highest frequency. I did not play, but from observation I would say that people got carried away with the game as such and did not really work too much on their problem resolution techniques. Learning: low, Fun Factor: very high, just because of the game as such |
My personal evaluation is partially based on just observing the people, I did not play the last two games. I am sure, everybody has a different summary, would be glad to see some in the comments.
The achievements?
As with every learning, you have to be very aware from where you start and what the existing level of knowledge is. And in our case – as a group of highly skilled QA experts – the starting level was too high for some of the games. I believe, in this situation the Testshpere card deck game advanced us most as a group. Individual learning probably has been very different, I believe for example I have to work on my requirements engineering skills: see the picture of the Test Driven Drawing game: the left hand drawing was just based on my requirements. But I seem to do ok with acceptance criteria: the top right drawing created with those on top was already much more similar to the real idea (bottom right) 😉
More generally the whole group identified that we did not need/practice any competitiveness in order to enjoy the games. In fact, we all forgot about that part of the games where one had to note down scores. We did not need the extrinsic stipulation but just liked to use the chance to learn. And play.
But isn’t this agile: only the overall team and its result is important and no individual’s score? Most games would not score based on team level, this I think is something to consider when gamifying in an agile environment.
The other reason I felt as relevant for not using scores was that the whole games happened in a non-competitive environment: at the StugHH there is a strong sense of being of the same kind. Being in a safe environment where you can just be a QA person. No need to prove you are better or can find bugs. Maybe in gamification with games with a strong competitive character you could destroy such a constructive atmosphere. But maybe it was just that we wanted to play – so it wasn’t really in a “non-game context”.
In conclusion
I believe there are situations where games can really support learning in QA, however you would have to pick the game and the mechanisms it uses very carefully. The evening was very enjoyable, also because of the great people participating.
Pingback: Reading Recommendations # 81 | Adventures in QA