The purpose of a UAT plan is to ensure that the solution effectively supports a company’s most common business processes and scenarios.  The UAT plan brings together automated system processes or workflows, user-executed steps, reports, user permissions, and data to meet this objective. 

The UAT plan should outline all the key processes that the solution and/or your business users must execute to support your business operations, including all standard business processes and the key exception processes so that, when executed successfully, the test plan provides your organization with confidence that greater than 80% of the business scenarios, or use cases, are supported with the solution and training that you will provide to your business users.

The components of a UAT plan include well-defined:

• business processes
• documented user roles
• test scripts
• numbered user actions with steps
• anticipated results
• actionable results
• documentation

The Pareto Principle (80/20 Rule)

A project team can spend dozens of hours simply putting together the UAT plan.  It is important to balance the time spent building the UAT plan with the benefit of having such a detailed plan.  Best practice is to ensure your plan covers 80% of the most common business scenarios or use cases, including the most common exceptions.  Capturing every exception in the text plan is likely to take more time than is worthwhile.

Plan structure

A successful UAT plan will be business-process-based and role-based. Execution of the plan should ensure that the processes and systems work, in addition to ensuring that the users/roles executing the plan have the appropriate and necessary permissions.

• The plan should also take into account all the necessary forms (screens) that display the appropriate fields for a given role and task.
• The UAT plan should incorporate automated system processes or workflows, user executed steps, reports, searches, and dashboards, user permissions, and data.
• When building a UAT plan, review flow settings, field mappings, process diagrams, requirements documents, and product documentation to gather the business processes and steps that should be included in the plan.

Testers

• Identify one or two “superusers” from each department or representing each type of business user (role) to participate in building and executing the UAT plan. These testers should ensure the UAT plan includes the most common business scenarios and use cases their role or departments come across.
• These testers should execute the test plan logged in as the role that will be performing the steps outlined in the plan. Testing should not be done using an administrator role if, upon go-live, non-administrator roles will be performing these business functions.
• These testers should be well versed in the company’s business processes, the original solution design and requirements, and the basic navigation of the solution and systems being tested. These testers should have enough knowledge and authority to determine whether a test result is acceptable to assign a pass or fail score. 

Testing grid for complex processes with variations

• Some business processes are complex – or there are many variations to the business process that adds significant complexity. For example, a sales order or fulfillment process may have many variations in types of items (such as inventory, non-inventory, service), varying quantities, one or many transaction lines, taxable and/or non-taxable items, multiple lines where each is treated or fulfilled differently, multiple ship-to addresses, committed or non-committed items, partial or full shipments, national or international shipments, stock or made-to-order items, new or existing customers (where treatment of each differs), partial or full order cancellation, partial or full order returns, etc.
• For scenarios such as these, it is useful to build a grid within your UAT plan that delineates each scenario and each combination of these variations or factors that must be tested. The steps that users must execute can be summarized above the grid (or on a separate tab), and users create a transaction or record for each row of the grid.

Data

The quantity of data to be tested depends on the volume of transactions and the complexity of the business process. For each business process and scenario, at least one test should be conducted. If changes are made to the solution or a user's roles and permissions, another test should be conducted.

Execution of the test plan

In the spirit of the 80/20 rule and making your testing most effective, Celigo recommends a certain sequence of integration flows to validate along with a concentration on those use cases and data that might be more unique to your business.

• For a given integration app, Celigo can provide guidance on the order of integration flow testing. This is typically based on a layering approach such that the most fundamental building blocks can be created through testing and then layered one after another to give the most thorough “from scratch” testing.
• Celigo integration apps are thoroughly tested products and used by many customers. You may take advantage of this by spending minimal time (if any) testing standard, out-of-the-box field mappings. We recommend that you focus your time on validating the field mappings you have added or adjusted.
• Allow extra time and effort for testing integration flows that have dependent logic. For example, have a script or workflow that is triggered when a customer record is added. 

Summary

Conducting user acceptance testing doesn’t have to be an overwhelming endeavor if you develop and execute your plan by employing smart strategies with a focus on validating the processes that are most unique to your organization.