Lesson 1 of 5
Why SAP systems need testing
9 min
Listen to this lesson
An SAP system is not a website that shows the wrong picture when something breaks. It moves money, stock and people. When Contoso Motor Co. ships 50 alternators CMC-ALT-100 to Great Lakes Fleet Services, SAP reduces inventory in plant 1710, posts cost of goods sold, creates a receivable, calculates sales tax and later clears the payment. A mistake anywhere in that chain becomes a wrong invoice, a wrong balance sheet or a truck that never leaves the dock.
- Goods issue50 CMC-ALT-100 leave plant 1710; inventory falls
- Cost of goods soldPosted at the $150 standard cost
- BillingInvoice to Great Lakes Fleet Services; revenue and receivable posted
- Sales taxCalculated from the ship-from plant and the customer's location
- PaymentIncoming payment clears the open receivable
Testing exists to reduce that risk before real business depends on it. The goal is not to prove the system perfect, which nobody can do, but to find the problems that matter while they are still cheap to fix, and to give the people who sign off a release honest evidence of what works and what does not.
Error, defect, failure
Testers use three words that everyday speech mixes up. The ISTQB Foundation syllabus and ISO/IEC/IEEE 29119 both keep them apart, and so should you, because each points to a different fix.
- Error (or mistake): a human action that produces a wrong result. A consultant assigns the wrong G/L account to the revenue account key for Contoso's domestic sales.
- Defect (also called a fault or bug): the flaw that the error leaves behind in configuration, code, master data or documentation. The account determination entry now points revenue to a balance sheet account.
- Failure: what you observe when the defect is executed. A billing document for Great Lakes Fleet Services posts revenue to the wrong G/L account in company code 1710.
- Root cause: the underlying reason the error happened. Perhaps the design document listed two candidate accounts and nobody confirmed which one finance wanted.
- ErrorConsultant keys the wrong G/L account into revenue account determination
- DefectThe wrong entry sits in the configuration, transported to QAS client 100
- FailureA test billing document posts revenue to the wrong account
- Root causeAn unconfirmed design decision; fix the process as well as the entry
Not every defect produces a failure every time. If the wrong account applies only to one customer account assignment group, most billing documents post correctly and the defect hides until the one customer group is billed. That is why testers think in terms of conditions and data, not just transactions.
What escaping defects cost
A defect found in development costs a conversation and a configuration change. The same defect found after go-live costs much more: invoices to reverse and reissue, a month-end close that does not reconcile, customers on the phone and auditors asking why controls failed. SAP failures tend to cluster in a few recurring patterns, which is useful, because it tells you where to look.
- ExploreFound in a design reviewA conversation and a corrected design document
- Realize: unit testFound by the builderOne configuration change, retested in minutes
- Realize: integration testFound in SITA defect, a fix transport, a retest and regression of related scenarios
- Realize: UATFound by the businessAll of the above, plus lost confidence and a possible slip in sign-off
- After go-liveFound by a customer or auditorReversed invoices, reconciliation work, a production fix and control findings
| Failure pattern | Contoso example | Business effect |
|---|---|---|
| Wrong tax determination | Sales tax not calculated for shipments from plant 1720 Chicago | Under-collected tax, liability and penalties |
| Blocked deliveries | A credit check blocks every fleet order after a credit limit change | Orders sit unshipped; revenue slips |
| Wrong pricing | A discount condition applies to aftermarket instead of fleet customers | Margin loss or customer disputes |
| Inventory valuation | Rotor CMC-RTR-200 valued at the wrong standard cost | Misstated inventory and cost of goods sold |
| Payroll and HR | A pay rule change applied to the wrong employee group | Wrong pay, compliance exposure, morale |
Common SAP failure patterns. Each starts as a small defect and ends as a business problem.
Notice that none of these failures needs a system crash. SAP saves the document, shows a green success message and carries on. The damage is in the values: the wrong tax, the wrong price, the wrong account. That is why a test that only checks "document saved" is not a test of the business result. Throughout this track you will see the same habit: decide the expected result before you run the test, then compare the actual values with it.
What would you do?
During a Contoso test, Priya sees that a billing document for Great Lakes Fleet Services posted revenue to the wrong G/L account. A consultant says, "That's just an error, I'll fix the entry." How should Priya describe and record what happened?
- Testing reduces business risk; it cannot prove a system has no defects.
- An error is a human mistake, a defect is the flaw it leaves, and a failure is what you observe when the flaw runs.
- Defects may hide until specific data or conditions trigger them.
- SAP failures cluster in patterns such as tax, pricing, credit, valuation and payroll; use them to focus testing.
Check your understanding · not graded
Lesson check
1. A test billing document posts revenue to the wrong G/L account. In testing vocabulary, the wrong posting you observe is a:
2. Which is the best example of a defect in an SAP system?
3. Why might a defect in tax determination go unnoticed for weeks?
4. What is the main purpose of testing an SAP release?