Lesson 5 of 5
From process to traceable tests
9 min
Listen to this lesson
The last skill in this course ties the others together. Traceability means you can follow a line from a business requirement to the process step that fulfils it, to the test case that checks it, to the test run that executed it and any defect it raised. Traceability answers the sign-off question "how do we know this requirement works?" with evidence rather than opinion, and it shows coverage gaps before they become production surprises.
- RequirementFleet customers are invoiced with their contract number and fleet price
- Process stepBD9 create sales order; create billing document
- Test caseO2C-FLEET-01: fleet order to invoice with expected price, contract number and revenue posting
- Test runExecuted in QAS client 100, build 7, by Maria; result and evidence attached
- DefectIf failed: linked defect, fix transport, retest run
Building a simple traceability sketch
You do not need a tool to start. A table with one row per process step is enough to see coverage. List the steps of the scenario, the requirements or design decisions each step supports, the test cases that cover it, and what downstream checks those cases make. Empty cells are the point: they show steps with no test, requirements with no step, or test cases that check only the save.
| Process step (BD9 at Contoso) | Requirement or design decision | Test case | Downstream check |
|---|---|---|---|
| Create sales order | REQ-12 fleet pricing; REQ-15 credit check for fleet | O2C-FLEET-01, O2C-CREDIT-02 | Price, tax, credit status |
| Create outbound delivery and pick | REQ-20 ship from Detroit or Chicago | O2C-FLEET-01, O2C-CHI-03 | Delivery from shipping point 1710 or 1720 |
| Post goods issue | REQ-31 stock and cost at standard | O2C-FLEET-01 | Stock reduced; COGS journal entry |
| Create billing document | REQ-12, REQ-40 contract number on invoice | O2C-FLEET-01 | Receivable, revenue, tax; invoice output |
| Post incoming payment | REQ-52 apply payments to open items | (none yet) | Gap: no test for payment clearing |
A traceability sketch for one scenario. The empty cell is a finding.
Traceability in SAP's tools
SAP Cloud ALM builds this chain into its data model. Test cases are created from solution processes, can be assigned requirements and user stories, are grouped into test plans and executed with results recorded per step, and defects are raised from failed steps. Its analytics include requirements traceability, so a test lead can see which requirements have tests and how they performed. SAP Solution Manager offers similar capabilities for on-premise programs. Whatever the tool, the discipline is the same: every test case links to something it proves.
Traceability also pays off after go-live. When a change request arrives to alter fleet pricing, the sketch shows at once which requirements, steps and test cases are affected, which is the starting point for choosing regression scope. A program that kept its traceability current can answer "what do we need to retest?" in minutes; one that did not has to rediscover the answer every time.
- Change requestAlter fleet pricing
- Affected requirementsREQ-12 fleet pricing
- Affected stepsCreate sales order; create billing document
- Affected test casesO2C-FLEET-01 and related cases
- Regression scopeThose cases plus neighbors that share the pricing setup
Coverage questions to ask
- Does every in-scope process step have at least one test case?
- Does every requirement or gap backlog item trace to a step and a test case?
- Does each integration point have a downstream check, not just a save?
- Are both plants, all relevant sales areas and the main customer groups represented in the test data?
- Are test cases that trace to nothing still needed?
- Does a process step have no test case?Yes → write one or record the gap as an accepted risk · No → go on
- Does a requirement trace to no step or test?Yes → confirm it is still in scope, then cover it · No → go on
- Does an integration point check only the save?Yes → add a downstream check · No → go on
- Does a test case trace to nothing?Yes → find its purpose or retire it · No → coverage is complete for this step
Keep the sketch alive. Update it when Fit-to-Standard decisions change, when gap backlog items are added or dropped, and when defects reveal a condition no test covered. A traceability table that was accurate in Explore and never touched again gives false comfort at sign-off.
What would you do?
Two weeks before UAT, Priya's traceability sketch for order to cash shows every step covered except incoming payment, which links to requirement REQ-52 but has no test case. Grace asks if they can sign off the scenario as fully tested. What should Priya say?
- Traceability links requirement → process step → test case → test run → defect.
- A one-row-per-step sketch reveals coverage gaps quickly.
- SAP Cloud ALM links test cases to processes, requirements and user stories and reports traceability.
- Empty cells are findings: close them or record them as accepted risks.
Check your understanding · not graded
Lesson check
1. What does traceability let a test lead show at sign-off?
2. In a traceability sketch, a requirement has no test case. What is it?
3. In SAP Cloud ALM, what are test cases created from and linked to?
4. Which column in a traceability sketch catches tests that only check the save message?