Why are there Bugs in Software?

Part:   1  2  3  4  5  6  7  8  9   10  11  12  13  14  15  16  17  18 

(Continued from previous part...)

How to Write a Fully Effective Bug Report

To write a fully effective report you must:
- Explain how to reproduce the problem - Analyze the error so you can describe it in a minimum number of steps.
- Write a report that is complete and easy to understand.

Write bug reports immediately; the longer you wait between finding the problem and reporting it, the more likely it is the description will be incomplete, the problem not reproducible, or simply forgotten.
Writing a one-line report summary (Bug's report title) is an art. You must master it. Summaries help everyone quickly review outstanding problems and find individual reports. The summary line is the most frequently and carefully read part of the report. When a summary makes a problem sound less severe than it is, managers are more likely to defer it. Alternatively, if your summaries make problems sound more severe than they are, you will gain a reputation for alarmism. Don't use the same summary for two different reports, even if they are similar. The summary line should describe only the problem, not the replication steps. Don't run the summary into the description (Steps to reproduce) as they will usually be printed independently of each other in reports.
Ideally you should be able to write this clearly enough for a developer to reproduce and fix the problem, and another QA engineer to verify the fix without them having to go back to you, the author, for more information. It is much better to over communicate in this field than say too little. Of course it is ideal if the problem is reproducible and you can write down those steps. But if you can't reproduce a bug, and try and try and still can't reproduce it, admit it and write the report anyway. A good programmer can often track down an irreproducible problem from a careful description. For a good discussion on analyzing problems and making them reproducible, see Chapter 5 of Testing Computer Software by Cem Kaner.
The most controversial thing in a bug report is often the bug Impacts: Low, Medium, High, and Urgent. Report should show the priority which you, the bug submitter, believes to be appropriate and does not get changed.

Bug Report Components

Report number:
Unique number given to a bug.

Program / module being tested:
The name of a program or module that being tested

Version & release number:
The version of the product that you are testing.

Problem Summary:
(data entry field that's one line) precise to what the problem is.

Report Type:
Describes the type of problem found, for example it could be software or hardware bug.

Severity:
Normally, how you view the bug.
Various levels of severity: Low - Medium - High - Urgent

Environment:
Environment in which the bug is found.

Detailed Description:
Detailed description of the bug that is found

How to reproduce:
Detailed description of how to reproduce the bug.

Reported by:
The name of person who writes the report.

Assigned to developer:
The name of developer who assigned to fixed the bug.

Status:
Open:
The status of bug when it entered.
Fixed / feedback:
The status of the bug when it fixed.
Closed:
The status of the bug when verified.
(Bug can be only closed by QA person. Usually, the problem is closed by QA manager.)
Deferred:
The status of the bug when it postponed.
User error:
The status of the bug when user made an error.
Not a bug:
The status of the bug when it is not a bug.

Priority:
Assigned by the project manager who asks the programmers to fix bugs in priority order.

Resolution:
Defines the current status of the problem. There are four types of resolution such as deferred, not a problem, will not fix, and as designed.

(Continued on next part...)

Part:   1  2  3  4  5  6  7  8  9   10  11  12  13  14  15  16  17  18