Define test cases and scripts
As you document and run the test plans, keep your audience in mind. Test cases for a project’s test team will have a different set of expectations than the end users will during user acceptance testing.
One strategy for testing is to follow tasks that have been marked as completed. The task has been marked as completed and now the tester evaluates it for completeness. While this seems like a fast way to complete the testing, it only works if the requirements, and tasks were written with the understanding that they were also intending individual tasks to be explicitly testable. Depending on the methodology for the project, these tasks will likely not have enough information for a tester to use for a test case. These tasks can help shape the testing narrative by grouping tasks together into a user story to test.
Many project teams include test teams who exclusively test the solutions at defined milestones. A Dynamics 365 project should have a documented process in place for testing, even if a separate team isn't in place to accomplish this task. The documentation of test plans can be done by any project team member with enough knowledge of the requirements, and the solution, to make a complete and easy-to-follow test plan. This testing should test functional and non-functional requirements.
As stated previously, user acceptance testing happens when expected users of the new system have a chance to use the system in an isolated environment to determine if it meets their needs. Often, these users do their testing based on what they already know about their job and how the system was expected to address their needs. However, user acceptance testing is more successful when the users are guided in their efforts. You can write test scripts for them to follow, or preferably, guide them in writing their own test scripts in advance. These test scripts should target logical groups of users based on common tasks.