Here is a question We ask every D365 QA team whome we work with.
If you had to remove 50% of your regression suite tomorrow — how would you decide what stays?
Most teams pause. Some say they’d keep the tests that run most often. Some say the ones that catch the most defects. A few admit they genuinely don’t know.
That pause is the problem.
If you don’t have a clear answer to that question, your regression suite isn’t protecting your releases. It’s just creating the feeling of protection.
This edition gives you the method. Not the observation — the actual, repeatable process that high-performing D365 QA teams use to run fewer tests, cover more risk, and release with confidence.
The Real Problem — Your Suite Is Getting Longer. Your Coverage Isn’t Getting Better.
The instinct when something breaks in production is to add more tests. One more regression scenario. One more automated script. One more validation step.
Over time, this compounds. Suites that started at 80 scripts are now running 600. Execution cycles that took two days now take six. Maintenance that was manageable is now consuming entire sprints.
And yet — the production defect rate hasn’t moved.
The reason is straightforward. Most regression suites grow by addition, not by design. New tests are added for every new feature or incident. Old tests are almost never removed. And nobody stops to ask whether the scripts being added are covering the processes that actually matter.
The uncomfortable truth: a 98% pass rate on the wrong test cases tells you nothing about whether your next release is safe.
The 4-Step Method — How High-Performing D365 Teams Decide What to Test
Step 01: Map your business risk. Before you open your test suite, open a spreadsheet. List every business process in your D365 environment that would cause financial or operational harm if it broke in production. Revenue posting, invoice matching, approval workflows, financial close, supply chain fulfilment. Rank them by impact. This is your risk register. Your test suite should be built around it — not the other way around.
Step 02: Identify what changed. Run a change impact assessment before every release. What did this Wave update touch? Which customisations were modified? Which hotfixes went in? Which configuration changes were made? The intersection of “changed this release” and “high business risk” defines your mandatory regression scope.
Step 03: Trace your integration dependencies. A change to a D365 Finance process rarely stays in Finance. It cascades into Supply Chain, Commerce, external reporting systems, and third-party connectors. Map the dependency chain before testing starts. Test the cascade, not just the trigger.
Step 04: Audit which scripts actually cover those risks. Cross-reference your test suite against everything you identified in Steps 01–03. Which scripts directly validate your high-risk, changed, integration-dependent processes? Those are your non-negotiable tests. Everything else is a candidate for removal, deferral, or deprioritisation.
This is the shift from volume-based to risk-based regression. It takes an afternoon to run for the first time. It gets faster with every release.
The 50% Cut Framework — How to Decide What Stays and What Goes
Plot every test case against two axes: how much did this area change in this release, and how high is the business risk if it fails?
The result is four categories — and a clear decision for each:
Must Test — Full: High risk AND high change impact. Every script in this zone runs. Non-negotiable. Block the release if failing.
Keep — Lite: High risk but unchanged this release. Run core path smoke tests. Full regression not required unless you detect environmental issues.
Watch — Selective: Area changed but business risk is manageable. Run a targeted subset. Flag for post-release monitoring. Re-evaluate the risk rating next cycle.
Retire or Defer: Nothing changed. Business impact is low. These scripts are consuming time and maintenance cost with near-zero protective value this cycle. Remove them from the active suite.
Most teams, when they run this exercise honestly, find that 40–60% of their active test suite falls into the Retire or Defer quadrant. That is the dead weight that has been making releases slower and more expensive without making them safer.
What Good Looks Like
The numbers above are not projections. They reflect what actually happens when teams make this shift — shorter cycles, higher critical flow coverage, fewer production defects, dramatically lower maintenance burden, and a QA team that goes into every go-live with genuine confidence rather than hope.
The reduction in test count is not a reduction in quality. It is a redefinition of what quality means — from running everything to protecting what matters.
Closing Thought
The best D365 QA teams are not the ones with the largest test suites.
They are the ones who can look at every test case in their suite and explain exactly what business risk it protects, what changed to trigger it this release, and what the consequence would be if it failed.
That clarity is what separates activity from assurance.
The question for this week: If you ran the 50% cut framework on your current regression suite — which quadrant would most of your tests fall into? Drop the number in the comments.
Crestech helps D365 and ERP teams across the US and UK build risk-based testing strategies, regression frameworks, and QA governance that actually protect releases. Subscribe to CrestCode for a new edition every Tuesday.
