how to do regression testing for new upgrade?

[saini]

how to do regression testing for new upgrade?

[david_loo]

While youre performing your test, if you pair your test instance up with Perspectium Observer, you can track and benchmark specific transactions before and after upgrade in order to see if you have gained performance due to the upgrade.   Customers also use this method to detect bad update sets before pushing to prod.

You can check out this video on how to follow specific transactions: Trending specific transactions over time with Observer - YouTube

Best

David

[sophielane7]

When you’re doing regression testing for a new upgrade, the main idea is simple: make sure nothing that used to work is broken after the change.

A good starting point is to understand what exactly is being upgraded. Go through the release notes and identify which modules or features are affected. Even small changes can impact other parts of the system, so it helps to think beyond just the obvious areas.

Next, focus on your critical workflows. These are the flows your users rely on the most, like login, core transactions, or integrations. If something breaks here, it has the biggest impact, so they should be tested first.

Your regression test suite also needs a quick review. Keep the important and frequently used test cases, remove outdated ones, and add new cases based on what has changed in the upgrade. There’s no point in running tests that no longer reflect the system.

If your project allows it, automation can make things much easier. Running the same regression tests manually after every upgrade is time-consuming and error-prone. Automating stable test cases helps you get faster and more consistent results.

Don’t forget about integrations and APIs. Upgrades often affect how systems communicate with each other, so it’s important to validate responses, data flow, and third-party connections.

It’s also a good idea to run these tests in an environment that’s close to production. This helps catch issues related to configuration or dependencies that you might miss otherwise.

Finally, go through the results carefully. Not every failed test means something is broken. Sometimes the behavior has changed as part of the upgrade, so you need to separate expected changes from actual defects.

Some teams also try to reduce the effort of maintaining regression tests by using real usage data. For example, tools like Keploy can capture API calls and turn them into test cases, which helps keep regression coverage closer to how the system is actually used.