Lesson 4 of 5
Coverage: mapping scenarios and exceptions
10 min
Listen to this lesson
Coverage answers a simple question with a complicated answer: have we tested everything the business will do in maintenance, including when things go wrong? A list of passed test cases is not coverage. Coverage is a map of scenarios, variants and exceptions, each linked to a test and its evidence, so that gaps are visible before the process owner is asked to sign.
The scenario map
| Scenario | Main variants | Exceptions to include |
|---|---|---|
| Technical objects | Create, change, install, dismantle; serialized equipment | Invalid label; blocked installation |
| Planned corrective | Stock parts, non-stock parts, external service | Missing part at release; requisition over $10,000; PO over $25,000; rejected approval |
| Emergency | Report and Repair Malfunction end to end | Unplanned part issue; work by a second technician |
| Preventive, time-based | Single cycle, strategy with packages | Late completion shift; completion requirement; skipped call |
| Preventive, performance-based | Counter readings drive the call | Missing readings; wrong reading rejected; counter replacement |
| Completion and settlement | TECO, NOCO, period settlement, CLSD | TECO reversal; late invoice; locked receiver; non-zero balance |
| Conversion | In-flight ECC orders; converted plans | Catch-up calls after cutover; deadline monitoring stopped in ECC |
| Analytics | Breakdowns, damages, costs, backlog | Figures traced back to source documents |
Contoso's maintenance coverage map.
Variants that multiply
Some variants multiply the map. Two plants (1710 Detroit, 1720 Chicago) with different work centers and storerooms. Two order types (PM01 corrective, PM02 preventive). Roles with different authorizations: operator, planner, technician, storeroom clerk, controller. Rather than testing every combination, Priya's team uses a risk-based selection: every scenario at least once in each plant, every exception at least once, and the highest-risk combinations (emergency in Detroit, settlement in both plants) more than once. The map records which combination each test covers.
Exceptions are where defects live
Happy paths usually work in a conversion because the configuration came across from ECC. Defects hide in exceptions: an approval workflow that behaves differently, an authorization that blocks a technician from an unplanned goods issue, a settlement profile that does not allow the asset receiver, a deadline monitoring variant that misses plant 1720. In Contoso's first test cycle, 9 of the 14 maintenance defects came from exception tests, although exceptions made up less than a third of the tests. That ratio is typical enough to plan for.
What would you do?
Grace asks whether the maintenance stream can drop its exception tests from cycle 2 to save time, because all happy paths passed in cycle 1. Most cycle 1 maintenance defects came from exception tests. What should Priya recommend?
- List scenariosFrom the process design and the ECC usage: what maintenance really does
- Add variantsPlants, order types, roles, stock and non-stock, internal and external
- Add exceptionsMissing parts, approvals, reversals, failed settlement, missing readings
- Link tests and evidenceEach line points to a test in SAP Cloud ALM and its evidence
- Review gapsUntested lines are either tested or accepted as a risk by the process owner
Use real usage to find scenarios. Contoso's ECC system knows which order types, notification types, plan types and movement types maintenance actually used in the last year. A short usage analysis, done by Rosa with Kenji's team, found two things the process design had missed: a small number of refurbishment orders for spindle motors, and service entry sheets created directly by maintenance plans for a contracted inspection. Both were added to the map.
Writing an exception test that proves something
An exception test needs the same precision as a happy-path test: a starting condition that forces the exception, the expected system reaction, and the business recovery. Here is Contoso's test for the "missing part at release" exception.
| Element | Content |
|---|---|
| Precondition | Bearing 6205 has zero unrestricted stock in 171S; order 4001312 (PM01, rotor line) plans 2 pieces |
| Step | Planner releases the order in Change Maintenance Order (or IW32) |
| Expected reaction | Material availability check reports the missing part; order release follows the order type's availability rule (warning or block) |
| Recovery | Planner creates a purchase requisition (non-stock) or a stock transfer; Omar converts it to a PO |
| Evidence | Availability log, missing parts list, PR and PO numbers, the released order |
| Pass criterion | Release behavior matches the design for PM01, and the part reaches the order before the scheduled start |
An exception test case written so that pass and fail are unambiguous.
- Coverage is a map of scenarios, variants and exceptions linked to tests and evidence.
- Select combinations of plants, order types and roles by risk; record what each test covers.
- Exception scenarios find most maintenance defects; protect them when time is short.
- Include conversion-specific scenarios: in-flight orders, converted plans, cutover scheduling.
Check your understanding · not graded
Lesson check
1. Which exception belongs in corrective maintenance coverage?
2. Why is a list of passed test cases not the same as coverage?
3. How should Priya's team handle the many combinations of plants, order types and roles?
4. An exception test cannot be run because the team cannot create the starting condition in CMQ. How should the coverage map show it?