Lesson 1 of 6
Sourcing models
8 min
Listen to this lesson
Very few SAP testing centers of excellence are staffed only by employees. Peaks such as a feature pack stack update or an acquisition need more people than any company keeps on payroll, automation needs scarce skills, and offshore delivery centers offer capacity at lower rates. The question is not whether to use partners but how: which work to source, under what kind of contract, and how to keep the capability the company's own. The course on leading test teams (sap-tst-310) covered partners on a project, mainly the system integrator's test deliverables. This course covers the permanent arrangement behind a TCoE.
It is worth knowing that ISTQB's Advanced Test Management syllabus (CTAL-TM v3.0, 2024) removed the section on distributed, outsourced and insourced testing that its 2012 predecessor contained. Sourcing has not become less important; the syllabus simply no longer covers it. A TCoE therefore needs its own playbook for it, and this course provides one.
Four models
| Model | What the customer buys | Who directs the work | How it is priced | Main risk |
|---|---|---|---|---|
| Staff augmentation | Skilled people for a period | The customer | Time and materials (day rates) | The customer carries all delivery risk and pays for effort, not results |
| Capacity call-off | Pre-agreed people and rates, available on notice | The customer | Day rates with a notice period and minimums | Call-off staff arrive without context unless the same people return |
| Managed testing service | Defined services delivered to service levels | The partner, within the customer's standards | Per service unit or a fixed monthly fee | Volume-based units can reward activity; the customer can lose know-how |
| Outcome-based | Business outcomes, such as fewer escapes or faster cycles | The partner, with shared governance | Part of the fee tied to outcomes, with risk and reward | Outcomes depend on things the partner does not control; needs mature measurement |
The main sourcing models for SAP testing. Most TCoEs combine two or three.
Match the model to the service
Choose a model per service, not per partner. The TCoE service catalog (sap-tst-401) already separates core services from demand services. Some of them suit a managed service with clear service levels; others need business judgment and stay in-house; peaks need flexible capacity.
Contoso's choice
Contoso's core TCoE of five stays in-house, together with the business test network of twelve named key users, as the business case in sap-tcoe-401 set out. Around it, Priya proposed three sourcing arrangements, approved by the quality council:
- A managed regression and automation service from a testing partner: execution of the regression pack, maintenance of automated tests after each release, and first-level triage of failures. An onshore service lead works in Detroit; the delivery team works from the partner's offshore center in India.
- A capacity call-off for peaks such as the feature pack stack updates and the Wave 2 roll-out for company code 1910, with named people who return each time and a four-week notice period.
- A small outcome-based component in the managed service: 10% of the monthly fee at risk against escapes attributable to regression scope and against automation stability, with earn-back. It starts in year 2, once the measures in sap-tcoe-406 have a year of reliable history.
Why not go fully outcome-based? Because most drivers of Contoso's escaped defects are not in the partner's hands: the volume and quality of changes, the regression scope Luis accepts, the data and environments the TCoE provides. An outcome contract that ignores this either pays the partner for luck or penalizes it for Contoso's decisions. A small, well-defined at-risk share aligns interests without pretending the partner controls everything.
What would you do?
A partner offers Contoso a fully outcome-based contract: a 40% bonus if escaped defects fall by half, a 40% penalty if they rise. Contoso has six months of incident data, not yet reliably linked to releases. What should Priya recommend?
- Use partners deliberately: staff augmentation, capacity call-off, managed service and outcome-based models each fit different services.
- Choose the model per service; work needing business judgment or sign-off stays in-house.
- Accountability and control move together; a managed service needs room to decide how to deliver.
- Add outcome-based terms only when outcomes are measured reliably and the partner can influence them.
Check your understanding · not graded
Lesson check
1. In which model does the customer carry most of the delivery risk?
2. Why choose a sourcing model per service rather than per partner?
3. What changed about outsourcing in ISTQB's CTAL-TM v3.0?
4. Why did Contoso keep the outcome-based share small?