QA glossary
What is operational acceptance testing (OAT)?
Operational acceptance testing (OAT) checks that a system can be run, supported and recovered in production, not just that its features work. It covers backups, restores, failover, monitoring, upgrades and support procedures, and it is usually carried out by the operations team that will run the system.
An example from QA practice
A new booking platform has passed user acceptance testing. Before go-live, the operations team runs its checklist: restore last night's backup to a clean server and confirm the bookings are all there, switch the database to the standby and time how long bookings are unavailable, apply a patch using the written upgrade procedure, and check that an alert reaches the on-call engineer when the payment service stops. The restore works but takes four hours against a promised one, so go-live waits.
Where it sits
- One form of acceptance testing: the ISTQB Foundation Level syllabus (CTFL v4.0.1, section 2.2.1) lists it with user, contractual and regulatory acceptance testing.
- Run by operations: the ISTQB Test Management syllabus (CTAL-TM v3.0, section 1.2.1) describes the operations team as the people who perform it and who ensure the system is ready for production.
- Non-functional by nature: recoverability, performance and maintenance procedures are typical subjects (CTAL-TTA v4.0, sections 4.1 and 4.6.1).
How BetterQA does it
OAT is usually the operations team's job, and we only test, we never build or run the client's infrastructure. So the operations team runs the procedure and we test through it: after a restore or a failover we check that the application still works, the data is all there and the recovery took no longer than promised. Each gap is logged in BugBoard with timings and evidence.