Turnover refers to the rate at which agile team members leave the company and must be replaced. I think this depends entirely on what your calculation for “defect density” is. Get started with Bold BI by signing up for a free 15-day trial and begin creating interactive business intelligence dashboards.

Number of items completed in a given time period — similar to throughput in kanban. Total time a feature exists from initial creation to customer delivery — similar to lead time in kanban. Visualization of completed work over time, similar to a burnup chart. Cumulative flow diagrams use color-coding to represent different statuses (e.g., in progress, done, in backlog). Based on a single question that asks customers how likely they are to recommend your product to another person — an indicator of quality and value. Answers are submitted on a 0–10 scale from “not likely” to “very likely.”

Metrics for tracking the testing efforts:

As we know, defect density is measured by dividing total defects by the size of the software. The goal is not about detecting the defects but to detect defects that actually matter. Therefore, it’s crucial to understand the factors that result in an efficient outcome. Developers and the testing team need to arrange all the necessary conditions before initiating this process. This helps developers trace the affected areas properly, allowing them to achieve highly accurate results. But, choosing the right metrics, implementing them correctly, and following them effectively is the only key to the success of the software testing process.

Remember, every defect tells a story—a story of missed opportunities, potential learning, and growth areas. Number of deployments that have failed in a given timeframe — an indicator of code stability. Total work in progress across all stages — similar to WIP in kanban. Queue length provides a view of how many items are sitting in each column over time.

Helps prioritize work in sprints

In another case, senior management might think that the amount of time and effort invested in the agile testing metrics is not beneficial to the overall business. Besides being an effective agile health monitor, agile metrics can help you track progress towards your goals. It is common among agile teams to establish performance standards based on agile metrics (which you might refer to as “agile KPIs”). Agile KPIs offer a quantifiable way to show if you have improved — and demonstrate your success. Of course, defect density is a powerful measure of the effectiveness of a software development process. When bugs consistently escape to production it tells us the something is seriously wrong in our software development process.

It is vital to measure the number of defects within the code and the time taken to fix them. There should be more emphasis on the number of defects in the code than the time taken to resolve those defects. Suppose multiple defects are occurring numerous times in the code and required to be fixed multiple times. In that case, it depicts a gap in the developer’s skills or misunderstanding of the software testing requirements that need to be adequately addressed. Your software quality assurance process might be effective, yet there can be room for improvement in terms of efficiency. Defect category, mean time to detect defects and mean time to repair are examples of such testing metrics.

Defect Category

As a general practice, your set of metrics should also have a cost related test metrics. Amount of different types of work (e.g. new features versus bug fixes) completed over time. Measure of how much work is assigned to each scrum team member for the current sprint.

By leveraging these metrics, agile teams ensure that the code adheres to established industry standards, such as indentation, inline comments, and correct usage of spacing. Defect density metric not only indicates the quality of the product being developed, but it can also be used as a basis for estimating what is defect density a number of defects in the next iteration or sprint. It can be defined as the number of defects per 1,000 lines of code or function points. In my 20+ years in software, I’ve never come across a team/leader/engineer that cares about defect density as per this definition (bugs per line of code)!

An introduction to Agile Software Testing Metrics

Consider a scenario in which your team has a web app like the one shown in the following image. It is a chart that depicts the graphical representation of the rate at which teams complete their tasks and shows how much work is yet to be completed within a defined sprint period. Typically in this chart, the sprint dates are represented on the x-axis, and ideal effort hours for completing a task using the remaining hours of effort are represented on the y-axis. This is an important metrics that does not only tell you the productivity of your QA team; rather, it also tells the effectiveness of your test cases. As a good QA manager, you would desire to detect more bugs and issues with a lesser number of test cases and in minimum time.

It also helps in analyzing ‘how efficient the testing process is in detecting defects and the amount of testing necessary to undertake? In this stage, the data is captured and verified by the testing teams. It also involves the calculation of metrics value as per the data captured. Similarly, ‘Mean Time to Repair’ is the average amount of time taken to fix the issue. This metrics is related to the efficiency of the development team.

Metrics for tracking defects:

You can also download the sample code used in the previous steps from our documentation. This number card shows the number of confirmed bugs in a module during the development period divided by the module size. Let’s consider an example to calculate the defect density in software. The defect density of software is estimated by dividing the sum of flaws by the size of the software. The metric values for two different modules will help in comparing the quality of their development and testing.

• In a system testing procedure, it’s typical to find flaws and faults.
• A greater defect detection percentage indicates a reliable and effective testing process.
• Answers are submitted on a 0–10 scale from “not likely” to “very likely.”
• ’ which leads to variation in the defect count and hence Defect Density.
• Agile managers use these metrics to predict how quickly teams can work towards attaining goals by comparing hours committed to and completed hours in previous sprints.

Defect density also makes it easier for developers to identify components prone to defects in the future. As a result, it allows testers to focus on the right areas and give the best investment return at limited resources. Defect density is a measure to track the progress, productivity and quality of the software.

When to use a defect-based technique in software testing?

In this stage, the need for the metrics is communicated to the testing teams and stakeholders. The testing teams are also educated about the data points that should be collected for processing the metrics. By analyzing all the above points, businesses can further evaluate their software project’s effectiveness and software testing efficiency by using these metrics. If there are more bugs in one category, the QA manager will give special attention to that category in the next iteration or sprint. For example, if there are more functional issues, the QA manager might propose the suggestion to improve the quality and clarity of software requirements specification document.