Archive for the ‘Agile Testing’ Category

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:

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.

Try first.. then test

June 6, 2011

Testers who are new to agile software development often struggle to find a way to test the code in smaller pieces. This is mainly because they are trained to test only after everything is done. It is big change in mindset for them.

I think testers should take an approach that they are just trying to see if the code works. Though they might be really testing it, an “I am just trying to see… “ mindset will make them loosen up from the formality of entering bugs etc. Every time the developer says that something testable is checked in, tester should try it and inform developer if it doesn’t work. This notification could be as informal as telling the developer at the water cooler or send an email or add a task card to the task board.

Once tester has tried the functionality enough times and gained confidence that the functionality is mostly working, she could do more formal testing. However, at this point, testing the standard cases should be a breeze, and that allows tester to spend more time on exploratory testing.

Sure, this causes fewer bugs to be entered in the defect tracking system, and some testers seem to be concerned about that. One tester told me that her performance review is based on how many bugs she entered. I think it is a really bad thing to use that metric. In this situation, probably the tester prays for her teammate (developer) to fail, so that she can have a better performance review. All members
of a team should have common set of goals rather than conflicting ones.

Another concern I’ve heard is that if you don’t enter bugs, you can’t control the quality. That doesn’t make any sense, because at the end of a sprint, if you don’t have any bugs to enter, the code is of highest quality.

Happy Testing!