Game – Test small, test often

This is a game to demonstrate Testing small and Testing often is more affective. Take any building blocks. I used Jenga wooden blocks.

I chose 36 Jenga blocks and numbered them from 1 – 36. I asked one person who is pretending to be a Developer to build a structure with the blocks:

Requirement:

  1. Build a structure that is at least 3 stories taller.
  2. Use all the blocks.
Something like:

I asked upon another person who is pretending to be tester. I gave four random numbers between 1 and 36 and told her they are problem blocks. We are going to play three rounds:

  1. Round 1: Tester is allowed to come and verify the built structure only after the whole structure is built. Tester points out problem blocks and the developer need to get rid of them and comply with the requirements.
  2. Round 2 : In this round the tester is allowed to point out the problem blocks after every 9 blocks (one fourth) are put in. So, tester gets 4 opportunities to give feed back.
  3. Round 3: Tester is allowed to work with the developer as he is building the structure and point out if he is using a problem block.

What did we learn:

Tester and developer when worked together, delivers high quality software with less rework. The first case depicts water fall where testing happens after the software is built. If the bugs found are more fundamental (like blocks in the first level), the project will be delayed more.

In the second case, feedback is faster. Developer could correct the code early and there is less risk than the option 1.

In the third case, it is the most agile way and the tester is helping developer avoiding putting the bugs in. It may not be possible to reach this in software development. Getting as close as possible to this level of agility is what an agile team should try for.

31 thoughts on “Game – Test small, test often

  1. Bala Manchikanti Reply

    I was thinking on how to build collaboration between dev and QA from very long time. This game is excellent way of making the team realize on how important and fruitful will be if they collaborate. Interestingly they realize that it is win-win and can change their mindset in no time.

    Thanks a lot for this article Nanda.

  2. Deepak T Gururaja Reply

    Hi Nanda,
    With your permission, I would like to conduct this game during one of the meetups in Bangalore. Please let me know your thoughts

  3. Pingback: Agile Jenga - An agile mind

  4. Pingback: Simple Game to Demonstrate Agile Concepts: Test Small, Test Often (Jenga) | Tom Sylvester

      • kennygrant993 Reply

        Hi Nanda

        Here’s the updates we made:
        1. Added ‘At least 1 story in the structure must use blocks stacked upright’ to the product requirements – we found this prevented very simple, horizontally stacked structures that were easier to remove bricks from even in round 1!

        2. For each round, the tester writes down problem bricks at the start of each round selected randomly, developer cannot know what they are. We found this gave the tester a more interactive role – rather than simply being told the defect blocks by the facilitator.

        3. For round 2 we specified that the bricks should be used in sequential order so that item 2. works ok. i.e. if the tester knows higher numbered blocks will be used in the later batches of 9 then they can be sure their 4 random numbers won’t all be in, say, the first story of the structure.

        Regards
        Kenny

  5. Pingback: (Agile) Testing

  6. Rayalu Chintalapudi Reply

    A very good and innovative idea in the form of a game to make things easy and clear to underand. A good foundation to build the further practical concepts of implementing Agile practices. Thanks for sharing.

  7. Lisa Crispin Reply

    We had fun playing this today with our new tester. Thanks for facilitating! I’d like to try this with a different construction set. The Jenga blocks are hard to build with, which may be good or bad – it can send the wrong message, if they accidentally fall down during phase 3. I may try it with the straw connector building set.

  8. Tal E. Reply

    great game, I loved the idea!
    like you said, in software testing it’s not very likely to use the 3rd case, at least not in large companies; but I do have friends working together as a team of 2 developers (without testers!). They give each other constant feedback, and the quality of their work is amazing, so it could happen.

  9. Cecile Davis Reply

    Great game to make early feedback clear. Do you mind if I use it in one of my presentations/courses?

  10. Christian Baumann Reply

    Hi,

    thanks for this exhaustive description. I´m looking for games about testing to play with our scrum team to enrich there testing understandment & skills, and this one might fit very well. Thanks!

    Two questions concerning your describtion:
    1. What do you mean by “Build a structure that is at least 3 stories taller.” What do you mean by “stories”? And “taller” then what?
    2. Why giving that random numbers to the tester and telling her, it are problem blocks? To sharpen her awareness that this blocks may cause more problems then others?

    Thy in advance,
    Christian

    • Nanda Lankalapalli Reply

      Thanks Christian.

      1. I meant three levels like the picture shows. The point is upper levels depends on lower levels. If there is a problem in the lower level they have to rebuild the level above it.
      2. The random numbers indicate random bugs and they could be any where in the structure. If they happen to be in the level one, when they remove it, the structure above will fall down.

      Hope this is clear. Otherwise, please ask.

      — Nanda

      • Christian Baumann Reply

        Thanks for the quick reply.

        @1: Got it, thanks! 😉

        @2: So this “random blocks” are a metaphor for bugs, the tester would have found in the real world?

        Regards,
        Christian

  11. Santanu Bhattacharya Reply

    The focus of the team needs to move from giving bug free software to the demo server to how to reduce the number of bugs found on the QA box itself.

    The team can figure out various ways of doing it depending on their team dynamics.

    Focus moving from the demo box to QA box helps to take the first step. The next step is moving the focus from QA box to dev box.

  12. AnandMahadevan (@Anand_Mahadevan) Reply

    Great game and the great explanation on why we need to get early feedback from testers on the code built by the developer. To me Round 2 in the game is more like smaller/shorter version of waterfall module, developer commits the code for an user story and then it’s ready for QA to test & tester provides feedback (which is what most of the companies are doing in India & calling them as a “Agile Scrum” company). Round 3 is the best example case for how the early feedback works in Agile and i am pretty sure now the handful of companies are doing & succeeding on this. But to reach that stage we/management have to patient enough to support this model to enjoy the benefits.

  13. Ram Lankalapalli Reply

    Excellent. Good effort with example. My only question : Is this practical in egile or any methodology to implement? though we are not working in egile management environment, we tried this way in our projects and it worked with lots of time and effort.

    • Nanda Lankalapalli Reply

      Thanks! The point here is to reduce the feedback loop between dev and testing. The biggest problem I see in lot of organizations is the attitude of the developers and testers in working together. However, I also see lot of agile teams succeeding with this.

Leave a Reply

Your email address will not be published. Required fields are marked *