Lesson 4 of 6
Restoring control of test and defect flow
11 min
A new baseline is a promise. Keeping it requires the delivery engine to work: builds that are stable enough to test, defects that move from report to fix to retest without waiting, environments that are available and in step, and transports that move in a controlled order. Most troubled SAP programs have lost control of at least one of these. This lesson shows how to get it back.
Make the flow visible
Picture each defect as a work item flowing through stages. Delays happen in the queues between stages, not in the stages themselves: a defect waits for triage, waits for a developer, waits for a transport, waits for a tester. Measure how long items wait in each stage, and you find where the program loses time.
- LoggedTester raises defect with steps and evidence
- TriagedPriority and owner set within one working day
- In fixDeveloper or consultant works the defect
- Ready to transportFix unit tested; transport released
- In test systemTransport imported in the agreed slot
- Retested and closedTester confirms; regression of neighbours run
Stabilize triage
Daily triage, short and decisive, is the heartbeat of recovery. Each new defect gets a priority by business impact, an owner and a target date within one working day. The process owner or a delegate attends, so that "is this a defect or a change?" is decided on the spot rather than debated for a week. In the what-if, Contoso's triage had become a weekly meeting of 30 people; Grace replaced it with a 30-minute daily session per area with five people who could decide.
Limit work in progress
When everything is in progress, nothing finishes. Limit how many defects each fixer works at once, and how many test cases each tester has open. Finish and retest before starting new work. This feels slower for a week and then becomes much faster, because work stops waiting in queues and context switching falls.
Protect the test environment
- Transport discipline. Import fixes to the test system in agreed slots, for example twice a day, with a list of what is coming, so testers know which build they test.
- Stable test data. Agree which data each cycle uses and protect it from being consumed or changed by other teams.
- Availability. Track test system downtime as a metric; a day lost to an outage is a day of SIT lost.
- Freeze before key cycles. Hold non-critical changes out of the test system during the final SIT cycle and UAT.
| Measure | Before recovery (what-if) | Target | After four weeks |
|---|---|---|---|
| Defect triage time | 6 days average | 1 working day | 0.8 days |
| Defects waiting for transport | 45 | Under 10 | 8 |
| Reopen rate | 22% | Under 10% | 9% |
| Test system downtime | 3 days in the last month | Under 4 hours a week | 2 hours a week |
| Arrival vs closure per week | 40 in, 25 closed | Closure above arrival | 30 in, 38 closed |
Flow measures in the what-if before and after recovery actions.
Root causes, not just fixes
Group defects by root cause every week: unclear requirement, configuration error, development error, data, test case wrong, environment. A cluster tells you what to fix upstream. If a third of defects come from unclear requirements, more developers will not help; a short design clarification with the process owner will. In the what-if, many order-to-cash defects traced back to pricing conditions changed directly in the test system without a transport, so the fix was a process rule, not a code change.
- Is the defect arrival rate above closure for two weeks running?Yes → check fix capacity and triage speed · No → keep monitoring
- Is the main root cause upstream (requirements, design)?Yes → fix the source with process owners · No → next question
- Is time lost waiting rather than working?Yes → shorten queues: daily triage, transport slots, WIP limits · No → add targeted fix capacity
What would you do?
The defect backlog is rising. The integrator offers ten more developers starting next week. Flow data shows that defects spend most of their time waiting for triage and for transports. What should Grace do?
- Recovery depends on a working delivery engine: stable builds, fast defect flow, reliable environments.
- Measure waits between defect stages; time is lost in queues.
- Run short, decisive daily triage, limit work in progress and import transports in fixed slots.
- Analyze root causes weekly and fix upstream sources before adding people.
Check your understanding · not graded
Lesson check
1. Where is time usually lost in defect flow?
2. Why limit work in progress for fixers and testers?
3. A third of defects come from unclear requirements. What is the best response?
4. What is the purpose of fixed transport slots into the test system?