User Acceptance Testing (UAT) is a critical part of any Dynamics implementation. In this article, I’ll provide an example Dynamics 365 UAT script, explain testing best practices, and more.
Table of Contents
- Example Script for User Acceptance Testing in Dynamics 365
- What Is User Acceptance Testing in Dynamics 365?
- What Is a UAT Script for Dynamics 365?
- Best Practices for UAT in Dynamics 365
- Azure DevOps for UAT
- Benefits of UAT in Dynamics 365
Example Script for User Acceptance Testing in Dynamics 365
What Is User Acceptance Testing in Dynamics 365?
User Acceptance Testing is testing of your new solution by your team, in a real-world environment. It should be conducted after your Dynamics implementation partner has developed a viable solution model and performed their own testing (called “unit testing”).
The UAT process determines whether there are issues that must be resolved prior to go-live, or whether the new system is ready for launch.
What Is a UAT Script for Dynamics 365?
A UAT script is a formal worksheet or checklist that guides a tester through test scenarios and allows them to report their testing results. Each scenario tested is categorized as “Pass” or “Fail.”
Be clear about “Pass” criteria for each scenario. A scenario should be considered “pass” only if the business process is completed as per the expected result, without workarounds. For instance, if the account’s billing address is supposed to load automatically on a new invoice record, and you have to manually select it from among all the accounts, that should be a “fail.”
Sometimes the “pass” criterion is simple and straightforward: for instance, “the record saves without error.”
Each UAT Script should document the following elements:
For the scenario, the level of detail entered should depend on how familiar testers already are with the system, and the training they have received.
Findings are typically only used when the scenario fails. Details may include specific records used to test, error messages encountered, etc.
Best Practices for UAT in Dynamics 365
Who should create the script? Actual UAT script creation should be assigned to someone in the client’s company who is familiar with the project requirements and who has a thorough understanding of the client’s business processes. However, the creation should be guided and advised by the Dynamics solution partner.
Who should do the testing? Testers should be the client’s subject-matter experts in the processes and areas being tested.
Prior to the beginning of testing, your testers should receive user training on the new solution, so that they are familiar with the user interface and main functions. They then follow a UAT script to step through all possible business scenarios related to a functional system area and record the test results.
What should we test? Test all the crucial business processes that connect to the new Dynamics 365 solution. Test full processes end-to-end, not just individual tasks by individual people. If you test tasks in isolation, you may miss any data problems or other issues that could occur at hand-off between departments, for instance.
How should we test? Set aside time with all the people involved in a given process. One best practice is to get them together in a conference room or videocall. Let them complete each step of the process and pass the relevant data through the system to one another.
For example, a sales coordinator may be responsible for working a lead up to a certain point before assigning it to a salesperson for more in-depth discovery. In testing, both types of users should work through that process together to test the steps that come before and after record reassignment to sales.
Important Note: Test the Unhappy Path
Make sure to test the “unhappy path.” The happy path is what you design and intend to have happen in your business processes: Salespeople enter complete data into the correct fields in your CRM. No one ever makes a mistake on an invoice.
You need test to ensure your solution is robust to the unhappy path too. What happens if a salesperson forgets to enter a deal size? How do you undo a mistake on an invoice that’s already been paid?
Leveraging Azure DevOps for Dynamics 365 UAT
At Encore, we often recommend that clients use Azure DevOps for User Acceptance Testing. DevOps provides automation within its Test Plan functionality for creating test cases, assigning them to testers, capturing the results and logging bugs, and useful reporting.
Here’s a screenshot of one DevOps dashboard, which shows the changing status of around 2,000 test cases during the UAT process.
Benefits of User Acceptance Testing in Dynamics 365
The time invested in UAT and test script creation for Dynamics 365 pays off in three main ways: any problems get identified before go-live, your company is better prepared for future updates and projects, and decision makers are empowered.
- Problems can be identified before go-live. This happens because testers are equipped and confident that they are testing the “right things,” and testing is consistent across users and over time.
- Your company is better prepared for future system upgrades, integrations, or customizations. That’s because UAT scripts created for the initial deployment of the new solution can be reused.
One of the attractions of the Dynamics 365 product line is its flexibility and extensibility. Having robust UAT scripts in place prepares you to take advantage of those features.
- Most importantly, UAT empowers decision makers by providing concrete information about system readiness for go-live. This informs the crucial decision: is our new Dynamics solution ready to launch?
If you are looking for more resources related to implementation, you may also be interested in:
- How to Mitigate ERP Implementation Risks
- CRM Implementation FAQs
- Encore, a Dynamics Implementation Partner
If you have any questions or would like assistance with your Dynamics testing or implementation, we’d be happy to talk with you. Contact us.
Many customers come to us for their first Dynamics implementation. Others want to add a new solution to their Microsoft stack. And others ask for help with ongoing but troubled implementations.