For example coverage. This means have we tested all of the right bits of the system? A lot of organizations need info about coverage of the requirements, functionality, architecture, risks etc. this is dead easy! Creating a traceability matrix which maps the attribute to be traced with the test cases covering it is the quickest & easiest way to manage this. It doesn’t have to be sophisticated, a spreadsheet will do.
Defect density is another key metric…basically translates into where are the defects and how many are there? To set this one up all you have to do is come up with a name for each of the parts of the solution that you care about (front end, back end, service layer) make sure everyone know these names and uses them whenever a defect is raised. You can extract the defect density information.
Progress = are we there yet? Or sometimes means “are we going to make it?”. To report on this metric you need to have a plan of the testing activities layer out on a calendar. You need to be able to predict or estimate how long each activity will take, then track it in real-time to see if it is taking the predicted time. A simple work breakdown structure & a calendar can help with this.
Does it work? Is my favourite question of all. What is “it” is the first consideration, are we talking about the system over all, the architecture components, the environments, or are we talking about the business functionality. Once we know that we can delve into the question of what “work” means! Using quality models such as Boehms, ISO 25020 or your own models will help understand works. The two key attributes of works are generally functionality and non -functional attributes. Mapping tests to these types of approaches and then overlaying the definition if “it” via a diagram or spreadsheet tells you this.
Given that testing is all about sharing information, it is important that testers know how to generate meaningful & valuable metrics.
Post by Sharon Robson