Why a CRM needs regression testing
After the go-live, your CRM keeps changing, even when your own team changes nothing. Salesforce and Microsoft update the platform for every customer. Most changes are improvements. Some change a page, a default setting or the way a feature works, and now and then one breaks something your business relies on.
A regression test answers one question: does what the business accepted at the go-live still work? It is not a new UAT. It is a short, focused check of the processes that matter most, done before the change reaches your users, by people who know the work.
Your own releases need the same check. A new integration, a new field on the quote, a change to the routing of cases: each one can touch something that worked before.
Salesforce: three releases a year
Salesforce has three major releases a year: Spring, Summer and Winter. The Winter release comes in the autumn and carries the number of the next year. Every org is upgraded, on dates that Salesforce publishes in advance.
- The sandbox preview. Sandboxes on a preview instance get the new release some weeks before production. That is your window to test. Before each release, Salesforce says which instances are in the preview and what to do to keep a sandbox there. A refresh can move a sandbox in or out of the preview, so check it in time.
- The release notes. Read them for the clouds and features you use. Look for what is switched on for you automatically, and what changes the look of pages your users work in.
- Release updates. Some changes are announced in Setup with a date on which they are enforced. Test them in the sandbox before that date, so they do not surprise you in production.
So for Salesforce, the rhythm is given: a regression round in the preview window of each release, three times a year.
In UAT StudioChoose Salesforce as the CRM of the project. From about two months before a release, the projects page shows Coming CRM releases, with the date of the sandbox preview, the date of production and a link to the release notes. Salesforce can still move these dates, so check the release notes.
Dynamics 365: updates all year
Microsoft no longer bundles Dynamics 365 changes in two release waves a year. New features and changes roll out all year. The release plans were archived in October 2026; what is coming is now in the Microsoft roadmap at aka.ms/AIatWorkRoadmap.
That means there is no longer one big moment a year to plan your testing around. Changes come in smaller steps, more often. Waiting for a big release does not work any more, and testing after every single change is too much.
Choose a fixed rhythm
The answer is a regression round on a fixed rhythm, whatever Microsoft releases in between:
- Every month when the CRM is central to the business, you use many apps and features, or you switch on new features often.
- Every quarter for a stable setup with few changes of your own.
- An extra round before a change of your own goes live, or when a change from Microsoft clearly touches one of your key processes.
Put the dates in the calendar of the testers for the whole year. A fixed rhythm is easier to keep than a round that is planned each time something comes up.
Before each round
- Read the Microsoft roadmap and the messages for your admins in the Microsoft 365 admin center, and note which changes touch your processes.
- Try features in preview in a sandbox environment first, before they reach your users.
- Make sure the sandbox you test in has the same version and the same solutions as production.
In UAT StudioChoose Dynamics 365 as the CRM of the project, and start each round with Start a regression round, from the project of your go-live or your last round.
In UAT StudioUnder Setup, choose Check the Dynamics 365 updates: Every quarter or Every month. The projects page then shows the current period with a link to the roadmap, and admins get one email per period, two weeks before it starts.
Choosing what to retest
A regression round is not the place to test everything again. Choose, in this order:
- The Must test cases. What has to work every day: creating a quote, converting a lead, routing a case, the approvals. Test these every round.
- What the change touches. Read the release notes or the roadmap with the list of your processes next to it. A change to quotes means the quote test cases, also the Should and Could ones.
- Integrations and automation. The links with the ERP, the website or the email, and the flows that run in the background. They break quietly, so test them on purpose.
- The Should test cases, when there is time.
Then look at what your own team changed since the last round. Everything you built yourself and nobody tested together with the platform change belongs in the round too.
Keep a short list of what is critical
Write down, once, the ten to twenty processes the business cannot do without for a day. Those are the core of every regression round. Review the list every half year with the process owners, and after every big change of your own.
In UAT StudioWith the Release readiness add-on, Review the release shows which of your test cases a Salesforce release or Dynamics 365 update touches, with the reason, proposes test cases for what is not covered yet, and lists the required updates with their dates. The regression round then gets exactly the Must test cases, the touched ones you keep and the new ones you approve. A fail in the round says which change it came with. €99 per month: add it under Plan & billing.
Reuse your test cases
The best regression test you have is the set of test cases from your go-live UAT. They describe exactly what the business accepted, with the steps, the test data and the expected results. Do not write new ones for each round.
- Keep the test cases after the go-live, in one place, with their priority.
- Update them when your own process changes, so the next round tests the CRM as it is now, not as it was at the go-live.
- Check the test data before each round. A sandbox refresh or a copy of production can remove or change the records the test cases use.
- Add a test case for every serious issue found in production, so it is caught next time.
Test cases that business testers can follow are worth the effort here: they are reused again and again. See Writing test cases business testers understand.
In UAT StudioStart a regression round copies the test cases of the project you start from, with their steps, test data and expected results. Choose which come along: Must and Should, Only Must or All test cases in scope; a test case without a priority counts as Should. The new project gets the groups and settings, and you invite the testers under Setup. Nothing is made up or changed.
Who tests, and how long
Who
A regression round needs fewer people than a UAT, but they should still come from the business. Ask one or two key users per process: people who do the work every day and know at once when something is off. The CRM admin prepares the round and tests what runs in the background, but should not be the only tester.
Let the same people test round after round. They get faster, and they notice small changes a new tester would miss.
How long
- Preparation: a day or two to read the changes, choose the test cases and check the test data.
- Testing: a few hours per tester, spread over one or two days for a monthly round, up to a week for a Salesforce release with many changes.
- Fixes and retests: keep a few days before the change reaches production, for the issues you find.
For Salesforce, that has to fit in the preview window. Start early in the window, not in the last week.
Logging what you find
Log issues as in the UAT: the step, what you expected, what happened instead, a screenshot and the link to the record. Triage them every day with the CRM team. For an issue caused by the platform, look in the release notes or the roadmap first: often it is a known change with a setting to adjust.
In UAT StudioEach round keeps its release, build and environment, so the go/no-go report says what was tested. After fixes, Start round 2 on the dashboard with Failed and blocked only retests just what went wrong; the results of the earlier round are kept.
Sign-off before production
A regression round ends like a UAT, with a decision, only shorter. Agree the exit criteria once, and use them every round:
- Every Must test case has passed.
- No Critical issue is open.
- Every open High issue has a workaround that the business accepts, or a fix before the change reaches production.
The owner of each process signs off for their part: accepted, accepted with conditions, or rejected. For a Salesforce release you cannot stop the upgrade, so a rejection means a fix or a workaround before the production date, and a message to the users. For a change of your own, a rejection means it waits.
Keep the result of every round. After a year you have a clear record of what was tested after each change, and who accepted it. For how to prepare the decision, see The go/no-go decision.
In UAT StudioA regression round is a project of its own, with the release as its Release, so its go/no-go report says which CRM release it is about. The process owners sign off per group, and the sign-off belongs to that round.
Free to use
The UAT checklist for a CRM go-live works for a regression round too, as a free Excel file. For each platform, see Salesforce UAT and Dynamics 365 UAT.
Salesforce is a trademark of Salesforce, Inc. Microsoft and Dynamics 365 are trademarks of the Microsoft group of companies. UAT Studio is not affiliated with or endorsed by Salesforce or Microsoft.