Software quality assurance (SQA) is a process that ensures that developed software meets and complies with defined or standardized quality specifications. SQA is an ongoing process within the software development life cycle (SDLC) that routinely checks the developed software to ensure it meets desired quality measures.

Different five quality metrics:-

1. Committed stories vs. delivered results meeting "doneness" criteria:-

Remember the last time someone committed to do something for you and either failed to deliver or didn't meet your standards? It caused delays and rework, along with a lot of frustration. In software development, "stories" are the pieces of work that are committed to and, ideally, delivered on time and to a certain spec.

As you may know, stories represent the simple, high-level descriptions that form a use case, such as a user inserting a credit card into an airline kiosk. Each story needs to be delivered at a specific level of quality or "doneness" criteria.

As teams continuously plan, elaborate, plan again, commit, and deliver, the ultimate goal should be to deliver these results in alignment with the broader team's doneness criteria. When that can be measured, the team can showcase its abilities to meet its commitments on schedule and with the highest standards.

2. Quality across the life cycle:-

The demand for software delivery speed continues to increase along with the demand for reduction in costs. But how can you achieve these goals when you don't have the time and resources to manually test every build? When you can't afford to wait and find those defects in your late-stage releases? The answer is to follow the build life cycle from story to code on a developer desktop.

Next, you should check, build, and unit test. Continue by using automation through the rest of the process, including automated, functional, performance, security, and other modes of testing. This gives teams the ability to show the quality of a build throughout the life cycle with quality metrics and automated pass/fail gates.

Given the frequency of these builds and automated tests, build-life results can be created and measured in seconds, minutes, and hours. Now, your most frequent tests are fully automated, and you're only doing manual tests on the highest quality releases that make it through the automated life cycle.

This results in automated build-life quality metrics that cover the full life cycle, enabling your team to deliver with speed and quality, while reducing costs through higher efficiency.

3. Production incidents over time and recurrence:-

Just as it's important to show the quality of the release over time, it's also important to minimize production incidents and their recurrence over subsequent releases. The table below illustrates a technique I've used to compare team performance over time. Imagine you are working with five teams over three completed releases.

The target for this typical (though imaginary) organization is 95 percent of committed stories delivered and zero production incidents. Teams that didn't meet these goals are highlighted in bold red. Often, production incident numbers are found within an incident management process.

Defining the root cause and implementing corrective measures enables continuous improvement and prevents recurrence of same issue in subsequent releases. With these quality metrics in place, you can learn which teams meet or don't meet specific goals. Finally, you can look across teams and discover why proven concepts work.

4. User sentiment

Get to know your end users by measuring how they feel when interacting with an application or system. By capturing and dissecting the feedback they provide regarding new or improved capabilities, you can incorporate their needs into an upcoming sprint.

At the very least, you can develop a plan to deliver something in response to those needs. On a larger scale, your analysis and incorporation of user sentiment can expand to a more general market sentiment, which can broaden your impact and market presence. Several components of quality can be covered via this metric, including simplicity, stability, usability, and brand value.

5. Continuous improvement:-

Following retrospectives, you should allow time and effort to implement prioritized continuous improvement stories. This enables the team to self-organize and be accountable for improving the quality of their process. By allocating this time and making it visible to all, the team and stakeholders can show their immediate impact.

They can demonstrate how one team, compared to others, has delivered results at increased speed, with higher quality and value to the end user. This allows team leads to ask and possibly answer these questions: Are there certain practices that need to be shared? How do teams perform over time with certain changes injected? The continuous improvement metric can also justify recent or proposed investments in the team.