Defect management Process

Introduction   Defect can be defined as an unexpected behavior of the software. No software exists without a defect or bug. The elimination of bugs from the software depends upon the efficiency of testing done on the software. A defect is basically the difference between the expected result and the actual result.

A defect is a specific concern about the quality of an Application under Test (AUT).

The cost of finding and correcting defects represents one of the most expensive software development activities. Defect should be finding as early as possible in the software to reduce the cost of fixing of the bugs. If a defect found later phase in the software, the cost of the fixing that bug becomes high.

It is fact that it will not be possible to eliminate all defects from the software. While defects may be inevitable, we can minimize their number and impact on our projects. To do this, project management team needs to implement a defect management process (DMP) that focuses on preventing defects, finding defects as early as possible in the process, and minimizing the impact of defects.

Defect Management Process: The defect management process is based on the following general principles:

There are following parts to manage the process:

Defect Prevention, Baseline delivery, Defect Discovery, Defect Resolution and Process Improvement.

Defect management process can be understood by diagrammatically:

Defect Management Process

Defect Prevention: It is a process of improving quality and productivity by preventing the injection of defects into a software product. It is virtually impossible to eliminate the defects altogether.

Objective of defect Prevention process are:

1. Identify and analyze the causes of defect, so that we reduce the occurrence of defect.
2. Reduction in number of defect category.
3. Reduce most frequent type of defects such as “not following coding guidelines” or Ambiguity within requirement and specification.
4. Reduction in the extent of defect escapes between the test phase and the release.
5. Establish practice within projects to identify defects early in the process.
6. Set goals for improving critical processes with team-level accountability.
7. It is practically impossible to prevent the defects in the software. So testers and developers should collaborate for quick detection of defects and minimize the risk. They should assess the critical risk associated with the system and identified the defects.

Baseline delivery: This process appears in the DMP when:

A predefined milestone is finished then product is baselined. Further development work continues from one stage to another stage to complete another milestone. A product should be considered baselined when developers pass it to the testes for testing.

Defect Discovery:  A defect is said to be discovered when it is brought to the attention of the developers and acknowledged (i.e., “Accepted”) to be valid one. Team should find defects before they become major problems. As soon as team finds the defects, they should report them so that those can be resolved. Team should also make sure that defects should be acknowledged by developers and should be valid one.

Defect Resolutions: A resolution process needs to be established for use in the process where there is a dispute regarding a defect. For example, if the group uncovering the defect believes it is a defect but the developers do not, a quick-resolution process must be in place.

The 2 recommended processes:

• A senior manager of the software department will be selected to resolve the dispute.
• Arbitration by the software owner – The problem should be discussed with the product owner to determine whether or not the problem is a defect.

Process Improvement:

Everyone has different view on process improvement. Developer thinks that defect is not a big deal, but there was a defect it was a big deal.

Testers thought that If this defect could have gotten later into the process before it was captured, there can be other defects may be present that have not been discovered.  For customer’s point of view, a defect can be anything that dissatisfies the customers whether it was in requirement, designing, coding or testing.

Program leadership advice the teams that efforts should be made to analyze the process and find out the cause behind the defects and also analyze the fact to prevent such defects.

So what can we do to improve the process? There are some goals of Defect management process:

• Senior management must understand, support, and be a part of the Defect Management Program.
• The Defect Management process should be integrated into the overall software development process and used by the team to improve the process.
• If we have automated script for the project, we should use those to find out bugs as early as possible.
• Specific development approaches (e.g., testing, inspections, reviews, exit criteria etc.) should be chosen based on project objectives.
• The efforts which use to improve the process should be driven by the measurement process: metrics, reporting and decision making etc.
• The defect management process should be risk driven.
• We can reduce the occurrence of defects by following points:
• By reviewing test scenarios and test cases
• By defining exit Criteria for Developer testing
• By defining QA acceptance of Development
• Functional/Non-functional Requirements
• Technical requirements
• Environment baselines
• GUI checklists prior to test case execution

We can use critical metrics to implement the process improvement

Critical metrics is a joint session of,

• What can we do to ensure that more of defects are found earlier in the cycle?
• Last minute discoveries of defects have been analyzed to determine why they were missed in our normal SIT test cycle?
• When these issues are found late in the cycle, what is done to ensure that we catch them next time?
• This is stemming from the way our business team is doing their testing (ad-hoc testing coming late, late in the process).

Calculating Metrics and Phases

Below are the few points which should be include when calculate the metrics:

• % Complete
• % Defects Corrected
• % Test Coverage
• % Rework
• % Test Cases Passed
• % Test Effectiveness
• % Test Cases Blocked
• % Test Efficiency
• First Run Fail Rate
• Defect Discovery Rate
• Overall Fail Rate

Identified Critical Risk: There are few challenges which can affect the critical metrics.

• Technology Risk
• No advanced technology available or the existing technology is in initial stages.
• Tight target dates
• Limited budget
• Bottlenecks within the Development & Testing cycles
• Resource constraints
• Continues changing in the requirements

Types of Errors: There are few errors which we generally face. If we keep those in mind during software development, we can find more defects early in the software development process and provide support in the improvement of the DMP.

Human Errors Omission:

• Knowledge: Lack of knowledge of application.
• Ignorance: Nature of ignorance.
• Informational: Lack of information.
• Process- Related: Lack of knowledge of process.
• Translation:
  • Miscommunication: Perception to understand the requirement.
  • Mismatch in solution and requirement: Whatever built does not match with the requirements.
  • Mismatch with requirement and test case: Test cases do not match with the requirement so it is very necessary to check the complete requirement first and then take a decision.

Design and Coding

• Affect Data Integrity: Affect on the consistency and accuracy of data throughout the software development life cycle.
• Alter Correctly stored data: Did some mistake while altering data which is correctly stored in DB.
• Affect downstream system dependencies : Affect the system dependencies
• Affect testing outcomes: If something wrong build in the code, that can affect outcome of the testing.

Testing

• Failure to notice a problem
• Misreading the screen
• Failure to execute a planned test
• Criteria disagreements

 

Written By: – Meenakshi Gangwar, QA Engineer, Mindfire Solutions