Product risk in SAP terms

Every SAP test lead runs out of time. There are always more processes, variants, plants and edge cases than the calendar allows. Risk-based testing is the discipline of deciding, deliberately and with the business, where the limited test effort goes. It does not mean testing less. It means testing the things that would hurt most if they failed, first and most thoroughly, and being honest about what was left lighter.

The international testing vocabulary (the ISTQB glossary and syllabi, and ISO/IEC/IEEE 29119) defines risk as a factor that could result in future negative consequences, and expresses its level as a combination of likelihood (how probable the problem is) and impact (how much harm it does if it happens). You will use both words all the way through this course.

Product risk versus project risk

Two kinds of risk get mixed up in SAP programs, and the mix-up wastes meetings. A product risk is the possibility that the solution itself fails to do what the business legitimately needs: tax calculated wrongly, deliveries that cannot be goods-issued, a payment run that pays a supplier twice. A project risk is the possibility that the project fails to reach its objectives: the QAS client is refreshed late, key users are on vacation, the budget runs out. Testing reduces product risk. Project risks are managed by the PMO and the test lead's plan, but no amount of test execution makes them go away.

What product risk looks like in SAP

Generic risk lists ("functionality may not work") are useless. Good SAP product risks name a business process, an organizational scope and a business consequence. At Contoso Motor Co. the useful ones sound like this:

• Financial misstatement: revenue for CMC-ALT-100 posted to the wrong G/L account or profit center in company code 1710, discovered at quarter close.
• Blocked shipments: outbound deliveries from shipping point 1720 cannot be goods-issued, so trucks wait at Chicago.
• Wrong valuation: the rotor CMC-RTR-200 is received at the wrong price in plant 1710, distorting inventory value and variances.
• Payment errors: the automatic payment run pays Lakeside Components with the wrong bank details or twice.
• Compliance and audit: a segregation-of-duties control stops working after a role change, or tax is calculated incorrectly for a new ship-to state.
• Integration failure: the EDI order interface from a fleet customer drops orders silently.

Notice that each one points directly at something a test can prove or disprove. That is the test of a well-written product risk: if you cannot imagine the test that would expose it, rewrite it.

Why SAP is risk-shaped

SAP systems are highly integrated: a goods issue posts to finance, a pricing change flows into billing and revenue, a business partner change reaches payments. That integration is why a small change can have a large impact, and why a risk view that stops at the changed transaction is never enough. It is also why the most damaging failures usually surface far from where they were caused, often in finance.

Where risk-based testing fits in an SAP release

Risk analysis is not a one-off planning exercise. It starts when the release scope is known, shapes the test strategy and the first test cycle, gets refreshed whenever the scope changes (late transports, new SAP notes, a deferred feature), and ends as the residual risk statement in the sign-off. The same register serves all of those moments. At Contoso, Priya keeps it next to the test plan in the project's test management tool so that every test case can point to a risk ID.

Risk-based testing also works at every scale. For a major program such as Contoso's move to SAP S/4HANA, the register may hold a hundred risks across all value streams. For a quarterly release of a dozen transports, it may hold ten. For an emergency fix, it may be three lines in the change record. The discipline is the same: name what could go wrong, agree how bad it would be and how likely it is, and test accordingly.