A defect can be defined in one or two ways. From the producer's viewpoint, a defect is a deviation from specifications, whether missing, wrong, etc. From the Customer's viewpoint, a defect is any that causes customer dissatisfaction, whether in the requirements or not, this is known as "fit for use". It is critical that defects identified at each stage of the project life cycle be tracked to resolution.
Defects are recorded for following major purposes:
· To correct the defect
· To report status of the application
· To gather statistics used to develop defect expectations in future applications
· To improve the software development process
Most project teams utilize some type of tool to support the defect tracking process. This tool could be as simple as a white board or a table created and maintained in a word processor or one of the more robust tools available today, on the market, such as Mercury's Test Director etc. Tools marketed for this purpose usually come with some number of customizable fields for tracking project specific data in addition to the basics. They also provide advanced features such as standard and ad-hoc reporting, e-mail notification to developers and/or testers when a problem is assigned to them, and graphing capabilities.
At a minimum, the tool selected should support the recording and communication significant information about a defect. For example, a defect log could include:
· Defect ID number
· Descriptive defect name and type
· Source of defect -test case or other source
· Defect severity
· Defect priority
· Defect status (e.g. open, fixed, closed, user error, design, and so on) -more robust tools provide a status history for the defect
· Date and time tracking for either the most recent status change, or for each change in the status history
· Detailed description, including the steps necessary to reproduce the defect
· Component or program where defect was found
· Screen prints, logs, etc. that will aid the developer in resolution process
· Stage of origination
· Person assigned to research and/or correct the defect
Severity versus Priority
The severity of a defect should be assigned objectively by the test team based on pre defined severity descriptions. For example a "severity one" defects maybe defined as one that causes data corruption, a system crash, security violations, etc. In large project, it may also be necessary to assign a priority to the defect, which determines the order in which defects should be fixed. The priority assigned to a defect is usually more subjective based upon input from users regarding which defects are most important to them, and therefore should be fixed first.
It is recommended that severity levels be defined at the start of the project so that they intently assigned and understood by the team. This foresight can help test teams avoid the common disagreements with development teams about the criticality of a defect.
Some general principles
· The primary goal is to prevent defects. Wherever this is not possible or practical, the goals are to both find the defect as quickly as possible and minimize the impact of the defect.
· The defect management process, like the entire software development process, should be risk driven, i.e., strategies, priorities and resources should be based on an assessment of the risk and the degree to which the expected impact of risk can be reduced.
· Defect measurement should be integrated into the development process and be used by the project team to improve the development process. In other words, information on defects should be captured at the source as a natural by-product of doing the job. People unrelated to the project or system should not do it.
· As much as possible, the capture and analysis of the information should be automated. There should be a document, which includes a list of tools, which have defect management capabilities and can be used to automate some of the defect management processes.
· Defect information should be used to improve the process. This, in fact, is the primary reason for gathering defect information.
· Imperfect or flawed processes cause most defects. Thus, to prevent defects, the process must be altered.
The Defect Management Process
The key elements of a defect management process are as follows.
· Defect prevention
· Deliverable base-lining
· Defect discovery/defect naming
· Defect resolution
· Process improvement
· Management reporting
Defects are recorded for following major purposes:
· To correct the defect
· To report status of the application
· To gather statistics used to develop defect expectations in future applications
· To improve the software development process
Most project teams utilize some type of tool to support the defect tracking process. This tool could be as simple as a white board or a table created and maintained in a word processor or one of the more robust tools available today, on the market, such as Mercury's Test Director etc. Tools marketed for this purpose usually come with some number of customizable fields for tracking project specific data in addition to the basics. They also provide advanced features such as standard and ad-hoc reporting, e-mail notification to developers and/or testers when a problem is assigned to them, and graphing capabilities.
At a minimum, the tool selected should support the recording and communication significant information about a defect. For example, a defect log could include:
· Defect ID number
· Descriptive defect name and type
· Source of defect -test case or other source
· Defect severity
· Defect priority
· Defect status (e.g. open, fixed, closed, user error, design, and so on) -more robust tools provide a status history for the defect
· Date and time tracking for either the most recent status change, or for each change in the status history
· Detailed description, including the steps necessary to reproduce the defect
· Component or program where defect was found
· Screen prints, logs, etc. that will aid the developer in resolution process
· Stage of origination
· Person assigned to research and/or correct the defect
Severity versus Priority
The severity of a defect should be assigned objectively by the test team based on pre defined severity descriptions. For example a "severity one" defects maybe defined as one that causes data corruption, a system crash, security violations, etc. In large project, it may also be necessary to assign a priority to the defect, which determines the order in which defects should be fixed. The priority assigned to a defect is usually more subjective based upon input from users regarding which defects are most important to them, and therefore should be fixed first.
It is recommended that severity levels be defined at the start of the project so that they intently assigned and understood by the team. This foresight can help test teams avoid the common disagreements with development teams about the criticality of a defect.
Some general principles
· The primary goal is to prevent defects. Wherever this is not possible or practical, the goals are to both find the defect as quickly as possible and minimize the impact of the defect.
· The defect management process, like the entire software development process, should be risk driven, i.e., strategies, priorities and resources should be based on an assessment of the risk and the degree to which the expected impact of risk can be reduced.
· Defect measurement should be integrated into the development process and be used by the project team to improve the development process. In other words, information on defects should be captured at the source as a natural by-product of doing the job. People unrelated to the project or system should not do it.
· As much as possible, the capture and analysis of the information should be automated. There should be a document, which includes a list of tools, which have defect management capabilities and can be used to automate some of the defect management processes.
· Defect information should be used to improve the process. This, in fact, is the primary reason for gathering defect information.
· Imperfect or flawed processes cause most defects. Thus, to prevent defects, the process must be altered.
The Defect Management Process
The key elements of a defect management process are as follows.
· Defect prevention
· Deliverable base-lining
· Defect discovery/defect naming
· Defect resolution
· Process improvement
· Management reporting
0 comments:
Post a Comment