User Acceptance Testing - a business analyst’s perspective

By Alex P on February 21st, 2009

uat_testing User acceptance testing is one of the many flavours of testing that has emerged over the last twenty years or so. As the software development life cycle has become more sophisticated and rigorous (or, in the case of agile, more lightweight), the testing phase has been broken down into many different aspects and styles of testing.

This article explains user acceptance testing from the business analyst’s perspective. It will describe the history, how it fits into the project life cycle, the objectives of UAT and how the business analyst can be involved.

History

User acceptance testing has emerged as more user involvement is both expected and required. User means the business or subject matter experts (SME’s) or, usually, the actual end user of the product rather than the manager who may have been more involved in the project.

The business expects to accept the product rather than simply assuming the final product will be fit for purpose. This additional involvement is reflected in the software life cycle in all stages prior to user acceptance testing with a particular focus during the analysis phase when the requirements are agreed.

The benefit is that there are no surprises when the product is released and any surprises can be addressed before the product is released to the wider user community. The downside is greater involvement of user time but this can be managed and the benefits offset the disadvantages.

Project Context

V model The V model is a common representation of the project life cycle. It should be read at the start of the V (top left) with user requirements, follow the V down to code and back up to Acceptance testing (top right). Acceptance testing can be seen to have a direct correspondence with the user requirements which should inform the structure and content of the user acceptance tests.

Objectives

UAT’s prime purpose is to demonstrate that the system is fit for use in the business. It is not the same as system testing which should prove (within time and resource constraints) that the system behaves in the way that was described in the requirements specification.

UAT is, to some degree, a public relations exercise as end users tend to be involved as well as stakeholders and they will (hopefully) gain some confidence in the quality of the system, understand how to use it and, very importantly, start to see its benefits.

There are many other forms of testing which, for example, prove the code works as designed at a fine grained level (unit testing) or prove the various systems interact as expected (integration testing).

Business analyst’s role

The business analyst will be involved in UAT to a degree, depending on the project.

At a minimum, he/she will provide guidance to system behaviour and identify scenarios which would be suitable to test. They may be requested to review the test scripts and objectives and, in some cases, may actually coordinate and manage the execution of the user acceptance testing.

The business analyst should do no more than co-ordination as it is critical that the business has ownership of the tests and, hence, believe that passing business acceptance testing genuinely means the product is fit for purpose.

This will depend on the company culture, the specific project and whether there are any resourcing issues.

Planning

Some time should be invested in selecting appropriate scenarios for inclusion as it will not be possible nor appropriate to test all scenarios. The following should be considered when deciding these scenarios:

existing requirement documentation
critical success factors
CSF’s will not all be provable in UAT as some may only be proven over a period of time
business benefits
Most business benefits will also not be provable as they are likely to involve a cost saving or revenue generation which can only be measured over a period of time
typical scenarios
Normal or happy path scenarios should be a central part of UAT
high risk scenarios
Scenarios that are recognised to drive profit, can trigger cost savings or have regulatory impact should be candidates for UAT.

Principles

Although it is not as exhaustive as system testing, it is equally rigorous in what is tested and documented and formal acceptance criteria and process.

Project objectives, business benefits and critical success factors should all be used to help define acceptance criteria

Users and business stakeholders should be involved in decision making and planning throughout UAT. They will become natural ‘champions’ for the new system if they are fully involved and consulted.

It is critical that the business are fully engaged in the planning and design of the user acceptance test and the production of acceptance criteria. This is one of the last hurdles before the product is released into the world and the understanding of the product and problems uncovered at this stage are vital in making the decision to ‘go live’ with the product.

Poor user acceptance testing can cause significant problems for the business.