1. Residual Risk. This is all about what do we know about (i.e. parts of the solution/risk profile that have been covered, tested) and what do we not know about. Residual risk is a great quality and progress metric as it can tell us about gaps in knowledge and coverage.
2. Coverage. This means have we tested all of the important or right bits of the system? This tends to be information about coverage of the requirements, functionality, architecture, or risks etc.
3. Defect density is another metric that matters. It translates into where are the defects and how many are there? Identify each of the parts of the solution that you care about (front end, back end, service layer), or user type, or functional area, or scenario then make sure everyone know these identifiers and uses them whenever a defect is raised.
4. Progress (aka are we there yet?). This is often translated into ”are we going to make it?”. This is about understanding what “there” is, and having a plan to get there. The plan needs to cover all the activities to achieve the required outcome and then be tracked and analysed to assess the completion of each stage. This can be formal or informal but is very important to keep track of.
5. Does it work? Clearly, understand what is “it” is, then what “works” means then how good it has to be. Using quality model such as Boehms, ISO 25020 or your own models will help understand works.
These are my top 5 metrics that I tend to use every time I test. They mean that I am focused on the right things at the right time and can tell people what they want to know. What metrics do you think matter?
Post by Sharon Robson