User Acceptance Testing Strategy
HR WORKSHOP by Ari Kopoulos, National sales and marketing manager, EmployeeConnect
This article is first published in HR Leader Magazine – issue 202 (22 June 2010)
Q: What are the elements of a successful User Acceptance Testing Strategy (UAT Testing) for an HR technology implementation?
A: A key milestone in any technology implementation is the User Acceptance Test (UAT) phase. It signals the point in the project when functionality has been implemented and requires input from the business requirements that all the expected results have been met. Typically positioned at the end of the project, this is where the words, “confidently delivering benefit” could be inserted and where for many users, it’s their first glimpse into the system that’s about to change the way they work.
Technically, UAT testing meaning a formal phase of validation, that the system meets the user defined requirements from the user perspective, in the user’s testing environment with real world scenarios, i.e. the system is fit for purpose. It’s the last step before issues are identified, resolved and the system moves to production. Despite its significance in ensuring fit for purpose and minimising risk, it’s not always given the level of importance it deserves and is often rushed as a tick the box exercise.
To ensure a successful UAT strategy, begin by deciding the reason for UAT right at the project management and requirements definition phase. Involve users in the definition of requirements, goals and motivations to ensure buy-in and smooth issue management and transition to production. Include an evaluation of risks and their impact on budget and schedule. Once you have clarified what the purpose of the acceptance unit testing is, it will be much more straightforward within that context to define acceptance criteria and identify the stakeholders.
When selecting users, as the name suggests, look towards the actual users of the proposed solution, the IT group, and management representation. These are the people who understand exactly what the business is and how it operates. Also, consider the individual’s motivation towards the system, time constraints and of course skill level as these could become training, risk or, change management issues.
As indicated earlier, often the specifications and requirements document serves as the one and only template for acceptance. When you consider that a significant portion of product defects originate in the requirements definition, this is not a bullet proof strategy. In fact all you are doing is verifying that the specification and requirements have been met.
This is a rather clinical approach, not representative of the real world. What you need to do is validate. That is, design a series of integration tests that reflect the user’s day to day workflows, processes and reporting requirements. These system testing will determine whether the solution will correctly support the business.
Define criteria on the basis of what is to be tested, why, and include the detailed steps, scripts and actions to be executed. These should include the expected and measurable objectives and acceptance criteria. Be sure to include a risk assessment matching the testing to the risk level and quantifying it.
By identifying what elements and business units are most exposed and the consequences, it allows you to allocate resources where defects will have the greatest impact. Finally, keep an open mind. UAT outcomes may call on you to revisit your initial requirements and specifications making adjustments as required.
In many ways, UAT is one of the most critical and risky aspects of any technology project. It combines all the elements of the business process into a single actionable and measurable activity that not only ensures the users will have a solution that meet their real world requirements, but delivers value to the business and that all important assurance to the key stakeholders.
