User Acceptance Testing (UAT): Identify software bugs before your end user does
What is a UAT and why should I conduct it?
UAT (User Acceptance Testing), also called application testing or end-user testing, is a phase of software development that involves real-world testing of the software by an intended target group. Conducting a UAT is often the last stage of the software testing process before the software is released to its intended market or target group. If the software is not tested beforehand, there is a high risk that bugs or other problems occur after the release date. As a result, the real user or customer ends up with these problems. Especially in today’s world, where the competitive pressure is high, retaining or acquiring a new customer is difficult and the willingness of a customer to switch to the company or a product is a lot higher. Every small mistake or dissatisfaction can have a big impact on the customer’s decision. According to the 2022 Customer Experience Trends Report, just one bad experience causes over 60% of customers to leave a company and move to a competitor. Of course bad experiences can take place at a wide variety of touchpoints, but nowadays there are very few customer journeys that do not include at least one online touchpoint. Therefore it is even more important to test if any features have been overlooked or if they contain any bugs.
What should I pay attention to?
User Acceptance Testing occurs after development and quality assurance, but before production. UAT can be done in-house with volunteers, by paid test users or by making the test version available e.g. as a free trial. The business or test users are evaluating the software or the implemented functionalities against the requirements. The results from the test users are forwarded to the developers, who make final changes, solve current bugs, and fulfill all the requirements before releasing the software. The interaction and communication with the development team is one of the most important assets to successfully conduct a UAT. Imagine a scenario of poor or unclear communication with the development team. As a result, the software may undergo other testing phases and be completely functional but might still not meet its requirements if it is not well accepted by the test users. This can happen if software requirements were not clearly defined to the developers, certain modifications made during development changed the scope of the project or the software simply was not ready to be tested in a dynamic, real-world environment. Therefore, it is even more important that the UAT should be thorough and reflect user requirements.
How to set up a UAT?
Planning – Consider test criteria in preliminary stages: What exactly do you want to test? Create detailed test cases and determine the time frame. Test cases are a set of specific actions that are taken to test and verify a particular system behavior, feature or functionality. Let your project managers and your UAT team review your test plan.
Select the test users – Depending on the project specifics, those can be experts, real-world users of the software, stakeholders, business analysts, product owners or the customers. Test users should have knowledge of the business and know how to detect and report issues. Introduce users to the testing process and its objectives. Furthermore, ensure that the users understand test cases properly and provide them with reporting standards and guidelines and support if needed (e.g. daily or weekly Q&A sessions). Do not use the functional team just for testing purposes. Functional testers are not meant to perform a UAT and may end up not testing all real-world scenarios. This leads to end-users finding issues when the software is already in production.
Communication and Documentation – As mentioned earlier, a clear communication between the development team, UAT team and business testers is paramount to reach the intended targets of the UAT. The test user is testing the software based on the test cases, raising any potential bugs or other issues and giving feedback on the software and its functions. All bugs should be documented in an issue tracker with a clear description of the bug (e.g. reproduction steps, description of the issue, expected outcome, screenshots, priority, business impact). A clear description of the issue is essential and makes the life of the development team a lot easier to understand the issue immediately and solve the problem in the correct manner.
Fix bugs, retest and sign-off – The development team must make solutions to address the issues revealed by the UAT. Once the bugs are fixed, the test user must retest the case to make sure everything is working properly. When all the acceptance criteria are reached and approved by reviewers, the final acceptance decision is made about production-readiness. A final UAT report (which at least includes the results of tests, bug reports, and fail/pass records) should be provided to stakeholders together with the estimated time and effort required to meet acceptance criteria and recommendations for the release.
Excursus – What is the difference between UAT and SIT?
System Integration Testing (SIT) is defined as a form of software testing conducted in an integrated hardware and software environment to validate the behavior of the entire system. The main goal of SIT is to ensure that all software module dependencies work properly and data integrity is maintained between different modules of the whole system. It is performed by developers and testers. Whereas the problems encountered in the UAT correspond to the functions that do not meet user requirements by business testers or end-users.
To sum up, UAT is the “last” chance to identify and rectify defects. There are no surprises when the software is released and the launch is no longer a jump into the deep end. A clear set up, documentation of the bugs and communication with the development team is essential to fulfill the UAT in the best possible way, otherwise the business may suffer losses. The losses that may occur if the UAT is not performed properly are much more expensive than fixing bugs before production and could potentially damage the software or company reputation.
Author: Markus Kittenberger
Sources:
https://www.zendesk.de/blog/heres-why-you-should-be-investing-more-in-customer-service/
https://www.altexsoft.com/blog/engineering/user-acceptance-testing/
https://www.techtarget.com/searchsoftwarequality/definition/user-acceptance-testing-UAT
https://usersnap.com/de/blog/tipps-user-acceptance-testing/