What is Regression Testing? Test Cases (Example)

This testing is done to ensure that new code changes do not have side effects on the existing functionalities. It ensures that the old code still works once the latest code changes are done.

When can we perform Regression Testing?

Here are the scenarios when you can perform regression testing.

New functionality is added to the application: This happens when new features or modules are created in an app or a website. The regression is performed to see if the feature is working properly.

In case of change requirement: When any significant change occurs in the system, regression testing is used. This test is done to check if these shifts have affected other features.

After a defect is fixed: The developers perform regression after fixing a bug issue in any functionality. This is done to determine if the changes made while fixing the issue have affected other related features.

Once the performance issue is fixed: After fixing any performance issues, regression testing is done to see if it has affected other functionalities.

While integrating with a new external system: Regression testing is required whenever the product integrates with a new external system.

Software maintenance is an activity which includes enhancements, error corrections, optimization and deletion of existing features. These modifications may cause the system to work incorrectly. Therefore, Regression Testing becomes necessary. Regression testing, and specifically various regression testing techniques, can be carried out for effective software quality assurance:

Retest All

This is one of the methods for Regression Testing, specifically employing a regression testing suite, in which all the tests in the existing test bucket or suite should be re-executed. This is very expensive as it requires huge time and resources.

Prioritize the test cases depending on business impact, critical & frequently used functionalities. Selection of test cases based on priority will greatly reduce the regression test suite.

Selecting test cases for regression testing

It was found from industry data that a good number of the defects reported by customers were due to last minute bug fixes creating side effects and hence selecting the Test Case for regression testing is an art and not that easy. Effective Regression Tests can be done by selecting the following test cases –

• Test cases which have frequent defects
• Functionalities which are more visible to the users
• Test cases which verify core features of the product
• Test cases of Functionalities which has undergone more and recent changes
• All Integration Test Cases
• All Complex Test Cases
• Boundary value test cases
• A sample of Successful test cases
• A sample of Failure test cases

Regression Testing Tools

If your software undergoes frequent changes, regression testing costs will escalate. In such cases, Manual execution of test cases increases test execution time as well as costs. Automation of regression test cases is the smart choice in such cases. The extent of automation depends on the number of test cases that remain re-usable for successive regression cycles.

Following are the most important tools used for both functional and regression testing in software engineering:

1) testRigor

testRigor helps you to directly express tests as executable specifications in plain English. Users of all technical abilities are able to build end-to-end tests of any complexity covering mobile, web, and API steps in one test. Test steps are expressed on the end-user level instead of relying on details of implementation like XPaths or CSS Selectors.

Features:

• Free forever public version
• Test cases are in English
• Unlimited users & Unlimited tests
• The easiest way to learn automation
• Recorder for web steps
• Integrations with CI/CD and Test case management
• Email & SMS testing
• Web + Mobile + API steps in one test

Visit testRigor >>

---

2) Avo Assure

Avo Assure is a technology agnostic, no-code test automation solution that helps you test end-to-end business processes with a few clicks of the buttons. This makes regression testing more straightforward and faster.

Features

• Autogenerate test cases with a 100% no-code approach
• Test across the web, desktop, mobile, ERP applications, Mainframes, associated emulators, and more with a single solution.
• Enable accessibility testing
• Execute test cases in a single VM independently or in parallel with Smart Scheduling
• Integrate with Jira, Jenkins, ALM, QTest, Salesforce, Sauce Labs, TFS, etc.
• Define test plans and design test cases through the Mindmaps feature

Visit Avo Assure >>

---

3) Subject7

Subject7 is a cloud-based, “true codeless” test automation solution that unifies all testing in a single platform and empowers anyone to become an automation expert. Our easy-to-use software enables fast, easy, and sophisticated authoring of regression tests without writing a line of code, and high scale execution that runs thousands of nightly tests.

Features:

• Integrates easily with DevOps/Agile tooling using native plugins, in-app integrations, and open APIs.
• High-scale parallel execution in the cloud or on-prem with enterprise-grade security.
• Flexible reporting of defects, with video capture of results.
• Simple, non-metered pricing, delivering financial predictability.
• SOC2 Type2 compliant

Visit Subject7 >>

Selenium: This is an open source tool used for automating web applications. Selenium can be used for browser-based regression testing.

Quick Test Professional (QTP): HP Quick Test Professional is automated software designed to automate functional and regression test cases. It uses VBScript language for automation. It is a Data-driven, Keyword based tool.

Rational Functional Tester (RFT): IBM’s rational functional tester is a Java tool used to automate the test cases of software applications. This is primarily used for automating regression test cases and it also integrates with Rational Test Manager.

Types of Regression Testing

Here are the different kinds of regression testing:

1) Unit Regression Testing (URT)

This is a very focused approach where only the modified section goes under the regression test instead of the impact region. In this way, the other portions of the module remain unaffected.

Example

In the example in Build 1, an issue is found and reported to the developer.

Let’s say there is a bug in the login functionality, so the developer fixes it, adds new features in Build 2, and submits it. The testing team checks only if the login feature is working as expected instead of checking other features.

2) Regional Regression Testing (RRT)

In Regional regression testing, the modification and impact areas are tested. This area is examined to find out if any dependable modules might be affected by the changes.

Example: In this example, in the first build, the modules A, B, C, and D are sent for testing by the developer. The tester finds bugs in module B, so the application is returned to the developer to fix the bugs.

Once the developer fixes the bugs in the second build in module B, it is sent to the test engineer again. The engineer learns that fixing module B has affected A and C.

Hence, the tester checks module B’s modifications in the second release. Then tests the impact regions in A and C as well to identify how they have been affected.

Note: While regression testing, there is a possible issue that this problem below may occur.

Problem:

• In build 1, the clients usually ask for changes, modifications, and added features.
• This request is then sent to both the development and testing units.
• The development team then makes the modifications. Next, the test engineer emails the client, informing them of the areas the modification will impact.
• The test lead then gathers the affected areas’ list from the client, the developers, and the testing department.
• The impact list is then sent to the test engineers, who start regression testing.

This type of testing method creates communication gaps. The developers and the customers cannot always revert to the emails; hence, there is no proper overview of the impact area.

Solution: To remove this kind of problem, the testing team can arrange a meeting once the new build arrives after bug fixes, new features, and modifications. This meeting will be held to discuss if the modules are affected due to the modifications.

There will be a test round to find impacts so they can create an impact list. The test lead adds the maximum number of areas in the impact region in this list.

Here, below is how the process will look like:

• “Build verification test” to check the main capabilities of the application.
• Testing of all new features.
• Examining changed or modified features.
• Retesting of bugs.
• Then, finally, impact area analysis using Regional Regression testing.

3) Full Regression Testing (FRT):

This testing covers all the functionalities of an application. Full regression testing is usually performed in later releases after the first or first two releases as a final test before launching.

In the second or third build, the clients ask for three or more modifications, demands new functionalities, and report defects. The testing unit then conducts impact analysis, makes all the modifications, and performs a final complete product test.

For example, the 4th build is the final release before the launch. So, in this build, the testing unit performs a complete test or retest of the product instead of just the impact area or a feature. This is done after the modifications and tests in builds 1, 2, and 3.

To perform complete regression testing, you have to consider these circumstances:

• In case any changes are created in the origin file of the product. For example, if there is a modification in a root file of an app, then the whole program used to build the application will be analyzed.
• If there are numerous changes made.

4) Corrective Regression Testing:

This testing is done when no modifications are made to the features. Such tests can be performed with existing cases.

5) Retest All Regression Testing:

In this form of testing, all the minor to major changes made in the application from the origin or build 1 is retested.

This testing is done when all other regression tests fail to identify the root cause of the issues.

6) Selective Regression Testing:

This is conducted to check how the code reacts when a fresh code is added to the program. In order to conduct this test, the sub-set from existing cases is used to make it efficient and cost-effective.

7) Progressive regression testing:

This type of regression testing produces important outputs when specific changes are made in the program, and new test cases are created.

It helps ensure that no components from the older versions have been affected in the latest version.

8) Partial Regression Testing:

This regression test is performed to find problems when a newly written code is inserted in existing lines of code. It ensures the application performance has not been affected due to adding new codes.

Automated Regression Testing

Automated regression testing is done when there are several releases, multiple regression cycles, and numerous repetitive activities.

This is manual method which usually takes longer, and you can test only once or twice. However, with automation, you can test several times as it requires writing the script for execution. The testing team does not directly start with automation during the new build. There are manual and automation teams when the new version and modifications start.

Here is how automated regression testing is done:

Step 1) The manual unit checks all requirements and identifies the impact region. After this process, they forward the requirement test bundle to the automation department.

Step 2) The manual team begins testing the new modules while the automation unit writes the script and automates the test case.

Step 3) Before using this method of a regression test, the automation team identifies which cases will support automation.

Step 4) They convert those regression tests into scripts depending on which cases can be automated.

Step 5) During the scripting process, the automation team takes the help of regression cases as they neither possess the product nor the tool and app knowledge.

Step 6) When the test scripts are completed, the automation team will execute them on the new app.

Step 7) After the execution, the result informs if the test was a Pass or Fail.

Step 8) If the test fails, it is re-checked using the manual method, and if the issue exists, it is reported to the respective developer.

Note: After the bug is fixed, the issue and the impact area are sent to the manual tester for retesting, and the automation team has to re-execute the script.

Step 9) This process continues until all the newly added regression features get a Pass status.

Here are the benefits of automated regression testing:

• Reusable: Its test scripts are reusable across multiple releases.
• Accuracy: The automation tools perform the task redundantly, reducing the chance of error.
• Saves time: It is faster than the manual process and is time efficient.
• Batch execution: It is possible to execute all the scripts simultaneously and parallelly in automated testing.
• No resource increase required: The regression test is bound to increase with every new release, but you do not need to add new resources for automation.

How to choose test cases for the regression testing?

Here is how you can select the right case for regression testing:

Select cases for highly visible features to users:

• Test cases that show frequent defects.
• Every integration test case.
• Test cases that determine the main capabilities of the product.
• Select the boundary value analysis case.
• Successful test cases.
• Choose complex test cases.
• Cases that suit your business needs.
• Select them based on priorities.
• Test cases in the areas with frequent defects.

Regression Testing and Configuration Management

Configuration Management during Regression Testing becomes imperative in Agile Environments where a code is being continuously modified. To ensure effective regression tests, observe the following :

• Code being regression tested should be under a configuration management tool
• No changes must be allowed to code, during the regression test phase. Regression test code must be kept immune to developer changes.
• The database used for regression testing must be isolated. No database changes must be allowed

Difference between Re-Testing and Regression Testing

Retesting means testing the functionality or bug again to ensure the code is fixed. If it is not fixed, Defect needs to be re-opened. If fixed, Defect is closed.

Regression testing means testing your software application when it undergoes a code change to ensure that the new code has not affected other parts of the software.

Here below are the primary differences between these two tests:

Retesting	Regression testing
It is built specifically for fixing defects.	Regression testing is done mainly to verify if code changes have impacted other functionalities.
Retesting doesn’t check the other versions and only verifies if the functionalities are restored.	It focuses on previous versions, and it tests if the old release’s functions are still working as needed.
It is a planned type of testing.	Regression is a generic test.
This testing is for failed test cases.	It is for passed-test cases.
It checks specific defects, so it cannot be automated.	Automation is a reliable testing form in regression, as manually doing repetitive testing is time-consuming.
Retesting is not compulsory in testing, as it is required only when bugs are found.	Regression is always a part of testing, as every time a code is changed, this test must be conducted to stabilize the product.
It is high-priority testing as it focuses on known issues.	This is low-priority testing, as it is overall testing of possible defects.
This testing is not time-consuming as it works on a specific defect.	As it involves a large area of the software, hence, it is time-consuming.
It determines defects with the same data and environment with a different input and a new version.	This testing can acquire cases from user manuals, defect reports, and functional specifications.
Retesting cannot be conducted without the first testing.	It is done when changes and modifications are obligatory in the existing project.

Also, Check out the complete list of differences over here.

Advantages and Disadvantages of Regression Testing

Advantages

• Regression testing improves the quality of the products.
• With this testing, you ensure that the modifications and bug fixes have not changed the existing functionalities and features.
• You can use automation tools and get faster results instead of depending only on manual testing.
• Once the issues are fixed, it guarantees they do not reoccur.
• It facilitates efficient development in building products.
• You can achieve high user satisfaction with this testing.
• Overall, it maintains the stability of the software.

Disadvantages

• It should be conducted every time a small change is made, as the slightest change can bring issues in existing modules.
• This test can be time-consuming when conducted manually, requiring repeated testing.

Challenges in Regression Testing

Following are the major testing problems for doing regression testing:

• With successive regression runs, test suites become fairly large. Due to time and budget constraints, the entire regression test suite cannot be executed
• Minimizing the test suite while achieving maximum Test coverage remains a challenge
• Determination of frequency of Regression Tests, i.e., after every modification or every build update or after a bunch of bug fixes, is a challenge.

Practical Application of Regression Testing Example with a Video

Click here if the video is not accessible

Conclusion

• Regression Testing Meaning – Regression testing is a type of software testing that ensures an application still functions as expected after improvements, any code changes, or updates.
• An effective strategy, particularly regression testing in software testing, can save organizations both time and money. As per one of the case study in banking domain, regression saves up to 60% time in bug fixes(which would have been caught by regression tests) and 40% in money