Bug Reporting is an art

The work of a software tester on software projects is much like diagnosis doctors do. There is no scope for ambiguity when a doctor diagnoses. Before a doctor reveals his diagnosis, a lot of symptom analysis and mind work goes into it. A doctor has to be very precise in reporting the problems as he diagnoses. “Patient X has something like cancer” will kill the patient just out of shock. In any field, effective reporting is much of an art.

Similarly, when diagnosing issues with software while testing, there is no scope of ambiguity. As testers, we have to remember that each bug reported involves some work for developers. They have to understand the context of issue, try to reproduce it and resolve it after it is reproduced. May a times, a project manager needs to understand what are severe issues open and manage the project accordingly.

For this, testers must clearly and succinctly report each of the finding with appropriate severity and priority assigned. Suppose you are a developer and you see a bug stating “The values in category combo box are not proper”. How would you react to it?

Following are pointers to effectively report software issues:

• Each bug should be clearly identifiable by the bug title
• Each bug should be reported after building a proper context. What are the pre-conditions for reproducing the bug?
• Write down steps to reproduce the bug.
• Be very clear and precise. Use short and meaningful sentences.
• Cite examples wherever necessary, especially if bugs are a result of a combination of values.
• Give references to specifications wherever required. E.g. Refer invoices module on page 14 of SRS.
• Keep the descriptions simple.
• Be objective. Report what you are supposed to without passing any kind of judgement in the bug descriptions.
• Thoughtfully assign severity and priority to the bug. Remember, a minor issue may have high priority and vice versa.

Reporting a bug is no rocket science but it surely requires a lot of common sense. I have seen people writing mini-essays in bug reports and also the ones who report one-liners.

Reported bugs should not add an overhead of understanding to the developers but help them instead to reproduce the bug and effectively resolve it.