In software testing, regression tests are a series of tests run right before releasing a new feature or update to make sure the critical functionalities of your software are still working.

Regression testing is done to make sure a new build didn’t introduce bugs into other, existing features of your software. However, if you don’t make smart decisions about what you’re testing and how you’re testing, regression testing can end up creating more work for your team without leading to significant improvements in software quality.

In this post, we cover the basics of regression testing, how to get started, how to overcome the most common challenges, and additional best practices for improving software quality without wasting time and resources.

  • What is software regression testing?
  • Who can do regression testing?
  • What test cases should be included in regression testing?
  • What are the main challenges of automated regression testing?
  • What are some best practices for automated regression testing long-term?
  • What are some options for automated regression testing tools?

Ready to automate your software regression testing? Talk to us about setting up a Rainforest plan that fits your needs.

What is software regression testing?

Regression testing is typically the last step in the software release process and focuses on testing the main user paths of the entire application rather than the new code specifically.

Regression testing can be performed manually or with an automation platform. While manual testing doesn’t require any special tools or knowledge, it’s slow, time-consuming, and prone to human error. Most teams (especially teams using the agile methodology) eventually need to automate their regression suite in order to keep up with release deadlines without sacrificing software quality.  

Who can do regression testing?

Who can write, run, and maintain your regression test suite will depend on the type of regression testing tool you choose to use.

Regression testing tools typically fall into two categories: coding frameworks and no-code tools. Coding frameworks, like Selenium, provide a way for developers to automate actions in a browser by writing test scripts using a programming language. Most no-code (or “codeless”) testing tools generate coded test scripts for you by recording your interactions with the application or by a library of pre-written actions. However, most are pretty limited in the types of test cases that can be created without having to write additional code. Eventually, most teams need someone with coding experience to create the necessary test cases.

Rainforest QA is the only true no-code tool that lets anyone write complex test cases without writing any code.

To write or edit a Rainforest test, select an action such as ‘click’ or ‘fill.’ Then, take a screenshot of the element you want to apply the action to by clicking and dragging your mouse over the element. Rainforest will use this screenshot to locate, interact with, and verify the element in test runs.

Adding a Click Action in Rainforest QA: Try for Free Button

The written steps appear to the left of your screen and the right panel of your screen is where you preview the steps. You can preview test steps as you write or view the entire test once all steps have been written out.

Then, when you’re ready for test execution, you can kick off a complete regression suite or select specific tests from within the Rainforest platform. Developers can also start a test run from within your CI/CD pipeline via our API, CLI, CircleCI Orb, or GitHub Action.

What test cases should be included in regression testing?

Many teams try to create a test case for every user path in an effort to ensure the entire application is bug-free. However, for most teams, complete test coverage takes too much time and causes delays in the release process.  

The good news is that even a small regression suite can significantly improve the quality of your software. However, not all test cases are created equal. If you aren’t testing the right things, more testing just means more work.

To determine which test cases to start with, we like to use the analogy of plowing city streets after a snowstorm. First, you focus on clearing the highly traveled main roads. Then, as time permits before the next snowfall, you clear side streets. In large cities, some streets may never get plowed before the next snow storm.

Likewise, we suggest focusing your testing efforts on the user paths of your application that get used by the most users and cover critical functionalities (such as a login or checkout process). From there, you can add more tests as the software grows or as your quality goals change.

What are the main challenges of automated regression testing?

With any type of software testing, one of the main challenges is allocating enough time to complete the entire testing process while keeping up with release schedules. This is particularly true when it comes to regression testing since it typically happens at the end of the software development lifecycle when there’s extra pressure to release quickly.

In this section, we cover the three main areas that slow down regression testing and show how Rainforest QA was designed to mitigate these challenges.

Challenge #1: Tests Breaking from Minor Code Changes that Don’t Affect the UI

Most functional testing tools search for element locators in the underlying code (a.k.a., the DOM) of a web application to perform test steps. If the element locator is present, the test will move on to the next test step and eventually return a passing test. However, if the element locator is changed even slightly, the test will usually fail because it doesn’t think the element exists.

In most cases, a minor error in the element locator doesn’t affect the functionality of the element or how it appears on the user interface (UI). This means tests may fail even though nothing about the element has changed for the end-user.

If the element is used throughout multiple regression test cases (like a homepage button, for example), a minor change in the underlying code could cause nearly every test in your regression suite to fail. In this case, it will be difficult (or impossible) to tell if there are any real bugs in your software. This means you have to re-run the entire regression suite after fixing the error or skip rerunning the tests and risk shipping bugs to production.

To avoid this, we recommend using a visual regression tool like Rainforest QA that tests the UI directly rather than the underlying code. Just like a real user that never touches the DOM, Rainforest tests only respond to changes on the UI. As long as the UI stays the same, Rainforest tests can handle a wide variety of back-end code changes without breaking.

Note: Smoke tests can also help you avoid having to re-run entire regression suites because of one broken element. You can read more about automated smoke testing in this article.

Challenge #2: Updating Tests to Reflect Changes in the Software

Although choosing the right tool can eliminate some of the false failures that come with code changes, there’s another culprit that can cause false failures: outdated tests. If a test doesn’t get updated to accommodate new functionalities or to reflect new changes to existing functionalities, the test will most likely break because it’s looking for an old version of the software that no longer exists.

That’s why test maintenance is a necessary part of any automated software testing. If tests aren’t up to date, many teams skip running the test altogether or ignore failed tests because they assume it was caused by obsolete test cases and not a real bug.

However, test maintenance can be very time-consuming when using a tool that requires you to make corrections by editing the code directly. With Rainforest QA, anyone can view the test script, understand exactly what’s going to happen, and make the necessary edits without writing any code.

For example, if the ‘Try for free’ button in the screenshot below was changed to ‘Sign up for free,’ anyone can easily see which test step uses that button and take a new screenshot.

Rainforest Signup Flow: Preview Actions

This is much easier (and faster) than analyzing and re-writing tons of code. And, you don’t have to rely entirely on developers’ time to keep up with test maintenance.

Challenge #3: Triaging Test Results

Understanding why a test failed is the final area that most teams struggle to find the time to complete. If you have a lot of failed tests to sort through, it can be difficult to attend to all of them before the release deadline. This means you either release late or release with potential bugs. Often, the severity of the bugs and the user flows they impact will be the determining factors in that decision.

Rainforest QA makes it really easy to understand test results and categorize failures. Here’s how it works.

Rainforest QA automatically records a video of every test run whether it passes or fails. These video recordings are stored indefinitely and can be used to figure out what changed between test runs.

Rainforest Signup Flow: Element Mismatch

If you aren’t able to immediately see what caused the failure, you can click on the ‘investigate action’ button for any test step. This gives you more information about how the result was determined, such as the difference between the original screenshot and the closest screenshot found.

Book a Flexible Trip Airbnb test: Action Failed example

You can also download HTTP and browser logs, which are often the key to identifying glitches in the testing environment.

Finally, you can categorize each test failure so the development team knows which bug fixes to prioritize.

Failed Tests Summary in Rainforest QA

What are some best practices for automated regression testing long-term?

Many teams believe that some testing is better than no testing when it comes to the quality of your software. While this is sometimes true, testing the wrong things in the wrong way will cost you a lot of time and resources without seeing much improvement in the quality of your software.

In this section, we cover a few best practices that will help you automate your regression testing from the start without wasting time or resources.

  1. Outline an automated testing strategy and update it regularly. A testing strategy will help you determine which user paths need to be covered by a test and the best testing technique to reach your quality goals. A testing strategy will also help you establish how testing will get done and by whom. You can read our guide for building an automated testing strategy here.
  2. Build a test plan. With a test plan, you get specific about what each test needs to cover, the dependencies of different test cases, and the success criteria for testing a specific feature. This helps ensure each test is actually contributing toward your quality goals without creating extra work. A test plan also helps with test case prioritization. Prioritizing your test cases from the beginning allows you to make quick decisions about which tests to run when you don’t have time to run the entire regression suite. You can read our tutorial on how to write a test plan which includes a free template and outlines six steps to follow.
  3. Manage automated and manual testing from the same platform. Automating as many test cases as possible allows you to manage more testing in less time with fewer resources. However, some test cases shouldn’t be automated. These include test cases with test steps that require human interpretation or user paths that experience constant change. You can read more about when to use manual vs. automated testing here.Even if your team can handle a few manual test cases early on, as your software grows, it can become increasingly difficult to manage manual testing without adding headcount. That’s why we recommend using a tool like Rainforest QA that provides an automated testing platform and a community of quality assurance specialists for manual testing.
  4. Minimize test maintenance. As we mentioned earlier, one of the side effects of a new build is the necessity for test maintenance. Test maintenance is often one of the main reasons for an ineffective or slow regression testing process, so finding ways to minimize it will help you speed up and improve your testing. We’ve provide an in-depth discussion (with examples) on eight best practices for reducing test automation maintenance here.
  5. Use a tool that lets you easily scale up your testing as your software grows.

Easily Scale Up Testing

Rainforest QA provides everything you need to write, run, and manage any size of regression suite including:

  • Test management tool for keeping any number of tests organized.
  • Access to multiple operating systems and browsers, including current and older versions of Safari, Chrome, Firefox, Edge, and Internet Explorer.
  • Built-in test data like randomized email addresses, credit card numbers, names, etc.
  • Unlimited team members.
  • Integrations with Slack, Microsoft Teams, and email so your team can get real-time testing reports for test failures, run completions, and more.
  • Jira integration so you can send new bug failures to the dev team. Tickets include steps from the failed test, a screenshot from the failed test step, and a link to the video replay and more information in Rainforest QA.

All of this is included with your account—you only pay for time spent running tests.

Talk to us about setting up a Rainforest plan that fits your needs.