Test case prioritization

Test case prioritization is something that all of us at entry level are given lot of lecture upon.  It is not just the importance of the particular Test Case , in fact much more than that, because in case of time crunch it remains the only criterion to do the so called risk based testing that in turn uncovers a high degree of Risk Mitigation due to the relevant prioritization.

(1) Priority of the requirements assigned by the Client:

A software product can have many features/functionalities but in the field, it's seen that only 20-25% of these features are actually used regularly also named regularly as the critical path, uncovering all the positive flows.  Therefore by identifying these highly important features and thoroughly testing these requirements we can increase the business value generated to the customer with minimal time frame availability.

(2) Implementation complexity:

Requirements with high implementation complexity tend to have a higher number of faults. As per the research data provided by maximum data analysis agencies , we have been able to design a sort of chart which clearly reflects that almost 80% of the defects uncovered by the testers, result from the 20% of the errors that the developers commit.  It is very commonly termed as the  Pareto Chart principle. Hence while prioritizing, we should focus on testing requirements with high implementation complexity and also prioritize them as per the dependency.

(3) Requirements volatility:

Roughly 50% of all faults identified in a project are errors introduced in the requirements phase.  This was the reason why 95% of the projects in the 1995 era failed . Researches show that the biggest cause for project failures happens to be changing or incomplete requirements.  So if a requirement is changing frequently it should be given proper attention while prioritizing test case execution which can be done in close proximity with the Requirement team, comprising in general of the Business Analysts.

(4) Fault prone modules:

This applies to the Maintenance Projects as in them ,fault-prone modules are more likely to cause field failures than the modules, which are not fault prone. So if a large number of defects were found earlier in the field or during system testing of a particular module of an earlier released version of a software, we need to prioritize corresponding test cases. But this factor is not applicable for new projects , commonly referred to as the Application Development Projects.

Mapping RTM:-  Here every requirement of the project as per the BRD is mapped to RTM(Requirement Traceability Matrix) against to which you can also map your test cases.

In such cases you need to prioritize those test cases that checks the functionality as a whole. That means once you finish prioritizing the test cases all the functionalities of the application will come under test. later on you add on those test cases that are attributes to the same. Herein also comes the feature of the two way dependency or one way depenedency for which the impact analysis will give us exact count that if a particular Test Case fails,  how many more Test Cases will be failing as they are directly dependent on that one Test Case.

Security, Rigidness and Correctness as main factors while prioritizing may also be taken into consideration as and when mission critical application are being Tested.

Thus far we can conclude Prioritization has a parametric dependency on

1.       Resources available at your disposal (5 Ms’ is what its popularly termed as)

2.       Degree of risks uncovered from every test case a sort of vertical and horizontal impact on the other scenarios.

3.       Customer expectations from the software release the sole criterion of all the analysis.