Request info

How to implement a manual regression testing strategy

With all the buzz about automation, (ok… it’s probably coming from us. It’s exciting, what can we say!) it’s almost a first response to start writing scripts. To keep the functionality and performance of your software, there are places where manual regression testing is required.

No code, no scripts, no automation. 

Keep scrolling for the reason why manual regression testing is a brilliant idea, our step-by-step process, and a checklist at the end. 

Why use a manual regression testing strategy?

As a reminder: regression testing is when you test parts of the mobile app or software to make sure that new updates haven’t introduced bugs that weren’t there before.

Instead of just testing new features and small updates alone, you also test:

  • What areas of the app the updates might have affected 
  • Or the app in its entirety, after any updates have been made

Manual testing—especially strategic exploratory tests where skilled testers take on different product areas and approach the product exactly as a user would—allows for the most realistic mobile testing possible.

Step-by-step regression testing process 

Regardless of your automation prowess, you need to be doing manual regression testing. Let’s look at a step-by-step process for how to do this right. 

1. Determine your regression testing strategy for this round

The first step is to make a very simple choice: for this particular round of regression testing, will your strategy be to re-test your entire app, or will you be focusing only on affected areas and known problem areas?

Sometimes, you only have time to do a check where potential issues will lie (in order to release the updates quickly). At other times, you’ll want to test the entire app, especially if this hasn’t been done in a while.

This decision is impacted by the breadth of the update, the timing for the launch, and how frequently you test old features. 

2. List out what updates have been made to the product

Next up, you need to list out what updates have been made to the product. Communicate with the product manager to better understand the nature of the recent updates. It helps to write all of this out either on paper or in a document, so you can be sure that you don’t forget anything. (Directives get lost in emails all the time.) 

3. Consider what additional features those updates could have impacted

Now that the product updates are in your own environment (your trusty notepad or Google doc), it’s time to list out what additional features could have been impacted by the updates.

For example, if your app moved from offering two-factor authentication to multifactor authentication, you might want to check different account organizational settings, user profiles, admin and permissions settings, etc. 

4. Decide what known problem areas or additional testing components will be included

Are there any problem areas in your app? Is there a feature that is prone to breaking and receives a disproportionate amount of customer service issues and QA-discovered bugs?

Maybe this feature or area is…

  • Used most often
  • Easily affected by updates
  • Frequently misused by users
  • Prone to hacking attempts

In addition to those known problem areas, you’ll also need to think about different testing components to include in this round. Especially with mobile app testing, this could mean device types, connectivity requirements, localization, etc. 

5. Divide and conquer the testing surface area

Now that you’ve got a big running list of what to test, it’s time to break it down into individual test cases and exploratory test prompts in your test management software such as TestRail or JIRA.

6. Create bug reports with steps, screenshots, and videos for easy reproducing

7. Confirm testing coverage with testing resources

Next, after all testing is completed, you need to get confirmation from your team on what was covered. Check that everyone marked their tasks as done in your manual test management platform. Also, review the bug reports to see if any feature areas are missing. Are there really no issues, or did something get missed?

8. Save and reuse your test cases

Now it’s time to review the test cases and exploratory test prompts you created for this round, and see how they fit into your regression testing strategy overall. 

  • Which test cases can be reused as is?
  • Which test cases need to be rewritten in order to be reused?
  • Which test cases do not need to be included in your ongoing regression testing strategy?

Using your test management tool, save, templatize, or copy the test cases and prompts so that the next time you do a round of regression testing, it’s much faster to strategize coverage and assign tasks. 

Regression testing can be overwhelming because of the inherent breadth and complexity, but when you use this process, you can keep yourself and your team on track. 

Jumbotron image