User acceptance testing (UAT) is the final phase of any software project, and is vitally important to project success. But really what is UAT, and how does it differ from other forms of testing?

WHAT IS UAT AND WHY IS IT NEEDED?

The goal of UAT is for the product owner to verify from an end user perspective that the delivered product fulfills the business need that the project was undertaken to solve.

Considering the definition of UAT, it should be fairly obvious how crucial a step it is. After all, you wouldn’t buy a car without test-driving it, or purchase a home without having an inspection done. In any software project, it is the last development step that will ensure product viability, before it is rolled out to the marketplace. In most cases, it is also the point at which the product is accepted and the project can be deemed complete.

HOW DOES UAT DIFFER FROM OTHER FORMS OF TESTING?

The piece of software should be tested through emulating “real” use-case scenarios, in order to ensure it adheres to specifications. Upon completion of the UAT phase (and any remediation of issues that are found), the product is then accepted and the project can transition into the Project Closing phase.

This is NOT to infer that a deliverable isn’t first tested by the vendor (or ‘quality assurance testing’). The vendor will test the back-end coded functionality (system testing) and also ensure that contracted requirements are met. Where QA focuses primarily on testing the functional code, UAT focuses on the usage itself.

WHO SHOULD TEST?

The 'What' and 'Why' of UAT should make clear that the testing is completed by the contracting party (the client), rather than the vendor. But within the client organization the 'Who' can certainly vary. Minimally it should be be done by the primary project contact, usually the client’s project manager.

A more typical scenario might be that the client’s Product Owner will test and accept the deliverable, as well as be supported by a UAT testing team, various product SMEs, or other project stakeholders who have a vested interest in verifying completeness. The key goal is to identify any and all testers who are best able to emulate the product's end-user(s).

HOW IS TESTING COMPLETED?

There can be as many UAT variations as there are projects; a driving factor likely is the complexity of the project. Keep in mind that testing should be based on real-life interactions with the website or piece of software.

UAT for smaller or less complex projects may be achieved through what is essentially a ‘walk through’ of the software or website. The tester is essentially a set of ‘fresh eyes’ who will likely follow use patterns that emulate an end user. However, even in the simplest of UAT scenarios, there should minimally be a checklist of scenarios to be tested.

More often, in medium to complex projects, the UAT plan should contain some or all of the following elements:

Definition of the UAT team:

• What end users need to be represented (or can test directly)?

Acceptance Criteria:

• These should be created at the beginning of the project and be based upon User Stories and/or requirements from the SOW.
• The criteria can also come from the development of the functional requirements, but remember that UAT is not functional or systems testing – it should focus on user experience testing.

Test Plans:

• Based on the acceptance criteria, you’ll want to develop test plans that can be used by all testing parties.
• In larger projects, a UAT test schedule may need to be developed and shared with the UAT team.
• There are many examples of test plans that can be found online. I’ve often found that Excel formats, posted using Google Docs or other online avenues for collaboration, are typically quite useful.

Testing Frequency:

• Spot checks should occur at the end of each development sprint.
• Remember to account for end-to-end testing of the final deliverable.

While User Acceptance Testing is ultimately the responsibility of the client, the vendor should be available to discuss with you the best approach warranted by the complexity of the project.

FINDINGS & RESOLUTION

If your project's QA budget was sufficient and well executed, we can assume that your UAT testing should encounter minimal issues related to function or scope. Also, if you practice ‘spot checking’ after sprints, it's more likely that issues are found and resolved well before the final ‘end-to-end’ UAT testing period.
 
However, it is not uncommon that once you see the software in action, a ‘better idea’ arises that you realize will enhance user experience. Leaving budgets (and the potential for change orders) aside, there are three options to manage such items:

• Push the go-live date to accommodate the issue.
• Accept the issue and leave the product as-is.
• Add the issue to a product backlog to incorporate into a future release.

No matter your decision, your attention to the User Acceptance Testing phase of the overall project is an important final step to ensure a successful end product.

Need additional guidance about UAT from a seasoned expert? Drop our BlueModus team a line. We'd be happy to help!