Regression testing that survives every Microsoft update wave.
Dynamics 365 updates arrive on Microsoft’s schedule. If every release means days of manual re-testing, or defects that reach production because nobody owns regression, the fix is a test pack written from your real processes and run the same way every time, with automation where it genuinely pays for itself.
What a usable test pack looks like
A test pack is only useful if it reflects how the business works. We write scripts with process owners: the actual purchase-to-pay path with its approvals, the real month-end sequence, the customer order with the discount rule that always causes trouble. Each script has data, steps and an expected result that a tester can follow without asking.
The pack becomes the regression baseline. Before each Microsoft update wave it is run in a sandbox, and the result is a short list: passed, failed, needs attention. Automation (using the Regression Suite Automation Tool for Finance & Operations, or Power Platform test tooling) is added for the scripts that run often enough to justify it.
Defects are tracked to closure with a severity, an owner and a fix date, so testing produces decisions, not spreadsheets.
- Each update wave means days of manual re-testing
- Defects reach production because nobody owns regression
- You need evidence that the system works before a cutover or an audit
- A big change is coming (new entity, new integration) and the existing tests do not cover it
The steps, in the order they happen.
Process inventory
The processes that matter, ranked by business impact. Month-end, order-to-cash and purchase-to-pay usually come first.
Test script writing
Scripts with data, steps and expected results, written with process owners and kept in one place.
Regression baseline
The pack is run once in full to establish the baseline. Failures found here are real defects, fixed before anything else.
Automation where it pays
Scripts run often enough to justify automation are automated. The rest stay manual and cheap.
Update wave cycle
Before each Microsoft release: run the pack in a sandbox, report, fix, then approve production. Every time.
- Process inventory ranked by impact
- Test scripts from your real processes
- Regression pack and baseline results
- Automated scripts where justified
- Defect log tracked to closure
- Update wave test reports
What usually goes wrong, and what fixes it.
The release that broke invoicing
A Microsoft update changed a number sequence behaviour. Invoices went out with gaps. A regression pack run in the sandbox first would have shown it in the invoicing script.
Testing that lived in one person's head
The only person who knew how to test month-end left. Written scripts with data and expected results make the knowledge the company’s, not an individual’s.
Automation for its own sake
A previous partner automated 200 scripts, most of which ran twice a year, and the suite broke on the next release. Automating the twenty scripts that run monthly is cheaper and lasts.
Frequently asked
Yes, for Dynamics 365 Finance & Operations where the scripts run often enough to justify it. Manual scripts remain the right answer for processes that change rarely.
Before every Microsoft update wave reaches production, and before any significant change of your own: a new legal entity, a new integration, a major configuration change.
Yes. Independent testing before cutover is a common engagement: scripts from your processes, run against the build, with a written result you can use in the go-live decision.
You do. They are written to be run by your team and kept in your repository or test tool.
Update wave testing against your key processes is part of the support service. Building the full regression pack is usually a separate, one-time engagement.
Often combined with this service.
Support & Optimization
Dynamics 365 support from the consultant who knows your setup.
AX 2012 to D365 Upgrade
Upgrade from AX 2012 to Dynamics 365 without losing your history.
Articles on this topic.
Microsoft update waves: how to test without stopping the business
A regression approach that fits inside the One Version schedule.
Batch jobs failing in D365 F&O: a checklist before you open a ticket
What to check in batch groups, servers, recurrence and the job itself before escalating.
D365 Finance month-end close: the seven things that usually go wrong
Unposted batches, currency revaluation, inventory close timing, and the fix for each.
Does every update wave mean days of re-testing?
Tell us which processes matter most and how testing works today. We will propose a regression pack that fits.