Lesson 2 of 5
Core testing principles in an ERP context
9 min
Listen to this lesson
The ISTQB Foundation Level syllabus (version 4.0) lists seven general principles of testing. None of them is specific to SAP, but each one shows up on every SAP program. Knowing them helps you push back when someone asks for something testing cannot deliver, and helps you spend limited test time where it counts.
| Principle | What it means | SAP illustration |
|---|---|---|
| Testing shows the presence, not the absence, of defects | Passing tests reduce the chance of undiscovered defects but never prove there are none | 200 passed order-to-cash tests do not prove the next new customer's tax will be right |
| Exhaustive testing is impossible | You cannot test every combination of inputs and conditions | Order types × sales areas × plants × pricing conditions × customers runs into millions of paths |
| Early testing saves time and money | Defects found early, even in designs, are cheaper to fix | Reviewing the pricing design in Explore beats finding the gap in user acceptance |
| Defects cluster together | A few areas contain most of the defects | Pricing, output determination, tax, interfaces and custom enhancements |
| Tests wear out | Repeating the same tests finds fewer new defects over time (the pesticide paradox) | A regression pack that always uses the same customer and material stops finding data-driven defects |
| Testing is context dependent | How you test depends on the system, risk and industry | A payroll change needs different rigor from a new report layout |
| Absence-of-defects fallacy | A system with few defects can still fail to meet business needs | Configuration matches the spec perfectly, but the spec missed how Contoso invoices fleet customers |
The seven principles from the ISTQB Foundation syllabus, with SAP illustrations.
Defect clustering: where SAP defects live
On SAP programs, defects are not spread evenly. They gather where many rules interact and where the project changed the standard. Pricing combines condition types, access sequences and customer and material data. Output determination decides which invoice, delivery note or order confirmation is produced, to whom, and in which channel. Interfaces depend on mappings and partner systems. Custom enhancements are code nobody but the project has tested. When Priya plans Contoso's next test cycle, she looks at where last cycle's defects came from and adds depth there.
| Hotspot | Why defects cluster here | Contoso example |
|---|---|---|
| Pricing | Condition types, access sequences and master data all interact | Fleet discount applied to aftermarket customers |
| Output determination | Rules decide which document goes to whom and through which channel | Invoice not sent to Great Lakes Fleet Services by email |
| Tax | Depends on plant, customer, product and jurisdiction together | No sales tax on shipments from plant 1720 Chicago |
| Interfaces | Mappings and partner systems change independently | Dealer orders arrive with the wrong sales area |
| Custom enhancements | Code that only the project has ever tested | Fleet contract check fails for a new contract type |
Why exhaustive testing is impossible, and what replaces it
Take one Contoso process: create a sales order and bill it. Count only a few variables. Two plants, three order types, four customer groups, five pricing scenarios, two tax jurisdictions, partial or full delivery. That is already 2 × 3 × 4 × 5 × 2 × 2 = 480 combinations before you consider quantities, dates, credit situations or user roles. Add procurement, production and finance and the numbers are astronomical.
- 2 plants2 paths
- × 3 order types6 paths
- × 4 customer groups24 paths
- × 5 pricing scenarios120 paths
- × 2 tax jurisdictions240 paths
- × partial or full delivery480 paths, before quantities, dates, credit or roles
Since you cannot test everything, you choose. The choice is driven by risk: how likely a failure is and how much it would hurt. You also use test design techniques such as equivalence partitioning (one representative per group that the system should treat the same way) and boundary values (test at the edges, for example right at a credit limit) to cover more ground with fewer tests. These techniques are taught in the 200-level course; for now, remember that selection is deliberate, not random.
Keeping tests fresh
The "tests wear out" principle matters most for regression packs. If every run uses customer Great Lakes Fleet Services and material CMC-ALT-100 in plant 1710, the pack will never notice that Chicago plant 1720 lost its tax setup. Vary data across runs, add tests for each defect you find in production, and retire tests that no longer protect anything.
What would you do?
Grace, the PMO lead, asks Priya: "Can you test every pricing combination before go-live so we know pricing is defect-free?" What is the best answer?
- Seven principles: presence not absence, no exhaustive testing, test early, defects cluster, tests wear out, context matters, absence-of-defects fallacy.
- SAP defects cluster in pricing, output, tax, interfaces and custom code.
- Risk (likelihood × impact) and test design techniques replace the impossible goal of testing everything.
- Vary data in regression packs so they keep finding new defects.
Check your understanding · not graded
Lesson check
1. A regression pack has run unchanged for two years and now rarely finds defects, yet production issues still appear. Which principle explains this?
2. What replaces exhaustive testing in a well-run SAP program?
3. Which SAP area is a typical defect cluster?
4. Contoso's configuration matches every specification, with zero open defects, but fleet invoicing does not work the way the business runs. Which principle is this?