Dynamics 365 Testing, Part 3: Leveraging Testing Automation After Your ERP Go-Live

Introduction

Go‑live isn’t the end of your Microsoft Dynamics 365 Finance and Operations testing. It’s the start of a new phase where the stakes are higher, the pace changes but doesn’t slow down, and the tolerance for mistakes is close to zero. Why?

First, Microsoft’s One Version philosophy means scheduled and automatic updates that you can delay but not avoid. Your Microsoft Dynamics 365 system is a platform that keeps evolving whether you like it or not. You’ll get new versions, cumulative updates, bug fixes, and new features on Microsoft’s timetable, not yours.

Then, there are the infamous phase 2 requirements. You know all those user requests that were pushed back during the implementation to avoid scope creep? They’re back now. Users want the ERP to do something new, something different, or the same thing in a different way — and they expect it fast.

When you change something, you need to ensure it works. This means validation, and this is what changes after go-live. Testing is no longer about proving the system works. It’s about making sure it keeps working exactly as it did yesterday, even after tomorrow’s update or new feature. In practice, this means a shift of importance towards regression testing and an increasing reliance on automation to protect your production environment.

In this article we’ll focus on what happens after your Dynamics 365 F&O go‑live and how to maintain business continuity without drowning in manual testing effort. We’ll cover:

• How post‑go‑live testing differs from implementation testing
• Why automated regression testing is now essential
• The Microsoft Dynamics 365 testing tools you should be using
• How to build smart, maintainable automated test suites
• How to include testing in your business‑as‑usual operations

Key takeaways

Here are the key lessons you’ll learn from this article:

• Stability: Post‑go‑live testing is required to keep your Microsoft Dynamics 365 F&O system stable across updates, bug fixes, and business changes
• Speed: Manual regression testing is too time‑consuming and unreliable to keep up with Microsoft’s automatic update schedule
• Continuity: Smart test automation helps you perform regression testing faster, reduce human error, and maintain business continuity
• Prioritisation: Start by automating high‑impact, low‑variance processes — not everything, and not all at once
• Tooling: RSAT, Task Recorder, and Azure DevOps give you a solid foundation, but may not be enough for complex or cross‑system testing requirements
• Governance: Sustainable test automation needs stable test environments, reusable scripts, and ownership embedded in BAU

Wait! Before we begin…

Go-live is a milestone, but further testing is pointless if your Dynamics 365 ERP is not working as it should. We wrote a practical guide for senior leaders of companies already live with D365 F&O, describing symptoms that your new ERP is failing to deliver the promised benefits, what are the likely root causes, and what to do about them. Download your free copy from the form below.

---

Implementation testing vs post‑go‑live testing

Testing during a Dynamics 365 F&O implementation and testing after go‑live are two very different games. The rules change, the goals change, and the consequences for getting it wrong become much more expensive.

Testing during the implementation

Implementation testing is wide‑angled. You are dealing with a brand‑new Microsoft Dynamics 365 system, fresh configurations, custom developments, and a user base that potentially has never touched Dynamics 365 F&O before.

We have seen in our previous article what the key phases are:

• Functional testing to check that specific features work against requirements
• End-to-end (E2E) and System Integration Testing (SIT) to follow a transaction from start to finish through processes and other systems
• User Acceptance Testing (UAT) to ensure that users can operate the system autonomously and meet agreed success criteria and exit criteria

Despite this structured approach, much of this is manual and, to a degree, exploratory. Test cases evolve as the system design gets finalised. Scripts get rewritten as new requirements pop up (it happens, let’s face it). Your test team is building understanding and confidence that the ERP system is fit for purpose before your company runs on it.

Testing after go‑live

Once you are live, the focus narrows. Users and consultants already know the system works (or at least, they should). The job now is to make sure it keeps working the same way after every change.

That’s where regression testing comes in. You’re re-running proven test cases to confirm that updates, bug fixes, patches, and configuration tweaks haven’t broken anything. The goal is stability, not to rediscover all the edge cases you already dealt with during implementation.

Manual testing still matters (we’ll get to that), but relying solely on manual testers is too time consuming and too risky. Structure and automation become the only sustainable way to keep pace with Microsoft’s scheduled updates and your own internal changes, without holding key users hostage every few months to perform regression testing every few months.

Stable, repeatable test suites in a non‑production environment give you confidence that your production update won’t derail operations. And unlike in implementation, a failed test now isn’t just a red mark in a spreadsheet. It’s a potential real-world problem — lorry drivers stuck in the factory car park because nothing’s shipping, a finance director losing it over invoices not being sent to clients, or a production line halted because raw material consumption can’t be recorded in the system. I’ve seen all three.

---

Why automated testing is now essential

Post‑go‑live, the overall volume of testing might be smaller than during implementation, but every wrong change can grind your business to a halt. That’s why automation moves from being a “nice to have” to the backbone of your business‑as‑usual (BAU) testing process.

It ensures business continuity

Once you’re live, you’re no longer in full control of your production environment. Microsoft pushes platform updates on a fixed schedule. ISVs release patches and new features. Super users tweak configurations. Any of these can break something — often in places you don’t expect, like upstream in a process or in a connected system.

Manual regression testing can’t keep up. It’s slow, reliant on busy people, and often based on guesswork from a business analyst skimming release notes and guessing any potential impact. That’s not a safe testing process.

Automated testing changes that. You can re-run proven test cases whenever a scheduled update lands in your non‑production environment, catching problems before they hit production. This way, way safer. A strong automated regression suite helps you adopt the latest version of Dynamics 365 confidently, without risking operational downtime.

It reduces dependency on humans

During implementation, it’s easy to get 20‑30 people from your test team in a room to run through user acceptance testing together. In business‑as‑usual, that luxury disappears. People are back to their day jobs. Coordinating manual testers across multiple departments becomes a logistical nightmare and burns valuable resources.

And when your testing depends on other teams acting first (for example, finance can’t test payment runs until procurement has created and receipted a purchase order), manual testing slows to a crawl. By the time everyone’s done, Microsoft has released the next update and you’re back at the start.

Automation removes these bottlenecks. It runs the full process from start to finish without waiting for someone in another department to be free. It also reduces fatigue and human error — the two biggest killers of accuracy in manual regression testing. The result is faster, cleaner test cycles that don’t rely on assembling a small army of testers every month.

It simplifies test maintenance

Coverage and speed are not the only benefits of test automation. Automation enforces predictability and structure, so you need a well‑maintained test suite that evolves as your business needs change. If every new feature, updated process, or rollout to a new country requires a business analyst to start from scratch, you’ll never keep up.

The goal is a library of automated tests built around your core business processes, not individual button clicks. This makes it easier to adapt when things change, regardless of whether that’s a Microsoft Dynamics 365 platform update, a series of consecutive updates, or a regulatory change.

Well‑structured test scripts should be quick to update and easy to maintain, ideally by non‑technical users. Keep them under version control in Azure DevOps, tie them directly to your process documentation, and update them alongside configuration changes. Do it right, and you’ll have a scalable, flexible testing capability that can react quickly without the lag and cost of a purely manual approach.

---

Testing tools for Microsoft Dynamics 365

If you are serious about your testing efforts after the Dynamics 365 F&O go-live, you will need tools. Not a random mix of Excel tabs and sticky notes, but specialist applications that let you perform regression testing quickly, repeatably, reducing human error and intervention. Microsoft gives you a starting point, so let’s start with it.

Regression Suite Automation Tool (RSAT)

The Regression Suite Automation Tool is Microsoft’s built-in answer to automated regression testing for D365 F&O. It works with Azure DevOps test cases and the Task Recorder to create automated test scripts that you can re-run whenever you like. In theory, you can record a process once, link it to a test case, and replay it across environments without touching a thing.

In practice, RSAT works best when the processes you are testing do not change much. Stable, high-value business flows like sales order creation, invoice posting, or purchase order receipts are perfect candidates. The tool can handle variations, but constant changes in forms, fields, or business logic will lead to extra maintenance work.

It is not flashy, but it does the job and doesn’t have extra costs.

Task recorder and Azure DevOps

Task Recorder is your way of capturing exactly what happens in a process. It is simple: you turn it on, run through the process, and it records every click, field entry, and system response. These recordings are very often used to create documentation and training materials, but they can also be used as a basis for automated RSAT scripts.

Azure DevOps is where you store, track, and manage those test cases. It gives you version control, traceability, and the ability to organise your testing backlog. It is also your home for defect tracking, test execution history, and reporting. You should have already used Azure DevOps heavily during the D365 F&O implementation project, so by now you should be very familiar with it.

When used together, Task recorder, RSAT, and Azure DevOps give you a decent baseline testing framework without having to invest in third-party automation tools. However…

Choosing the right tool for the job

Just because RSAT is included in your standard Microsoft toolkit, it does not mean it is always the best option. Its limitations are well known: it’s not intuitive, it requires technical knowledge to maintain the test cases, and it’s confined to D365 F&O. So if your testing requirements extend beyond the ERP system or you want to empower your users (you should), RSAT may not be the best choice. There are solid options in the market, like Leapwork and Executive Automats. If you’re already familiar with them, this article might be too basic for you.

In short, the right testing automation tool is the one that:

• Can be maintained by key users without a team of techies: think low-code or no code, plus modular test cases that you can reuse across multiple processes.
• Is platform-agnostic, integrating seamlessly across applications: your E2E processes may extend beyond Dynamics 365 F&O, so you want something that works well across all your test environments without complex configuration.
• Fits well into your internal release management process: you want a tool that saves time rather than adding another layer of work every time you plan a new release.

We know that if you stick only to manual testing, you will eventually fall behind. But if you automate badly, you will create a convoluted and unreliable testing process that nobody trusts. Choose wisely, and the tools will do the heavy lifting so your team can focus on higher-value work.

---

Best practices for post‑go‑live test automation

Automating testing after your Dynamics 365 F&O go-live is a smart move, but it’s not instant magic. You can’t just flip a switch and have every test case automated overnight. Success comes from starting in the right place, focusing your efforts, and embedding automation into your day‑to‑day governance.

Start with a solid foundation

If you diligently documented your efforts during the ERP implementation project, this is where it pays off. Reuse what you can: process maps, test cases, configuration, dataset, task recording and so on are a valuable repository of artifacts to save time to set up your test automation.

Chances are that you did not focus much on automation during the implementation itself, but reusing what you can from it will simplify things massively — this is yet another confirmation that in a D365 F&O implementation every step builds the foundations for the next one.

But make sure you build your automated tests on clean, consistent, and version‑controlled test data and system configuration. Wherever possible, keep those stable across environments — the production environment is messy, so refreshing a test environment with its content carries an inherent risk of false failures due to bad records. The same goes for test scripts: design them to survive UI tweaks and minor process changes, and store them under version control in Azure DevOps so updates are quick and traceable.

Target high‑impact, low‑variance processes first

You don’t need to automate everything, nor should you aim for that. Start with the core processes that keep your business running and don’t change often — examples include posting journals, receipting purchase orders, or starting a production order. These are high value scenarios with low variance but high risk if broken, and they are relatively stable to automate easily.

Avoid chasing every obscure exception from day one. Automate what will hurt you most if it fails, not what happens once a quarter. You can expand coverage over time once your core regression suite is in place.

Balance test automation with human oversight

Automated tools handle the heavy lifting of regression testing, but they are not a replacement for people. Manual and exploratory testing still matter for new features, unexpected behaviours, and user experience checks.

The point of automation is to free your human testers from repetitive checks so they can focus on spotting the things automation can’t. Think of test automation as your always‑on safety net, and your people as the ones who check if the net is in the right place.

Embed automation into BAU governance

Testing is not a one‑off project phase during the implementation (something we explained in this article), nor it should be once you’re live with Dynamics 365 F&O. By then, it should be part of your operational governance. So assign clear ownership for maintaining the regression suite, run tests for every Microsoft update, and sign off the validation before you deploy changes to the production environment.

Integrate automation into your release process, which should work like this: update applied to test environment → regression suite runs → results reviewed → targeted manual checks → production deployment only if everything passes.

For regulated industries, the same governance process provides an audit trail of what was tested, when, and with what results. This helps you produce the evidence needed to keep auditors and senior stakeholders happy.

---

Conclusion

Go‑live is not the end of your Dynamics 365 F&O testing. It’s the start of a constant cycle of updates, fixes, and changes that can break your most important processes overnight.

Manual regression testing is too slow and too dependent on people’s availability. Automated tests let you keep pace with Microsoft’s update schedule, intercept problems before they reach production, and protect business continuity without draining valuable resources.

The formula is simple: start with clean data and stable scripts, focus on high‑impact processes, keep human oversight, and make testing part of BAU governance. Do this and updates stop being a gamble. Ignore it, and you’ll end up testing in production — the most expensive way to find out something is broken.