Defect Profile

1.Defect - Nonconformance to requirements or functional / program specification.
2.Bug - A fault in a program, which causes the program to perform in an unintended or unanticipated manner.
3.Bug Report comes into picture once the actual testing starts.
4.If a particular Test Case(s) Actual and Expected Result will mismatch then we will report a Bug against that Test Case.
5.For each bug we are having a Life Cycle. First time when tester identifies a bug then he will give the Status of that bug as 'New'.
6.Once the Developer Team lead go through the Bug Report and he will assign each bug to the concerned Developer and he changes the bug status to 'Assigned'. After that developer starts working on it during that time by changing the bug status as 'Open' once it got fixed he will change the status to 'Fixed'. In the next Cycle we have to check all the Fixed bugs if those are really fixed then concerned tester change the status of that bug to 'Closed' else change the status to 'Reviewed-not-ok'. Finally 'Deferred', those bugs which are going to be fixed in the next iteration.

See the following sample template used for Bug Reporting.
7.Here also the name of Bug Report file follows some naming convention like
Project-> Name-> Bug-> Report-> Ver No-> Release Date
8.All the bolded words should be replaced with the actual Project Name, Version Number and Release Date.
For eg., Bugzilla Bug Report 1.2.0.3 01_12_04
9.After seeing the name of the file anybody can easily recognize that this is a Bug Report of so and so project and so and so version released on the particular date.
10. It reduces the complexity of opening a file and finding for which project it belongs to.
11.It maintains the details of Project ID, Project Name, Release Version Number and Date on the top of the Sheet.
12. For each bug it maintains :--
a)Bug ID
b) Test Case ID
c) Module Name
d) Bug Description
e) Reproducible (Y/N)
f) Steps to Reproduce
g) Summary
h) Bug Status
i) Severity
j) Priority
k) Tester Name
l) Date of Finding
m) Developer Name
n) Date of Fixing.

Bug ID: Bug ID column represents the unique Bug Number for each bug. For this one each organization follows their own standard to define the format of Bug ID.

Test Case ID: This column gives the reference to the Test Case Document, against which test case the bug was reported. With this reference we can navigate very easy in the Test Case Document for more details.

Module Name: Module Name refers to the Module, in which the bug was raised. Finally based on this information we can estimate for each module how many bugs are there in each Module.

Bug Description: It gives the summary of the Bug. What is that bug, what was happened actually instead of expected result.

Reproducible: This column is very important for developers based on this they know whether it can be reproducible or not. If it is reproducible then it is very to developer team to debug that otherwise they will try to find it out. Simply it is Yes or No.

Steps to Reproduce: This column specifies the complete steps to produce that bug. We can say it as Navigation. This is very useful both for testers and developers to reproduce the bug and to debug the bug. If the Reproducible column is yes then only we will specify steps to reproduce column. Otherwise this column is Null.

Summary: This column gives the detailed description of the bug.

Bug Status: This column is very important in Bug Report, it is used to track the bug in each level.

1.New: It is given by the tester when he find out the bug
2.Assigned: It is given by the developer team lead after assigning to concerned developer
3.Open: It is given by the developer while he fixing the bug
4.Fixed: It is given by the developer after he fixed the bug
5.Closed: It is given by the tester if the bug is fixed in new Build
6.Reviewed-not-ok: It is given by the test if the bug is not fixed in new build
7.Deferred: The bug which is going to be fixed in next iteration

Severity: This column tells the effect of that bug to the application. Usually it is given by the Testers. For this severity also various organizations follow different conventions. Here I am providing sample of this severity based on its affect.

Severity It is specified by the tester how much effect it gives to the application.
Very High: Tester will give this status when you are not able to continue your testing eg. Not opening application.
High: Tester will give this status if he is not able to test this Module but he can test some other module.
Medium: Tester will give the status if he is not able to progress in the current module.
Low: Its like cosmetic some spell mistake or look and feel problem.

Priority: This column is filled by Test Lead he will consider the severity of the bug, Time Schedule, Risks associated with the project especially for that bug. Based on that he will give the Status to Priority Very High, High, Medium or Low based on the all aspects.

Tester Name: This column is for the name of the tester, who identifies that particular bug by using this column developers can easily communicate with that particular Tester if any confusion is there to understand the Bug Description.

Date of Finding: This column contains the Date when the tester reported the bug. So that we will get a report for a particular day how many bugs are reported.

Developer Name: This column contains the name of the Developer, who fixed that particular bug. This information is very useful when a particular bug is fixed but still there then Testers can communicate with the concerned Developer to clear doubt.

Date of Fixing: This column contains the Date when the developer fixed the bug. So that we will get a report for a particular day how many bugs are fixed.