Lesson 1 of 6
Anatomy of an SAP test case
7 min
Listen to this lesson
Most SAP test cases are written by people who will not be around to run them a year later. The system integrator's testers roll off after hypercare, consultants move to the next project, and the key user who wrote the order-to-cash scripts gets promoted. What stays behind is the document. A test case survives handover when someone who was never in the design workshops can pick it up, set up the data, run it, and reach the same pass or fail verdict as the author would have. At Contoso Motor Co., test lead Priya has a simple rule for the move from SAP ECC to S/4HANA: every test case must be runnable by the Contoso regression team after the system integrator leaves. That rule sounds obvious, yet most inherited SAP test packs fail it. They depend on document numbers from a system that has since been refreshed, on "the usual customer", or on expected results such as "works as before". This course teaches how to write to Priya's standard. This first lesson takes a test case apart and names each piece, so that the later lessons can improve each one.
Test condition, test case, test script
Three terms get mixed up on SAP projects. A test condition is something that needs to be checked, such as "a fleet customer order is priced from the customer-specific price list". A test case is a set of preconditions, inputs, actions and expected results designed to check one or more conditions. A test script (the ISO/IEC/IEEE 29119 family calls it a test procedure) is the ordered sequence of steps a tester follows, often running several test cases in a row because the output of one is the input to the next. In SAP language the word "test script" usually means the step-by-step document for a business process. SAP Best Practices content, browsed in SAP Signavio Process Navigator, ships a test script for each solution process, and SAP Cloud ALM can turn those into manual test cases. Whatever your project calls them, the parts are the same.
- Requirement or process stepOrder-to-cash: sell finished alternators from stock to a fleet customer
- Test conditionCustomer-specific price is applied; credit check passes; goods issue posts cost of goods sold
- Test casePreconditions, data reference, steps and expected results for one business outcome
- Test scriptTest cases in execution order, with the data passed from step to step
- Execution recordActual results, evidence, verdict, defects, tester and date
The parts of a test case
The international standard for test documentation, ISO/IEC/IEEE 29119-3, describes templates for test case and test procedure specifications. You do not need the standard in hand to write good SAP test cases, but its idea is useful: every element has a job, and a reviewer should be able to check each one. The table below uses names common on SAP projects.
| Part | What it holds | Contoso example |
|---|---|---|
| Identifier and version | A stable, unique ID plus a version number | TC-O2C-010, version 3 |
| Title and objective | One business outcome, stated as what is proven | Standard order from stock is delivered, billed and posted to finance |
| Traceability | Links to the requirement, process step or solution process | Process O2C-01 Sell from stock; requirement REQ-SD-014 |
| Priority and risk | Why this case matters and how badly failure would hurt | High: revenue posting, used daily |
| Preconditions | What must already be true before step 1 | QAS client 100; role for sales order entry; stock in plant 1710 |
| Test data reference | Which data set or variant to use, not literal document numbers | Data set DS-O2C-01, variant A |
| Steps | The business actions in order | Create order, create delivery, pick, post goods issue, bill |
| Expected results | Observable outcomes to compare against | Order status, delivery goods movement status, journal entry amounts |
| Evidence | What the tester must capture | Document numbers, document flow, journal entry display |
| Postconditions and cleanup | What the case leaves behind or must reverse | Stock reduced by 50; open receivable for the customer |
| Ownership | Author, reviewer, approval status | Author Maria; reviewed by Priya; approved |
Parts of a test case and what each holds.
A few of these parts deserve a word. The identifier should never change once testers and defects refer to it; encode the process area (TC-O2C, TC-P2P, TC-R2R) rather than the author or the cycle, and use the version to show change. Priority tells a test lead which cases to run when time runs short, so tie it to business impact rather than to how hard the case was to write. The evidence list is part of the design, not an afterthought: if the author does not say what to capture, every tester captures something different, and the sign-off reviewer cannot compare runs.
Where do these parts live? In SAP Cloud ALM, manual test cases are created in the Test Preparation app, typically from the activities of a solution process. Each activity is broken into actions, and each action carries an instruction and an expected result. When the case is complete its preparation status is set to Prepared, it can be grouped into a test plan in the Test Plan app, and testers record results in Test Execution. SAP Solution Manager offers comparable test management for on-premise landscapes. Field names differ by tool and release, so map the parts above onto whatever your project uses rather than the other way round.
- Solution processActivities of the process, such as O2C-01 Sell from stock
- Test PreparationEach activity broken into actions with an instruction and expected result
- PreparedPreparation status set once the case is complete
- Test PlanCases grouped into a plan for a cycle
- Test ExecutionTesters record results and evidence
What would you do?
Priya inherits 400 test cases from the previous release. Most are titled "SD test 1", "SD test 2" and so on, with no requirement links and no version numbers. The steps look reasonable. The next regression cycle starts in three weeks. What should she do first?
- A test case survives handover when a stranger can run it and reach the same verdict as the author.
- Test conditions say what to check, test cases say how to check one outcome, and test scripts sequence cases for execution.
- Every case needs an ID and version, objective, traceability, preconditions, data reference, steps, expected results, evidence and an owner.
- In SAP Cloud ALM, manual test cases are built from activities and actions, each action with an instruction and expected result.
Check your understanding · not graded
Lesson check
1. What makes a test case "survive handover"?
2. Which item is a test condition rather than a test case?
3. In SAP Cloud ALM, which app is used to build manual test cases?
4. A test case title reads "Create order and change price and add partner and reject item and bill". What is the main problem?