Netsparker Web Application Security Scanner

How You Should Prioritize Test Cases In Software Testing?

Do you know why we run regression whenever there is a change or fix or a feature is added to the software application? Answer is simple, to test whether that change has affected any old functionality or not. So, regression test suite has all the test cases covering major functionalities of the application. And it becomes a PRIORITY to run this suite every time to check if the application is stable to carry out further testing or not. However if you have thousands of test cases in regression suite and you do not have sufficient time to execute all test cases, then what you gonna do. Simple answer to this question is we execute the test cases based on prioritization.In this article we will understand the prioritization of test cases and the factors to be considered while prioritizing them.

Prioritize Test Cases In Software Testing

The purpose of this prioritization is to increase the likelihood that if the test cases are used for regression testing in the given order, they will more closely meet some objective than they would if they were executed in some different order. Some organizations prefer to run “Smoke” or “Sanity” test every time they get a new build or version of the developing software. In this case, test cases will be prioritize based on all the major modules of the software and sanity will be run on them to check the basic functionality for example, in a mobile testing, sanity test suite will have test cases like “restarting the device”, “turning off”, “signing in”, “updating software” etc.

Whether your organization runs regression or sanity or both, Test Case Prioritization techniques are applicable for all the cases. Prioritizing test cases can be done on the basis of requirements, costs of bug fixing, history of the parent device etc. Let’s analyze each factor in detail. Some organizations have the practice of categorizing test cases into Blockers, Critical, Major and Minor functionalities.

You also may like: Test case design techniques

For this, tester has to understand two major points:

  1. Understand what product is meant for.
  2. Who are the users?

Based on above points you know how to keep test cases in following categories:

  1. Blockers: These are the test cases which test the lifeline of the software. Those features without which the software becomes useless. If any of the feature stops working then this will block the further testing and issue has to get fixed on priority. For example, if a software fails to start then you cannot carry on any testing and product is of no use to the customer.
  2. Critical: This will have all the test cases related to all the major functionalities performed by the software keeping in mind how users are going to use it. These functionalities are very important to the customer and if these fail then customer will trash the software so they also need to be fixed ASAP to avoid huge loss in business.
  3. Major: These are the ones which makes our software unique in the market and different from competitors. If these stops working, customer will be unhappy but will still use the software as all the critical features are working fine. They are also important after blockers and critical test cases as this can lead to loss in business as well.
  4. Minor: In this category, all the suggestions, and small UI changes or product improvements will be included. They will not affect the software usage in anyway and can be avoided if there is tight deadline.

These were four major categorization based on the features of the software. Cost for fixing blocker and critical is high so it’s a best practice to test them on priority. SRS or FRD documents have all the information about blockers and critical. Understanding them properly can make categorization easier. And then we can include them in regression suite and rest others in functional one. Test coverage is another factor to consider here, test cases are prioritize such that they also cover all the major functionalities providing maximum test coverage. It is a better practice to automate regression test cases if possible, this saves a lot of time and efforts and you get time to focus on other areas too.

Conclusion on Test case prioritization:

Test case prioritization is a method to prioritize and schedule test cases. The technique is developed in order to run test cases of higher priority in order to minimize time, cost and effort during software testing phase. Every organization has their own methods and way to prioritize test cases, I follow the above method while categorizing test cases. However, there is one issue that existing test case prioritization techniques assume explicitly that there is only a single test suite. The test suite is a collection of a set of test cases. There are no prioritization techniques to resolve the problem of multiple test suites. If you have some suggestions based on your experience then feel free to help others by mentioning it in the comments section below. Hope you find this article useful, do share it with your friends.
If you are not regular reader of this website then highly recommends you to Sign up for our free email newsletter!! Sign up just providing your email address below:

Enter your email address:

Check email in your inbox for confirmation to get latest updates Software Testing for free.

Happy Testing!!!

4 comments to How You Should Prioritize Test Cases In Software Testing?

  • Mahesh

    I am fresher in testing field, thanks for article. It looks good and i will definitely follow this.

  • aranga

    can we leave the low or minor priority test cases without testing before release.if so, the customers find out and feels bad and unhappy what we can do to satisfy the customers.

  • Sapna

    Useful information, thanks

  • Archana

    Excellent !!!
    I am preparing for interview. Admin, can you please share some points on “how to write a good cover letter ”
    Thanks in advance!!!

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>