SCP expertise / Tools and techniques
Prove the change against criteria agreed with the business.
Testing strategy / Phases and readiness
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.
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.
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.
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.
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.
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.
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.
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.
Plan OAT alongside SIT and UAT where dependencies and a suitable environment allow; it is not simply a final step after UAT. Combine business acceptance, operational acceptance and the remaining readiness evidence at the go/no-go decision.
Performance and other non-functional testing: response times, throughput, concurrent-user load, peak demand, endurance and recovery behaviour need measurable targets and representative workloads. Performance testing is a test type that can span system testing, SIT and operational readiness; it is not a synonym for OAT. Agree specialist ownership and environment requirements early.
Illustrative plan: component checks → ST / agreed PAT → SIT → UAT → cutover and go live. OAT and relevant non-functional tests run in parallel when ready, with their exit criteria feeding the same release decision. The exact overlap and gates are agreed in the delivery plan.
Projects and programmes use decision gates between phases and sub-phases. Entry criteria define what must be ready before work starts; exit criteria define the evidence and conditions required to complete that phase. These apply across discovery, design, build, testing and deployment, as well as between testing phases such as PAT, SIT and UAT.
Agree the criteria, measures, evidence owners and approval authority in advance. Completing one phase does not automatically make the next phase ready: check its entry criteria separately. Phases may overlap where the agreed scope, dependencies and risks allow.
Illustrative thresholds, not a universal rule: 95% is an example to agree for each project. Execution coverage and pass rate are different measures and should both be reported against a controlled test scope. A headline percentage cannot override a failed critical process, a blocking defect or a mandatory control. Priority and severity should be defined separately, including which defects block progression.
Record the gate decision: proceed, proceed with explicitly authorised conditions, or do not proceed. Any permitted exception needs a recorded rationale, risk acceptance, accountable owner and follow-up date. UAT exit approval does not itself authorise deployment: cutover, operational readiness and the next phase's entry criteria still need approval.
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.
Requirements through to acceptance
We would describe user needs through requirements, user stories and use cases, then agree acceptance criteria. A test plan links those requirements to scenarios, expected results and evidence. Testing may cover functionality, system handovers, data, performance and failure paths according to the change.
User acceptance testing (UAT) allows appropriate business users to assess the solution against agreed needs. A pilot examines performance in a bounded operating setting. The two activities complement each other. Test results, defects, pilot outcomes and any remaining risks inform the authorised rollout decision.
Example: a planner can identify an order at risk, understand its cause and carry out only the actions their role permits. The acceptance criteria and tests should cover the normal case, missing information and restricted actions.
UAT evidence supports the decision; it does not replace acceptance criteria. A pilot also checks performance in a bounded operating setting.
Open a technique for when to use it, its output and related service links.
Which controllable changes affect the outcome?
Designed trial and analysis.
Plan a controlled trial when several factors may influence the result.
How might queues, variability or disruption change the result?
Scenario results with assumptions.
Explore queues, variability or disruption before committing to a change.
When evidence must show that a change meets its requirements.
Traceable test cases, expected results, responsibilities and defect records.
Link each requirement to tests, covering integration, data quality and performance where relevant.
When business users need to judge whether a solution meets their needs.
Recorded user test outcomes and an authorised acceptance decision.
Ask planners to execute agreed order-exception scenarios and record issues before release.
Explore how these techniques could support your operation, with the scope and depth agreed around your needs.