Our last Agile Mëtteg was about “Agile Testing Games” was held as a workshop, where participants played two different games. The aim was to experience in a safe environment how we can learn from these games for (agile) testing. After a short introduction on the topic of “playing games at work”, we directly started to play.
The first game played was the “Dice Game”, which I played the first time at the GATE Workshop in 2011 from Markus Gärtner. The rules are quite simple: A set of dices is rolled, and every participant has to guess what the output is. After everybody has guessed, the facilitator gives the real output, and the next guy in the round roles the dices and the guessing starts again. This can be repeated until everybody has decoded the underlying algorithm which transforms the results of the thrown dices into a certain output.
After the first game, we did a debrief, to find out what the participants learned from playing that game, and how this can be useful for (exploratory) testing, following our results:
- Since the algorithm is not known, we´re making assumptions. These assumptions need to be verified.
Also when testing, we very often don´t know enough about the system we´re testing, these strategy can also applied here.
- Reducing the complexity (number of parameters) makes it easier
These also applies for testing, e.g. when trying to find out the exact conditions on how to reproduce a bug
- Only change one condition at a time
See “Reducing complexity”
- Don´t interpret the results
You might interprete them wrong!
- Collaborate with other people
Talking about a problem with other people often makes it easier to solve the problem; if you´re alone, also Rubber Ducking might help.
The second game we played was Test small, test often by Nanda Lankalapalli. Based on a paper of Lisa Crispin we made some variations to the original game description of Nanda: we used only 27 blocks and created concrete user stories; these blocks have been numbered from 1 to 27 and a certain set of blocks had to be used per user story. We played 3 iterations, each with one developer and one tester. The first iteration was building the product straight away, and at the end the tester did his job, similar to the waterfall approach in software development. In the second iteration we followed a kind of mini-waterfall approach, where the developer built a story, and then the tester tested. The final iteration was kind of agile, where developer and tester worked together for every single brick, and where able to spot defects right from the beginning.
Outcome from this session have been the following:
- The later you test, the more rework you have if bugs are found, which will make the project late.
- The earlier the tester gets on board, the faster you will receive feedback.
- The aim of agile testing is to prevent bugs as early as possible.
At the end we opened a general question & answer session concerning the speciality of “agile testing” where various topics have been discussed.
The Slides of the session are available on slideshare:
Other resources Agile Testing Games are listed in the author´s personal blog.
- Elisabeth Hendrickson: Explore It!: Reduce Risk and Increase Confidence with Exploratory
- Lisa Crispin & Janet Gregory – Agile Testing: A Practical Guide for Testers and Agile Teams
- Gojko Adzic – Specification by Example: How Successful Teams Deliver the Right Software
- Markus Gärtner: ATDD by Example: A Practical Guide to Acceptance Test-driven Development
Finally some pictures of the session: