Lesson 4 of 6
Running multi-team cycles
8 min
Listen to this lesson
An end-to-end cycle is a relay race. Purchasing hands a purchase order number to the integration team, who hand a message ID to the warehouse, who hand a goods receipt to accounts payable. Every hand-off is also a hand-off between people, often in different locations and time zones. Most lost days in SIT are not caused by defects; they are caused by a baton nobody picked up: a tester who did not know the previous step had finished, a message waiting for a job nobody scheduled, or a key user pulled into a workshop on the day their step was due.
The fix is to plan the run like a schedule, not a list. For each scenario, write the run book: the steps in order, the role and named person for each step, the expected start time, the checkpoint that ends the step and the person who takes over next. Put batch jobs in the schedule too. If invoice creation from the portal depends on an inbound job that runs every 30 minutes in QAS, the accounts payable tester needs to know that. Name one cycle coordinator, usually someone on Priya's team, who watches every chain, chases late hand-offs and owns the cycle channel where each team announces "step done, baton passed." Agree environment rules for the cycle as well: which transports may be imported mid-cycle (usually only fixes for blocking defects, at fixed times), and who must approve a change to shared configuration. A transport imported at 11:00 without warning can turn half the morning's results into noise.
- Day 1, 09:00PurchasingPO for 200 rotors CMC-RTR-200 created; PO number posted to the data sheet.
- Day 1, 10:00Integration teamConfirms outbound IDoc and integration flow completed; message IDs recorded.
- Day 1, 14:00Supplier simulationConfirmation and shipping notification sent from the portal test account.
- Day 2, 09:00Warehouse DetroitGoods receipt into 171A against the inbound delivery.
- Day 2, 13:00Accounts payableInvoice from portal checked, posted, GR/IR reconciled.
- Day 3, 10:00TreasuryPayment run in client 100; clearing and bank file checked.
The shared data sheet
Chained tests need chained data. Step 4 cannot start until step 3's output is known. Keep one shared data sheet per cycle where every step writes its output and the next step reads its input. If you manage tests in SAP Cloud ALM, you can group the test cases of a chain in a test plan, record results per step, and raise defects from a failed step so the link to the test case is kept. Many teams still keep a simple shared sheet alongside for the live document numbers.
- Read inputStep 4 takes inbound delivery 180000412 from the data sheet
- ExecuteWarehouse key user posts the goods receipt
- Record outputMaterial document number written to the sheet
- CheckpointGR/IR posted at the expected value, marked passed
- Hand overAccounts payable notified in the cycle channel
| Column | Example for P2P-01 |
|---|---|
| Scenario and step | SIT2-P2P-01, step 4 goods receipt |
| Input taken from previous step | Inbound delivery 180000412 |
| Output created | Material document 5000012345 |
| Checkpoint status | Passed, GR/IR posted at expected value |
| Executed by and time | Warehouse key user, Day 2 09:40 |
| Next owner notified | Accounts payable, via the cycle channel |
One row per step. Document numbers are illustrative.
Protect the test data. Reserve the master data each scenario uses, such as a dedicated material, supplier or customer, so that two teams do not consume the same stock or clear the same open item. Contoso reserves Lakeside Components and storage location 171A for P2P scenarios in SIT2; ad hoc testing uses 171B. Prepare data the chain needs before the cycle starts, such as stock for the goods issue in O2C-01, open purchase orders for invoice-only tests, and customer credit limits set to the values the credit scenario expects. Check it again on the morning of the run; other tests and overnight jobs change data. When the cycle uses migrated data, record which mock load it came from, because a defect may belong to the migration rather than to the process.
The daily cycle stand-up
- Progress: scenarios planned, started, passed, failed and blocked today.
- Batons in flight: which hand-offs are waiting, on whom, since when.
- Blockers and defects: new high-priority defects, and which scenarios they block.
- Environment and data: transports imported, interfaces up, jobs running, data refreshed.
- Next 24 hours: who runs what, and which retests are due.
When a step is blocked
- Is the blocker in the step itself or upstream?Upstream → localize it first (lesson 5) · In the step → continue below
- Can the step continue with a documented workaround?Yes → continue and record the deviation in the result · No → next question
- Can later steps start from pre-built data?Yes → run downstream steps on a prepared document and mark the chain incomplete · No → next question
- Can other scenarios use the time?Yes → re-sequence the day · No → park the scenario and escalate at the stand-up
What would you do?
SIT cycle 2, Day 1. The supplier portal test account is down, so P2P-01 cannot receive the order confirmation. Accounts payable and treasury are waiting for steps 5 to 7. Cutover manager Luis asks Priya how to keep the cycle on track. What is the best response?
- Write a run book: steps, named owners, timing, batch jobs, checkpoints and hand-overs.
- Keep a shared data sheet so each step reads the previous step's output.
- Reserve master data per scenario so teams do not consume each other's data.
- When blocked, keep downstream steps moving on prepared data, but never report an unproven chain as passed.
Check your understanding · not graded
Lesson check
1. What causes most lost days in a multi-team SIT cycle, according to this lesson?
2. Why reserve master data such as a supplier and storage location per scenario?
3. A downstream step runs on a prepared document because an upstream interface is down. How is the scenario reported?
4. Which item belongs in the daily cycle stand-up?