Test Design Techniques — Experience-Based
Experience-based testing isn't guessing — it's structured intuition. Learn exploratory testing, error guessing, and checklist-based testing and when each adds the most value.
ISTQB Foundation Level Series — Part 8 of 10 This series walks through every major topic of the ISTQB CTFL syllabus. Start from Part 1 or jump to any section that interests you.
1. The Third Dimension of Test Design
When most testers think about test design, they think about specifications. Black-box techniques like equivalence partitioning or boundary value analysis derive tests from requirements. White-box techniques like statement coverage derive tests from code. Both are systematic and repeatable — but neither captures what an experienced tester knows in their gut.
That gap is what experience-based techniques fill.
| Dimension | Driven by | Example technique |
|---|---|---|
| Black-box | Requirements, specifications | Equivalence Partitioning, Decision Tables |
| White-box | Code structure, control flow | Statement Coverage, Branch Coverage |
| Experience-based | Tester’s knowledge, intuition, history | Exploratory Testing, Error Guessing, Checklists |
All three dimensions are complementary. A mature test approach uses all of them. Experience-based testing adds the most value in areas where requirements are incomplete, code is complex, or the team has encountered similar bugs before.
2. Exploratory Testing (ISTQB 4.4.3)
What it is
The ISTQB definition: “An experience-based test technique in which the tester simultaneously learns about the test object while designing, executing, and evaluating tests.”
That simultaneity is the key difference from scripted testing. You don’t write a test case, then execute it later. Instead, learning, design, and execution happen in a single continuous act. You follow what you find. Each observation shapes the next test.
This is not ad-hoc testing. Ad-hoc testing lacks structure and produces results that are hard to reproduce or report. Exploratory testing is disciplined.
Session-Based Exploratory Testing
The most widely-used structure for exploratory testing is the session model:
- Charter — a focused mission statement defining what to explore and optionally what to look for. Example: “Explore user profile editing under concurrent sessions to find data integrity issues.”
- Timebox — a fixed duration, typically 60–90 minutes. This keeps sessions focused and prevents endless wandering.
- Debrief — a short review after the session: what was covered, what was found, open questions, and areas needing follow-up.
Sessions produce notes, not formal test cases. The output is a session report: time spent on testing vs. investigation vs. setup, defects found, and coverage achieved relative to the charter.
When exploratory testing adds the most value
- New or poorly-documented features — when specifications are thin, exploratory testing surfaces issues that scripted tests would miss.
- High-risk areas — before a major release, focused sessions on the riskiest modules add a safety net.
- After an incident or production defect — use the bug as a charter to explore the surrounding area.
- Validating automation gaps — exploratory testing catches what your automated suite doesn’t cover.
ISTQB exam note
A common trap: ISTQB classifies exploratory testing as an experience-based technique, not a black-box technique — even though it doesn’t require access to source code. Don’t let that confuse you on the exam.
3. Error Guessing (ISTQB 4.4.1)
What it is
Error guessing means predicting where defects are likely to exist, based on:
- The tester’s personal experience with past defects
- Known developer habits and common implementation mistakes
- Historical bug data from the project or similar projects
- Common failure modes for the technology stack in use
Unlike exploratory testing, error guessing starts with a hypothesis: “I think this function probably fails when the input is null.” You design tests to prove or disprove that hypothesis.
Rich sources for error guessing
| Source | Examples |
|---|---|
| Edge cases | empty string, null, 0, negative numbers, max integer, special characters (<, ', \0) |
| Boundary violations | one below/above documented limits, exact boundary values |
| Integration points | API version mismatches, timeout handling, malformed responses |
| Concurrency | simultaneous updates to the same record, race conditions, deadlocks |
| State transitions | operations performed in unexpected order, re-submitting a completed form |
| Security | SQL injection, XSS, path traversal, JWT manipulation |
| Historical bugs | defects logged in your issue tracker for this or similar systems |
Fault Attack: structured error guessing
Ad-hoc error guessing is useful. Fault attack makes it systematic. Before testing a component, create a written list of potential faults, then design specific tests to attack each one.
Example — fault attack for a login form:
| Fault hypothesis | Test |
|---|---|
| Empty username accepted | Submit with username = "" |
| Password field echoes plaintext in DOM | Inspect element after entering password |
| No account lockout on failed attempts | Attempt 20 rapid failed logins |
| SQL injection in username | Enter ' OR '1'='1 as username |
| Session token not invalidated on logout | Capture token, log out, replay token |
| ”Remember me” stores password in plaintext cookie | Inspect cookie after checking “Remember me” |
| Concurrent login creates duplicate sessions | Log in from two browsers simultaneously |
:::tip[From error guessing to fault attack] Error guessing becomes much more powerful when formalised into a fault attack list. Writing down your hypotheses before testing forces you to be explicit about assumptions, creates a lightweight test record, and makes it easy to share knowledge with teammates. :::
4. Checklist-Based Testing (ISTQB 4.4.2)
What it is
Checklist-based testing means executing tests against a predefined list of items to check. Each item represents a condition, behaviour, or quality attribute to verify.
Unlike test cases, checklist items are intentionally concise. They remind the tester what to check without scripting how to do it. This leaves room for experienced testers to apply judgment.
Types of checklists
| Type | What it covers |
|---|---|
| Functional checklist | Key user-facing behaviours for a feature or module |
| Cross-cutting checklist | Concerns that apply to every feature: error messages, loading states, empty states, mobile responsiveness, accessibility |
| Regression checklist | The most business-critical flows to verify after any change |
| Release checklist | Pre-release gates: smoke tests, performance benchmarks, security scans, documentation updated |
Advantages
- Low overhead — writing and executing a checklist is faster than maintaining full test scripts.
- Shareable — a cross-cutting checklist can be given to developers for self-review before code review.
- Good for non-functional concerns — accessibility, performance, and security checks translate naturally to checklists.
- Encourages consistency — every tester covers the same ground.
Disadvantages and risks
- Checkbox exercise — testers may tick items without genuinely verifying them.
- Gets stale — a checklist written for v1 may miss important new behaviours in v3.
- Illusion of coverage — a short checklist can give false confidence.
Best practice
Review and update checklists after every major incident or production defect. If a bug escaped testing, add a checklist item to catch it next time.
5. Comparison: When to Use Each Technique
| Technique | Best for | Key risk |
|---|---|---|
| Exploratory Testing | New features, risk-driven investigation, low-spec areas | Sessions not focused enough; notes too sparse to reproduce |
| Error Guessing | Known high-risk areas, integrations, security-sensitive code | Misses unknown unknowns; relies on individual experience |
| Checklist-Based Testing | Regression, cross-cutting concerns, non-functional checks | Checkbox mentality; checklists go stale |
In practice, the three techniques reinforce each other. A fault attack list is a specialised checklist. An exploratory testing charter can be seeded by error guessing. Use them together rather than picking one.
6. Building Your Experience Base
Experience-based techniques are only as good as your experience. Deliberately building that experience base pays compound interest over a career.
Personal defect log — keep a running list of every interesting defect you’ve found, including what caused it and where you found it. Review it before starting new testing assignments.
Study postmortems — when a production incident occurs, read the postmortem carefully. What failed? What was missed in testing? What would have caught it?
Read security advisories — CVE databases, OWASP Top 10, and vendor security bulletins describe real-world failure modes. These are fault hypotheses handed to you for free.
Pair test with seniors — watch how experienced testers think. The questions they ask and the areas they probe are the product of years of accumulated error guessing.
Review bug trackers — search your organisation’s historical issue tracker for patterns. Which modules have the most defects? Which developers introduce the most off-by-one errors? This data shapes your next fault attack list.
7. Conclusion
Experience-based techniques are the third pillar of test design — not a fallback when you run out of ideas, but a structured way to apply accumulated knowledge.
- Exploratory testing is disciplined, session-based investigation driven by a mission.
- Error guessing / fault attack is hypothesis-driven testing built on what has gone wrong before.
- Checklist-based testing is fast, shareable coverage of known-important areas.
None of them replaces black-box or white-box techniques. All of them make your test suites smarter.
Action item before your next test session: Take 15 minutes to write a fault attack list for the feature you’re about to test. Start with edge cases, then think about integration points, then look up the last three bugs found in that area. You’ll catch more defects — and you’ll do it faster.
Next up — Part 9: Test Management: Planning, Estimation, and Metrics