Lesson 2 of 5
Test estimation
10 min
A good test estimate is built from drivers: things you can count or measure, multiplied by rates you can defend, plus explicit allowances for the work that rework creates. This lesson builds one for Contoso's system integration test (SIT) step by step, and shows which estimation technique to use when.
Start from scope you can count
In an SAP S/4HANA program the natural unit of test scope is the solution process and the test cases linked to it. If your program uses SAP Cloud ALM, test cases in Test Preparation are assigned to solution processes and grouped into test plans, so you can count scope by process, by test level and by complexity rather than guessing. Classify each test case as simple, medium or complex using a short written rule, for example by number of steps, number of roles and number of systems touched.
- ScopeSolution processes in scope for this test level
- Test casesCounted and classified simple, medium, complex
- First-pass executionCases × hours per complexity class
- Rework allowanceRetest of failures plus regression per fix drop
- Preparation and proofTest data, case updates, evidence, triage meetings
- CalendarHours ÷ people × productive hours per day, plus contingency
A worked example: Contoso SIT
Priya, Contoso's test lead, counts 180 end-to-end SIT test cases: 60 simple, 80 medium and 40 complex. She times a pilot of ten cases in a sprint demo environment to calibrate the hourly rates instead of taking them from a textbook. She then adds rework and preparation as percentages taken from Contoso's last major release, adjusted for a bigger change.
| Component | Driver | Hours |
|---|---|---|
| Simple cases | 60 × 1.5 h | 90 |
| Medium cases | 80 × 3 h | 240 |
| Complex cases | 40 × 6 h | 240 |
| First-pass execution | Subtotal | 570 |
| Retest | 25% of cases fail first time | 145 |
| Regression | 2 fix drops × 10% of execution | 115 |
| Preparation | Test data and case updates, 30% of execution | 170 |
| Defect management | Logging, triage, status, 10% of execution | 55 |
| Total before contingency | 1,055 |
Contoso SIT estimate. The rework and preparation lines nearly double the first-pass number.
The original plan allowed about 600 hours for SIT, close to the first-pass figure alone. The gap is not padding; every extra line has a driver and a source. When a steering committee member asks why testing needs so much time, Priya can point at the retest rate and ask which number they think is wrong.
Cycles, not blocks
Plan SIT as cycles, each with its own entry criteria, scope and retest window. A common pattern is a first cycle on core flows within each area, a second cycle on full end-to-end processes with interfaces, output and authorizations, and a short final cycle for regression and retest of fixes. UAT is usually one formal cycle plus a retest window. Every cycle boundary is a point where the estimate can be checked against what really happened.
- Weeks 1–3SIT cycle 1Core flows per area; most defects are found here
- Week 4Fix and retest windowFix drop 1; retest failures; regression of touched processes
- Weeks 5–7SIT cycle 2Full end-to-end with interfaces, output and roles
- Week 8SIT cycle 3Fix drop 2; regression; exit criteria checked
- Weeks 9–11UATBusiness acceptance with key users; retest window in week 11
Choosing an estimation technique
The ISTQB Foundation Level syllabus (version 4.0) describes four estimation techniques. Use them together: a metrics-based estimate checked by expert judgment is more credible than either alone.
| Technique | How it works | Best when | Watch out for |
|---|---|---|---|
| Ratio-based | Uses a known ratio, for example test effort to build effort, from past work | You have history from similar SAP releases | Ratios from a different kind of project |
| Extrapolation | Measures early actuals and projects the rest | After a pilot or the first cycle | Early cycles are rarely representative of later ones |
| Wideband Delphi | Experts estimate alone, discuss differences, re-estimate until they converge | Little history; complex scope | Group pressure; one dominant voice |
| Three-point | Optimistic, most likely and pessimistic values combined, often as (O + 4M + P) ÷ 6 | You want a range, not a single number | Pessimistic values that are not really pessimistic |
For Contoso, Priya used a ratio from the last release as a sanity check, the pilot for rates, and a three-point estimate for the retest rate, the most uncertain driver: optimistic 15%, most likely 25%, pessimistic 45%. The weighted value is about 27%, and the spread tells Grace how much contingency the retest assumption alone needs.
- Estimate from drivers: counted scope, calibrated rates and explicit rework allowances.
- Retest, regression, preparation and defect management can nearly double first-pass execution.
- Plan testing in cycles with retest windows; each cycle boundary is a checkpoint for the estimate.
- Combine techniques: ratio or extrapolation from data, Wideband Delphi or three-point for uncertain drivers.
Check your understanding · not graded
Lesson check
1. What is the most defensible unit for counting SAP test scope?
2. In three-point estimation, what does the common weighted formula (O + 4M + P) ÷ 6 give you?
3. Why plan SIT as cycles rather than one block of weeks?
4. When is extrapolation most useful?