Saturday, 11 October 2008

Writing/Logging Bugs....Must read for QA people

Writing is easy, but writing clearly is hard. When it comes to write bug explanations... well, writing seems to get even harder, as far as the IT professional is concerned. In my life as a developer (especially while working at Graycell Technologies) I have seen a lot of bug reports that are either incomplete or missing critical reproducible steps, or have no explanation of why the results are wrong. Juts Imagine (my dear testers) if you were a developer and you got this kind of bug report, won’t you feel frustrated? The best you could do is to mark the case as not reproducible and assigned it back to the tester. The tester, would, in turn would, insisted that the bug was there and, well, there went a football-kicking session. Congratulations, you've wasted a few non-productive minutes on just trying to get message across. All these wasted minutes would add up, resulting in a loss in productivity. And at last it is always a developer’s ass to be kicked

So my hope is that for those who haven't know how to write a proper bug report, they can gain something after reading this post. As for those who are already knowledgeable (like our QA lead at GCT), they would still find the information here useful, or at least entertaining.

The Dos:

1. Clear title-- Good title is a must, as the developer should be able to grasp the essence of the bug report from the title alone.

2. One bug per issue-- Report one bug in a single issue, no more, no less. If you put in too many bugs, some of them may be overlooked. To avoid confusion and duplication, please, one bug per issue, no more, no less.

3. Minimum, quantifiable steps to reproduce the problem-- This is important. Developers need to be able to get to the problem in the shortest time. So the testers' job is to help them to do just that. Testers need to do a few round of testing to clarify the steps, and to be able to reproduce the problems using minimum steps. We the developers will appreciate the extra efforts, really. If the testers can't specify the steps to reproduce the problem, then the developers have to conclude that the bug doesn't exist.

4. Expected and observed results-- A bug report should always contain the expected and observed results. A generic description like "This is a bug" is not helpful, because the bug in question is not immediately obvious to the developers. Another reason for spelling out explicitly the expected and observed results is that sometimes the developers don't think that the bug is a real bug. So it is the testers 'duty to explain to the developers what went wrong.

5. The build that the problem occurs-- Daily builds are common nowadays. So if the testers don't specify the exact problematic build, developers might have a hard time trying to solve an already-solved problem. That will be a waste of resources.

6. Include background references, if possible-- If a bug is related to other bugs, then please include that information in the bug reports. This will help everyone who reads the report understand the issues.

7. Pictures-- A picture is worth a thousand words! Sometimes words just don't flow; in that case why don't just capture a clear picture that illustrates the problem?

8. Proof read the bug report! -- This is very, very important. Now the bug report is readied, but why not just trial run what is written to make sure other people can follow and reproduce the problem exactly? A proofread bug report has a much higher chance of being understood properly by the developers and fixed by them.

The Don’ts:

1. Don't write generic titles-- Don't write titles like "Help!", "What happen?” These kinds of titles are devoid of content at best and irritating at worst. So please provide a clear, concise title to your reports.

2. Don't use personal communications-- Put everything you know, all the latest developments in the bug report. Don't resolve the bug privately with the developers. The whole purpose of bug report is to capture all the interaction that is going on so that the knowledge won't be lost. Using personal communication or resolve the case privately is defeating very purpose of bug tracking.

3. Don't assume that the developers can read your mind-- The developers don't have telepathic ability. Don't ask them "do you get what I mean?", or "you get me?” follow up by a confusing stare. Try your best to express yourselves, use pictures if possible. And don't assume, the developers can only follow things that are written on the bug report, don't assume them that they will do a few extra steps you think are obvious.

4. Don't kick the bug report around! -- We have enough politics in the office already. Using bug report to score political points is detrimental to everyone.

5. Don't be rude-- Well, if you can help it :)



That's all from me, anymore?

3 comments:

  1. Sanjeev,
    This was really good, in fact when you left the GCT just after that we refined the bug reporting skill.
    we added the default format into mantis itself, which forces every QA to log the bug in proper manner. e.g.
    1.Category: functional/GUI/verfication/non functional/etc..
    2. Platform
    3. Browsers
    4. Title
    5. #Fact: (means what is happening)
    #Expected:
    6. Steps: (explaining what happened & how)
    1.
    2.
    3....
    7. Image
    8. Testcase ID
    9. UserRole

    While bugs are resolved, root cause is also written by developers & closed by testers. at any stage we can have stat of verification & validation.

    and and .... Finally at the EOD a bug report is kicked towards development team :-)

    Build versions: as you know I started having this but all in vain now.

    Anil Sharma

    ReplyDelete
  2. hi anil

    That’s good to know that a process has been implemented, and I really appreciate your efforts….but I think there are certain loop holes from management side....
    nyways...keep rocking

    ReplyDelete
  3. true,
    it is world known that following the processes demand for time, and we do not get, each QA is working on 2 projects in a chaos. from estimates efforts

    Efforts can be put on Processes, but if top manager do not bother what their team is doing, then ???? all goes useless.

    it can happen from top to bottom only....let us see

    ReplyDelete