Lesson 5 of 6
Experience-based techniques
8 min
Listen to this lesson
Formal techniques are only as good as the specification they start from. When the tolerance document forgets that Lakeside sometimes invoices in Canadian dollars, no partition will appear for it. Experience-based techniques fill that gap by using what testers know about where SAP processes break. The ISTQB syllabus names three: error guessing, exploratory testing and checklist-based testing.
Error guessing with a fault list
Error guessing is not guessing at random. It is a structured attack built from a list of faults seen before: in past projects, in defect logs, in production incidents. The list for an SAP rollout repeats from program to program, and it is worth keeping as a team asset. The richest areas are dates, currencies, rounding and units of measure.
| Area | Fault to attack | Contoso example |
|---|---|---|
| Dates | Posting periods, period end, leap years, document date versus posting date | Post a goods receipt on the last day of a period after the period is closed; post an invoice dated February 29 |
| Currencies | Foreign currency documents, exchange rate type and date, currencies with different decimal places | An invoice from Lakeside in CAD against a USD purchase order |
| Rounding | Price units, per-item versus per-document rounding, tax rounding | A rotor priced per 1,000 pieces, ordered in quantity 7 |
| Units of measure | Order unit versus base unit conversions | Order rotors in boxes of 12, receive in pieces, invoice in boxes |
| Master data gaps | Missing or expired records found by determination | A price record that expired yesterday; a customer with no tax classification |
| Concurrency and repeats | Two users on one document, double posting, reprocessing | Two clerks posting the same invoice; a background job rerun after failure |
A starter fault list for SAP finance and logistics rules. Extend it with your own defect history.
Exploratory testing with charters
Exploratory testing designs, executes and learns at the same time. It works best when it is time-boxed and guided by a charter: a short mission that names the target, the resources and the information sought. A common format is "Explore target with resources to discover information". Sessions of 60 to 90 minutes, with notes taken as you go and a short debrief afterward, keep exploration accountable.
- Explore supplier invoice entry for Lakeside Components with invoices in CAD, different exchange rate dates and partial quantities, to discover how price variance is calculated in foreign currency.
- Explore the Release Purchase Requisition app with a user holding only release code P1, to discover what the app shows and allows when P2 is outstanding.
- Explore period-end postings in company code 1710 with goods receipts and invoices dated on and around the last day of the period, to discover how closed periods and posting dates interact.
- Explore order-to-cash pricing for CMC-ALT-100 with quantities of 1, 7 and 1,001 and price units per 1,000, to discover rounding differences between item and header totals.
- CharterExplore CAD invoices for Lakeside to discover how price variance is calculated
- Time box60 to 90 minutes in client 100
- NotesInputs tried, behavior seen, questions raised
- DebriefFindings reviewed with the test lead or process owner
- FormalizeFindings become new partitions, table rules and scripted regression tests
Exploration finds things nobody wrote down, which is its value. It also produces something formal techniques can use: when a session reveals that CAD invoices are handled differently, the finding becomes a new partition in the tolerance model and a scripted regression test. That is the healthy loop: explore, learn, formalize.
Checklist-based testing sits between the two. A checklist is a set of conditions to verify, drawn from experience, standards or earlier defects, without prescribing the exact steps: "each new output rule has a test for every channel", "every posting test includes a closed-period attempt", "every price test includes an expired condition record". Checklists keep experience from being lost when people rotate off the program, and they work well as a review aid for designed tests. Keep them short and current; a checklist nobody updates after go-live soon checks yesterday's problems.
Experience-based techniques cannot give you a coverage figure in the same way. "Four charters, five hours, three findings" is a useful report, but it does not tell a process owner that every boundary of the tolerance rule was checked. Formal techniques can say that, but only about what the specification includes. Use both, and choose the weight by how well the rule is specified and how much harm a defect would do.
| Error guessing | Exploratory testing | Checklist-based testing | |
|---|---|---|---|
| Starts from | A fault list of defects seen before | A charter with a target and a mission | Conditions to verify, without fixed steps |
| Contoso example | Invoice dated February 29; price per 1,000 ordered in 7 | CAD invoices for Lakeside | Every posting test includes a closed-period attempt |
| What you report | Faults attacked and found | Charters run, time spent, findings | Items checked and failed |
| Main risk | List goes stale | Unfocused without a time box | Checks yesterday's problems if not updated |
What would you do?
Dan, the finance process owner, is worried about month-end. The specification for period-end postings is two sentences long and the deadline for test design is Friday. What is the best plan?
- Error guessing, exploratory testing and checklist-based testing are the experience-based techniques.
- Keep a fault list for SAP: dates, currencies, rounding, units of measure, master data gaps and repeats.
- Exploratory sessions need a charter, a time box, notes and a debrief.
- Findings from exploration become partitions, table rules and scripted regression tests.
- Weight formal versus experience-based testing by specification quality and business risk.
Check your understanding · not graded
Lesson check
1. Which three techniques does the ISTQB syllabus group as experience-based?
2. What does an exploratory testing charter contain?
3. An exploratory session finds that CAD invoices are checked against the tolerance differently. What should happen next?
4. Which area is a classic error-guessing target for SAP finance postings?