As we stated earlier, planning is critical to perform successful UAT. During the planning, you are not only required to identify what test cases to execute, but also to list the correct resources and the required training and logistics – such as the UAT environment – to perform testing. The following details should be considered when planning for UAT:

• Providing training to business users before the UAT. Untrained business users will take more time to test, which can result in low confidence in the new system.
• Ensure that the UAT/sandbox environment is ready for the UAT. Data migration should be completed, and the required configuration done and tested. Ensure that business users have the appropriate security roles assigned.
• Plan multiple rounds of testing, scheduled a few weeks apart, to fix issues. It is not uncommon to find a few pieces missing once the business starts looking at the solution. The goal should be to fix everything in between both the cycles so that the business does not experience the same issues, and the test cases are not blocked due to those issues.
• Ensure proper sequencing in the test cases. For example, you start with the data migration validation and then move on to customer/product creation, then to order processing, shipping, invoicing, processing returns, commission reports, financial postings and financial statements, tax reporting, inventory value reports, and so on.
• The people who run the business should be engaged to verify the system; the team should have cross-functional knowledge and knowledge of case scenarios. For example, your top-performing, most brilliant sales talent pool needs to be involved in testing the order entry system. They will know all the different scenarios and gotchas from the current system, and they can help you to break the system.

• Avoid relying on the temporary staff for testing; you need Full-time equivalents (FTEs) to review your new world. Engage the temporary staff in backfilling the FTE jobs to run the day-to-day business tasks, not in reviewing the future of the company.
• Encourage the business to bring in as many real examples as possible. For example, the AP can bring in a day's worth of a stack of invoices for processing, running a check on both the migrated open AP and newly created AP invoices to review the results, and on the real customer orders for order entry. This will help verify credit limits, customers/products, on-hand inventory migration, and the related scenarios.
• Define the process for logging the bugs (record using the task guide or screenshot, provide a reference to the test case, the step that failed, description of the issue being reported, any input file used for uploads, business impact, and so on, for every issue that is being submitted by the users). Users need to be educated on bug-tracking tools and the overall triage process. The more information you have, the less time will be required for the development team to analyze and fix the issues.
• Use a separate environment for UAT testing, rather than the regular testing environment. Limit the number of people having access to this environment; you don't want users creating random transactions and messing up the UAT test scenarios.