What makes a good User Acceptance Test, for a successful go-live?

User Acceptance Testing (UAT), or application testing, is the final stage of any software development or change request lifecycle before go-live. The list below is not exhaustive, and every project will be different according to the nature of the project, circumstances and stakeholders.


Have a clear testing programme. Random testing gives random results and sampling may be good in the early stages of development but you really need complete, comprehensive and detailed testing if you are relying upon a system for your business.

Having well documented tests and processes allows for repetition, for example when redoing test or after an upgrade where you want to be clear what worked OK in the past still works OK.

Be very clear what is a minor fail (cosmetic issues), a significant fail (must be fixed within a few weeks after go-live) and what is a major fail (meaning you cannot proceed). 

Ranking tests, results and what is acceptable or not up-front avoids contract or commercial disputes of scope, quality and function, and what constitutes success. And in some cases, payment or withholding payment.

Make sure your have a Test Manager / Leader to organise the testing and manage the feedback. This is important so that if 50 people have the same problem you only report one issue and don’t confused issues with duplication, error or omission.

Make sure your Test Manager / Leader has a deep and wide knowledge of systems and processes so that they understand where in issue is with the person, product, process, or procedures. This means being able to work with a whole range of people and not wasting time alerting the software supplier for something that may be a training issue or vice-versa.

Make sure your testing team has sufficient knowledge of systems and processes, and the time and capacity to do the job well, which includes accurate reporting of issues. Moreover, the testing team need to represent all aspects of the product and all areas of the business. What may be OK for Sales may not be acceptable for Compliance and what suits one jurisdiction or office may not be adequate for the other. 

Have at least 2 ideally 3 or possibly 4 test-cycles of test, report, fix, retest. Nothing is perfect first time and not allowing sufficient time to learn, improve, correct and retest may mean that you simply don’t have time enough to address defects.


Avoid testing before the systems are ready for testing! Do not proceed with UAT Testing (of functionality, config, design, operation) until you have approved the config / design and the data is 100% correct  (where data-migration from old to new systems is a key element). To test a product that has config or data errors before you start is not productive and creates a bad experience for users which may impact on their engagement and adoption, as well as their ability to later train the end-uses.

Avoid doing testing when key stakeholders are absent, for example technical people to fix issues or senior people to offer guidance. You really want all the stakeholders and experts available so as to be able to address issues quickly and successfully.

Avoid using novice or part-time testers or those with significant business-as-usual opportunities which mean they cannot fully do the testing, understand the results and support the diagnostics and remedy. 

Do not allow random testing at odd hours which undermines communication and coordination. Aim to have an organised plan for each day and an agreed time to review and feedback so that results can be understood as a whole and actions coordinated. A 20min stand-up meeting at the beginning and end of the day is a great way to set the agenda and review the progress.

Tim Rogers Mob 447797762051 

We offer #consulting, #coaching, #mentoring, #facilitation and #mediating to support individuals, teams and organisations. 

#jersey #timhjrogers #prince2 #agile #waterfall #pmo #projects #lean #training #programmes