UAT (User Acceptance Testing) gives an organisation the chance to test its software (a new implementation, an upgrade or even a customisation) using both real-world examples and those people who will be using the software day to day. It is often the final stage of the implementation process; conducted to ensure that system requirements meet business needs and allowing for any issues to be fixed before the system goes live.

Unfortunately, UAT is often the part of an implementation project that slips the most, due to lack of resource availability. The end users that are required to do UAT tend to already be stretched to the limit running their organisation and can’t afford the time to test new software. Once the project goes live the issue is exasperated, as the project team typically goes back to their day jobs and contractors are released.  Nevertheless, UAT is vital not only to the successful deployment of any new business application or software enhancement but also to ensuring organisational efficiency and success. It mitigates risk, increases the ROI of the application, and ensures that your organisation’s customers do not wind up being user acceptance testers by default.

User acceptance testing is often considered a one-off at the end of an implementation project. This is where organisations are mistaken. UAT extends beyond your business applications project due to:

1. Additional phases

Your organisation may have chosen to roll out a new business application or upgrade existing software in a phased approach. Phases can consist of different types of users, additional locations, different companies (for mergers, acquisitions, or parent companies) and more. Separate, and additional UAT needs to be planned and conducted for each individual phase. The results need to be communicated as well to ensure that earlier phases benefit from later testing.

2. Hotfixes

Developer testing or bug reporting during normal day-to-day operations may lead to a hotfix. These bug fixes need to be tested by end users to ensure they solve the problems originally reported.

3. Releases or further modifications

Software organisations regularly release updates. Microsoft, for instance, produces General Distribution Releases (GDR) and Limited Distribution Releases (LDR). General distribution releases are usually heavy tested before release whereas limited distribution releases fix issues within a specific problem area. Both, however, need to be tested within your organisation to ensure they fit your real-life scenarios and help you achieve business objectives.

Your organisation may decide to make further modifications or customisations to your business application(s) to help you handle unique business requirements. It is essential that these are tested by end users using the same scenarios and plans to ensure the modifications fit processes and objectives.

4. Upgrades
Dynamic organisations upgrade their software regularly to ensure they are following industry trends, keeping up with the latest technology, and offering their customers the most advanced experience. No matter what upgrade approach you take (vanilla, with significant customisation, or somewhere in between) it is important that UAT is completed, after a careful review of business requirements. An upgrade is the most important time for end users to ensure that the end result matches the original business requirements.

Where does that leave you? 

It is my recommendation that you have a regular team of end users that spend a part of their day job testing your systems. Whether that is on an ad-hoc basis, weekly, monthly, or based on projects is up to you. It is important to remember that as you evolve as a business your software needs to work for you, and the best way to avoid problems with functionality, automation, corrupt data and more is to have those closest to your business applications monitor and test them.