Lesson 1 of 6
Why technique beats intuition
9 min
Listen to this lesson
Priya, the test lead on Contoso Motor Co.'s move to SAP S/4HANA, inherits 140 procure-to-pay test cases written by key users during the ECC years. She sorts them by what they actually do and finds that more than a hundred create a standard purchase order for 100 rotors CMC-RTR-200 from Lakeside Components at the agreed price, post a goods receipt into plant 1710 and enter an invoice that matches the order to the cent. The cases differ in their titles, their testers and their screenshots. They do not differ in what they prove.
This is what intuition produces. People who know the business write the cases they can picture, and the case they picture first is the one that happens every day. That case matters, but it is also the case least likely to hide a defect after a migration, because it is the one everyone will notice on the first morning after go-live. The defects that reach production sit somewhere else: at the edge of a tolerance limit, in a combination of conditions nobody pictured, or in a status change the process is not supposed to allow.
Where SAP configuration defects hide
| Kind of rule | Contoso example | What happy-path tests miss |
|---|---|---|
| Limits and tolerances | Invoice price variance above 5% blocks payment | The invoice that is exactly at, or one cent over, the limit |
| Thresholds in master data | Credit limit for Great Lakes Fleet Services | The order that tips exposure over the limit |
| Determination logic | Which output, price or tax code is found | Combinations of customer, document type and channel nobody listed |
| Document lifecycles | Purchase requisition release, sales order blocks | Steps done in the wrong order, or steps that should be refused |
| Calculations | Rounding on prices per 1,000 units, currency conversion | Small amounts, odd quantities, currencies with different decimals |
Five places configuration defects cluster, and why an everyday test case walks straight past them.
What a test design technique gives you
A test design technique is a repeatable way of turning a requirement into test conditions and test cases. Instead of asking "what would a user do?", it asks "what does this rule distinguish, and how do I exercise each distinction once?". The ISTQB Foundation Level syllabus (version 4.0) groups techniques into three families: black-box techniques built from the specification, white-box techniques built from the internal structure of code, and experience-based techniques built from the tester's knowledge of where things go wrong.
For people testing SAP configuration, black-box techniques do most of the work. The "code" under test is mostly standard SAP behavior steered by Customizing settings and master data, so the specification is the rule the business agreed: the tolerance, the release strategy, the determination table. This course covers the four black-box techniques that map most directly to that kind of rule (equivalence partitioning, boundary value analysis, decision tables and state transitions) and then adds the experience-based techniques that catch what a specification forgets.
- RequirementThe agreed rule: "invoices more than 5% over the PO price are blocked for payment"
- ModelPartitions, a decision table or a state model that makes the rule explicit
- Coverage itemsThe things the model says must each be exercised: partitions, boundaries, rules, transitions
- Test casesConcrete data and steps chosen so every coverage item is hit at least once
- Coverage statementWhat was exercised, out of what, and what was deliberately left out
Coverage is the measure of design quality
A pile of test cases says nothing about quality on its own. "We have 140 procure-to-pay tests" cannot be checked, compared or signed off. Coverage can. Coverage is the share of a model's coverage items that your tests actually exercise: three of three partitions, six of six boundary values, seven of eight decision table rules, five of five valid transitions. Each technique defines its own coverage items, and each gives you a number you can defend.
Coverage also makes gaps visible. When Priya modeled the invoice tolerance rule she found three partitions (below the lower limit, inside the limits, above the upper limit). The 140 legacy cases covered one of them. That is 33% partition coverage and 0% boundary coverage, after many hours of key-user effort. A designed set of seven cases now covers all of them.
| Counting test cases | Stating coverage | |
|---|---|---|
| Typical claim | "We have 140 procure-to-pay tests" | "Tolerance key PP: 3 of 3 partitions, 4 of 4 boundary values" |
| Can it be checked? | No; the number says nothing about what was proved | Yes; each coverage item maps to a test and a result |
| Shows gaps? | No; 100 duplicates look like 100 tests | Yes; 7 of 8 decision table rules shows one rule untested |
| Can a process owner sign it? | Only on trust | Yes, rule by rule |
Contoso users will enter purchase orders in the SAP Fiori Create Purchase Order experience and some power users will keep using ME21N in SAP GUI. The tolerance check, the release strategy and the determination logic behave the same whichever screen starts the process, because they live in the business logic underneath. Design the rule tests once, then decide where to run them. Checks that are about the user interface itself (does the app hide the Release action for a user without the release code, does a field show the right message) are separate test conditions that you add on top.
What would you do?
Priya has 140 legacy procure-to-pay cases and capacity to run about 60 in the first integration test cycle. The procurement process owner suggests running the 60 "most important" ones, meaning the ones written by the most senior key users. What should Priya do?
- Intuition-based SAP test cases cluster on the everyday happy path, where defects are least likely to hide.
- Configuration defects concentrate at limits, combinations, lifecycles and calculations.
- A test design technique turns a rule into a model, coverage items and test cases.
- Coverage (items exercised out of items in the model) is the measure of design quality; counts are not.
- Design against the business rule once; run it in Fiori or SAP GUI, and add UI-specific checks separately.
Check your understanding · not graded
Lesson check
1. Why do intuition-based test cases tend to miss configuration defects?
2. Which ISTQB family of techniques does most of the work when testing SAP Customizing rules?
3. What makes a statement about test design checkable at sign-off?
4. A rule is reachable from a Fiori app and from an SAP GUI transaction. How should you design its tests?