Lesson 5 of 6
Operational acceptance testing
17 min
Listen to this lesson
Operational acceptance testing (OAT) asks a different question from every other test: can the people who will run this system keep it running and bring it back when it fails? It covers backup and restore, high availability and disaster recovery, monitoring and alerting, job operations, and the runbooks people will follow at 03:00. If OAT is skipped, the first real test of recovery happens during an outage.
Who does what under RISE
Contoso's S/4HANA runs as Private Edition under RISE with SAP, so SAP operates much of the infrastructure and database layer. Which backups, high-availability setups, disaster recovery options and monitoring are included, and which tasks stay with Contoso, is defined in the contract and its roles-and-responsibilities documentation. Read it with Sam before writing the OAT plan. Where SAP performs an activity, Contoso's OAT shifts from "do it" to "request it, witness it, and prove our side works": users reconnecting, interfaces resuming, jobs restarting and business checks passing.
The OAT catalog
| Test | What proves success |
|---|---|
| Backup and restore | A restore to a point in time succeeds within the agreed time; business data and interfaces check out afterwards |
| Database failover (takeover) | The secondary takes over, clients reconnect, open work is handled as designed, within the recovery time objective |
| Failback | The former primary is reintegrated as secondary and replication is back in sync |
| Disaster recovery | The system runs from the recovery site; data loss is within the recovery point objective |
| Monitoring and alerts | Each critical alert fires, reaches the right team and has a runbook entry |
| Job and interface restart | Operators restart a failed chain from the runbook without developer help |
| Housekeeping | Log, spool and job cleanup jobs run; storage growth is within plan |
An OAT catalog for Contoso. Targets such as recovery time and recovery point objectives come from the business continuity requirements.
SAP HANA system replication is a common high-availability mechanism. SAP Learning describes the takeover decision (can a takeover reduce downtime, and can data loss be ruled out?), the takeover itself, which can be run from administration tools or the command line, a "takeover with handshake" for planned switches while the primary still runs, and how clients reach the new primary through IP or DNS redirection. After a takeover, the former primary is registered as the new secondary. A failover test should record each of these steps and the business checks that follow.
- AnnounceAgree window, scope and rollback; inform users and partners
- BaselineRecord open orders, a test posting and interface queues
- TriggerPlanned takeover or simulated failure, as agreed with the operator
- MeasureTime until users can log on and interfaces resume
- VerifyBusiness checks by Maria and Dan; compare with the baseline
- Fail backReturn to the normal configuration and confirm replication in sync
What would you do?
Grace asks whether Contoso can skip the failover test because "SAP runs the infrastructure under RISE." What should Priya answer?
- OAT proves the system can be operated, monitored, backed up, restored and failed over by the people who will run it.
- Under RISE, read the contract's responsibilities; where SAP performs a task, Contoso requests, witnesses and verifies its own side.
- Test restore and takeover end to end with timings and business checks, plus failback.
- Alerts, job restarts and runbooks are part of OAT, not afterthoughts.
Check your understanding · not graded
Lesson check
1. Which test belongs in operational acceptance testing?
2. After a takeover, what happens to the former primary when it returns?
3. Under RISE, what remains Contoso's to prove in a failover test?