Avoiding release testing bug battle

[Allan]

I’d like to know how other software teams avoid the final push to fix bugs before a release. Approaches couYld be to fix defects as they arise, allocate time each sprint/dev cycle for bug fixing (for example bug Wednesdays :P).
How to avoid a development team moving from “forward energetic creative push” to “bored debugging until release date”

[Tassawer]

Our development team also use a “Bug Fixing Day” i.e Wednesday duirng their Scrum sprint.

[Archana]

One of my client has set a target of “x” defects to be fixed each week by each developer.

[Alin]

Hi Allan,

In projects I have worked a developer was allocated for bug fixing each sprint by rotation. In this way, the load related to bug fixing during the sprint was kept at a constant level and there was not such a high push before release. Another approach I have seen on projects is to fix the bugs as they arise.

Regards,
Alin

[Melvin]

We do what we call bug “Stand-down” once in a while before the release, in order to tackle Major and high priority bugs, fixe it and verify it. In this way the counting of bugs towards the release date most of the time remain in the target scope. For “minor” bugs it always depends on resource availability and time.

Regards.

[Cliodhna]

We have an eBook on Debugging which we just released… This eBook describes rule #2, Make It Fail, which may be of particular interest to test engineers. You will learn why and how to make a test consistently break the system, and what information is needed from those failures to fix the bug. And you will be entertained by the humorous writing style and fun examples from hardware, software, cars, houses, and human bodies.
Making It Fail is important for a number of reasons, and must generate certain kinds of information to enable debugging.

[Download] Make it Fail: Debugging

[Dan Svensson]

 

The team employs a zero bug policy or some kind of variation of it at least, which means we only track bugs that will be fixed within a month. If it is not fixed within a month it wasn’t important. This allows us to easily find the important bug that need fixing(as they are the only ones in the bug database). This leads to us fixing bugs that are important for the current stage of the project and to the team. If an issue wont be fixed within the month but will be important to fix before release we still close it. When we reach a stage in the project where that issue might be important it will be detected again if it is still relevant to the team, if it doesn’t come up again it obviously wasn’t important.

To help with this we do regular bug triage to keep the issues relevant and up to date. This does not take long since we usually only have 10-20 issues in data base, this number usually goes up as we approach a mile stone(We should be harsher though as we usually have a few issues that lingers too long in the database).

Before we started doing the zero bug policy we had 500+ issues in the database. That said the quality of the product has gone up after we started doing zero bug policy as we fix the important issues and are not distracted by other issues that might seem important but in reality are not.

If something is very critical(and important for the milestone), applies to new features being developed in the current sprint or hinders testing I just talk to the relevant dev and they usually fix it right away otherwise it goes into the bug database if me and/or the dev thinks that this is important enough and then it will be looked at again at the the bug triage meeting

 

[Author]

Posts