User Acceptance Tests (notes)

Email Notifications

SHARE
Request to reuse this

This article is a compilation of notes on acceptance testing in my region.

Acceptance tests are conducted when a system or deliverable is defined as ready for acceptance. How a deliverable is determined as ready or complete is a matter for agreement between the project owner i.e. customer and the project team aka supplier. Generally the completeness of a deliverable should cover all aspects of contracted requirements. People's expectations in particular and specified granularity on requirement details for quality matters, can influence and change what will ultimately constitute the completeness of a project deliverable.

Acceptance tests are conducted in the presence of the customer, typically after the customer has agreed to take over a deliverable.

Testing considers the location and are conducted at both the following (always for large projects):

• Staging site which may be at the Factory where a system or product is created, or at a location where the system or product is setup prior to delivery to the customer's site.
• Actual site where the project is deployed

In brief, the following are performed leading to the actual test (see test categories):

1. Agreeing on what will constitute acceptance testing for that test category - especially if not already specified or detailed.
2. Document test - review test procedures and walkthrough the steps, a dry run to test a deliverable, system or product.
3. Preliminary test - a real test conducted with or without the presence of the customer to validate the tests and readiness for acceptance testing. This will be the last save-face stage or opportunity where flaws are affirmed and finally rectified.
4. Conduct actual or final test e.g. Site Acceptance Tests

The different test categories in sequence:

1. Factory Acceptance Tests - this exclude testing at subcontractors', suppliers' as they are not known to your customer
2. Site Acceptance Tests - that whatever delivered from Factory are as-is. Functional tests may be conducted separately. 
3. Site Security Acceptance Tests or Systems Security Acceptance Tests - may involve separate tests such as physical security, checks on personnel, and cyber security.
4. Reliability Acceptance Tests - this exclude the warranty period
5. Audits by independent internal and-or external parties - this exclude any visit by the authorities

The number of tests can easily double when we factor in requirement for preliminary testing (the exception being the reliability test itself and audits - we can't tell auditors what to do). And yes, there will be corrections in every test category.

Upon completion of each test from the category list above - at the least, will incur the following activities:

1. Review test results
2. Ratify test results
3. Massage the customer to Accept test results

Note that acceptance tests may be conducted:

• Before handling over and taking over (HOTO) the deliverable
• Throughout the HOTO process 
• After HOTO of a deliverable!
• Or in any manner as agreed between the customer and supplier.

A best practice approach to acceptance testing:

• Let the domain experts determine and decide on what to test for acceptance of deliverables.
• Corroborate testing with what was contracted.
• Seek the agreement and approval of all stakeholders especially the customer on the tests. The exception being - perhaps if you are the empowered authority or auditor who can barge in to test for compliance.

Read also User Acceptance Tests (documentation issues)

* I'll keep this as a live document. Hmm ..