It’s important to value the work done by a Tester. Though a tester will typically create and modify own assets namely the test cases, test execution results these are not necessarily quantifiable in terms of productivity and hence there is need to take help of better metrics. Typically the following are widely used:
• Number of Test Cases
• Test Execution Rate
• Defect Finding Rate
A Testing project consists of Test Deliverables – these include testing and its results. A product is measured in identifying defects in code and is correctly identified by defect rate.
What are the other metrics?
The product quality requires consideration for the other metrics
• Quality of Test Cases
• Quality of Execution
• Quality of Defects
These metrics are a result of what result these produce. Though before we can proceed with the next step it’s important to measure more critical “Quality Metrics”.
To understand the issue let us look at the developer live cycle (SDLC). A Developer spends considerable time in designing the product and identify use cases. The main use case and secondary uses are thoroughly understood and then code logic is developed and implemented. The code is then tested and defects reported. These do cover most of the testing although it cannot be said that all is done. During our testing of small and large test projects it was observed that following additional techniques were required to further improve the testing efforts and add value to testing process. These methods are well known and very useful for identifying the defects and improving overall quality
• Root cause analysis using Fishbone Diagram
• Test case documentation standard Checklists
• Verification Checklists
• Preparing the Modular flow (and understanding) of the code.
In the above methods fishbone diagram as shown has shown the maximum benefit:
Having a process oriented approach and applying all of the above techniques the rate for defect finding was found to be improving and quantifiable.
Additional reading can be found here