There are many things to consider in developing a plan; this covers the majority of considerations but may vary from project to project.

Know how the business operates to be able to test a change in an area. Is this information to be gained via documentation or key users?

The business processes may change, and as the UAT is implemented in a separate environment, you will need to know the new business process changes, including inputs, outputs, and outcomes.

You may want to document this understanding and associated data capture using a classic structure. However, the downside of this is it does not lend itself to multiple scenarios. In this case, you will need to support any process definition with the data variations that are required, both for input and output. 

If the project is largely revisions and additions to an already existing system, you may want to capture the existing process from production if the knowledge is not already available. You can use this to create text style instruction cases or even how-to videos, which users can refer to alongside data scenarios.

The UAT management tool should be used here to provide a) a repository for these assets and b) the ability to organize and hence reuse them.

It is important to look at Test Case coverage, identifying if you have covered all the processes and scenarios that need to be tested. This analysis is critical, and it may require considerable input from business users to create.

Some organizations opt to delegate this task entirely to the users, which is often the best route; however, if you take this approach, you will need inspection and reconciliation to ensure that you have achieved the necessary coverage level.

Two simple things you’ll need to consider for the coverage:

Do the test cases provide full coverage of the test scope?Maintain traceability between changes/requirements and test cases

It is possible to perform effective UAT with very lightweight cases, but this depends on the system knowledge level of the users performing tests. If you don’t require extensive detail, there is no reason to put it in the test case.

Historically, detailed test cases and scripts also helped define what the tester was doing so any issues could be described in the context of that series of events. Modern UAT, however, uses capturing technology to show precisely what the user was doing and document their concerns and feedback.

Regardless of the approach, your UAT will take, test cases have become valuable assets that we want to re-use, and hence they need to be stored and organized in a way that supports that.

The same principles as outlined for test cases apply to any scripts which take instructions to the next level. The coverage and level of detail in relation to the skills and knowledge of the persons executing the tests. A purpose-designed organizational repository that makes scripts accessible, maintainable, referenceable, and reusable is fundamental for increasing organizational efficiency and avoiding frustration.

There are two aspects of data that need to be initially considered:

You’ll need to consider where the required data will come from, and this is inevitably based on what data is already available. This data needs to be treated as an asset; you should aim not to rebuild it or recreate it every time you go through a test cycle. Automation is sometimes used in this scenario to automatically create the data needed for subsequent testing and to carry it out when it is difficult to manage the condition of supporting data. However, the use of automation can be avoided in these scenarios by using a solution to manage data, this will allow for automation to be implemented in other areas which would benefit from it more.  

You can avoid this by utilizing available technology and virtualized environments, which will save considerable time and effort.

If you have created test scripts to be given to the users, then you will need to check, for at least some of them, that they are workable and understandable.  If the users have created them you probably won’t need to.

There are times when a project doesn’t go to plan. To successfully achieve a competent and effective UAT, it is important to understand the critical testing areas and those that can be deemed as lower-risk. If the situation arose, it could be cut from the test. Through understanding these risks, you will need to prioritize important tests first.

As with any testing process, not all phases need to be implemented within every project, but each should be considered to achieve the best possible outcome.

Over the coming weeks, we will cover the whole approach to UAT in a  step-by-step guide.  If you have just found us you can catch up here on the Overview, Scope, Strategy, and Planning.

Coming up next – Detailed Plan