Regression Candidates ?

What is Regression Testing BTW ?

Regression testing can be defined as a skill of identifying un-expected changes throughout the product which could have happened by introduction of new feature. Some of key factors to be known and considered for picking regression test candidates includes:

Knowing what the feature is, how the feature is implemented in the system, in which module is the feature introduced. Understanding the requirement is most important aspect of software testing. Testing a product with having empathy towards users are more important so that the product will behave what it is intended to. Once we know what the requirement is, why the requirement is and how requirement is implemented, concluding test cases are far easier.

Time window:

Adhering to given timeline window is another important aspect when it comes to software life cycle given that we need to deliver good quality product within a short time.

There is no point in executing whole regression pack which would take weeks to finish when the release happens in two days. Depending on the size and scope of change it may be necessary to use risk-based methods to attempt to regression test in smaller time frames.

Pre-requisites and Environment:

The next factor to consider is, whether hardware / people needed to test them are available or not. Hardware components can be categorized as internet stability, number of machines (Local and cloud) etc. Aligning team effectively is also important to yield a better outcome.

Stable QA Environment should be available so that team will not face any downtime. Elements to look for here are ensuring that the build and the data layer are accurately aligned. Many false positives will be given if there are missing new data fields or tables.


Test data is a major factor when it comes to regression testing. Reusable test data should be created for regression pack so that the dependency toward this layer is much lesser.

Risk and Priority:

Risk estimation and identifying priority of test cases plays a big role when it comes to regression testing. Basically, regression test should cover all the P0, P1 test cases for the product.

Post P0 and P1 test, the next priority would be the module which have high defect density and High flakiness. The rest modules / test cases are good to cover but not mandatory.


One area of testing that lends itself to automation is regression. Automation allows repeatability, and re-use, over the more mundane tasks required. Possibly all the UI test cases can be covered in this part where we do an automation run over night and analyze what the result is tomorrow morning. This process helps us to cover all the UI test cases, and only time required would be to analyze failure in automation if any.


So, what constitutes a successful regression test? The number of defects found, or maybe the number of test cases ran? Ultimately the QA department can only do so much, no system can be tested exhaustively. The only real measure of success, or failure, is the customer experience after the software is delivered. If all is as it should be, and no defects have found their way through- then you have conducted a successful regression test.

A universe of atoms , an atom in the universe. ⚛️