Lesson 4 of 6
Risk weighting with real volume
9 min
Listen to this lesson
Course sap-tst-302 scores risk as likelihood times impact. Mining improves the impact side with facts: how many cases a variant carries, how much value flows through it, and how many users touch it. It can also sharpen likelihood, by showing which variants use the objects a release changes. This lesson combines the two into a ranked regression scope, without falling into the trap of testing only what is frequent.
Impact from mining
| Impact factor | From mining | From elsewhere |
|---|---|---|
| Volume | Share of cases per variant | None needed |
| Value | Share of net value per variant | Margin from controlling, if needed |
| Reach | Number of customers, plants or users per variant | Business importance of key customers |
| Compliance and finance | Whether the variant ends in a financial posting or a legal output | Dan's list of SOX-relevant controls |
| Time sensitivity | Throughput time between steps | Customer service levels |
Mining supplies most impact factors as measured facts.
Likelihood from the change
Likelihood still comes from change impact analysis: transports, notes, simplification items and configuration changes, as in sap-tst-303. Mining adds a link: if a release changes credit management, every variant with a credit-block activity becomes more likely to break. Tag each variant with the components and apps it uses (from the activity map in lesson 3), and a change list then lights up the variants it touches.
A simple scoring model
| Scenario | Case share | Value share | Touched by release? | Policy floor | Score (1-9) | Depth |
|---|---|---|---|---|---|---|
| O2C-01 standard | 61% | 58% | Yes (pricing note) | No | 9 | Full, automated |
| O2C-03 credit block | 12% | 17% | Yes (credit management) | No | 9 | Full, both outcomes |
| O2C-04 partial delivery | 6% | 9% | No | No | 4 | Smoke |
| O2C-05 complaint and credit | 3% | 2% | No | Yes (financial posting) | 6 | Standard |
| O2C-06 reject before delivery | 3% | 1% | No | No | 2 | Rotate every second release |
| Year-end revenue cut-off | Not in sample | High | No | Yes | 7 | Before each year-end |
Illustrative course data: Contoso's order-to-cash scope for one quarterly release. The policy floor lifts rare but critical paths.
The scale is deliberately coarse. A score of 1 to 3 for impact and 1 to 3 for likelihood gives 1 to 9; volume and value set impact, the change list sets likelihood. Do not let decimals create false precision. What matters is the ranking and the depth decision that follows from it, and that process owners agree with both.
Running the scoring workshop
In Contoso's first usage-based scoping (illustrative course data), the order-to-cash regression set shrank from 96 to 81 test cases while case coverage rose from 71% to 89%. Fifteen dead or duplicate tests were retired, and nine new test cases were added for the credit-block, price-change and partial-delivery paths. The regression window did not get longer; it got more representative.
- Bring to the workshop: the variant list with case and value shares, the change list mapped to activities, last release's defects by scenario, and the current policy floor.
- Decide in the workshop: the score per scenario, the depth, any rotation, and additions to the policy floor.
- Record after the workshop: the signed scope, every override with its reason, and the open risks for the risk register.
The frequency trap
Ranking only by frequency removes exactly the cases that hurt most when they fail: year-end close steps, recalls, intercompany billing to Contoso Parts Distribution (company code 1810), returns of cores, tax-relevant corrections. Some never appear in a twelve-month sample at all; year-end activities appear once. The policy floor fixes this: a short list, owned by Dan and the process owners, of paths that stay in scope regardless of volume.
- Is the path on the policy floor (legal, financial, year-end, safety)?Yes → in scope at its required depth · No → next question
- Does the release touch the objects this path uses?Yes → depth by volume and value · No → next question
- Is it in the top variants by volume or value?Yes → keep a smoke test · No → rotate or retire, with the owner's agreement
What would you do?
For a small support-pack release, Priya's team is short of time. The mining-based ranking would drop intercompany billing to company code 1810, which has under 1% of cases and is not touched by any transport. Dan objects. What is the right outcome?
- Mining measures impact: volume, value, reach and time.
- Change impact analysis supplies likelihood; tag variants with the objects they use.
- Keep the scale coarse and agree it with process owners.
- A policy floor keeps rare but critical paths in scope.
Check your understanding · not graded
Lesson check
1. Which part of the risk score does mining mainly improve?
2. What is the policy floor?
3. Why keep the scoring scale coarse?
4. How does a change list connect to variants?