In our development process we expect teams to do all testing necessary to deliver quality software. One of the disadvantages of our approach is that all product backlog (PBL) items are tested by testers (or if necessary and possible programmers or requirement engineers) from the team who also builds the software. In most cases this is not a problem. However, sometimes it could really improve the quality when others testers (or programmers, requirement engineers and/or technical writers) from other teams test the software.
There are some PBL items that don’t need to be tested by other teams, like business rules. However, PBL items:
- that could affect client of server performance;
- that could affect user interface of for example a Web client (that can’t be tested automatically);
- are about usability;
- that are high risk;
are candidates to be tested also by other teams. However, in a Scrum environment every team has his own planning.
We introduced the Bug hunt sessions.
A regular meeting, every two weeks where everyone is free to step in and do some testing. Teams are able to report PBL items that can be tested in the bug hunt sessions. It is a regular meeting of one hour, the impact on the planning is low. Therefore, other team members are willing more easy to participate.
The approach of Bug Hunt Sessions is:
- We introduce the concept to all development employees and ask who is interested to participate in these sessions;
- We plan a recurrent meeting, every two weeks on Friday from 11:30 – 12:30 CET (16:00 – 17:00 IST);
- When a team has a subject for the bug hunt session, they inform all teams and publish a link to the information required for the participants;
- One day for the session, everyone is reminded again;
- The bug hunt session will be started with a short introduction (maximum ten minutes) by the team who send in the topic using for example GotoMeeting. If a team needs more than ten minutes to explain the topic, it is too complex for the bug hunt session;
- The session starts, maximum one hour. During the session the organizing team is available for support;
- All findings are reported to the organizing team by email or Skype. The organizing team creates the calls and filters out any double reported calls;
- The person who will find the most valuable call(s) will be Mr. or Mrs. Bug-Hunter until a new session is organized 🙂
We are organizing the first session the coming months, as soon as we have some experiences I will share them with you. And of course we will improve our approach after every iteration, bug hunt session.
Are you already familiar with such a concept? Do you you believe everything should always be tested by only the team who develops the software or should there always be an independent tester be involved? Please leave your comments.