Testing Microsoft Dynamics CRM: Beyond the UI

My company is using Microsoft Dynamics CRM and customizing it. We are currently testing it with essentially all UI tests. Obviously as testers we should strive for most of our testing to be done with Unit and Integration testing.

Does anyone have input on how they test a customized third party tool like this? The difficulty is that most of our changes happen via modules and configuration changes, not in code. There is an API for Dynamics CRM and I was thinking the best way to test it may be adding data via the API and then checking it was created correctly.

What say you? Any ideas or resources?

1 Like

Hi @kdellis

Thank you for reminding us that there’s also projects in the space of customizing MS dynamics CRM, AX, SAP, Oracle and other COTS enterprise tools. We talk so much about purpose built web and app’s that many enterprise solutions are forgotten. We forget while there is software shops developing health care applications, there are other people that sit and configure and customize those solutions. And in that context (an others [1]) testing happens too.

here’s some random thoughts: :wink:

  • One problem I faced was tracking what was changed - try to put the config-files and other changes under source control, if possible…
  • Are you looking to into testing it using some GUI tools - perhaps MS coded UI or similar that can hook into the interface?
  • Besides test data, the test environments have always been tricky. If there is a test environment at all. The “developer” might sit and configure it in the same instance as testing is happening, so another issue would be to agree went it’s time to do what - so that you don’t fall over each others feet. … Perhaps pairing would be good.

1: https://jlottosen.wordpress.com/2017/05/24/testing-across-the-it-landscape/ and https://jlottosen.wordpress.com/2017/05/19/cmmc-application-cycle/

Thank you for the articles you wrote, interesting reads.

We do currently have some UI testing using Nightwatch and Selenium Webdriver, but I would ideally like to test in more stable and faster ways.

And thank you for your other thoughts, we do some of these things already but I will definitely ponder them more deeply. I am brand new to the team so have plenty of opportunity to reconfigure how our team now works with the testers.

1 Like

Hi Kyle,
I suggest you look into an automated testing tool called Rapise. It has out-of-the-box support for testing Microsoft Dynamics CRM. Specifically, it has special support for interacting with the Dynamics CRM grids. You could download a free trial of Rapise and see how it works for your situation. See this document for details.
Full disclosure: I’m a tester at Inflectra, the company that makes Rapise.

1 Like

Any recommendations more geared toward how to move away from testing the UI?

We did a simialr thing but with a competitor system, so a lot of the code was configured especially for processes within the organisation. For the most part (due to budget issues in getting automated tools) had to rely on a lot of manual processess, so documentation of the configured workflows, flow diagrams etc. stored in Jira and then reflected in manual test scripts - thankfully managed to get resource to run through these regression scripts. We also ensure that a transport style policy in place for changes, so that DEV/QA/PRD matched once change live.

One think I would mention is the need to ensure you know how the system is operating before any quarterly upgrades - I joined the project after a few of these and there was a lot of confusion if the upgrade had changed a process/caused a bug - so first thing I did was to ensure the behaviour/position of system known before any supplier update!


I’m hoping someone can help me on this thread, even though I know it says ‘Beyond the UI’. I’ve recently started testing D365 as well but I want a faster way to set up test data. At the moment, I am creating a customer account manually. There is currently no API set up so that is not an option and the developer will not allow us to do import/export (for whatever reason). That leaves me with trying to do automatic form filling but I am trouble with this.

I posted the same question on https://stackoverflow.com/questions/63374896/how-do-i-automate-form-filling-in-ms-dynamics-365.

Here it is:

I am having a go at using javascript to fill in a form and then save it in hopes I can use these scripts to set up test data.

On Chrome, I tried to do the following to edit an existing account / submit a new account. I can confirm the elements are definitely correct because the browser highlights them.

document.querySelector('input[aria-label="Account Name"]').title='Test Company'
document.querySelector('input[aria-label="Account Name"]').value='Test Company'

I can see that the field name changes for the account name but hitting save fails. In the case of the edit account scenario, it reverts back to the old name. In the new account scenario, it doesn’t save the account successfully.

The ideal scenario would be for me to generate company data and have the forms filled in for me as well. But if that doesn’t work then I can always copy paste the company data into the script (not sure that would be any faster than manual testing to be honest).

hi @pwong

Good idea to use automation in testing for your tedious test data tasks :slight_smile:
It seems to be a stuggle to script into D365, first of all because it’s pretty tricky to interface into the code presented and you can’t just ask MS to add more testability into it. Secondly, when the deploy a new update you have to start your scripts over again.

Some more modern tools seems to be able to solve this challenge better. Have you experimented with testim or cypress wrt this challenge?

yeah I have, that’s what I am having trouble with. I’m going to start a new post on the club rather than continue this one.