The main purpose of this article is to list all aspects of implementing and executing an optimal set of software regression test cases.

What is regression test activity? Well, the answer is not straight forward and should be detailed explained.

The common opinion of regression test definition is usually considered testing the current software functionality and verifying that these functionality is working at least as before. This is true, but also partial target and ability of regression test activity. Regression is an evolution, developmental and dynamic process. For the same system, the same software, regression can include hundreds of test cases or tens only. In order to determine the optimal number and efficient test cases that will cover a specific regression test it is needed first to carefully consider and analyzed the following key elements:

1. Time table
2. Software Customization - Existing software which changed for any requested reason.
3. Testers availability, ability and talent
4. Software complexity
5. Project risks

Each one of the above elements has sub elements which can make the regression test more complex. In addition these elements are unequivocal connected. The target is to try coming with mitigation plan for a problematic element or sub element, so the regression design and execution will be efficient.

For instance, if the software is customized and several areas are changed a professional tester who knows the software will understand the impacts and adapt the regression test cases accordingly. The most probably result would be detecting all or most of the software defects related to regression. Another example which is always a factor in testing phase is time table. In complex software the regression is complex as well, due to incorrect planning many test groups are doing a common mistake by aiming higher than can be really achieved. Hundreds of test cases are planned to be executed in a tight time table. The bread and butter functionality in many cases is eventually not tested. The most probably result is delivering or releasing half tested software with bugs in the main existing business scenarios.

Regression test activity of existing software, which simply upgraded due to functionality added or changed or by performing technical infrastructure changes, is absolutely different from a new software implementation.

The benefit of knowing the software performance in real live is huge. Regression test cases can be defined according to the most common real live scenarios, volumes, appearances etc. The list of test cases should be prioritized. In each version testing group is gaining and gathering more information and develop the regression accordingly. The Optimum is considering the regression as evolution process, meaning each version the regression activities will be adapted according to the real live operational, functional and business performances. All this will allow keeping high level of software quality assurance.

As mentioned above new software implementation in context of regression test is a different story. Actually it might surprise few of you, but there is a clear contradiction saying in one sentence that a regression test activity is designed for new software. It would be much wiser to look at new software implementation as a new big software change which should be tested in a change mode rather than in a regression mode. In other words a regression test is nearly or relatively not exists in a new software implementation.

In a project life cycle which performing upgrades to an existing software version, the regression test activity is critical and must be considered as one of the project millstones. The regression outputs (results) are being used as strong tool for management to be able to make a wise decision related to the next steps.

Why the regression results are so important? These results are reflecting and presenting the current system status which services both the vendor and the consumers with the performed changes. Bad results of important regression tests cases can impact badly serious and major items as company revenue or consumers satisfaction. The regression result interpretation is not black or white thing. As mentioned above the test cases should be prioritized first. The prioritization will assist having a better view of specific business flow results and impacts as well as understanding the whole picture, the whole project status.

For instance, if a company is providing internet services and you as consumers received a paper invoice to be paid with amount of 4$, while in practice you were supposed to pay 4.7$, the company loss is 0.7$. This is small amount of money right? Wrong! If 3 millions consumers have the same profile as you have, the company total loss will be 2.1 millions dollars. Form personal experience companies have a major problem to over come these kinds of losses, preventing them by performing good regression tests is less expensive and more assured.

One of the key elements which define the coverage and time table of regression is the project risks. The risks are being handled separately in Project Risk Management activity, but regression scope and planned scheduling can be directly affected from these risks. It is important to know that not each problem, even major one, is considered as risk. A conceptual problem as well as development delay can put the regression scope and scheduling in danger. It might be that the regression scope will be reduced or compensated by giving extra time or resources for completing the tests.