Tuesday, November 03, 2009

How to write an Effective Bug Report - Part 1


Use some reporting tool of your choice like Bugzilla. There are many free reporting tools available, some of the useful links are as follows,
1. After installing bug tracking software, do read its Bug Reporting Guidelines section, it will really help.
2. Select component, platform, OS etc
3. Set priority (most of the times it is assumed the duty of a tester but its logically incorrect).
4. Set severity
Here arise some questions like, What is priority? What is severity? What is the difference between priority and severity? What considerations should one have in his mind while setting priority and severity?
Severity is the one that states how bad or critical, is the bug. It is usually reported by the tester to the developing team. Priority is the level that determines which bug needs to be fixed first, whether it is of high priority or can it be resolved (not fixed in this release) or can it Wait (low level), it is usually determined by the developing team or the Project Manager. For details on severity and priority you can click here.
5. Summary should be precise and compact. A good summary should quickly and uniquely identify a bug, means after reading summary reader gets an idea about the whole bug just like the name of a novel gives you an idea about what you are going to read in next 500 pages.
6. Description should contain comprehensive details. Here your first audience, the developer who fixes the bug, needs clear and unambiguous steps to follow in order to reproduce the symptoms. The more information you provide the better it should be. The developer needs precise detail about “what you did” and “what you saw”. Your second audience, the person or group who decides the fate of the bug, needs to understand the consequences of choosing not to fix the bug. This audience needs information that can grab their attention and also help them see implications of not fixing the bug at the time you reported it. So the key point here is, that your description should be clear and easy to understand, do not use big difficult words so that the developer needs to consult a dictionary to understand the bug :)
Here I want to divide description in two portions, Without Screen-shot and With Screen-shot.
1.

In first case (Without Screen-shot) Write complete description in the description area and do not attach any screen-shot with it. In this case somehow it will become difficult for the tester (reporter at the moment) to report and cover the bug completely and at the same time developer also faces some difficulty while understanding the bug, I am not saying that developer didn’t understand your point in the bug but he have to spend more time to understand and may be bored while reading the bug. As a reporter it is your duty to convince the developer to read the whole text or focus on your reported bug.

2.
About the second case (With Screen-shot) I will tell you a very effective way to attract the developer in my next blog (because this one is becoming very lengthy) and that is very important, so don’t miss that.
7. Do not report two bugs in a single bug report, in this case developers fix one bug and leave the other, I had been a victim to this.

4 comments:

  1. By first - Many congrats Sobia for joining the world of testing bloggers out here.
    Secondly; you hit the very crucial idea of writing a reasonable n comprehensive bug report. I really appreciate.

    Please allow me to share one of my recent experience here. Somedays back i wrote a very clear-cut & concise bug report (in MS excel) and sent that to developers I was working with, but each time when new build released I was getting an small percentage of bugs being fixed and a large percentage seemed untouched by the developers. Then I changed the approach; I simply jotted all errors down very precisely as bulleted form in an email and sent to developers n here the miracle happened; I got all my bugs fixed within 1 week. so making the long story short sometimes it depends on general practice of your organization too. Developers often find themselves reluctant to read full steps of a testcase and this "mostly" happens when your cabin is right besides your developer.
    Cheers.

    ReplyDelete
  2. "By first - Many congrats Sobia for joining the world of testing bloggers out here"

    Thank you so much Fatima

    "Secondly; you hit the very crucial idea of writing a reasonable n comprehensive bug report. I really appreciate."

    thax again

    "I simply jotted all errors down very precisely as bulleted form in an email and sent to developers n here the miracle happened; I got all my bugs fixed within 1 week"

    As i am suggesting in my blog's first line that always try to use some scripting tool (like Bugzilla), because whenever u add a new bug in scripting tool, it is mailed to the Developer, Project Manager (PM) and every one else who is added in the CC list, so as the related person saw more emails coming from bugzilla ... pressure increases on him/her. And detail is important to understand the bug.

    Hope u understand my point :)

    And the experience u r sharing, me too have the same experience, so dont worry, sometimes it happens :D. Infant it is the duty of PM to ensure that the bugs are going to be fixed or not.

    ReplyDelete
  3. I love reading through your blog, I wanted to leave a little comment to support you and wish you a good continuation. Wish you best of luck for all your best efforts.
    Tableau Guru
    http://www.sqiar.com/services/tableau-software-consultants

    ReplyDelete
  4. Enpersol offers Tableau Consulting Services, specializing in implementation and dashboarding in pune and indore. also help you, whether you're just starting out with Tableau, or you need some advanced expertise.

    ReplyDelete