This Blog is moved to my company (poweragile.com) website. I don’t want you to miss the interesting content I have it there. Please make a bookmark.
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:
- Build a structure that is at least 3 stories taller.
- Use all the blocks.
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:
- 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.
- 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.
- 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.
PowerAgile Blog 
September 16, 2011 at 6:27 am |
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.
September 16, 2011 at 9:18 am |
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.
September 16, 2011 at 12:21 pm |
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.
September 16, 2011 at 12:58 pm |
Absolutely!
September 18, 2011 at 11:09 pm |
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.
September 19, 2011 at 10:37 am |
Hi Santanu,
Sorry, I am not familiar with the jargon ‘Demo box’, ‘QA box’ and ‘Dev box’. It would be helpful if you could elaborate.
Thanks,
Nanda
October 6, 2011 at 6:28 pm |
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
October 6, 2011 at 7:49 pm |
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
October 6, 2011 at 8:00 pm
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
October 29, 2011 at 8:23 pm |
Great game to make early feedback clear. Do you mind if I use it in one of my presentations/courses?
October 29, 2011 at 10:34 pm |
Thanks! You could use the game.
October 31, 2011 at 8:08 pm |
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.
October 31, 2011 at 8:32 pm |
Thanks Tal!
November 7, 2011 at 11:04 pm |
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.
November 18, 2011 at 6:46 pm |
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.
November 18, 2011 at 7:58 pm |
Thanks!
January 29, 2012 at 9:05 pm |
Why don’t you post this in tasty cupcakes?
February 20, 2012 at 7:07 pm |
Agile Testing Games…
A while ago I started looking for agile testing games, unfortunately I didn´t find much, but since a couple of people asked me for that, I´m gonna now publish what I have. Hopefully, this (small) list grows a bit over time, so please let me know, if yo…
May 13, 2012 at 8:21 am |
Reblogged this on lava kafle kathmandu nepal.
August 15, 2012 at 7:47 pm |
Great game – used it successfully today, some great feedback also to evolve the game in our situation.
August 17, 2012 at 1:20 pm |
That’s Great! Could you share the feedback?
August 20, 2012 at 10:54 pm
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
March 25, 2013 at 1:43 pm |
Hi,
we played the Jenga game ~2 weeks ago with 7 participants, and it went quite well, a report is available here: http://blog.agilepartner.net/agile-testing-games-seminar-on-march-14th-2013/
We did some modifications: We used only 27 blocks, we defined exact user stories and also the blocks that had to be used for these stories.
Best,
Christian
April 2, 2013 at 5:14 pm |
Hi Christian,
Thanks for sharing the results.
May 22, 2013 at 12:24 am |
[…] Nanda Lankalapalli for introducing this game to me. The original description can be found on his blog. I first played this game when I took a trip to Denver and visited ePlan Services. The purpose […]
May 22, 2013 at 9:12 am |
Hi Tom,
I am glad that it is working for your teams.
October 28, 2014 at 8:01 am |
[…] https://nandalankalapalli.wordpress.com/2011/09/15/game-test-small-test-often/ […]
July 21, 2015 at 6:12 pm |
What if the bugs are detected even before being written? That is Quality Assistance. It is a philosophy based on risks analysis instead of in pure testing. https://www.atlassian.com/agile/how-to-deliver-quality-assurance-at-speed-video
July 31, 2015 at 1:49 pm |
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
July 31, 2015 at 2:36 pm |
Hi Deepak,
Please go ahead and use the game. I would appreciate if you post the results.