Construction or Assembly? The Question That Defines Your Next D365 Wave Release
By Andrew Doughty, CEO, Virtuoso QA
Last month I got on a call with an IT director who told me his team had worked fourteen straight days to stabilise their D365 environment after a Wave release. He wasn't boasting. He was exhausted. And he asked me a question that told me everything I needed to know about the state of D365 testing in 2026: "Is it supposed to be like this?"
Two weeks later we were presenting a webcast on MSDW called Select, Configure, Automate: Stop Building D365 F&O Tests From Scratch. Same week, the fourteen-day fire drill and the webcast. Sitting with both at the same time, I realised how connected they were.
The pattern nobody inside a single D365 org can see
I've heard some version of the fourteen-day question more times than I can count this year. What strikes me isn't the exhaustion. It's the resignation. Capable, senior D365 leaders have quietly accepted that Wave releases are supposed to cost them two weeks of panic, a couple of weekends of firefighting, and a slow erosion of trust between IT and the business units who thought the system was going to work properly this time.
It doesn't have to be like this. And from where I sit, talking to D365 teams across industries and geographies, I can see the pattern clearly.
The teams who move through Wave releases cleanly and the teams who suffer through them are not separated by budget, headcount, or the seniority of their D365 architect. I've watched lean teams glide through updates and well-funded enterprises implode. They're separated by a single, quiet distinction: whether they're still building their tests, or whether they've started assembling them.
Construction is not the same as assembly
Most D365 testing programmes I see are still organised as construction projects. Every release, every customisation, every integration triggers a round of "we need to write these test scripts from scratch." RSAT scripts. Custom Selenium frameworks. Ad-hoc spreadsheets of manual test cases regenerated each Wave. Functional consultants briefing developers. Developers learning business logic second-hand. Tests that are fragile the moment a UI element shifts.
That model made sense a decade ago, when D365 change was slower and customisations were fewer. It does not make sense now. The regression surface grows every quarter. Wave cadence is faster than your test maintenance cycle. And every time you're building a test to cover Procure-to-Pay, Order-to-Cash, or Lead-to-Revenue, you're building something that has been built a thousand times before, in a thousand different tenants, to cover roughly the same business logic.
The teams who've stopped firefighting have stopped building and started assembling. They pick from a library of pre-built, composable test modules that already cover the standard D365 processes. They configure those modules for the specifics of their environment: their customisations, their data shapes, their integration endpoints. They automate. Select. Configure. Automate. One week to the first tests running. Two to four weeks to full regression coverage across their footprint. No heroics. No weekends.
The 94% gap
At Virtuoso QA we've put this model into practice with over 1000 pre-built D365 tests spanning Finance & Operations, Sales & Customer Service, Supply Chain Management, and Project Operations. Roughly eighty percent of standard D365 processes are covered out of the box. The remaining twenty percent get configured for your specific setup.
The delta between building tests from scratch and assembling them from pre-built components, in our customers' own data, is a 94% reduction in test development effort. That is not a marketing number. It is the structural consequence of switching from construction to assembly. And once you see the gap, you can't unsee it.
Three questions worth sitting with
If you're inside a D365 org right now and wondering whether any of this applies to you, I'd ask yourself three questions.
First, who is authoring your tests today? If it's a small group of technical testers or developers, you're paying a translation tax every time business logic moves from the functional consultant who actually understands the process to the engineer writing the test. That translation tax compounds with every Wave release.
Second, what happens to your tests when Microsoft ships the next UI update? If the answer involves someone manually rewriting selectors or re-recording scripts, your test library is a liability, not an asset. AI self-healing is no longer a nice-to-have. It is the thing standing between your team and the next weekend lost to firefighting.
Third, how much of your regression pack are you rebuilding from scratch that already exists, in composable form, in someone else's library? This is the question that changes economics. For most D365 teams, the honest answer is uncomfortable.
An invitation
If you're heading into the next Wave release wondering whether you'll spend it firefighting again, I'd like to offer thirty minutes with my team. Not a pitch. A working session on your current regression surface, where the brittleness is, and what a Select-Configure-Automate approach would actually look like for your specific D365 environment.
You'll walk away with a clearer view of your testing risk profile, whether or not you ever become a Virtuoso QA customer. That seems like a fair trade for half an hour.
And if you'd rather watch before you talk, our recent MSDW webcast Select, Configure, Automate: Stop Building D365 F&O Tests From Scratch walks through the full model in about twenty minutes. No registration wall, no follow-up email barrage.
Andrew Doughty is CEO of Virtuoso QA, the composable test automation platform built for Microsoft Dynamics 365.
Learn more at www.virtuosoqa.com or connect at [email protected]