From risk to test approach

A risk ranking is worthless unless it changes what the team does. This lesson turns risk levels into concrete decisions: which test techniques, how many variants, who reviews, what gets automated, and in what order things run.

Risk changes four things

Depth and techniques: high risks get more rigorous design (boundary values, decision tables, negative tests, more organizational variants); low risks get a smoke test or rely on existing regression.
Independence and review: high-risk tests are reviewed by the process owner before execution, and results are checked by someone other than the tester.
Order: high risks run first, so defects surface while there is still time to fix and retest.
Evidence: high risks need stronger evidence: document flow, journal entries against expected values, not just a success message.

Risk level	Test design	Review	Execution order	Evidence
High	Positive and negative cases; boundary values; all relevant org units and variants; end-to-end incl. finance	Process owner reviews cases; independent result check	First cycle, first week	Document flow plus journal entries vs expected values
Medium	Main positive path plus key variants; integration to the next process step	Key user review	After high risks in the same cycle	Document display and key values
Low	Smoke test or existing automated regression	Peer review	When capacity allows	Execution record

Example mapping from risk level to test approach. Write your own version into the test strategy so it is agreed before execution.

The Sign-Off Table · thesignofftable.com/academy/sap-tst-302

Depth in SAP terms

"More depth" must mean something specific. For Contoso's high-risk billing revenue account risk, depth means testing every relevant combination that drives account determination: domestic and export customers, the alternator and the rotor as products with different account assignment groups, both plants, a credit memo and a cancellation, and a check of the resulting journal entry in each case. For a medium risk such as a changed delivery output, depth might be the main output in both shipping points plus one reprint. For a low risk, a single run in the automated regression pack is enough.

Automation and risk

Automation is not a risk level. It is a way to run checks cheaply and repeatably. The best candidates are high- and medium-risk processes that are stable and run in every release, such as Contoso's standard sell-from-stock order to cash. Brand-new functionality usually changes too often during its first test cycles to automate well, so test it manually first and automate once it settles. SAP's own options include the test automation tool for SAP S/4HANA Cloud Public Edition and eCATT in ABAP-based systems; many programs also use other automation, which this course does not cover.

Execution order

Sequence the first cycle so the riskiest, most integrated scenarios run early. Defects found in week one can be fixed and retested in the same cycle; defects found in the last week usually become open items at sign-off. Dependencies still apply (you cannot test billing before deliveries exist), so plan the high-risk end-to-end chains first and slot lower risks around them.

Week 1High-risk end-to-end chainsBilling revenue account, payment run, GR/IR, intercompany
Week 2Remaining high and medium risksFleet pricing variants, plant 1720 goods issue, output
Week 3Low risks and automated regressionSmoke tests, reports, regression pack
Week 4Retest and re-assessFix confirmation, register update, residual risk summary

A risk-ordered four-week cycle for Contoso release R2.

The Sign-Off Table · thesignofftable.com/academy/sap-tst-302

What would you do?

Two days before cycle 1 starts, Contoso's developer adds a late change to the rebate logic used in fleet pricing, already scored high risk. The planned rebate tests are scheduled for week 3. What should Priya change?

What low risk does not mean

A low score is a decision to test lightly, not a decision to test nothing. Low risks still get at least a smoke test or a run of the existing regression pack, because the score could be wrong and because the cost of a quick check is small. Low risks are also the first thing to cut if time runs short, and the cut should be recorded in the register so it appears in the residual risk summary rather than vanishing silently.

Equally, a high score does not mean "test forever". Define in advance what "done" looks like for each high risk: the variants to cover, the evidence to capture, the owner review to complete. When that is achieved and defects are resolved, the risk is mitigated and the effort moves on.

Key points

Risk sets depth, techniques, review, execution order and evidence.
In SAP, depth means covering the configuration branches the change touches: org units, document types, account assignment groups, condition types.
Automate stable, repeated, important processes; test new functionality manually first.
Run high-risk end-to-end chains first so defects can be fixed in the same cycle.