Friday, January 20, 2012

Defect Tracking or Defect/Bug Life Cycle

Hey folks,

Defect Tracking or bug life cycle is vary from company to company and tools to tools.


Defect Tracking
To track defects, a defect workflow process has been implemented. Defect workflow training will be conducted for all test engineers. The steps in the defect workflow process are as follows:
a) When a defect is generated initially, the status is set to "New". (Note: How to document the defect, what fields need to be filled in and so on, also need to be specified.)
b) The Tester selects the type of defects:
Bug
Cosmetic
Enhancement
Omission
c) The tester then selects the priority of the defect:
Critical - fatal error
High - require immediate attention
Medium - needs to be resolved as soon as possible but not a showstopper
Low - cosmetic error
d) A designated person (in some companies, the software manager; in other companies, a special board) evaluates the defect and assigns a status and makes modifications of type of defect and/or priority if applicable).
The status "Open" is assigned if it is a valid defect.
The status "Close" is assigned if it is a duplicate defect or user error. The reason for "closing" the defect needs to be documented.
The status "Deferred" is assigned if the defect will be addressed in a later release.
The status "Enhancement" is assigned if the defect is an enhancement requirement.
e) If the status is determined to be "Open", the software manager (or other designated person) assigns the defect to the responsible person (developer) and sets the status to "Assigned".
f) Once the developer is working on the defect, the status can be set to "Work in Progress".
g) After the defect has been fixed, the developer documents the fix in the defect tracking tool and sets the status to .fixed,. if it was fixed, or "Duplicate", if the defect is a duplication (specifying the duplicated defect). The status can also be set to "As Designed", if the function executes correctly. At the same time, the developer reassigns the defect to the originator.
h) Once a new build is received with the implemented fix, the test engineer retests the fix and other possible affected code. If the defect has been corrected with the fix, the test engineer sets the status to "Close". If the defect has not been corrected with the fix, the test engineer sets the status to .Reopen.. Defect correction is the responsibility of system developers; defect detection is the responsibility of the AMSI test team. The test leads will manage the testing process, but the defects will fall under the purview of the configuration management group. When a software defect is identified during testing of the application, the tester will notify system developers by entering the defect into the PVCS Tracker tool and filling out the applicable information.

How to write Effective Defect Report


 
Defect reports are most important deliverables to come out of test. Effective defect report will
  • Reduce the number of defects returned from development
  • Improve the speed of getting defect fixes
  • Improve the credibility of test
  • Enhance teamwork between test and development
Defect Remarks
  1. Condense - Say it clearly but briefly
  2. Accurate - Is it a defect or could it be user error, misunderstanding, etc.?
  3. Neutralize - Just the facts. No zingers. No humor. No emotion.
  4. Precise - Explicitly, what is the problem?
  5. Isolate - What has been done to isolate the problem?
  6. Generalize - What has been done to understand how general the problem is?
  7. Re-create - What are the essentials in triggering/re-creating this problem? (environment, steps, conditions)
  8. Impact - What is the impact to the customer? What is the impact to test?
Sell the defect.
 
Debug - What does development need to make it easier to debug?
(traces, dumps, logs, immediate access, etc.)
 
Evidence - What documentation will prove the existence of the error?

The defect report contains proper following data.
<!--[if !supportLists]-->1.     <!--[endif]-->Title of bug - it should start with your Module number along with your defect summary. For ex Module No-Module Name- Record is not getting updated in database.
2. Select Cross Reference#, if any
3. Select all mandatory details like, opened by, severity, found during, assigned to, etc.
 
In comment section we should provide detail information along with test environment. Because if any new member validates the defect then he/she should able to understand the same in better way.
In comment section, we should follow as:
1. Copy title of bug
2. Test environment: like L1, L2(if any), Browser detail(if any), Database details (if any)
3. Steps to reproduce
4. Actual output
5. Expected output
6. Build date and number (if any)
7. Attachment of log or screenshot (if any)
8. Any special observation/comment
9. Test data (if any) like ID, xml etc.
 
Same way, when we close or retest or reopen the details we need to follow same style.
1. Mention on which build and date you test the defect.
2. Reason for closing the defect, like DB getting updated properly.
3. Defect due to Code, Document etc (if any)
4. Provide test data with which defect is validated.