CAT - Customer Acceptance Testing

Acceptance Testing is often seen as marking the change in a system’s ownership from the developers of the system to those who will use the system.It is a distinct phase of testing prior to final sign-off and delivery of a system to the customers or business users.The responsibility for acceptance testing may reside with the customer (CAT - Customer Acceptance Testing) and/or end users (UAT) themselves.
The primary objectives of preceding test phases (unit, integration and systems testing) are those of defect identification and ensuring that each step in the process of building the software delivers working products (verification).
The objective of Acceptance Testing is to give confidence that the software being developed, or changed, satisfies the specified requirements, meets customer/user expectations and is fit for business purpose (validation). Unlike the other test phases, an objective of acceptance testing is not to actively look for faults. The expectation should be that the preceding stages of testing have identified and resolved software faults and that the system is ready for operational use.
Clear entry criteria may need to be put in place to ensure that the expectation of a system being ‘production ready’ has been met.This is an opportunity to review the effectiveness, completeness and outcome of previous test phases and to declare any known problems that remain prior to acceptance test commencing.
As a testing phase with it’s own objectives, acceptance should not seek to duplicate other test phases.However, it may repeat previously run test scenarios to provide confidence that preceding test phases have been completed as appropriate. Those responsible for acceptance testing should dictate the objectives and coverage of the test phase. In doing so they are likely to consider the following:

• Have the acceptance test conditions been demonstrated?
  
• Do the test conditions model realistic business scenarios?
  
• Is there appropriate coverage of each business function?
• Is there appropriate coverage of system reports and screen?
  
• Is there appropriate coverage of application menu options?
• Are updated training materials and system documentation subject to test?

It is important to minimise the number of changes taking place to the system during the acceptance test phase.The cost of reworking, to change software or system operation, at this stage of development is high.Implemented changes may invalidate testing that has been already conducted and require greater levels of regression testing to be carried out.
Where faults are uncovered during acceptance, temporary fixes should first be investigated before attempting to make changes to the software.However, it may be necessary to agree the correction of high severity/priority problems and to defer/timetable the correction of others before acceptance can occur.
In order to minimise the risk of software faults and system changes, acceptance should not just start at software delivery. It needs to be a function of the earliest design and development stages. Early involvement of users in the system requirements and design stages can minimise the risk of gaps and misinterpretations occurring in end system functionality.The benefits reaped at later stages can be the avoidance of re-work and the reduced cost of system delivery.