Software Testing-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.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 :-- <!--

12.google_ad_client = "pub-0583724520158210";
 google_ad_width = 468;
google_ad_height = 60;
google_ad_format = "468x60_as";
google_ad_type = "text";
google_ad_channel = "";
google_color_border = "FFFFFF";
google_color_bg = "FFFFFF";
google_color_link = "000000";
google_color_text = "000000";
google_color_url = "008000";
google_ui_features = "rc:6";
//-->
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.
13.
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.
14.
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.
15.
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.
16.
Bug Description: It gives the summary of the Bug. What is that bug, what
was happened actually instead of expected result.
17.T
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.
 <!--
google_ad_client = "pub-0583724520158210";
google_ad_width = 468;
google_ad_height = 60;
google_ad_format = "468x60_as";
google_ad_type = "text";
google_ad_channel = "";
google_color_border = "FFFFFF";
google_color_bg = "FFFFFF";
google_color_link = "000000";
google_color_text = "000000";
google_color_url = "008000";
google_ui_features = "rc:6";
//-->
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.
18.
Summary: This column gives the detailed description of the bug.
19.
Bug Status: This column is very important in Bug Report, it is used to track
the bug in each level. Bug Status It is used to keep track the status of the
bug in this bug report
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 u r 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.
click here for the Defect profile document