Overview | |
---|---|
Definition (Hover Text) | The Defect Rejection Rate KPI measures how effective the testing team is by tracking the percentage of defects that are rejected during an iteration. |
Source Tools | Jira, Azure Boards |
Graph type | Line Chart |
Filters | - |
Hover Format on KPI | Sprint Name: <<Percentage Value>> Rejected Defects: <<Value>> Total Defects : <<Value>> |
Fields on Overlay | Sprint Name Defect ID Issue Description Defects Rejected |
Business Logic | |
Calculation Formula | No. of defects tagged to stories in the iteration that are rejected / Total no. of defects tagged to stories in a iteration
Formula: Imagine your team tagged 50 defects to stories in an iteration, but 10 of these defects were rejected. The Defect Rejection Rate would be: Defect Rejection Rate =10 / 50 = 0.2 or 20% |
Trend | A lower Defect Rejection Rate indicates better quality, as it means fewer defects are being incorrectly reported and then rejected. |
Maturity Levels | DRR maturity is assessed by averaging data from the last 5 sprints. This helps in understanding the stability and improvement over time. M1 - >=75% , M2 - >=50-75% , M3 - >=30-50% , M4 >=10-30% , M5 <10% |
Instance level thresholds | Target KPI Value denotes the bare minimum a project should maintain for a KPI. |
Global Configurations- (Field Mapping) | |
Processor Fields | Whenever we update the defect mapping and issue type mapping, whether we add or remove any issue type, we must run the processor. This is necessary to show the changes in the KPI. Defect Mapping :
|
Mandatory fields
| Project Settings
Defect Mapping :
|
How to Validate KPI | |
Suggested ways of working | |
Sample JQLs | JQL query to get the defects created during a sprint: project = "Your Project Name" AND issuetype = Bug AND Sprint in openSprints() JQL query to get the defects rejected during a sprint: project = "Your Project Name" AND issuetype = Bug AND Sprint in openSprints() AND status changed to Rejected |
Best Practices | |
Automate Testing | Implement automated testing (unit, integration, and end-to-end tests) to catch defects early in the development process. |
Pair Programming | Implement pair programming to increase code quality and reduce the likelihood of defects being introduced. |
Adopt TDD/BDD | Use Test-Driven Development (TDD) or Behavior-Driven Development (BDD) methodologies to write tests before code, ensuring that functionality is well-defined and tested from the start. |
Use Static Analysis Tools | Implement static code analysis tools to automatically check code for potential defects and enforce coding standards. |
Benefits of KPI | |
Quality Measurement | It helps in measuring the quality of the code being produced and identifying areas where improvements are needed. |
Predictability | Understanding the defect injection rate can help in forecasting the amount of rework required and in planning more accurately. |
Cost Reduction | Reducing the defect injection rate can lead to lower costs associated with fixing bugs, especially those found later in the development cycle or after release. |
Process Improvement | By tracking this metric, teams can identify stages in the development process where defects are commonly introduced and take steps to improve those stagesHelps ensure that only valid defects are reported, leading to more accurate and useful defect tracking. Reduces the number of invalid defect reports, allowing the team to focus on real issues. |
Efficiency | Saves time by reducing the effort spent on investigating and rejecting invalid defects. |
Risk Management | Helps in assessing the risk associated with defects and planning mitigation strategies accordingly. |
Process Improvement | Helps in refining the defect reporting and validation process, leading to continuous improvement in quality assurance. |
Page Comparison
General
Content
Integrations