1) Write your intended test plan (test script) when the requirements analysis is fresh in mind. Get ahead and have this ready at project start in preparation for selection – to be refined later – or as one outcome of a business process review
2) Test scripts can be very detailed and appropriately so. There are templates available for download to see examples. The essence of the plan contents describes:
- Objectives of testing
- Business scenarios and functions in and out of scope of testing
- Roles to test, approve and receive results
- Pass and fail criteria, against each item and overall
- You may wish also to describe assumptions, risks and key points of method
Tip: Test scripts relate only in part to a particular system solution. If HR technologies are a significant part of your day-to-day departmental operations you may well be wise to invest time in devising a generic test script that can be applied in any one case (with some refinement) of new software deployment or upgrade.
3) Engage your internal project team to carry out UAT. If you try to involve other functional team members, it could simply be too hard to be efficient and you risk that a less-than-perfect result at this stage jeopardises initial reactions when going live later. To stress, do not ask your supplier to do the job for you. If you wish to involve external advisers (see part 6 on the who is who), only count on those you are sure have a sound grasp of the real requirements of the business.
4) Allow plenty of time. Quite how long is contextual and understand that even on the most modest scale you are likely to need to dedicate more than one focused day. Quite often I see product suppliers offering plan examples which include a 2-week window for UAT by their customer. To plot through different circumstances end-to-end and to record results takes a surprising amount of time.
5) Document results carefully and diligently. The format to which this is to be done should be agreed in the test script (and shared with those who you’ll give that back to) and it is absolutely essential that every scenario tested, outcome observed and score (the pass or fail, or the categorisation of the importance of error) is completed. Ask the consultancy team what evidence you need to be able to produce, typically a screen shot to accompany your notes, ahead of time so that you don’t have to repeat.
Key question: Is the supplier involved at all in UAT? Do I have to do it all alone? No, you’re not alone. Whilst I offer no wriggle-room around getting out of your user role, do expect your consultants to support you. Largely those experts are waiting for your responses, so keep in touch to report results throughout. You can be efficient with time needed for repeats of the UAT period to limit how long the whole process takes. It is also fine to ask for guidance about writing your script [see above] and to expect a low-key introduction as to where to start in this first trialling. But have confidence! You do not need to have received full training in how to use a system to do UAT.
Note and report failures. Overall success may then be defined, for example, as “X% of test items have achieved with no problems classified as high or medium on impact – and with 100% of items now tested.” Be sure that all those items that do not pass as individual tests have a decision attached to them as to whether to fix or to accommodate. The exit point of the UAT exercise is then the signing-off of the scope of that testing with a concluding “pass” result.