Lesson 6 of 6
Keeping scope current after each release
10 min
Listen to this lesson
Usage-based scope decays like any other. After go-live it decays faster, because SAP S/4HANA changes how work is done: new Fiori apps, new credit management, new output. The variants in ECC were the right baseline for conversion testing; within months, the variants in SAP S/4HANA are the baseline that matters. This lesson sets up the routine that keeps scope current.
The refresh rhythm
Contoso's rhythm follows its regression calendar. CMR, the masked pre-production copy, is refreshed quarterly before each regression window; the mining refresh runs just before that, so the scope for each window reflects the last quarter of real usage. The regression service level, ten working days in the first year after go-live, leaves no room to rediscover scope during the window itself.
What to compare after each refresh
| Change in usage | What it means | Action |
|---|---|---|
| New variant above threshold | The business does something new, or the system routes cases differently | Investigate; add or extend a scenario |
| Variant share grew sharply | More business flows through a path | Raise its impact score; check depth and automation |
| Variant disappeared | A path is no longer used | Confirm with the owner; retire or rotate its tests |
| New exception or rework loop | Possible defect or training gap in production | Raise with the process owner; consider a regression test |
| Throughput time worsened | Something slows the process | Check whether a release coincided; add a performance check |
Reading drift between two mining periods.
The first months after go-live
Hypercare is the moment the ECC baseline stops being reliable. New apps change the order of steps, some paths disappear by design, and users try workarounds while they learn. Do not re-baseline on the first weeks: hypercare data is full of training noise and corrections. Contoso compares the ECC variants with the first full quarter after hypercare, keeps the ECC-based scope until then, and uses the comparison to decide which conversion-era tests to retire and which new S/4HANA paths to add.
Retiring dead tests safely
- Require two consecutive periods with no cases before retiring, so seasonal paths are not lost.
- Check the policy floor first; floor paths are never retired for low volume.
- Ask the process owner: is the path closed for good, or just quiet?
- Archive the test case with its evidence history instead of deleting it.
- Record the retirement in the release notes of the test set, with the date and owner.
After the conversion, Contoso saw two typical shifts in its order-to-cash variants (illustrative course data). Credit blocks moved from the classic credit check to SAP Credit Management, so the activity names changed, and Maria's credit scenarios had to be remapped, not rewritten. And the share of orders created through EDI from Great Lakes Fleet Services grew, so the inbound IDoc path gained weight in the scope and became a candidate for Ravi's API checks.
- Week -3Mining refreshLast quarter of production usage; same case definition
- Week -2Drift reviewNew, grown and vanished variants with Maria and Dan
- Week -1Scope updateScenario map, scores, retirements in SAP Cloud ALM
- WindowRegression in CMRTen working days in year 1
- ExitCoverage reportPass rate plus case and value coverage in the release pack
Who does what in the routine
| Role | Responsibility |
|---|---|
| Priya, test lead | Owns the routine, the scenario map and the coverage report |
| Maria, O2C key user, and Dan, finance process owner | Review drift, approve scope changes and retirements, own the policy floor |
| Wei, test data and environment lead | Turns new data slices into recipes for CMR; aligns with the quarterly refresh |
| Ravi, automation lead | Re-ranks automation candidates by case share; updates automated coverage |
| Nadia, security and GRC lead | Approves the privacy rules for event data |
| Luis, release manager | Puts the refresh and drift review on the release calendar |
Contoso's responsibilities for keeping usage-based scope current.
Keep the artifacts where the rest of the release lives. The scenario map with variant IDs sits on the test cases in SAP Cloud ALM; the drift review is a short record attached to the release; retirements are visible in the test plan history. A new test lead should be able to see, a year later, why each scenario is in scope and when it entered.
What would you do?
After the third quarterly refresh, a variant "order created, delivery created, delivery deleted, delivery created again" has grown from 0.5% to 4% of cases. No release touched deliveries. What should Priya do?
- Refresh mining on the regression rhythm; after go-live, S/4HANA variants replace the ECC baseline.
- Compare periods for new, grown and vanished variants, rework and throughput changes.
- Retire tests only after two empty periods, outside the policy floor, with the owner's agreement.
- Treat event data as personal data: pseudonymize and limit it.
Check your understanding · not graded
Lesson check
1. When does Contoso refresh its mining data?
2. What is the rule before retiring a dead test?
3. A rework loop grows sharply with no related release. What is it first?
4. Why pseudonymize user names in event logs used for testing?