UAT: A Quick Overview

User Acceptance Testing (UAT) is an important part of the SDLC: it entrusts users to manually evaluate whether a feature meets business requirements. Here’s why it promotes stable software.

/images/blog/cover-images/UAT.png
What is UAT, and why is it important?

by on

UAT is an important stage of the SDLC – it’s a manual process for verifying that each feature meets all outlined business requirements. It’s best practice to have this as a final gate before a feature deployment, since testers will be simulating real-world usage of that feature. These test cases ideally should catch any last-minute bugs that QA or automated tests don’t pick up.

What is User Acceptance Testing (UAT)?

User acceptance testing (often abbreviated as UAT) is a manual review process for newly-built features. It exists as a final quality procedure to make sure a feature fulfills all business requirements. A Product or QA team will develop a list of “acceptance tests” for the feature, and users will assess the software against these. Acceptance tests will outline a feature’s desired behavior, e.g. bug-free workflows, or properly accommodating a user story. Each test will have a pass/fail outcome, and from there, a feature will be shipped or handed back to the dev team, respectively.

UAT is handled by end users who may be existing customers, volunteers, or paid users. These testers are often the same people who made the feature request. At the absolute minimum, there should be 3-5 testers per feature.

Often, UAT is performed in an isolated testing (or dedicated UAT) environment. Testers are granted access to the environment, in which they’ll manually evaluate each acceptance test. Sometimes, UAT is done in production, and new features are unlocked to relevant users via feature flags. In both scenarios, testers (and devtools) will gather logs, screenshots, and events. This data will then help determine whether a feature meets requirements.

Who is responsible for UAT?

UAT is usually owned by the Product team but QA may also run it. This often depends on org structure above all else. For example, sometimes UAT is a function of testing, and sometimes it falls under the customer experience umbrella.

Larger teams delegate UAT to real users (hence the name). This is because users tend to use software in novel, unpredictable ways. They’ll catch bugs that pop up in unique workflows, and might be more likely to spot recessive bugs that those building your software can miss. Users who are performing UAT are pretty familiar with the application, so they can quickly simulate realistic workflows.

Much of the time, the person/group performing UAT will be the one who requested the new feature. They will understand the feature’s intended behavior, and should verify it fits their ticket.

What is a typical UAT workflow?

Ideally, UAT should happen on every single feature. It happens after E2E, unit, and integration tests: it’s most efficient to have automation catch as many bugs as possible before looping in humans. QA will then manually evaluate on any grounds that can’t be automated. Once a feature is semi-finalized, UAT can begin. The workflow might look like this:

  1. QA (or Product) designs a set of UAT test cases.
  2. Stakeholders and users are briefed on test cases, and offer constructive feedback.
  3. QA provisions a short-lived UAT environment to demonstrate the new feature.
  4. The users who submitted the feature request are granted access to the UAT environment.
  5. Users execute their workflows, take notes, view logs, and record application behavior.
  6. Users review results and determine whether test cases pass.
  7. If all users agree that a feature passes the test cases, Product will do a final check. Once approved, the feature will be deployed to production.

This loop takes anywhere from a few days to a few weeks. The process moves faster if Product coordinates the testing phase with users’ schedules.

What tools do teams use for UAT?

As a manual process, UAT isn’t heavily tool-dependent, outside of its underlying environment infrastructure. However, there are some extremely useful tools to record feedback and track workflows.

Loom

Loom UI

Loom is a video recording tool that allows users to capture screenshares with voiceovers. In UAT, it’s used to show an application workflow, whether successful or buggy. Instead of listing steps to replicate a bug/workflow, you can record it firsthand and save everyone some time.

Marker.io

Marker.io Overlay UI

Marker.io is a feedback tool that allows users to attach product comments to a given UI component in an app. It’s overlaid on the UAT environment, and allows users to export screenshots and logs alongside their review comments. User feedback comments can be automatically converted to tickets.

Sentry

Sentry dashboard

Teams use Sentry to get realtime alerts and monitor application performance. When users are performing UAT, the QA team can filter logs to see what unexpected behaviors or bugs pop up.

Fullstory

Fullstory dashboard

Fullstory is designed with user testing front and center. Users can create testing sessions, and Fullstory will record their workflows and which events get triggered. With its dashboards, QA and Product can view analytics on how people interact with a feature.

UAT Environments with Shipyard

Perhaps the most critical prerequisite for UAT is a dedicated UAT environment. This environment should be separate from QA, staging, and test environments. It also should be easily accessible to stakeholders and authorized users via SSO. It should mirror your production infrastructure so that features function predictably.

Ephemeral environments are an easy choice for UAT:

  • They spin up quickly when someone needs to review a feature
  • They spin down when not in use, saving cloud costs
  • They sync with a PR through GitOps to reflect latest code changes
  • They are production-like, with all services and data
  • They are SSO-gated, so you can grant role-based access to team members, users, and other reviewers
UAT environment with Shipyard

Shipyard’s UAT environments help teams ship faster and with more confidence. But don’t take our word for it. Sign up for a 30-day free trial and see for yourself!

Try Shipyard today

Get isolated, full-stack ephemeral environments on every PR.

What is Shipyard?

Shipyard is the Ephemeral Environment Self-Service Platform.

Automated review environments on every pull request for Developers, Product, and QA teams.

Stay connected

Latest Articles

Shipyard Newsletter
Stay in the (inner) loop

Hear about the latest and greatest in cloud native, container orchestration, DevOps, and more when you sign up for our monthly newsletter.