Testing and Business Acceptance

Testing strategy / Phases and readiness

Test the product, the connections and the business outcome.

For a package-led change, SCP would agree a route from component checks through product testing, System Integration Testing (SIT) and User Acceptance Testing (UAT), followed by cutover and go-live readiness. Define each phase’s scope, owner, environment, entry and exit criteria, evidence and approval authority in the test strategy.

Agree the terminology: Product Acceptance Testing (PAT) is used here for the client/provider’s agreed package-level acceptance phase, such as a configured or extended ERP product. Its name and boundary vary between organisations. System Testing (ST) tests the complete application; it is distinct from unit testing. Avoid duplicating ST and PAT where one agreed phase can cover the required objectives.

1. Component / unit and component integration testing

   Developers check individual components and their interactions before broader application testing.

   SCP delivery focus: confirm provider responsibilities and retain relevant results for changed calculations, extensions and internal interfaces.

2. System Testing (ST)

   Test the complete application’s behaviour, including relevant functional and non-functional requirements.

   SCP delivery focus: link application-level scenarios to the functional specification and agreed criteria; record the tested build, configuration and defects.

3. Product Acceptance Testing (PAT)

   For the agreed package scope, demonstrate that configuration and modifications meet the specified product requirements before wider integration testing.

   SCP delivery focus: agree who accepts the package and what evidence is needed. For an ERP change, check configured rules and extensions, including failure and boundary cases, within the package test boundary. Use controlled substitutes for external systems where necessary.

4. System Integration Testing (SIT)

   Test interactions between systems and external services.

   SCP delivery focus: exercise ERP, WMS, transport and other relevant handovers using realistic end-to-end scenarios. Include mappings, timing, missing or duplicate messages, failure recovery and reconciliation. Resolve or explicitly disposition issues before business acceptance testing.

5. User Acceptance Testing (UAT)

   Business users assess whether the solution meets agreed business needs and acceptance criteria.

   SCP delivery focus: business representatives execute realistic work and exceptions, with exploratory challenge as well as planned scenarios. Record results, defects and unmet needs; route changes through change control. UAT is more than trying to break the solution: it establishes whether people can perform the required work.

6. Operational Acceptance Testing (OAT)

   Confirm that the service can be operated and supported in the agreed production conditions, with operations and support owners involved.

   SCP delivery focus: demonstrate monitoring and alerts, incident escalation, access administration, backup and restore, recovery or failover, scheduled jobs and support runbooks as relevant. Record operational acceptance against agreed service criteria.

7. Cutover readiness, go live and early-life support

   Use an authorised readiness decision to move from an accepted solution to production operation.

   SCP delivery focus: rehearse migration and reconciliation, confirm access, training, support, monitoring, rollback or recovery arrangements, owners and communications. Record the go/no-go decision, conditions and outstanding risks; verify production operation after release.

Testing terminology in plain English

Unit / component testing

Checks an individual piece of the application.

ST — System Testing

Checks the complete application or product.

PAT — Product Acceptance Testing

The agreed package-level acceptance scope; define this local term with the client and provider.

SIT — System Integration Testing

Checks the handovers and interactions between systems.

UAT — User Acceptance Testing

Business users assess fitness for agreed business needs.

OAT — Operational Acceptance Testing

Operations and support teams assess readiness to run and support the service.

Non-functional testing

Checks quality characteristics such as performance, reliability, security and accessibility.

Regression testing

Checks that a change has not adversely affected other behaviour.

Cutover

The controlled transition of systems, data and people into production operation.

Make the handover between phases explicit

For an SCP engagement, a readiness record would identify the version and scope tested, requirements and acceptance criteria covered, results, open defects, residual risks, accountable owner and decision. Agree severity thresholds and blocking conditions before execution. Passing PAT does not prove cross-system integration; passing SIT does not constitute business acceptance; UAT approval does not by itself authorise go live.

The sequence is a planning view, not a requirement to wait until late in delivery to involve users. Prepare criteria and test cases early. Agile and hybrid teams can repeat the relevant levels for each increment, with risk-based regression testing after changes. Performance, security, accessibility, data migration and operational readiness checks should be planned at suitable levels, rather than left entirely to UAT.

Test-level terminology: ISTQB Foundation Level syllabus v4.0.1, section 2.2 ↗. The PAT boundary, package-led sequence, delivery examples and readiness controls above describe SCP’s proposed application, to be agreed for each engagement.