Regression Suite Automation Tool for Dynamics 365 Finance and Operations

With Microsoft’s launch of D365 Finance & Operations, the concept of “One Version”, an “evergreen” ERP solution became a reality. The promise of frequent updates, rich with feature enhancements and net-new functionality was received with great excitement effectively eliminating costly and burdensome re-implementation efforts.

Early adopters enjoyed those benefits but quickly came to the realization that testing had become a real challenge. With an aggressive update cadence from Microsoft and their restrictions on how many updates may be skipped before they become mandatory, many businesses were left wondering how they could ask their business process owners to make mandatory testing a routine part of their daily work lives.

Microsoft recognized and responded to this difficulty by adding a new tool to their previous investments that allows for automated testing, the Regression Suite Automation Tool (RSAT). By supporting testing automation, the effort of manual testing can be significantly reduced and thereby positioning businesses to take full advantage of new feature releases without the heaving burden resting with their process owners.

RSAT utilizes familiar tools to bring together your automated test suites, principally, Task Recorder, Lifecycle Services Business Process Modeler and DevOps (formerly known as Visual Studio). With these tools, an investment of time and the commitment to recording business processes, an organization can thoroughly understand their processes, increase the ROI from their ERP investments as well as move manual, business process owner efforts into technology supported solutions. This has never been more important than with the new world of One Version.

RSAT Depends on Well-planned Task Recordings

Task Recorder has served many purposes in the past from providing the Help system in D365 with visual prompts for the user on how to perform various tasks. It also is frequently used to create illustrative, in-depth SOPs or work instructions for compliance and training purposes.

Developer recordings have also aided support desks by allowing users to submit recordings of bugs or issues, saving developers investigatory time.

With the release of RSAT, it is critical to consider how these recordings may support your automated testing with well-planned consideration being given to what requirements will become test cases and how those test cases should be constructed in order to capture automated validation points.

By adding “gestures” and validation steps, you can devise robust and repeatable process scenarios that RSAT will understand and execute.

“Gesturing” is the use of special Task Recorder functions, such as Copy and Paste”, which, are not viewable in the recording but are understood by RSAT. These functions make note of fields of your choosing and, upon creating the executables and parameter files in RSAT, convert those gestures into variables which can be used to “chain” your test cases together.

Validation steps are also critical when the expected results should be verified as a part of the test case. Where an inventory quantity should be updated and verified from a Sales Order that has been picked, packed and invoiced, it is useful to have such a validation step in your recording.

Great task recordings follow the business process closely. Business process owners who know these processes well and the use cases involved are critical to the success of an IT effort to automate. A deep collaboration between process owners and technical/functional resources responsible for test automation is essential to a successful automation test suite.

Business Process Libraries and their Role in RSAT

The Business Process Library (BPL) is a feature of Lifecycle Services that supports many functions in D365. With respect to this discussion, the BPL provides the process structure for your recordings. Libraries can be created at a very high-level of a business process or at a more granular level. These level at which Libraries should be created will be governed by individual needs.

However, it is important to consider the level at which you need to 1) explain a process to an end-user as well as 2) automate your testing.

Test cases will be created from their originating business process and then synced into DevOps Test Suites. You will have the opportunity to orchestrate multiple Test Plans to cover as much automated testing as your organization requires.

RSAT Relies upon DevOps Test Cases

Regardless of whether you choose to automate your testing, the BPM sync will transmit all the steps within the task recording over to Test Cases in DevOps. There, you will be able to create bugs and collect Business Process Owner sign-off against those test cases. In many situations, it is important to think about the management of the test cases.

Who will care for the test cases? Who will make assignments for testing? Moreover, it is important to have a complete strategy for your implementation it is also crucial to have a vision of your post go-live world.

RSAT Connects the Tools

Once RSAT is connected and operational, it is time to configure your test cases and execute them.

The first step is to Load them into RSAT from DevOps. This will bring all the information about the test case into RSAT, specifically the test recording itself. Once loaded, select the Test Cases you would like to run and Generate the Executable Files. This will generate DLLs, C# code and the Excel parameter files into RSAT’s working directory that you will need to chain your tests together.

Chaining the tests together is done inside the generated Excel files. The variables inside those files, created by the gestures and validations referenced above, are copied from the source file, and pasted into a subsequent, “chained” test. This will pass the actual value used in a prior test to a following test (rather than the original value used to record the test).

The power of Excel formulas can be used and is particularly useful. For instance, you may wish to randomize a field’s value upon entry in which case you may use an Excel formula to do so.

Validations is another great way to use formulas. Capturing a value in one step and adding it into a value captured in a subsequent step can now provide you with a logical step using comparison operators such as “=”, “<” ,” >”, etc.

Should a recording need to be referenced in multiple chained sequences, you need not record the test case more than once. You simply mark it as a “derived” test to allow access to it in other test chains.

Once ready, mark the tests ready to be run and click “Run” from the RSAT console.

Executing your test cases will invoke RSAT to “print to screen” all the test steps from the task recordings as it performs them. You will see the message “Chrome is being controlled by automated test software.” The screen captures are accessed by DevOps to illustrate where and how errors occur along with XML information about any error encountered.

Additionally, in the DevOps environment, you will find a very rich feature set to help you manage errors as well as your test runs.

While executing RSAT through the console is extremely useful for debugging purposes, it also adds performance overhead to the Test Runs. Once you are satisfied with your tests, you may wish to execute them from a command line or invoke the run from Power Automate. RSAT provides several command-line keywords parameters which gives you full control to schedule these test runs after business hours.

Being prepared for One Version of Microsoft’s D365 Finance and Operations has never been more important. Microsoft’s Regression Suite Automation Tool will help you document your business processes, limit the amount of manual testing by business owner and position your business to increase your ROI with every Microsoft update.