When you’re starting out with regression testing, you might assume that to implement a regression testing strategy, you need to start writing scripts. Not so! In this post, we’re giving you the exact steps you need to manage regression testing in a fully manual way.
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?
While automated regression testing can be one of the first types of testing that teams choose to automate, that doesn’t mean that regression testing shouldn’t also be manual.
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
The reason why it’s often automated is that it needs to be done continuously and the test cases can be reused. However, manual testing delivers higher quality at a lower cost. It’s often more time consuming to manage automated scripts than to handle testing using manual and strategic exploratory methods.
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.
For fully managed manual testing with a global network of expert testers, check out our mobile application testing service.
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.
While test cases will give testers exact steps, exploratory test prompts will assign certain features or areas and leave it up to the expert tester to intuitively create their own test cases. It’s usually best to use both methods in combination, and with some overlap.
6. Create bug reports with steps, screenshots, and videos for easy reproducing
Whether you’re handling regression testing with a team of 5 testers or 50, one thing is for certain: you need complete consistency with the bug reports. The ideal bug report includes the feature name, the environment, steps to reproduce (bonus points for screenshots and screenshare videos), the expected result, the actual result, and the assumed priority of the issue.
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.