What is UAT (User Acceptance Testing)?

To explain it simply, UAT is performed to answer the question: “Have we produced the result our customer wants?”

Actual users test the software to find out if it works as expected in real-world situations and is able to carry out day-to-day business scenarios in accordance with specifications. The UAT is most often carried out at the final stage of the software development cycle.

The steps in conducting User Acceptance Testing include:

1. Planning – an outline of all details of the UAT is produced.
2. Designing Test Cases – these test cases are designed and defined so that they will cover all the functional scenarios of the software in real-world usage. 
3. Selection of the Testing Team – a group of end-users is created.
4. Executing Test Cases and Documenting – the testing team executes the test cases, logging bugs and comments. 
5. Bug Fixing – the development team resolves the bugs reported by the Testing Team
6. Signing Off – when all of the bugs have been fixed, the Testing Team indicates acceptance that the software meets user requirements and is ready to be released.

Usually such testing happens in a war room of sorts, with the team including the users, PM and QA working through all the acceptance test cases. How do we do it at Voypost? We are a remote company that provides outsourcing and outstaffing services for clients all over the world, so after an inner session with the QA, we give out the feature to the client. They conduct the UAT autonomously.

Without proper UAT, some problems can only be noticed by users after the platform launch. Going back to debug and improve the platform will not only cost more, but can also result in a loss of reputation. The process risks being dragged out, as the little problems on each stage can pile up and in the end it may be difficult to untangle it all to address the problematic part specifically.

In addition, UAT is a good safeguard against issues that arise when change requirements are not effectively communicated to developers. Sometimes, while developers have an impression that they are following requirements to the letter, they might find errors only after the platform release. Such situations happen often when requirements change in the middle of the project.

Voypost uses Agile methodologies. In an agile setup, a Product Backlog consists of user stories. They follow a formula:

• As a (User)

• I want (a feature)

• So I can (reason of need/business benefit)

This is a great guideline for UAT. The feature is clearly defined: who needs it and why. During Backlog Refinement, the client and the development team collaborate on the details of these user stories, outlining acceptance criteria.

Such an increment is only considered to be done when it is a working (meaning fully tested) software that fulfills the customer needs and meets all the acceptance criteria.

So, you might ask, how is UAT different from Functional Testing? The latter one tests specific requirements and specifications of the piece of software, however, it does not involve the user factor. It means that a functional test might conclude that software behaves as it needs to — but it cannot state whether it will actually work for the user. UAT, on the other hand, concentrates on how specific requirements are working for the end user. The focus is precisely on how well the client can use the product to complete the required tasks.

The main purpose of this testing is to validate the digital product against the business requirements. This is why this validation is carried out by the end-users — as they are familiar with the business requirements.

At Voypost, we have devised a system, where we let the client conduct UAT after each stage of the development. After they test it out and the client rules a milestone as achieved — only then they receive an invoice and pay for it, and we can move forward to the next phase of development. This way we can deliver a perfect product rapidly and ensure customer satisfaction.