For every improvements or enhancements we make to a system,
whether it is a product, website, service or software, there are defects. Depending on the nature and scope
Here at developerWorks, we use IBM Rational ClearQuest to keep track of change requests, which are further
categorized as Request for Enhancments (RFE) or defects. It doesn't get any simpler than that. A defect goes through its own workflow from
the moment it is submitted till the point it is validated and closed. Let's look at some of the stages of a defect
SUBMITTED - a defect submitted by a person reporting a
problem. This doesn't necessarily have
to be a tester. It can be a developer,
project manager, UI team, or anyone with access to defect tracking tool that
has a stake in the project.
ASSIGNED - A defect is assigned an owner with a business
priority. This way an owner will know
the nature of the issue as well as business priority to address in a given time.
RESOLVED - The owner of the defect will mark the issue
resolved with appropriate notes saying the issue is fixed, or unreproducible, works
as designed or feature not in scope. There
can be many reasons to mark a defect resolved.
By marking it resolved, the defect owner is changed back to the tester
who originally reported the problem, that way they know that the fix for the
defect is ready for testing.
CLOSED - Once a defect is tested, and meets expected
behavior then it is marked as closed.
These are just the basic stages that a defect goes through. Of course, the owner can mark the defect
duplicate, if another one identical to it exists, or reassign the defect if the
issue is reproducible. Every
organization or company can customize their own workflows. But having these different stages for a
defect, it makes it easier for stakeholders to measure and manage the quality
of a system. Generating reports by
means or running queries in ClearQuest, we can see how many high severity
defects are open; how many are resolved and ready to test; find fix vs. find
rate to determine the progress being made.
All these data generated from the defect tracking tool can help us make
critical decisions at any given point during the release on whether we are
ready to go live or not.
Now let's look some of the benefits of using a defect
tracking tool such as ClearQuest:
a) Ease of access and simple to use. Having multiple replicas based out of several
locations makes geographically dispersed team to track defects from anywhere. Whether
your team is a small workgroup or spread across several
locations, ClearQuest is scalable for teams that are small or large in size.
Ability to generate real time reports, and customize them
by business priorities, owners and other fields allows you to find out
who is assigned to which defects or how many defects belong in a
c) History of each defect can reveal audit trails &
ensure changes are made by authorized users.
d) Its customizable & automated workflow allows
integration with other IBM tools such as
ClearCase (for software configuration management), RequisitePro (for
requirements management), and more.
e) A central tracking tool that not only tracks defects, but
also RFEs for the purpose of tracking features to be considered for future release(s).
f) An e-mail notification system that notifies identified
team members by components or specific defects if they are on the notification
list. Benefits include defect awareness
and call to action.
All of the benefits of using a defect tracking tool such as
ClearQuest is only effective if everyone on the team collectively uses it. The idea is to keep the workflow and usage of the tool simple so that defects are measured
and managed wisely.