Skip to content

How to Tackle Technical Debt in Dynamics with Test Automation 

Anna Thorsen

Anna Thorsen

Companies are undergoing a digital transformation en-masse. They’re rethinking their approach to their IT infrastructure, and they are releasing more customizations to Dynamics as a result. But with more releases, comes more testing.

Many older organizations, particularly within the BFSI industry, continue to use Microsoft’s legacy software products (i.e. Dynamics GP, SL, NAV and AX). They rely heavily on these products to run business-critical processes. However, there is pressure to continuously add more features to them, which can increase technical debt.

But you may ask yourself, why would technical debt be bad? Because organizations are spending more time on managing technical debt than on building product innovations.

This begs the question - how can you tackle your mounting technical debt with test automation? And what is the right solution for doing so quickly and efficiently for the highest return? We’ll cover that, and more, in this post.

Skip ahead to:

What is technical debt?

Why Selenium automation can cause more problems than it solves

How codeless test automation reduces technical debt in Dynamics

What is technical debt?

Technical debt happens when businesses choose speed over quality when developing software. For example, a development team is pressured to release an application that isn’t fully featured. It helps them go to market faster, but results in a backlog of tasks and an even larger requirement for testing.

You can think of technical debt as a laundry pile. When you are cleaning your laundry by hand, it takes a long time to get through the pile. With every major or minor release to your Dynamics ecosystem, the pile gets bigger.


Just like cleaning all of your laundry by hand, manually testing every service update and proactive quality update can quickly get out of control. With every update, your technical debt grows, and so does the risk of something going wrong.

But technical debt isn’t always bad. It’s an inevitable part of agile software development. However, if it takes a long time to “repay” your technical debt - it’s a sign of a bigger problem.

So how can test automation help you, and why is Selenium not always the most efficient choice?

Why Selenium automation can cause more problems than it solves

Test automation tools are not the one and only answer to reducing your technical debt. But in combination with setting coding standards and creating a plan of action, test automation can free up time so teams can focus on product innovation.

For many, the search starts with Selenium. It’s free, so it doesn’t require a significant budget to get started. But Dynamics is a complex web application to automate with Selenium scripts.

Nested iFrames, dynamic IDs for child windows, and deep object trees make even the simplest tests time-consuming to automate. To be able to identify elements in an application, you have to build an element locator strategy. This makes you heavily dependent on technical resources with developer skills. And, it prevents those who are experts in testing Dynamics updates (business analysts, end-users, and QA) from contributing towards building automated tests.

In an age where costs are being cut, it can be difficult to justify using technical resources on building automation, especially when their skills are required for building new features.

Related reading: Microsoft Dynamics CRM Automated Testing Using Selenium

What options are then available for maximizing your automation test coverage while reducing manual testing and bugs hitting production? We’ll cover that in the next section.

How codeless test automation reduces the technical debt in Dynamics

What’s more powerful? A solution that can only be used by resources with coding experience, or a tool that can be used by developers, business analysts, quality assurance (QA), and end-users?

BNP Paribas Cardif increases Dynamics releases from every quarter to every month with Leapwork

Leapwork’s codeless visual language means that anyone, whether technical or non-technical, can build, maintain and scale test automation in Dynamics in a matter of weeks.

How does this work?

The Capture functionality in Leapwork means that you don’t need to write a single line of code. All testers need to do is identify an element (even if it’s a drop-down field), and use the object in the test case.

In the video below, you can see an example of what a completely no-code Dynamics test looks like when built in Leapwork:


It’s an empowering solution that can give you the potential to shift your IT practices as a whole. Move from mounting technical debt to free up time to work on and create value-based deliveries.

Learn more about the challenges and intricacies of testing Dynamics in our guide to automating Dynamics 365 testing:

New call-to-action