Most D365 teams cannot answer a simple question: what does our testing actually cover? There is usually a regression suite, inherited from an implementation partner, that nobody has audited since go-live. It runs, it passes, and everyone assumes that means something.
This checklist is what we walk through on a coverage review. Score each item honestly: covered, partly covered, or not covered. Any item you cannot answer confidently is itself the finding — unknown coverage is the same as no coverage the day something breaks.
Across the reviews we run, the same four items come back uncovered more often than anything else on the list.
Almost every suite tests the happy path. Almost none tests a partial shipment against a credit-held customer with a back-dated invoice — which is the transaction that will break.
Teams test that integrations work. Very few test what happens when the other system is down, slow, or returns something unexpected mid-batch.
Roles get tested for what they can do. The far more expensive question — what can this role do that it should not — is rarely asked until an audit asks it.
A suite that passes against three clean records proves very little about a system carrying six years of real, messy history.
It takes about an hour with the right two or three people in the room:
No. The full 15-point checklist is published on this page with nothing gated, no download and no form. If you want a second opinion on how you scored, we run a free coverage review — but the checklist itself is yours to use either way.
At minimum: configuration and posting routines, financial dimensions, period-end close, exception paths, cross-module dependencies, integrations including failure modes, data migration accuracy, security roles and segregation of duties, batch and workflow timing, release-wave regression, extension compatibility, realistic test data, and clear ownership of failures.
Score it once now to establish a baseline, then re-score after each of Microsoft's release waves or any significant configuration change. Coverage decays quietly — a suite that was adequate at go-live usually is not two years and four waves later.
That is the normal result, and it is more useful than a good score. Almost every team we review has significant uncovered areas, usually because the suite was built during implementation and never revisited. The point is to know which gaps matter enough to close first, not to pass.
© 2026 TestSquad. All rights reserved. · Privacy Policy
