hen most people think of regression testing, they think “automation” — and while automation is definitely where you'll want the majority of your regression tests to be, you shouldn't overlook the benefits of having a manual regression testing process.

If you're not doing any regression testing at all (or if you do, but it's all automated and those automated tests aren't up to date because you haven’t had time to catch up), have a read below and see if running some manual regression testing might be the answer.

What is manual regression testing?

Regression testing is about trying to make sure your product doesn't regress, and making sure that bugs which have been previously fixed don't come back to haunt you. It's a safety net that can catch what might otherwise be embarrassing. No product is totally bug free, but a product that repeats the same bugs gives the impression of a development team that doesn’t learn from its mistakes, which isn’t a good look.

The regression testing process involves creating a growing list of tests to check that everything that has broken before is still working in the latest release. Think of it as the equivalent of a holiday packing checklist. You go on holiday and realize you forgot the sunscreen, so as well as going out to buy some, you amend your packing checklist with a "did I pack sunscreen?” option for next time.

Automation tends to be the go-to for most organizations when it comes to regression testing. It’s fast, reliable, and super efficient — and it’s a perfect solution when the conditions are right and budget allows it.

So where does manual regression testing come in? Manual testing follows the same process, but the testing is performed manually, by hand, with a human working through a defined list of bug checks.

It’s less about speed, because automation is so fast, and more about having a regression test for a bug immediately — regardless of whether you have the time and resources to implement an automated test for it.

It's also a good solution for when automating a test is never going to be cost effective, a test is too difficult or awkward to code, or there’s simply not enough developer capacity available.

When to go manual, and when to automate

So which should you choose, manual or automated testing? It boils down to trying to automate regression testing when it’s a cost effective option, and using the manual process for everything else.

When to use manual regression testing

The key benefit of manual regression testing is that you can bring a new test into existence almost instantly. All you need to do is open your regression test list document and type in a new test.

It can be a good idea to have a regression testing process where, for every bug that's fixed, you add it to your list of manual regression tests. Then later, when resources allow it, consider promoting these tests into your automation framework, if you have one.

Manual testing is your best friend in situations where you need to catch previously encountered bugs, but can’t immediately automate a test for whatever reason. Having a checklist of predefined manual tests means your team can start testing immediately, rather than waiting for automation scripts to be created, debugged, and launched.

Regression tests don’t need to wait until you have time or money or resources to automate them, because their value stands however they're implemented.

When to use automated regression testing

Basically, any test that can be automated cost-effectively should be, as soon as resources allow it. Automated tests can be run over and over again, near instantly, and often automatically when a developer makes any change to the code base.

This lets you identify issues as soon as they're created, which can also be the cheapest time to fix them, as the relevant code is still fresh in the developer's mind.

But of course, not all tests can be easily, cheaply, or quickly implemented in code. Many tests are tricky to automate, sometimes requiring complex test harnesses to replicate conditions and test responses.

Every automated test adds more code that needs maintenance – and that will have bugs in it from time to time that also need to be detected and fixed. So automations aren’t a catch-all solution by any means.

In the early stages of development, or dealing with iterating on complex features, it’s best to start with manual tests. As your software becomes more stable, and your regression tests begin to prove their value, consider automating the tests where it makes sense to do so.

Remember, the goal isn’t to automate everything. It’s to automate wisely, leaving room for your human testers to step in and check things when it makes sense.

Tips for Effective Manual Regression Testing

The manual regression testing process is simple. You just need to build and maintain a list of tests for things that have been previously detected and fixed. Here are some tips to get you started:

1. Make a list

Open a new spreadsheet or document (or use a tool like Testpad) to keep your list of manual regression tests in. Decide what you’ll be adding to your test checklist, and make sure that all the relevant people know where the checklist is located so they can add to it and run manual tests when resources allow.

2. Maintain your list

Your list of manual regression tests should evolve along with your software. Every time a bug is fixed, add a new test to your checklist to make sure it doesn’t come back to haunt you.

3. Keep it simple

Don’t overcomplicate things. A simple checklist can be your best friend for manual regression testing. Use it to ensure you’re covering all the bases without missing a step. Tools like Testpad can help keep your checklists and testers on the right track, but even a spreadsheet can do the trick.

4. Review your list

It’s a good idea to regularly review your list to see if there are any manual tests that could be automated.

5. Prune your list

Later on in the product life cycle, say after several releases, your manual test list might be taking your testers hours to run through. If the list gets too long, consider pruning older tests for bugs that are very unlikely to happen again, or if they do regress, no-one will remember anyway so it won’t be so embarrassing.

6. Prioritize your tests

If the test list gets long and needs to be long, consider prioritizing the more critical or important aspects of the product. This will find any regressions in more important areas earlier in the process, saving time if you need to fix and restart the regression testing process.

Is regression testing the only type of testing you need?

Regression testing is a useful part of the development process, but it doesn’t give you a complete picture of what’s going on with your software.

Because each regression check (whether manual or automated) is precisely defined, the scope of testing is limited to exactly those checks. Any bugs or problems that might exist outside that detailed scope won't be detected.

For the wider picture of possible problems, a good test strategy will include methods that go beyond regression testing.

Exploratory testing

Exploratory testing is arguably the best kind of testing. It takes advantage of tenacious human curiosity and intuition to hunt for the unexpected, to dig into software, invent test ideas on the fly, and react to how the software is behaving.

Where regression tests make structured, precise checks for specific things, exploratory testing is more freeform. Your human testers are free to use their own ideas to move around in the software, and react to what they're seeing. In the process, they learn much more about the state of the software and whether it’s ready to ship or not.

Pair regression testing with exploratory testing and you've got a great test process that is likely to find bugs, both new and old.

Other useful tests

• Unit testing: These are automated tests for small units of code (components, classes, functions, capabilities), written beside or together with the code they're testing. They are always run automatically, usually as part of continuous integration. It’s a great process for helping to make sure each separate tiny part of a software system is doing what the developer intended, but it’s not as good for the bigger picture. This means it’s not a substitute for exploratory and regression testing of the whole product.

• System/integration testing: Essentially this is just testing at a higher level from individual components. Simpler products don't need to worry about taking this approach versus just testing the whole product. If your system is more complicated, then this article probably isn't for you anyway!

• Stress/performance testing: It’s a good idea to make sure your testing (of whatever kind) includes checking system performance — both normal performance, and performance under heavy usage. These tests could be a separate process, or could be part of the scope of your exploratory testing, or even your automated testing (if it’s automatable).

• Accessibility testing: The global standards and guidelines set out for web accessibility can help to guide your testing and make sure your software is usable by people with disabilities.

• UX testing: This is testing carried out by live users. By setting tasks or asking targeted questions, users can give you feedback on how easy and intuitive your product is to move around in, so you can identify areas to improve on before release.

Each type of testing has its place, and combined with manual regression testing, they’ll help to make sure your software is ready for every user scenario.

Wrapping up

Manual regression testing isn't really about manual versus automatic testing. It's just about doing some regression testing in the first place, and not failing to do it because you're waiting for the time and resources to automate everything. It’s also about accepting that some regression testing is simply going to be easier or more efficient to perform manually.

Whether you’re using manual or automated tests, it’s important to remember that regression testing is just one piece of the development puzzle. To build truly resilient and stable software you need a variety of testing methods, with each one bringing something different to the table.

We may be bit biased, but if you’re looking for a simple and effective tool to help you stay on track with your manual regression tests, check out Testpad. We combine spreadsheet simplicity with the technology you need to quickly organize and assign your tasks, so you can spend less time documenting, and more time testing.

If you liked this article, consider sharing