The Top 6 Dynamics AX Testing Challenges

Mainstream support for Dynamics AX has ended. While migrating to the Dynamics cloud based offerings can lead to productivity gains and major reductions in the cost of ownership for ERPs, over 8500+ businesses still operate on AX. For businesses yet to undergo their migration, Dynamics testing has never been more important. 

When support for an application ends, your business is prone to a loss in productivity and security breaches. 

From finding the resources, to testing at speed, and getting the end-to-end coverage required to assure quality, QA teams lack sufficient resources to test AX.

In this post, we’ll explain what AX is, why it’s challenging to test, using the example of a service order, and what you can do to resolve some of these issues through visual test automation.

What is Dynamics AX?

AX is an ERP module, and it’s the legacy version of what is now termed Dynamics Finance and Operations (F&O). 

While support has discontinued, the need for testing is very much alive. Why? Because even the smallest change within AX (such as customizations or configuration settings) can introduce unforeseen bugs. 

Service orders, in particular, are complex to test because of how dependent they are on other modules. 

Why are service orders challenging to test?

Testing service orders can be complicated. There are a few reasons for this:

1. Customizations. AX users customize their module to fit specific needs which makes testing more complex. For example, if you customize service orders to include more fields or workflow steps, this change can impact the behavior and functionality of a service order. Because customizations are unique to an organization, the process may not be well documented, or it might have uncharted territory where your level of exposure is not well understood.
   
   
2. Configurations. Configuration settings, which control the appearance and behavior of AX components, can also introduce errors to service orders. If, for example, a user changed the time and expense tracking configuration, and doesn’t add this test to their regression suite, they could introduce an error that impacts the accuracy of this information. 
   
   
3. Limited resources. Functionally testing and User Acceptance Testing (UAT) in AX is carried out by domain experts (e.g. business analysts, solution architects). Because testing is not always their primary role, they have to strike a balance between getting enough test coverage to ensure quality processes, while also managing their primary workload. Manually testing takes too long to carry out. And most automated testing solutions are not easy to use or maintain.
   
   
4. Prioritizing what to test. A service order can contain hundreds of steps. If it is tested manually, a business might be forced to test the features that are of the highest risk of failure. The rest is left untested, which can result in defects and errors going into production.  
   
   
5. End-to-end testing. A service order can involve integrations with other systems, such as D365 CRM or ERP modules. Since it spans across different departments and module types, getting end-to-end coverage is tricky. Manually carrying out this lengthy test requires heavy collaboration and a lot of time. A coded approach has its limitations too. Coding tests across applications requires a lot of time, and you might find yourself coding complicated workarounds. This leads to flaky and unreliable tests due to the difference between Dynamics modules under the hood, and the mix between web and desktop.
   
   
6. Regression testing. Running regression testing in Dynamics manually requires an excessive use of time. If you’re using a code-based tool, for example, the volume of code that you have to maintain exceeds the benefits you gain from test automation. 

Testing Dynamics doesn't have to be a headache, but it often leads to bottlenecks that create delays. Learn how Ascensus automated Dynamics testing inside and out, while keeping their technical debt at bay in this webinar. 

How can visual test automation help?

Test automation has seen many generations. From code-based solutions like Selenium, to low-code and no-code solutions. What they have in common is their long onboarding times and heavy maintenance.

A visual test automation approach is different. It limits build and maintenance times by cutting out coding, and keeps the process of building and maintaining tests simple.

You don’t have to be technically savvy in order to build and maintain automation. Nor do you have to spend months learning how to use the tool. 

How Leapwork empowers testers with visual test automation 

Leapwork is the first of its kind, using AI-powered visual test automation that starts showing results in just 30 days. You can work with the resources you have to get the coverage you need. 

How? A combination of a visual recorder, visual debugging to help you quickly identify what and where a test failed, and smart locator strategies to limit build and maintenance. 

Image: A Leapwork flow depicting the login to Dynamics and creation of a new lead. On the bottom right, you can see an activity log of the steps that are being carried out, along with a video recording of each step on the left hand side.

Our solution works across Dynamics applications, enabling users to build complex end-to-end tests. If you have test cases that fall outside of the Dynamics arena, we automate those too. All within one central place. 

Want to learn more about how Leapwork works in detail? Our Dynamics solution brief explains how we handle the heavy DOM structure of Dynamics so you don’t have to, and how we help you quickly and easily automated across the Dynamics landscape.