Archive for September, 2011

Game – Test small, test often

September 15, 2011

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:


  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.


Test First Development is like driving a car with GPS

September 6, 2011

I had this funny thought that what if you have a GPS that tells you that you made a wrong turn only after you made a turn (I know no one will use one like that), what will happen?

Lets say you are driving around with this kind of GPS and reached an intersection. You made a right turn and the GPS beeped that it is a wrong turn. What do you do? If you are in India, you just reverse your car and take a different choice. If you are in US, you may have to find a “U” turn and come back to the intersection and then make another choice.

When we don’t do Test First Development this is how it feels like.  Every time a bug is found, developer needs to figure out what and where to fix. This could take a significant amount of time, depending on how well the code is designed.  Of course, GPS is pre loaded with maps and a developer needs to create his own GPS (executable tests) before starts his journey (coding).

Once a bug is found, developer has two choices:

1)   Some how quickly fix it. This is very likely, if the code is not well factored, since it could take lot of rework to fix the bug. If the developer is in a hurry, he wants to patch it up and move on. This is like in Indian scenario above where you could bump into on coming traffic or someone and create a bigger mess, that leave the code in an undesirable state.

2)   Take the right path by re-factoring the code and place the fix , which takes longer.

Test First development helps reduce number of bugs since the code is driven by executable tests and also helps fixing the bugs, if found, easy since the code is better designed.  Here the tests are the GPS for coding and helps you reach your destination faster.

Hope, this makes sense!