Lesson 4 of 5
Partners and contracts
10 min
Listen to this lesson
Most SAP programs are delivered by a customer team and one or more partners: a system integrator for the implementation, perhaps a separate partner for testing or data, and under RISE, SAP itself for the technical platform. Each party has a view of what "testing" means. If the contract and the test strategy do not line up, gaps open between them, and defects fall through.
Who typically does what
| Area | System integrator (typical) | Customer (typical) | SAP under RISE (typical) |
|---|---|---|---|
| Unit and string testing | Executes and evidences | Reviews samples | Not involved |
| System integration testing | Executes with customer participation | Process leads review; business testers join | Not involved |
| User acceptance testing | Supports, fixes defects | Owns, executes, accepts | Not involved |
| Technical upgrade and platform | Supports functional retest | Plans and tests business impact | Performs the technical upgrade |
| Test strategy and exit criteria | Drafts | Approves and owns | Not involved |
SAP's own learning material on Private Edition upgrades states the principle for the platform clearly: under RISE, SAP performs the technical upgrade, while planning, preparation, testing and other non-technical activities are the responsibility of the customer or an implementation partner. Make sure your contracts say who that partner is and what they deliver.
Make test deliverables explicit
A statement of work that says "the partner will perform testing" is not a test deliverable. Agree, in writing, what each deliverable contains and how it is accepted:
| Deliverable | What acceptance looks like |
|---|---|
| Test strategy | Approved by the customer test lead and PMO lead; covers scope, levels, environments, data, tools, defect process and criteria |
| Test cases | Reviewed by the process test lead; traced to requirements; executable by someone who did not write them |
| Test execution evidence | Stored in the agreed tool, with tester, date, system and client, expected vs actual, and linked defects |
| Defect resolution | Within agreed response and fix times by severity; retested by the reporter or an independent tester |
| Cycle exit report | Results against exit criteria, open defects with owners, residual risks, recommendation |
Test deliverables with acceptance criteria. Put these in the statement of work or a test schedule to it.
Independence and trust
A partner that configures a process and also declares it tested is marking its own homework. That does not mean the partner is untrustworthy; it means the customer needs independent evidence before signing. Practical controls include customer review of a sample of SIT evidence, business testers participating in SIT for critical processes, retests confirmed by the original reporter, and the customer owning the exit decision.
Entry criteria, defect times and handovers
Three contract details prevent most partner disputes. First, entry criteria for each cycle: what the partner must hand over (unit-tested build, transports imported, test data loaded, test cases reviewed) before the customer commits business testers. Second, defect response and fix times by severity, measured from the shared defect record, so that "we are working on it" has a clock. Third, a handover at the end of the program: test cases, automated scripts, data recipes and known issues transferred to whoever runs regression after go-live. Without that handover, the customer pays to rebuild its regression pack at the first upgrade.
- Before each cycleEntry handoverUnit-tested build, transports imported, data loaded, test cases reviewed before business testers commit
- During each cycleDefect clockResponse and fix times by severity measured from the shared defect record
- End of each cycleExit reportResults against criteria, open defects with owners, recommendation
- End of programRegression handoverTest cases, automated scripts, data recipes and known issues passed to the post-go-live team
Handling partner performance
When partner testing falls short (thin evidence, late defect fixes, optimistic status), address it with data and the contract, early. Show the specific gaps against agreed acceptance criteria, agree a correction plan with dates, and escalate through program governance if it does not improve. Avoid quietly redoing the partner's work with customer staff: it hides the problem, burns your business testers and weakens your position later.
- MeasureSample evidence; Priya finds 7 of 20 passed tests with no evidence
- Show the gapCompare findings with the agreed acceptance criteria in the statement of work
- Agree a correction planActions and dates owned by the integrator
- TrackCheck progress in the shared tool, not in status slides
- EscalateTo program governance through Grace if it does not improve
What would you do?
Contoso's integrator reports SIT cycle 1 as "95% passed." Priya samples 20 passed tests and finds that 7 have no evidence beyond a status. What should she do?
- Write the test split between integrator, customer and SAP into contracts and the test strategy.
- Define each test deliverable with its acceptance criteria, not just "testing."
- Keep independence: the customer reviews evidence and owns the exit decision.
- Handle partner shortfalls early, with data, the contract and governance, not by quietly redoing work.
Check your understanding · not graded
Lesson check
1. Under RISE with SAP, who typically performs the technical upgrade of a Private Edition system?
2. Who should own UAT?
3. What makes a test deliverable contractually useful?
4. Why record partner SIT execution in the customer's test tool?