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 the 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 its 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, a maximum of 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 in 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 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.
I've done this several times – it's a great idea.
I typed out a long comment but blogspot threw an error when i hit post.
Get in touch with me if want to discuss more the logistics of this more.
Pitty blogspot threw an error, maybe Google need to do a bug hunt session on the comment features 😉
If I have some questions I will contact you, thanks!
Is in your case always the whole team developing one item?
In our case 1-3 developers are working on one feature, and someone else, who didn´t work on the feature, is responsible for what we call “internal testing”. This is part of the definition-of-done, and is even done before the product owner does the “official” acceptance testing.
So the concept seems to be the same: Let someone else test what you have developed. I think that´s a common and widely accepted rule in the world of sw development, isn´t it?
Regards,
Christian
Christian thanks for your comment.
A teams is working on multiple items, and a team has multiple disciplines. A team has dedicated programmers, testers, requirements engineer and a technical writer.
Indeed, a developer does only do alpha testing and the testers does the “real” testing. I agree with you that the person who build something, should not test itself.
The bug hunt sessions are there to do extra testing on specific items. Items where you would like to have the opinion of other people, not sitting in your team. Or, you would like to do some real life multi user testing, etc.