Lesson 6 of 6
Choosing and documenting technique
9 min
Listen to this lesson
By now you have four formal techniques and three experience-based ones. Real requirements rarely announce which one they need, and many need more than one. This lesson gives you a selection guide, a way to record technique and coverage in a test case so a reviewer can check it, and a worked exercise on a Contoso procurement approval rule.
Most procure-to-pay and order-to-cash rules need more than one technique. A release strategy has a value threshold (boundaries), several characteristics such as plant and account assignment (decision table) and a lifecycle (state transitions). Use each technique for the part of the rule it models best, then remove duplicate tests: a single requisition at $10,000.01 for plant 1710 can serve as both a boundary test and a decision table rule.
- Does the rule depend on a number, date or quantity with limits?Yes → equivalence partitions and boundary values · No → next question
- Do several conditions combine to decide an outcome?Yes → decision table; collapse only where the system truly ignores a condition · No → next question
- Does the object move through statuses, approvals or blocks?Yes → state transition model; attempt invalid transitions · No → next question
- Is the rule poorly specified, new, or known to be fragile?Yes → exploratory charters and the fault list, then formalize · No → one test per partition is usually enough
- Is the rule high risk to money, compliance or customers?Yes → raise the coverage level: three-value boundaries, full tables, all transitions · No → keep the lighter level
| Requirement type | Primary technique | Coverage to state |
|---|---|---|
| Tolerance, limit, threshold, minimum quantity | Equivalence partitioning and boundary value analysis | Partitions and boundary values exercised out of total |
| Pricing, tax, output or account determination | Decision table | Feasible rules (columns) exercised out of total |
| Release, block, approval, document status | State transition testing | Valid transitions exercised; invalid transitions attempted |
| New, vague or historically fragile area | Exploratory testing and error guessing | Charters run, time spent, findings and follow-ups |
Requirement types, the technique that fits each, and the coverage you report.
A designed test is only reviewable if the design travels with it. Whatever test management you use (SAP Cloud ALM test management, the Test Suite in SAP Solution Manager or a controlled spreadsheet), record the same few things for every rule:
- The requirement or configuration item tested, with its ID (for example, tolerance key PP for company code 1710).
- The technique used and the model, attached or linked: the partition table, the decision table or the state table.
- The coverage items, each with an ID (P1, B1, R3, T4), and which test case covers which item.
- The coverage achieved, as items exercised out of items in the model.
- Items deliberately excluded, with the reason and who agreed (for example, "R6 infeasible: no EDI partner without fleet flag in 1710; agreed with Maria").
- Requirement IDTolerance key PP, company code 1710
- ModelPartition table attached to the test
- Coverage itemsP1 to P3, B1 to B4, each with an ID
- Test casesEach case names the items it covers
- Coverage statementItems exercised out of total, exclusions and who agreed
Put the coverage item IDs in the test case name or description. When a test fails, the reviewer can see straight away which partition, rule or transition is at risk, and when the configuration changes, you can find the tests that cover the changed rule in seconds.
Designed tests also make the best candidates for automation. A partition table, a decision table or a state table translates naturally into one parameterized script driven by a data set, where each row of data is one coverage item. SAP's own options include eCATT on on-premise and private cloud systems and the Test Automation Tool for SAP S/4HANA Cloud Public Edition; whichever you use, keep the coverage item ID in each data row so automated results report coverage, not just pass counts. When the tolerance moves from 5% to 7%, you change two data rows instead of rewriting a script.
Mixed exercise: a Contoso approval rule
For this exercise, suppose Contoso extends its plant 1710 policy (a what-if: lesson 4 used the simpler rule where every requisition over $10,000 needs P1 then P2): requisitions of $10,000.00 or less need no release. From $10,000.01 to $49,999.99 they need P1. From $50,000.00 they need P1 then P2. Requisitions with account assignment K (cost center) need one release level higher than the value alone would require, so a $5,000 cost center requisition needs P1. Here is a designed set:
| Requisition value | No account assignment (stock) | Account assignment K (cost center) |
|---|---|---|
| $10,000.00 or less | No release (rule 1) | P1 (rule 4) |
| $10,000.01 to $49,999.99 | P1 (rule 2) | P1 then P2 (rule 5) |
| $50,000.00 or more | P1 then P2 (rule 3) | P1 then P2, no higher level exists (rule 6) |
| Test | Value | Account assignment | Expected strategy | Covers |
|---|---|---|---|---|
| T1 | $10,000.00 | None (stock) | No release | B1 lower side, DT rule 1 |
| T2 | $10,000.01 | None | P1 | B1 upper side, DT rule 2 |
| T3 | $49,999.99 | None | P1 | B2 lower side |
| T4 | $50,000.00 | None | P1 then P2 | B2 upper side, DT rule 3 |
| T5 | $5,000.00 | K | P1 | DT rule 4 |
| T6 | $20,000.00 | K | P1 then P2 | DT rule 5 |
| T7 | $60,000.00 | K | P1 then P2 (no higher level exists) | DT rule 6 |
| T8 | T4 document | None | Release P2 before P1 refused; PO from blocked refused | Invalid transitions |
| T9 | T2 document, value raised to $55,000 after release | None | Release reset or change refused, per changeability setting | Change after release |
Nine tests for the approval rule: four boundary values, six decision table rules, and the key lifecycle transitions.
What would you do?
A new requirement arrives: "Billing documents for Great Lakes Fleet Services must use payment terms of net 45 if the order value exceeds $100,000, net 30 otherwise, unless the customer's contract says net 60." Which design approach fits best?
- Choose techniques by what the rule contains: limits, combinations, lifecycles or weak specifications.
- Many SAP rules need two or three techniques; share tests where one case covers several items.
- Raise the coverage level for rules that put money, compliance or customers at risk.
- Record technique, model, coverage items, coverage achieved and exclusions in every test case.
- A coverage statement per rule is what turns test execution into something a process owner can sign.
Check your understanding · not graded
Lesson check
1. A requirement says "orders below 20 pieces get a small-order surcharge". Which technique is the primary fit?
2. What should a designed test case record so a reviewer can check its design?
3. In the approval exercise, why does test T2 use exactly $10,000.01?
4. When should you raise the coverage level, for example to three-value boundaries or a full decision table?