A Comprehensive Guide to Manual Regression Testing

One step forward, two steps back. That is how we would describe the QA strategy that doesn’t include software regression testing. The purpose of regression testing services is to perform a search-and-destroy mission on defects that have been made through intended changes.

Regression testing can be manual or automated. It is a perfect candidate for test automation, since the regression testing suite is repetitive, and test scripts would be reusable. When coupled with manual testing services, it becomes even more powerful as humans can pick up on subtle test nuances. But in this article, we’ll examine manual regression testing in detail. Keep reading for a step-by-step guide on manual QA testing and a checklist at the end.

What Is Regression Testing?

The code changes are unpredictable. So, sometimes a deployment of an app’s new version unexpectedly affects the functionality of existing features. To manage risks and be confident in product quality before the release, QA engineers run regression testing.

Briefly, this type of software testing verifies that a platform continues to work as intended after any code revisions, updates, or optimizations. For example, there was a bug on the login page that was successfully fixed. Now, the login feature works properly. But instead, there is a problem with user registration. As you see, even bug fixing can cause a new issue – a regression bug.

Why Do Regression Bugs Appear?

Regression bugs are the result of changes in the code. When one part of the code depends on another, any changes in that particular functionality can affect the other part. And to tell the truth, sometimes these are quite unexpected places. By finding defects or system malfunctions caused by the new code, you can repair the damage before the market launch.

Types of Regression

• Regression of bugs – defects that seem to have been fixed, but there is a reason to believe they can still be reproduced.
• Regression of old errors – a situation where recent changes in the code have canceled previously corrected defects, and old bugs have returned.
• Side effect regression – recent changes have made other parts of the program inoperable for some reasons.

What Is Regression Testing and How to Run It?

When to Perform Manual Regression Testing?

Regression is a set of tests that are repeated from one software build to another, covering the main or error-prone functionality. QA engineers perform regression testing to check the impact of changes in the code on:

• the critical functionality;
• the new features or fixed parts of the product.

In each of these cases, the purpose of regression is to verify the stability of the latest software build developers receive for further work.

Wherein Manual Regression Testing Is Necessary

Ideally, you should perform regression testing after making any changes to the code. However, it’s recommended to run regression tests on the following occasions:

1. New functionalities
2. Changes in the requirements
3. Defect fixes
4. Performance issue fix

Methods of Manual Regression Testing

There are different regression testing methods. You can choose which one suits best for a specific project when you are familiar with the project details. Thus, it is essential for a QA engineer to be familiar with at least several of these methods.

Retest-All

This is the most comprehensive method of regression testing, since you retest the entire system to confirm there are no defects to the current code version. It is useful when there are extensive updates and revisions, not just small modifications or changes. It can also work for small projects, since full retesting of large systems would be too time-consuming.

Selective Testing

Software testers check how the new code impacts the rest of the code. As the name indicates, for testing, you select a few parts that might have been affected due to the change. In the process of regression test selection, QA engineers use a subset of existing test cases to save a lot of time.

Prioritizing Tests

In this case, QA engineers use a risk-based approach. They choose cases for a regression suite based on the business impact of the covered functionality, frequency of usage, failure rate, bugfix cost, etc. The task here is to go through as many top-priority cases as you can within required time limits.

Manual Regression Testing Step-by-Step

How to plan and organize regression testing? As a rule, this process includes four steps:

1. List the changes.
2. List the affected parts.
3. Determine the coverage.
4. Plan and run the tests.

Now, a bit more details on each of these steps.

List the Changes

Regression is a change-related type of testing. Obviously, QA engineers should be aware of what has changed in the system since the last time they’ve tested it. This information is important for the following steps.

List the Affected Parts

You can request this information from developers. They have written the code, and they are aware of all the connections and dependencies. Therefore, developers can point out the potentially affected parts.

Determine the Coverage

With this information in mind, a QA engineer reviews the existing test cases. They decide what to use in the upcoming round of regression testing and what additional tests should be executed. In other words, a QA specialist needs to finalize the types of regression tests for this particular build.

Plan and Run Tests

Now, it is time to add a couple of new test cases if they are lacking, schedule the testing process, and execute the tests. Typically, the regression suite will include cases that:

• cover the core features;
• have a high defect rate;
• undergo frequent changes;
• include boundary values.

Again, some of these artifacts may already be present in a regression test suite, and some need to be added.

Example of a Regression Checklist

Let’s say, you work with an e-commerce platform. During the current sprint, developers have made some changes to the functionality:

• added a new search module;
• moved the page for buying gift cards from the catalog to the site header.

It would be necessary to run regression testing for the website search and gift card. Thus, a checklist will look something like this:

Search regression

• Check the search field displaying.
• Check the search history displaying after field activating.
• Check the search by history.
• Check the search suggestions.
• Check the search by category name.
• Check the search by product name.
• Check the search with an empty field.
• Check the search with invalid data.
• Check the search results page.

Gift card

• Check the gift card icon displaying.
• Check the gift card page opening.
• Check the breadcrumbs.
• Check the gift card page displaying.
• Add to cart with invalid data.
• Add to cart with letters in the value fields.
• Add to cart with empty field.
• Check the gift cart preview, and so on.

These aren’t the precise checklist – the final version will vary based on the particular search and gift card functionality you are working with.

To Sum Up

Because of the dependencies in software code, even a slight change can affect other features and integrations. Manual regression testing helps detect what exactly has been affected. To perform it accurately, you need to understand the prerequisite specifics of every functionality, both old and newly-introduced ones. It will save a lot of your time.