Agile Testing Games – Seminar on March 14th 2013

Agile Testing Games – Seminar on March 14th 2013

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.
Dice Game

Some of the dices used for the game

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.
Agile Jenga

The used Jenga blocks

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:
[slideshare id=17417104&doc=agiletestinggamesslideshare-130320121846-phpapp02]

Other resources Agile Testing Games are listed in the author´s personal blog.

Related books:

Finally some pictures of the session:

Dice Game in Action

Dice Game in Action

 

Building with Jenga

Building with Jenga

 

Books

Books

Christian Baumann

I´m an agile practitioner with a strong focus on software testing. I started my professional career as a consultant in the area of test automation (GUI- as well as performance-testing), working in many different business domains; then became test automation engineer/ project manager verification/ test team lead in the healthcare sector. After getting in touch with "Agile" in the beginning of 2008 for the first time, I started reading (and learning) more & more about, being "infected" by this kind of working. In February 2011 I started for Agile Partner and and I´m courius what the next chapters of this story will be!

No Comments

Post a Comment

Comment
Name
Email
Website