Defect reporting

During each phase of the SDLC in HP TestDirector for

Quality Center, we reported all discrepancies and issues
relating to a project. When a defect was opened, my
team would follow the process described below.
1. A release team member would log a defect report
in HP TestDirector for Quality Center as soon as
enough information was gathered to recreate or
explain the situation. The default status was set to
“New.” I encouraged everyone on the team to log
defects as soon as possible to allow optimum time
for investigation and repair.
2. The person who logged the defect assigned an
initial severity to the defect based on how it affected
the application and/or the test process itself. Listed
below are the requirements we used for defining the
defect's severity.
a. Show stopper: This level of defect prevented the
team from proceeding in an area that would affect
deployment schedules. No workaround was available,
and the team required an immediate solution.
b. High: This level of severity was the same as “show
stopper,” except that a workaround existed and the
team could wait for the defect to be fixed until the
next scheduled build.
c. Medium: The team needed the defect to be fixed
as soon as possible prior to deployment.
d. Low: The team could wait for the defect to be
fixed in a subsequent release (a later project).
e. Enhancement: A defect that could be fixed
any time.
3. The team used a defect writing standard to include
all pertinent information. A team member then
incorporated the specifics of the discrepancy,
including print screens, associated test cases,
selection criteria and any other critical information
to help resolve the issue.
4. The team used the “Assign To” field to indicate
who would be the likely choice to conduct an initial
investigation, and the appropriate group leader was
assigned to the defect. This fast-track assignment
allowed defects to be reviewed and possibly resolved
prior to the defect-resolution meeting described in
the next section. If the team could not decide on the
resolving group, the defect was assigned to the
project manager.
5. If someone other than a release team member
identified a discrepancy, that individual forwarded
the specifics to the test lead so the data could be
logged into HP TestDirector for Quality Center.

Defect-resolution meeting
We wasted time during the testing phase when defects
were not acted upon in an efficient manner or went
undetected. During defect-resolution meetings, we
reviewed and resolved defects efficiently. So we decided
to discuss defects in a periodic meeting with the test
lead and representatives from the development, project
management, product management (user acceptance)
and business groups. The highest number of defects in
the system approached 5,000, and we handled 25 to
50 defects per defect meeting.
The test lead updated HP TestDirector for Quality Center
during the meeting, which centered on a review of each
defect report. Each report was prepared in HP Test-
Director for Quality Center and contained all information
needed to determine the severity of the defect and to
whom it should be assigned. The defect reports were
sorted by severity and status so that high-profile and new
bugs would be addressed first.
“New” defects were first reviewed for the criteria
listed below.
• Summary and description: If a defect lacked the
information needed to adequately investigate the
discrepancy, we assigned it back to the individual
who found the defect to provide more information.
The defect maintained “New” status. The individual
who found the defect then provided the necessary
information by updating the defect in HP TestDirector
for Quality Center. Next, the defect was assigned
back to the project manager via the test lead so it
could follow the process for “New” defects.
• Severity: We reviewed a defect's severity for accuracy
and required the team's consensus.
• Assign to: We assigned the defect to the appropriate
team (environment, developer or business analyst)
for investigation and resolution. Note: Whenever an
assignment was changed, HP TestDirector for Quality
Center was set up to send out an e-mail to the
assignee so the assignee immediately knew if a defect
required attention.
• Status: We changed the defect's status from “New”
to “Open.”
We set up HP TestDirector for Quality Center to send
e-mail to the assignee each time a defect was assigned,
and to send an e-mail to the test lead each time a
defect changed status. The project manager and test
lead also received an e-mail each time a new defect
was entered. The test manager received an e-mail each
time status was changed to “User Error” or “Works” as
designed. The test manager then used this information
for mentoring. The development manager received an
e-mail for each status changed to “Reopen.” You can

easily customize HP TestDirector for Quality Center so

that these changes can be made by a non-programmer;
my team often made changes to support processimprovement
initiatives. One tester used 50 percent of
his time to administer HP TestDirector for Quality Center
and make all of the experimental and real changes. This
is one of the most powerful reasons to use this solution.
Next, my team would review any “Open” defects, and
this is where the “Comments” became useful. At each
stage of defect-resolution from “New” to “Closed,” we
entered comments to document the defect’s journey.
The “Comments” revealed the why, how and when
a defect would be resolved. I would then make appropriate
assignments to move the defect’s resolution along.
If the system’s behavior was acceptable and the systems
functioned as expected, we updated the defect with
the acceptance information and assigned it to the test
analyst who set the defect status to “Closed.”
My team then reviewed what was entered in a userdefined
field called “Cause.” This enabled us to examine
the root cause of the defect, as well as to pull reports at
a later time for process-improvement purposes. We also
had the option to review any disputed “Closed” defects.
Defect fix
Because we held defect-resolution meetings, we assigned
defects to the appropriate lead from one of the resolving
groups: development, environment support or the
business group.
1. We assigned the defect to the business group if there
were any questions regarding a defect's
requirements. At this point, we made any necessary
requirement changes

2. We assigned the defect to the development lead if

we suspected there was a bug in the code, if any
code changes were needed, or if it was identified as
an enhancement for a later release of the application.
This person then assigned the defect to a developer.
When the developer fixed the code, the developer
changed the defect status to “Fixed.” The fixed defects
made their way into build packages and were handed
off to the test group. HP TestDirector for Quality Center
produced a report that reflected all defects fixed in a
build. When we handed off a build, the test lead set
the status of the “Fixed” defects to “Ready to Retest,”
and assigned the defect to a tester for retesting.
Note: A strength of HP TestDirector for Quality Center
is its ability to define attributes for defects so as to
support various processes. One of these is the “Code
Fix” process. When configuring HP TestDirector for
Quality Center, the code fix team took into account
the attributes needed to track the defect as it went
through the fixing process: setting developer priorities,
keeping fix-time statistics, etc. The same procedure
was applied by all the other groups. The team
controlled the quality of the information for each
defect by a system of attribute ownership.
3. We assigned the defect to the environment support
group when configuration and set up errors were
identified. These discrepancies usually surfaced when
we ran a “smoke test.” (Smoke testing is non-exhaustive
software testing that determines whether the most
crucial functions of a program work without disturbing
the finer details of the program. The term was derived
from hardware testing, in which the device passed the
test if it didn’t catch fire the first time it was turned on.)
The environment support group fixed the problem, set
the status of the defect to “Ready to Retest” and then
assigned the defect back to the test lead for retest and
subsequent closure.