Structured techniques test what you know to look for — experience tests what you do not
EP, BVA, and decision tables are powerful for requirements-driven testing. But they only cover what is specified. The most damaging defects are often the ones nobody anticipated: the race condition that only occurs under specific timing, the crash triggered by an emoji in a text field, the security bypass discovered by clicking buttons in an unusual order.
Experience-based techniques leverage tester knowledge, intuition, and domain expertise to find defects that specification-based methods miss.
// example: slack — finding a race condition through exploratory testing
Experience-Based Techniques — CTFL 4.0.1
Error Guessing
The tester uses experience and knowledge of common defect types to predict where defects are likely to exist and designs tests to expose them. Based on an informal "fault attack" list — known defect-prone patterns like empty inputs, null values, special characters, boundary conditions, concurrency, and error handling paths.
Exploratory Testing
Simultaneous learning, test design, and test execution. The tester explores the system in real time, using discoveries to guide subsequent tests. CTFL defines exploratory testing as most useful when specifications are incomplete, time is limited, or to supplement formal techniques.
Often structured using session-based testing: time-boxed sessions (typically 60–90 minutes) guided by a test charter — a short statement of the scope and goal. Notes, findings, and time spent are recorded.
Checklist-Based Testing
Tests are designed from a checklist of items based on experience, standards, or regulations. The checklist ensures consistent coverage across testers and builds up institutional knowledge over time. Less flexible than exploratory testing but more repeatable.
// tip: Exam Tip: Exploratory testing is NOT random testing. It is structured through charters, time-boxed sessions, and notes. The key characteristic is that learning, design, and execution happen simultaneously — unlike formal techniques where design precedes execution. If the exam describes "simultaneous learning and testing," the answer is exploratory testing.
Writing an Exploratory Testing Charter
A test charter defines the scope and goal of one exploratory testing session. It guides without over-constraining.
| Charter Element | Purpose | Example |
|---|---|---|
| Area / Target | What part of the system to explore | Payment checkout flow |
| Goal / Mission | What to investigate or find | Explore how the system handles payment failures and retries |
| Resources | Time box and tools | 60 minutes, test credit cards, proxy tool to simulate network errors |
| Notes / Findings | Record observations, defects, questions | Logged during and after the session |
Example charter: "Explore the checkout payment retry behaviour when the payment gateway times out. Time box: 60 minutes. Goal: understand how the system handles partial transactions and whether the cart is preserved correctly after a failed payment."
Exploratory Testing
Basis
Simultaneous learning, design, execution
Structure
Charter + time-boxed session
Best for
Incomplete specs, time pressure, supplementing formal techniques
// Example charter
Target
Payment checkout flow
Mission
Explore how system handles payment failures and retries
Resources
60 min, test cards, proxy tool for network errors
Notes
Log observations, defects, questions during session
// Techniques compared
Repeatability
Low
Low
High
Documentation
Fault list
Charters + notes
Checklist with status
When to use
Deep domain knowledge
Incomplete specs
Compliance/regression
// Exam tip
Exploratory testing is NOT random. It is structured through charters, time boxes, and notes. The key characteristic: simultaneous learning, design, and execution. If the exam describes this, the answer is exploratory testing.
// Exam trap
"Exploratory testing produces no documentation" is FALSE. CTFL states that session-based exploratory testing should be documented through charters, session notes, and defect reports. The informal nature applies to test design — not to recording findings.
Experience-Based Techniques Compared
| Aspect | Error Guessing | Exploratory Testing | Checklist-Based |
|---|---|---|---|
| Basis | Tester knowledge of common defect types | Real-time learning and discovery | Predefined list of items to verify |
| Structure | Informal fault attack list | Charter + time box | Formal checklist |
| Repeatability | Low — depends on individual tester | Low — each session is unique | High — same checklist run by any tester |
| Best used when | Testers have deep domain knowledge | Specifications are incomplete or time is limited | Compliance, standards, or regression checks are needed |
| Documentation | Fault attack list | Session notes, charters, defect reports | Checklist with pass/fail status |
// warning: Exam Trap: "Exploratory testing produces no documentation." This is false. CTFL states that exploratory testing, especially session-based testing, should be documented through charters, session notes, and defect reports. The informal nature applies to test design — not to the recording of findings. Undocumented exploratory testing cannot be reviewed, repeated, or improved.
Exam Practice Questions
// ctfl 4.0.1 style — select an answer to reveal explanation