User Acceptance Testing Checklist

User acceptance testing (UAT) refers to the review and testing process that occurs right after a feature is implemented and is ready to be released. This article will explore UAT and cover what happens behind the scenes. We will discuss the people involved and how they can work together to achieve the goal of UAT, which is to ensure that implemented features meet the functionality requirements specified to the developers. In turn, this ensures that the shipping product meets the business requirements expected by various stakeholders, including end users.

‍

The cross-functional group involved in UAT includes software engineers, product managers, designers, product marketing people, and analysts. Because UAT requires collaboration among people from different functions with different responsibilities, this article will focus on both technical and non-technical aspects of collaboration, which goes beyond systems and infrastructure.

‍

Teams perform UAT by following a checklist that they put together. This checklist explains which team members need to perform which actions to mark the feature as ready to be released. This includes automated testing by engineers for various requirements and a manual inspection by QA engineers and product engineers, each checking a specific aspect of the feature.

‍

A good UAT checklist reflects how the organization views cross-functional work and the people involved. To develop one, you first need a good understanding of how engineering, product, and design (collectively called EPD) work together. In a simplified world, the usual stakeholders are a product person who provides direction, a designer who brings the feature to life visually, and an engineer who makes it all happen by implementing the feature. These people should collaborate on developing the UAT checklist, and all are accountable for the outcome.

‍

Key takeaways

‍

• There is no universal UAT checklist. Tailor your checklist to fit your organization and avoid adding requirements that do not align with your team’s size and structure.
• How you prepare for and execute UAT reflects your team’s level of maturity in terms of accountability and collaboration. If your team is having issues with alignment overhead, you might need to be conscious of your UAT checklist and involve fewer folks to speed up delivery.
• A robust testing infrastructure with the appropriate test management tools can speed up a time-consuming process, removing manual work and the mental overhead required to get things done.

Summary of user acceptance testing checklist concepts

A baseline for a UAT checklist for a new product flow would involve the following:

‍

‍

The goal is for the product requirements document to incorporate all business requirements. In reality, things can be slightly different, and your list may need to be adjusted accordingly. For example, implementing an instant money-transfer feature might require the approval of the CEO, not just the PM owning the feature. How this works in practice will be explained further in the next section.

‍

Cross-functional teams

Who does what?

UAT checklists help facilitate cross-disciplinary communication within and across product, engineering, and design teams. The collaboration goes cross-functionally not only at a team level but also at an organizational level. This checklist’s primary purpose is to drive alignment while maintaining a specific level of quality that the organization has agreed upon. It also provides a clear separation of responsibilities in terms of who should do what to drive an initiative to the finish line.

‍

Let’s start with a role definition in a relatively mature organization.

‍

‍

Designs the feature and provides the sign-off that nothing is violating the company’s design system.

‍

As this table shows, the complexity is significant here. Every function (i.e., engineering, design) has its spheres of interest and influence, and the cross-functional team has its own goals. All are important to the company’s success, and the challenge is to keep everyone aligned so the job gets done. This complexity is why UAT is non-trivial: Many people must sign off before something is released, and they often have different (though ideally non-opposing) goals.

‍

The answer to the essential question of who’s accountable depends on your organization. Some companies embrace the idea of an accountable lead who champions initiatives end-to-end and ideally guides the UAT process. Other organizations embrace the variability involved in the process and push that each function owns its part, hoping the end product will get to the finish line correctly.

‍

In smaller organizations, employees can wear multiple hats. Maybe you have a skilled front-end developer who can do both design and engineering. There may be no direct marketing or product function, so the CEO or business owner covers those roles. These organizations usually optimize for speed and have less rigid requirements for releases. Going faster necessitates a substantial investment in observability and proper testing infrastructure because things tend to break more often.

‍

Larger companies have clearly defined boundaries, which increases quality but slows down delivery as more alignment and communication are needed. Releases are more sensitive here as they can affect millions of users, and flaky releases can lead to significant losses.

‍

How does collaboration take place?

When thinking about the product development cycle, which concludes with UAT, a sequential approach to implementation might work in smaller organizations, as mentioned above.

‍

‍

A sequential flow of the product development cycle from PRD to UAT, with the function responsible for each step

‍

This way of working is overly optimistic and assumes that each phase has a clear-cut outcome that is passed on to the next stage of development. For example, product teams come up with requirements and then disappear to work on the next thing, while developers simply execute. This approach has several disadvantages, including creating silos, misunderstandings, and missing expectations when the feature comes together for review.

‍

A more collaborative method is for everyone’s input to be required at each stage in the product development lifecycle. This is a team approach where all team members, regardless of their function, are involved in all phases. Involvement means regular discussions and check-ins, transparent status updates, and collective decision-making on what needs to change if there are bumps in the road during the development process. This avoids the silos created by the previous sequential approach and unpleasant surprises when everything comes together.

‍

Following a sequential or collaborative approach relies heavily on the company’s culture. Some companies are not as product-centric, and a collaborative approach will be overkill in such cases. Others require more regular input from product folks and designers to ensure success; in these cases, the collaborative process is necessary.

‍

‍

A collaborative approach to the product development cycle with the function responsible for each step

‍

The same collaboration approach should be considered when performing UAT. If one person does it, then expectations won’t be met. If everyone does it, it has to be streamlined to avoid over-coordination and excessive communications overhead.

‍

How to prepare a user acceptance testing checklist

‍

Who should put the list together?

‍

Most of the time, the burden of owning the UAT flow falls on a team lead, the product or engineering manager, or the software engineer who executes the initiative. As shown in the diagram just above, everything comes together in the implementation phase, led by the software engineers. If leadership develops and champions this checklist, the engineers become the bottleneck for releasing initiatives as projects increase. However, because they know the big picture and can drive alignment much faster, there is less risk of failure.

‍

UAT checklists led by team members, and especially engineers, scale easier but might need more communication and alignment to make sure the output is up to the standards and requirements defined by the team. A team-led, end-to-end product development flow is usually a sign of an organization’s maturity.

‍

Developing a checklist

Here are some initial questions to ask when creating a checklist:

• Who are our customers? What are they expecting from this feature?
• Do we have a design element? Do we have clear acceptance criteria?
• Do we have the infrastructure to run the tests we defined to ensure that the acceptance criteria are met?
• How can we provide a smooth testing infrastructure that enables asynchronous testing?

‍

Exploring the questions above will help prompt a more comprehensive set of questions that yield a complete UAT checklist:

• Is the expected feature adequately implemented?
• Are all integration and end-to-end tests succeeding?
• Has the code been properly reviewed?
• Are all edge cases covered?
• Does the design follow the initial expected design?
• If other systems or product parts interact with this feature, is the interaction consistent with the initial product requirement?
• When performing an A/B test, do we have the right experiment design with the events, metrics, and variants the team agreed on?
• Did QA perform all the tests to confirm the feature’s readiness?

‍

The distinction between the happy path and the edge cases is intuitive since the happy path is usually a reflection of what this feature is truly about. (A happy path is the most basic flow that delivers the core business value of the feature; it’s “happy” because it doesn’t consider edge cases such as errors, just normal operation.)

‍

Alternatively, consider a flow-based approach where a product feature is broken down into flows, some of which might include edge cases and others not. For example, the happy path is one of these flows. The main difference here is that in a flow-based approach, edge cases are not considered a luxury that should be handled later but first-class citizens that should be taken into account from the beginning. A flow-based approach where all UAT is performed flow by flow can come in handy where cross-functional discussions are more complex.

‍

Here’s an example of a flow-based checklist for a “sign up with Google” feature:

‍

‍

How good is good enough?

How much time does it make sense to invest in a UAT process? The whole process can take days or weeks, depending on how fast coordination happens and how automated the process is.

‍

It’s always good to ask how much the organization wants to invest to ensure quality. Considering the testing triangle, the more tests we run, the more time we support, and the more sure we are of the outcome. Can we embrace some risk of uncertainty in a particular feature? Probably not if we’re working on a payment gateway, but it might be okay for a new “Add to favorites” button.

‍

In reality, there’s only so much time you can spend on a test, and you will need to release the feature eventually. The time and effort spent on QA testing to increase confidence depend on the resources available to perform this test in the first place, and investing in automation and testing infrastructure can alleviate some of that pressure. At the same time, it’s worth noting that increased levels of testing can help make up for resource limitations in other areas of the organization, ensuring that the final product shipped to the user is always of the highest quality.

‍

A proper test management tool that provides ephemeral environments for stakeholders can be essential for maximizing the efficiency of the testing process.

‍

The following diagram puts the various aspects of testing into perspective.

‍

‍

Expanding the testing process with UAT alongside the functions responsible for executing each step.

‍

Engineering aspects of user acceptance testing

The engineering infrastructure is the puzzle piece that will make or break everything mentioned so far. The organization can either use asynchronous messages nudging people back and forth until the process is complete or implement proper tooling to streamline the UAT process.

‍

An ephemeral environment allows the team to spawn new environments for testing and reviewing with little to no effort. It also allows scaling across the organization to serve different needs.

‍

The following diagram shows a typical flow of action. Developers merge code, and an environment is built in a fully automated fashion and provided in the form of a URL that everyone can access to test the feature. The developers then incorporate feedback, and everyone keeps iterating until the desired state is reached.

‍

‍

A high-level representation of the coding and the testing flow in an ephemeral environment

‍

Imagine doing this via Slack messages, pinging everyone asking for feedback, and going through multiple iterations before every release. Now think of an entire company following the same practice with little to no tooling provided. This approach is inefficient and introduces high overhead to keep everyone aligned. Team members will be spread thin between implementing new features, following up on initiatives in the testing phase, and maintaining existing systems.

‍

Regular context switching and constant pressure from leadership to release faster while using an inefficient process can lead to frustration. An automated testing infrastructure aims at reducing those inefficiencies. That’s why Uffizzi provides both an open-source solution and hosted service to make sure that teams focus less on coordination and more on delivering value.

‍

Wrapping up

Instead of trying to provide a specific UAT checklist, this article aimed to describe the mindset behind a proper UAT process, so you can build the checklist that fits your needs. Cross-functional collaboration is non-trivial, and UAT is where it all comes together as the last checkpoint before a feature is released. Understanding cross-functional accountability and how it manifests in UAT is the best way to prepare and perform the review process to ensure a successful release.

‍