Tips on disputing a bug - Pramod Lumb

Author: Pramod Lumb

Introduction: The primary responsibility of a tester is to help improve quality of the product being tested. This is best achieved by detecting high-value bugs in the product, before the customer releases it to the public. However, does the responsibility of a tester end with documentation of the defects found? Sometimes yes, but often times, no.

A tester should not only ensure that the defects detected in a product are logged and brought to the notice of development team as soon as possible, but also that they are properly disposed off. In order to ensure this, testers may sometimes be required to sit down with the development team in order to help them understand and reproduce documented defects. Testers may also, sometimes, be required to help developers understand the impact of not fixing or deferring the fix of a defect.

Valid reasons to dispute a bug:

This is where the concept of disputing a bug comes into place. Development teams may often dispute the severity of a bug as pointed out by testers. In fact, they may even dispute (in certain cases) if the incident being reported is a defect in the first place. There may be other cases as well where development team may dispute the observations of testers.

Let us look at some of the areas wherein a defect reported by the test team may be disputed:

1. A defect may be considered to be a product design feature by the development team. Hence, they may believe that it does not need to be fixed at all.
2. Development teams (or product management teams) may not agree with the stated severity, or implied priority, of a defect logged by the test team. Hence, the defect may get scant and delayed attention, or may never get a chance to be taken up for resolution at all.
3. Development teams may not be able to reproduce a bug in their environment, or else, a bug marked as resolved by them may seem fixed in their environment but may not actually turn out to be resolved when verified in test environment.

Besides, there may be disagreements on the way a defect should be documented. Sometimes, a debate may even take place on independent parts of a bug which have been documented as a single defect. At other times, different development teams may not agree on the correct allocation of defects assigned to them for resolution, i.e., there may not be an agreement on which part of an application is defective.

Tips to avoid bugs being disputed:

In order to ensure effective and speedy disposal of bugs, it is essential that certain good practices be followed. First and foremost, the defects should be documented in an unambiguous manner, with the test environment as well as steps to reproduce the bugs being documented clearly. Secondly, supporting screenshots/videos should be provided wherever possible. Finally, the perceived impact of the bug on AUT (Application under Test) as well as business of the customer should be unambiguously documented.

However, in spite of providing supporting documentation and a clean sequence of steps for reproducing the defect, sometimes confusions do creep in. If they do, it is essential that the bugs be disputed in a peaceful and amicable manner.

Tips for effectively disputing logged bugs:

Here are a few tips to help you dispute bugs effectively without leaving a sour taste in the mouths of either development or test team members:

1. If the reported bug is considered to be a design feature and not a defect, always provide supporting documentation, e.g., requirements or design documents, to support your viewpoint. In case the supporting documentation is itself ambiguous, seek clarification from the customer before disputing a bug.
2. Always understand why a particular severity or priority has been assigned to a defect. There may be cascading impact(s) of the bug unknown to you because of which it has been assigned a higher priority/severity compared to the values you deem fit.
3. Do not ever point fingers at a particular individual for logging an invalid defect, or for marking a defect as resolved even though it has not been fixed as such. Never use offensive language in your bug reports, or in related communication.
4. If a particular individual seems to be making repeated mistakes in terms of logging invalid defects or marking defects as resolved incorrectly, talk to that individual’s manager. Do not let the ‘Bozo bit’ be flipped on for yourself.
5. If you are not able to reproduce a defect in your environment, always ask the author of the defect for help. There may have been certain changes between the time when the defect was documented, and now, because of which you are not able to reproduce the defect now. Application build may have got updated, or else, the defect may have got masked because of some other defect which got fixed.

If you keep these tips in mind, you will always find that you are respected across development and test teams for your inputs, and that your suggestions and inputs are looked forward to, rather than being frowned upon.