Lesson 4 of 5
Building the scoped list
11 min
Listen to this lesson
You now have two streams of evidence: object impact from transports and notes (lesson 2) and behavior impact from SAP release information (lesson 3). The third ingredient is risk, from the risk-based testing course. This lesson combines them into a scoped regression list that names every process in scope, how deeply it will be tested, and why, and also names what was left out and why.
Start from a baseline, not from zero
Every release should run a small, stable baseline regression: the critical end-to-end flows that must work no matter what changed. At Contoso these are sell-from-stock order to cash for CMC-ALT-100 in sales area 1710 / 10 / 00, procure to pay for CMC-RTR-200 from Lakeside Components, the payment run, and a period-end close check for company code 1710. The baseline is ideally automated and protects against the unknown unknowns of lesson 5. Impact analysis then adds targeted tests on top.
Combining the evidence
For each candidate process step, record the evidence and decide. The rules below keep decisions consistent:
- Changed object or behavior reaches the step and the step is used in production: in scope, depth by risk.
- Changed object reaches the step but it is not used: out of scope after owner confirmation that it is not a periodic or emergency function.
- Step not reached by change but critical: covered by the baseline.
- Step not reached and not critical: out of scope, reason "no change, low risk".
- Uncertain: in scope until someone with knowledge can rule it out. Uncertainty is not a reason to exclude.
- Is it uncertain whether change reaches the step?Yes → in scope until someone with knowledge rules it out · No → next question
- Does a changed object or behavior reach the step?Yes → next question · No → baseline if critical, otherwise out with reason "no change, low risk"
- Is the step used in production?Yes → in scope, depth by risk · No → out after the owner confirms it is not periodic or emergency
| Process step | Evidence | Decision | Depth | Rationale |
|---|---|---|---|---|
| O2C: price fleet order | Rebate routine changed; condition records loaded; every fleet order | In | High | Revenue and customer invoices; risk R-03 high |
| O2C: delivery note output | Form changed; daily at 1710 and 1720 | In | Medium | Customer-facing; both shipping points |
| P2P: supplier invoice | Tolerance key changed; daily | In | High | Payment blocks and GR/IR; risk R-11 |
| Inventory: stock aging report | Layout changed; not executed in 6 months; Maria confirmed | Out | – | Unused; owner confirmed, smoke test only |
| R2R: asset depreciation | No change reaches it | Baseline only | Baseline | Covered by period-end baseline check |
| Intercompany billing | Note changes a shared billing class; usage unknown | In | Medium | Uncertain; included until ruled out |
Extract from Contoso's R2 scoped list. Every row has a decision and a reason.
Writing rationale that survives review
Each row needs a rationale an auditor, a steering committee or the next test lead can understand. Good rationale names the evidence: "changed tolerance key; used daily; high risk". Weak rationale names a feeling: "probably fine". Exclusions matter most, because they are where post-release incidents come from. If a production incident ever arises in an excluded area, the rationale shows whether the decision was reasonable with the evidence available, which is the difference between a learning point and a credibility problem.
Keeping the list current
Late transports and new notes arrive during testing. Run each through the same rules on arrival, add rows, and highlight changes to the list since the last review. A scoped list that stops at the planning date is a snapshot of a release that no longer exists.
What would you do?
Halfway through Contoso's R2 test cycle, a late transport changes the output determination for billing documents. The scoped list was approved last week. What should Priya do?
Measuring the method
Track two numbers across releases. The first is scope ratio: how many test cases ran out of the full regression library. A falling ratio with stable quality means the analysis is doing its job. The second is escapes: production incidents caused by the release, split into those in scoped areas (a test design problem) and those in excluded areas (an analysis problem). If escapes rise in excluded areas, tighten the rules or widen the SME review before shrinking scope further. Reporting both numbers to the change advisory board builds trust in smaller, faster regression cycles.
| Metric | What it shows | Healthy trend | Warning sign and response |
|---|---|---|---|
| Scope ratio | Test cases run out of the full regression library | Falling while quality stays stable | Falling while escapes rise: stop shrinking scope |
| Escapes in scoped areas | Incidents in processes that were tested | Low and stable | Rising: improve test design and depth |
| Escapes in excluded areas | Incidents in processes left out | Near zero | Rising: tighten rules or widen SME review |
- A scoped regression has three layers: baseline, impacted regression and targeted tests for changes.
- Combine object impact, release information and risk with consistent rules.
- Uncertain items stay in scope until someone with knowledge rules them out.
- Every inclusion and exclusion carries an evidence-based rationale; owners confirm the list.
- Keep the list current as late changes arrive.
Check your understanding · not graded
Lesson check
1. What is the purpose of a baseline regression?
2. A changed object reaches a process step that is not used in production. What is the decision?
3. How should uncertain impact be treated?
4. Which rationale is strongest?