Testing-KPI-Reporting
Testing-KPI-Reporting

Top 6 Testing KPIs

Within your Salesforce Test Team you should be looking to standardise your test reporting to provide your team with a clear direction and understanding of what is expected from them and the deliverables to the wider project team.

Dependent on what Test Management software you are currently using, you may be able to leverage some out of the box reports and dashboards to be used by Testers, Test Leads and QA Test Managers to provide relevant metrics across all your projects.

Whether you plan on using pie charts, bar graphs, scatter plots or heatmaps to visualise your data, it is worth noting that there are some metrics that can be of a bigger benefit than others and should be you ‘go to’ metrics.

Test Execution Summary

An obvious one to start, a simple Passed, Incomplete, Failed, Unexecuted table or pie chart will do for a ‘straight to the point’ progress report. These stats should be easy to obtain and update and should be the bare minimum the Tester should be expected to provide.

Tests Planned vs Executed

This metric will help understand their testing progress and tracks the number of tests that have been executed vs the number of tests originally planned over a set amount of time. An understanding has to be in place to be able to know and plan the expected number of tests to be run, and also knowledge of what is able to be tested and when as this will quickly disrupt this reporting.

Raised/Rejected/Deferred Defects

Defects that have been rejected are a valuable metric that should be reviewed by a QA Test Manager. With using relevant categories, as to why defects have been rejected, this information can serve as an identification of a gap in the knowledge of your Salesforce Testers and used to assign specific training sessions to members of your team.

Deferred Defects can also be a significant metric to review as these may form part of your next release/sprint and although not of high priority/impact to fix for the current release are still worth highlighting in your reporting.

Requirements Coverage

In order to monitor requirement coverage a traceability matrix can be used. The target for test coverage for your Salesforce Testing should be 100%. If you have requirements that are not covered by test cases then you / your test team should be creating further tests to cover them. Likewise if you see test cases that are not related to the testing of a requirement then do you need to actually run this test?

Root Cause of Defects

To be able to provide feedback as well as an understanding of why defects are being identified, tracking the root cause of defects is a metric that not only provides this information but also serves as a training mechanism once root cause trends are identified eg. maybe a lack of knowledge in a certain area is leading to a high number of issues. This metric also helps upper management to understand why a Customer maybe raising defects within UAT but the same issues has not been picked up by their own Test Team eg. Environmental issues.

Defect Leakage Percentage

An additional metric that is worth mentioning is the Defect leakage percentage. This a a testing metric that can help monitor the efficiency of your quality assurance process in your Salesforce projects.

The definition of the Defect Leakage Percentage is to measure the percentage of defects ‘leaked’ from the current testing stage to the subsequent stage. This can be easily calculated using the below formula:

No. of Defects identified [UAT Phase] / Total No. of Defects Identified [UAT + SIT Phases] * 100

eg. If 20 ‘true’ defects have been identified during UAT and the total defects identified during both SIT and UAT Phases were 100 then the calculation would look like the below:

(40/200)*100 = 20%

Therefore, the defect leakage percentage is 20%. You can set your own acceptable percentage within your QA Team but essentially the lower the value of defect leakage, the better is the quality of software testing.