When developing a plan, various aspects need to be taken into account. Alongside determining factors, including the scope, strategy and timescales, you will need to consider the business’ capturing process and the test scripts.
As the testing process may vary from one project to another, the considerations may vary; however, this covers most of them.
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 data capture using a classic structure, however, the downside of this is how it is not suitable for 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 repository for users and the ability to organise them.
There are several important factors to consider when looking at the content of test cases. It is important to identify their 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 them.
Some organisations 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:
It is possible to perform effective UAT with very lightweight cases, but this depends on the system knowledge level in 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 showing precisely what the user was doing and documenting 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 organised 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 repository that makes scripts accessible, maintainable, referenceable, and reusable is fundamental for increasing organisational 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 your test scripts have been created for distribution, you will need to check that they are understandable for users who will also be able to work with them. If the users have created them, it is the UAT manager’s choice how important this is to do.
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 important 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 prioritise important tests first.
We are sorry to tell you that using Internet Explorer as your browser won’t give you the best experience of this website.
To get the best value visit us via Chrome, Edge or Firefox