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
Issue type Mapping
| KPI Specific fields | Workflow Status Mapping Resolution type to be included eg; Invalid , Duplicate Status to identify Rejected defects eg; Rejected :
|
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 | How does the KPI help|||
Quality Measurement | Helps 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