Computer Weekly IT Blog Awards 2009

Computer Weekly’s blog award ceremony is going to be held on 25th November
in association with IBM , they want to know who you think are the best bloggers and Twitter users in the UK IT industry, so to kick off the Awards they are asking IT professionals to submit their nominations to them. Interestingly, Blogs do not need to originate in the UK, but they must contain some coverage of the UK IT industry and Self-nominations are also permitted.
Check out the details here

How to write an Effective Bug Report - Part 2

Whenever you are reporting a bug always try to attach a screen shot, by using this method you can pinpoint the bug very easily, its a very good way to elaborate your bug that where the bug lies and highlight the particular area in the screen short where the bug lies and write the bug detail (steps which you follow to reproduce a bug) with that.
             You should use different tools like Microsoft Paint or Cropper or any other of your choice to highlight and elaborate the particular bug area. Find some good tools here

1.    In the description area just write something like
“Module Name --> Page Name --> Problem in Short --> Attachment notification”,
For Example “Poll --> Create Poll --> Confirmation message is not shown --> Please view the attachment for clarification (or details)”.
In this case, its easy to describe the bug for a tester and also there is some better understanding for the developer. He/she (the developer) can easily switch to the page where the bug lies in complex applications without wasting much time in finding out the particular bug area. See the example below,

2.    Do not highlight more then one issue in one screen shot. In this case developers fix 1 highlighted issue (bug) and leave the other. Let me give you an example for clarity, see the figure below  

   Here there should be two separate bugs and screen shots, one for the “Cancel” button and the other for the “Reset” button.
3.    In the comparison cases, screen shot method is very handy. For Example same drop down show different options on different pages, look and feel of different pages in the same application etc. By using this method you can elaborate your point in a very effective way without writing long details. Have a look at the figure below,

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,

Bugzilla

Bug Genie

Three free bug-tracking tools
126 Hand-picked Defect Tracking Tools
9 Free And Open Source Bug Tracking Softwares

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.