What is user acceptance testing (UAT)?

User acceptance testing (UAT), also sometimes called end user testing, is the stage in a project where the software is tested by its intended users. The goal of UAT is to make sure the software performs as intended and no features have been overlooked or contain bugs. 

Why is UAT important?

Simply put, developers should build the product; quality assurance (QA) professionals should handle all the initial testing, and the end user should be completing the UAT. By sticking to this distinction, we ensure that the software is doing what it is designed to do in the user’s actual workflow that may have been missed by general QA testing. On top of validating the end-to-end business flow, UAT is also a cornerstone in helping prevent re-work after a release. Fixes that are made after the software has gone live can create an unnecessary burden and typically ends up costing more time and money than it would have if those issues had been caught prior to release. This is where UAT really thrives. 

UAT Process Management

The key to successful UAT is adopting industry standards. Let's go over the steps you can take to successfully implement UAT into a business development schedule.

1. Knowledge Gathering: The first step to successful UAT is gathering the information required to create comprehensive test cases. Here, we are defining the sequence of user action, guidelines for specific tests, and intended results from the user action.

2. Scope: While testing in general is crucial to the success of a business process, there are unique situations where UAT can safely be ignored. Ensuring that UAT is included when defining the scope of a project means that both the development team and end users can be assured that resources are not being wasted on tasks that are non-critical to the overall success of a project.

3. Design and Execution: This is where the success of UAT will really be defined. The best suggestion is to plan time for UAT sessions before crucial milestones when the development team, dedicated testers, and end users can meet to create successful documentation. Once a testing document is created, the users that will be testing can begin work. At the end of this article, there is a downloadable UAT template that can be used during this design and execution phase.

4. Confirmation: Once the testing document has been executed and all defects and bugs have been resolved, it is time to sign off on UAT and then go live.

UAT Document Training

Accurate and thorough documentation on the UAT strategy and general plan is crucial to a successful and efficient outcome. Documentation should feasibly include as much of this list as possible:

• Out-of-scope situations worth testing

• A generalized agreement on standards that dictate a pass or fail on a test step

• How to carry out each step in the testing process

• Expectations for the UAT session as a whole

At the end of this article is a downloadable template that can get your organization started implementing a UAT cycle into your development workflow. 

Starting at the top of the document, you should begin with general information including who will be completing the UAT tests, the project name, and any other information deemed relevant to the project. Just below this header are the columns where the actual test cases will be defined by number. Make sure to always include the date of testing for each test case.

While most of these first columns are self-explanatory, the focus of this article’s training will be in columns C - F, which describe the user actions, expected vs. actual results, and the pass/fail column.

Typically, the user action and expected results columns will be defined by whoever would have the most knowledge on potential fringe cases, overall workflow for the project, and where the most value will be seen from the project. 

Following this, the users tasked with completing the UAT will fill out the columns for actual results and pass/fail. If the intended result of a step is completed, no real action is necessary and a quick check in the box defines that step has passed UAT. However, if something unintentional happens during a step in the process, this is where the most valuable information will be found. Issues that would be helpful to add here would be inconsistencies in visual elements within the project, defining whether or not the user experience is intuitive and efficient, and any error messages that may get presented.

Finally, the notes field at the far right is a great spot for documentation of fixes or where developers or support employees can put the date that they resolved the issues, which lets the UAT professionals know it is safe to test again. Think of the notes field as a sort of change log for each individual step.

The scope of the project will dictate whether the bottom tabs of the document are necessary. If the scope is small and the project does not have multiple iterations or releases, then we can easily use one dedicated document to complete all UAT. However, if there are known milestones in the project development cycle, having separate tabs for milestone-specific UAT sessions is beneficial.

Conclusion

A successful UAT cycle can take some time, but the benefit of spending that time upfront will prove invaluable to anyone that’s experienced the hassle and cost of post-release bug fixes. By allocating resources early in the scope of a project for UAT planning and execution, there will be greater security in knowing that a project is truly ready to be released into the wild. While it is great to be skilled in all steps of a project’s lifecycle, one key thing to remember is: developers should develop, internal QA should be done by dedicated QA professionals, and the intended end users should be the last bastion to complete UAT.

If you have any questions regarding this article, the downloadable template, or user acceptance testing as a whole, please feel free to reach out to DB Services and let’s see how we can implement UAT in your organization.