Defect Age: Defect Age in Time Defect Fix Date (OR Current Date) - Defect Detection Date

Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 6

Defect Age can be measured in terms of any of the following: Time Phases

DEFECT AGE (IN TIME) Definition Defect Age (in Time) is the difference in time between the date a defect is detected and the current date (if the defect is still open) or the date the defect was fixed (if the defect is already fixed). Elaboration The defects are confirmed and assigned (not just reported). Dropped defects are not counted. The difference in time can be calculated in hours or in days. fixed means that the defect is verified and closed; not just completed by the developer.

Defect Age Formula Defect Age in Time = Defect Fix Date (OR Current Date) Defect Detection Date Normally, average age of all defects is calculated. Example If a defect was detected on 01/01/2009 10:00:00 AM and closed on 01/04/2009 12:00:00 PM, the Defect Age is 74 hours. Uses For determining the responsiveness of the development/testing team. Lesser the age better the responsiveness. DEFECT AGE (IN PHASES) Definition Defect Age (in Phases) is the difference in phases between the defect injection phase and the defect detection phase. Elaboration defect injection phase is the phase in the software life cycle where the defect was introduced. defect detection phase is the phase in the software life cycle where the defect was identified.

Defect Age Formula Defect Age in Phase = Defect Detection Phase Defect Injection Phase Normally, average of all defects is calculated. Example Lets say the software life cycle has the following phases: 1. 2. 3. 4. Requirements Development High-Level Design Detail Design Coding

5. 6. 7. 8.

Unit Testing Integration Testing System Testing Acceptance Testing

If a defect is identified in System Testing and the defect was introduced in Requirements Development, the Defect Age is 6. Uses For assessing the effectiveness of each phase and any review/testing activities. Lesser the age better the effectiveness.

Defect Density Definition, Elaboration, Formula, and Uses: DEFINITION Defect Density is the number of confirmed defects detected in software/component during a defined period of development/operation divided by the size of the software/component. ELABORATION The defects are: confirmed and agreed upon (not just reported). Dropped defects are not counted.

The period might be for one of the following: for a duration (say, the first month, the quarter, or the year). for each phase of the software life cycle. for the whole of the software life cycle.

The size is measured in one of the following: Function Points (FP) Source Lines of Code

DEFECT DENSITY FORMULA

USES For comparing the relative number of defects in various software components so that high-risk components can be identified and resources focused towards them. For comparing software/products so that quality of each software/product can be quantified and resources focused towards those with low quality.

Defect Detection Efficiency Definition, Elaboration, Formula, Unit, Target Value, Uses, Example:

DEFINITION Defect Detection Efficiency (DDE) is the number of defects detected during a phase/stage that are injected during that same phase divided by the total number of defects injected during that phase. ELABORATION defects: phase: Can be any phase in the software development life cycle where defects can be injected AND detected. For example, Requirement, Design, and Coding. injected: The phase a defect is injected in is identified by analyzing the defects [For instance, a defect can be detected in System Testing phase but the cause of the defect can be due to wrong design. Hence, the injected phase for that defect is Design phase.] FORMULA DDE = (Number of Defects Injected AND Detected in a Phase / Total Number of Defects Injected in that Phase) x 100 % Are confirmed and agreed upon (not just reported). Dropped defects are not counted.

UNIT Percentage (%) The ultimate target value for Defect Detection Efficiency is 100% which means that all defects injected during a phase are detected during that same phase and none are transmitted to subsequent phases. [Note: the cost of fixing a defect at a later phase is higher.] USES For measuring the quality of the processes (process efficiency) within software development life cycle; by evaluating the degree to which defects introduced during that phase/stage are eliminated before they are transmitted into subsequent phases/stages. For identifying the phases in the software development life cycle that are the weakest in terms of quality control and for focusing on them. EXAMPLE Injected Phase Injected Phase Requirements 10 Defects Specific Activity Require- ment Develop- ment 4 Detected Defects Detected Phase Detected Defects that were Injected Specific Activity in the same Phase Require- ment Review 4 Defect Detection Efficiency 40.00%[= 4 / 10] TARGET VALUE

62.50%[= 15 / Design 24 Design 16 Design Review 15 24] 14.19%[= 22 / Coding Unit Testing Integration Testing 0 System Testing Acceptance Testing 0 5 3 Acceptance Testing Operation 0 83 30 System Testing Integration Testing 0 25 Unit Testing 155 Coding 23 Code Review 22 155]

Opera- tion 0

The DDE of Requirements Phase is 40.00% which can definitely be bettered. Requirement Review can be strengthened. The DDR of Design Phase is 62.50 % which is relatively good but can be bettered. The DDE of Coding Phase is only 14.19% which can be bettered. The DDE for this phase is usually low because most defects get injected during this phase but one should definitely aim higher by strengthening Code Review. [Note: sometimes, Coding and Unit Testing phases are combined.]

The other Phases like Integration Testing etc do not have DDE because defects do not get Injected during these phases.

Cost of Quality: Definition, Explanation, Formula, Calculation, Notes: DEFINITION Cost of Quality (COQ) is a measure that quantifies the cost of control/conformance and the cost of failure of control/non-conformance. In other words, it sums up the costs related to prevention and detection of defectsand the costs due to occurrences of defects. Definition by ISTQB: cost of quality: The total costs incurred on quality activities and issues and often split into prevention costs, appraisal costs, internal failure costs and external failure costs. Definition by QAI: Money spent beyond expected production costs (labor, materials, equipment) to ensure that the product the customer receives is a quality (defect free) product. The Cost of Quality includes prevention, appraisal, and correction or repair costs. EXPLANATION Cost of Control (Also known as Cost of Conformance) Prevention Cost

The cost arises from efforts to prevent defects. Example: Quality Assurance costs The cost arises from efforts to detect defects. Example: Quality Control costs

Appraisal Cost

Cost of Failure of Control (Also known as Cost of Non-Conformance) Internal Failure Cost The cost arises from defects identified internally and efforts to correct them. Example: Cost of Rework (Fixing of internal defects and re-testing) The cost arises from defects identified by the client or end-users and efforts to correct them. Example: Cost of Rework (Fixing of external defects and re-testing) and any other costs due to external defects (Product service/liability/recall, etc)

External Failure Cost

FORMULA / CALCULATION Cost of Quality (COQ) = Cost of Control + Cost of Failure of Control where Cost of Control = Prevention Cost + Appraisal Cost and Cost of Failure of Control = Internal Failure Cost + External Failure Cost

NOTES In its simplest form, COQ can be calculated in terms of effort (hours/days).

A better approach will be to calculate COQ in terms of money (converting the effort into money and adding any other tangible costs like test environment setup). The best approach will be to calculate COQ as a percentage of total cost. This allows for comparison of COQ across projects or companies. To ensure impartiality, it is advised that the Cost of Quality of a project/product be calculated and reported by a person external to the core project/product team (Say, someone from the Accounts Department). It is desirable to keep the Cost of Quality as low as possible. However, this requires a fine balancing of costs between Cost of Control and Cost of Failure of Control. In general, a higher Cost of Control results in a lower Cost of Failure of Control. But, the law of diminishing returns holds true here as well.