Microsoft Dynamics 365: Key considerations for test automation

"In real open source, you have the right to control your own destiny." - Linus Torvalds

Indeed, what Mr. Linux said is undeniably true. At the same time, we must also understand that open-source libraries do not provide an off-the-shelf solution for every development problem. The user must explore the existing solution, design new approaches and develop a customized solution to achieve the desired results. The same process must be followed while automating Microsoft Dynamics 365 application with open-source utilities.

To create a scalable and robust automation solution for this cloud-based business application, an automation expert must weigh the challenges and work in the right direction to arrive at the best strategy and to customize these utilities & COTS.

As per a Tricentis report, organizations that automate 50% or more tests reap benefits like faster testing cycles (88%), improved test coverage (71%) and increased chances of catching bugs earlier (68%).

Are you facing hurdles with automated testing of Microsoft Dynamic 365 applications? Read on to learn more about these applications, understand the challenges, and discover the best practices to their automated testing.

Microsoft Dynamics 365: An overview

Microsoft combined the modules of two of its most popular applications: CRM (Customer Relationship Management) and ERP (Enterprise Resource Planning), along with some other related applications and AI-based tools to create Microsoft Dynamics 365. MS Dynamics365 is a one-stop solution for business entities to run a large enterprise with the ability to select a component from multiple options like Customer Insights, Customer Service, Finance, Operations, Marketing, Retail or Sales, and create a complete application suite as per their business requirements. All these components are seamlessly integrated with one another and with other productivity applications/tools, to eventually help organizations make improved, quicker, and intelligent decisions.

The Dynamics 365 application suite comprises many components that have custom business processes and workflows, which must be validated during quality checks. Further, since it is available in 24 languages, localization testing is very important and mandatory. Validating the GUI is another equally important aspect in testing, as the newly-added functionalities and the tailored parts of the application (entities, features, and fields) might get broken during Dynamics 365 customization.

Apart from this, some other testing challenges could come in the form of complex functionalities, control and configuration for various environments, customizable systems, multiple Microsoft patches, and customization for standard processes.

Automated testing of Microsoft Dynamics 365 applications: The challenges

Let us look at the challenges in automated testing of Microsoft Dynamics 365 applications:

• The Dynamics 365 products are complex web applications that comprise nested iFrames, deep object trees, and dynamic IDs for child windows. Due to this, it is difficult to write and maintain Selenium scripts (or scripts with any open-source test automation library).
• Automation testers spend a lot of time and effort in deciding the correct locator strategy to identify the right element in the application to perform the action. Locating the controls/UI-elements takes a lot of time during execution, resulting in script failure.
• The tests are quite unpredictable for these applications. The same test, when done a couple of times, can give different results (sometimes getting the element and sometimes not). It is also strange to know that Dynamics 365 does not even guarantee that the ID-attribute (or other locators) of elements is unique whenever the user does a deep-dive into the DOM structure.
• The UI standard of the Dynamics 365 applications differs across versions. An automation engineer cannot lock-in designer resources to the GUI for all the application versions. These multiple versions also require changes in the locator strategy and the Object Repository (OR) to maintain tests for each version.
• Since Dynamics 365 is a web application, its test scripts should be compatible with all major available browser versions. However, its compatibility with IE and Firefox is not as good, with major synchronization issues that result in test failures.
• Once developed, the test script continuously requires updates that involve additional effort from the tester. Another tedious activity is the continuous validation of these scripts at regular intervals to ensure script correctness.
• The CRM application often uses lookups - either to get values from it or to set some value in it. For a test script to work, these lookups should be validated from a different perspective. Sometimes, it becomes tricky to apply automated methods (like SendKeys, tab out, etc.) on these lookups.
• During technical deep-dives, automation engineers face many other challenges like SendKeys ignoring the "maxlength" attribute in input tags, which could generate false-positive results, challenges dealing with an alert pop-up to provide login credentials, and many more.

Automating Microsoft Dynamics 365 apps: Best practices

Here are some best practices that you can follow when automating Microsoft Dynamics 365 applications:

• Before testing the Dynamics 365 application, an automation engineer must have a strategic approach with a clear perspective of the customizable features. This helps to focus on the customized code, personalized entities & areas, and the specific feature being validated. This approach must focus on functional, visual display, regression, localization, and system testing.
• The automation framework should be scalable, modular, and robust. Test design patterns that increase the reusability of application-specific business actions (which are converted into methods) and the approach of “Write Once Run Anywhere” are crucial to follow. Use the modular approach to ease code-debugging, whenever necessary.
• The multi-layer architecture of the automation framework makes it easy to maintain. Common application methods must be included in another layer, which can be called in test methods and is easy to maintain in the future.
• One layer of the framework should contain the methods that implement actions on application-specific controls/objects. It should be generic enough to be used across multiple test scripts by simply passing a few parameters. For example, validating a cell value in a grid can be done by passing grid locator, row-id, and column-id in the method. Similar methods can be created for lookups, calendar controls, alert popups, and other complex objects.
• A resilient locator strategy can help in reducing any script failure due to fragile elements properties. The scripts need to capture the dynamic properties instead of the static ones.
• Nagarro has implemented self-healing capabilities in DRIVEN, its test automation framework, which heals the script at run-time, whenever an element is not found in the UI.
• A clear strategy around visual display testing is very important as GUI tests are flaky. These tests should be robust enough to discover UI defects.
• One of the best practices to validate this application is to design and run the tests as a real-time user to pick genuine defects. A strong test data management approach with accurate test data will also help in testing all positive and negative workflows.
• The framework should support automated tests to work on multiple environments like QA, development, staging, etc.
• The tester should also maintain version of the script as per its different application versions to ensure a robust configuration management plan. UI standards differ a lot across different application versions. The tailored part of Dynamics 365 also needs special attention as some parts of the application are already tested. The newly-added part involves entities, features, and fields that need more focus during testing.

Bottom line