Wednesday, October 26, 2016

The Bug Battle game

A couple of years ago, I was the Scrum Master in a project. Though we had a steady delivery of business value, we also noticed that too many bugs were found by our Product Owner. The team knew it had to improve by finding and fixing bugs earlier in the process. Therefore I introduced the ‘Bug Battle’ game. How does this work?

The game

The game has multiple goals:

  1. Improve the quality of your application
  2. Teaching that finding bugs can be fun for both testers as developers
  3. Team building

Participants

The entire agile team

Timing

The bug battle may take as long as you want, though 1:15 hour is most effective.

MaterialsBug swatter

The Bug Battle game makes use of:

  • Some nice prices for the winner. I often use bug swatters, because this is close related to the game.
  • A testable application
  • A bug registration tool, both analog and digital tools will fit this purpose
  • A timer

Instructions

Preparation

In order to have a smooth battle there should be a couple of things arranged:

  • A team member prepares the test environment. The application that is subject of this bug battle runs in this environment. He or she also takes care of creating accounts for users with all kind of roles. There should be so many accounts that participants cannot hamper each other.
  • All team members should have access from the battle location to the test environment
  • A tester or the agile coach prepares the bug registration tool. Normally this would be the tool that is already being used in the project. If don’t use such tool sticky notes will fit this purpose as well.
  • For huge applications it might be useful to define a test focus. I would choose an area that has high quality requirements or has a high error rate lately.
  • The agile coach or the product owner defines the price winning categories. Be sure that you have a price per category. I have used the categories stated below, but in your situation others might be more useful.
    • The first bug found
    • The most weird bug found
    • The most bugs
    • The most obvious (but never found) bug

Execution – explanation (5 minutes)

The agile coach starts the battle by giving the rules

  • Everyone uses dedicated users
  • All bugs are reported in the bug registration tool in a reproducible way, so including situation, steps etc. If sticky notes are used reporter name and time are written down
  • If bugs are reported by more than one person, the first reporter ‘owns’ the bug
  • Testing start and end time
  • Test focus (if necessary)
  • Known errors will not be taken into account
  • Any other prerequisites like use of specific tools

Execution – actual game (e.g. 1 hour)

Each team member acts like a tester during the test period by testing the application in a way he or she likes.

Once in a while the agile coach mentioned the remaining time in order to keep every in the battle mode. In between he encourages every team member to find more bugs. At the end he announces the closure of the battle.

Execution – awards ceremony (10 minutes)

After the test period the product owner and agile coach go through the reported bugs and decide upon the winner in each category. The product owner compliments the team and especially the winner and rewords them with a beautiful price.

Learning points

  1. The team members learn that testing need to be done by all kind of roles in the team. People with different focus will detect different kind of errors.
  2. Finding bugs is no thread, but can be a fun element as well.

No comments:

Post a Comment