4.7 Experience-Based Testing

Core Idea

Experience-based testing draws tests from the tester's knowledge, skill, intuition, and experience — including familiarity with similar applications, technologies, the domain, and the kinds of defects that have surfaced before. It is not random clicking; effective experience-based testing is deliberate, observant, and informed by perceived risk and prior failures.

These techniques are most useful when:

• the test basis is sparse, outdated, or missing, so black-box techniques have little to work from;
• there is time pressure and you need to find the most serious defects quickly;
• you want to augment systematic tests by probing the assumptions those tests bake in.

The trade-off is that coverage is hard to measure and reproducibility is lower — two testers may design very different tests, and results depend heavily on the individual's skill. CTFL v4.0 names three experience-based techniques you must distinguish: error guessing, exploratory testing, and checklist-based testing. They are presented as a complement to — never a substitute for — the systematic black-box and white-box techniques covered earlier in the chapter.

Error Guessing and Checklist-Based Testing

Error guessing is the structured anticipation of errors, defects, and failures based on experience of how things go wrong. The tester asks: what mistakes might the developer have made? What inputs typically break this kind of feature? A fault attack is a methodical version where the tester lists likely defects and designs a test for each.

For a date input field, error-guessing test ideas include: 29 February in a non-leap year; 31 April; month 13 or 0; a swapped day/month for a localised format; the boundary at midnight and time-zone roll-over; an empty value; and a far-future or far-past date. None of these is dictated by a model — they come from knowing how date handling fails.

Checklist-based testing uses a curated list of conditions, rules, or things to verify to steer coverage. g. a usability checklist, a security checklist, a 'common form-validation pitfalls' list) but does not prescribe exact test cases — the tester decides the specific data and steps for each checklist item. Checklists keep otherwise free-form testing systematic and repeatable across releases, and they are easy to maintain as new failure modes are learned. The exam contrast to remember: a checklist guides what to consider; it does not fix the precise inputs the way a decision table or EP analysis does.

Exploratory Testing

Exploratory testing interleaves test design, test execution, learning, and evaluation in real time: the tester designs and runs tests, observes the result, learns from it, and immediately designs the next test based on what was just discovered. It is most effective with few or poor specifications, under schedule pressure, or as a complement to formal techniques, and works best with experienced, domain-literate testers.

To make it more structured and accountable it is usually run as session-based test management, organised around a charter:

For example, a one-hour charter to 'investigate payment-retry behaviour after a declined card', with the tester adapting each test based on the previous observation, is exploratory testing — the charter gives focus while leaving the exact tests to emerge during the session.

The overarching exam message for this section: experience-based techniques find defects that systematic techniques can miss precisely because they exploit human judgement, but they complement equivalence partitioning, BVA, decision tables, state transition, and white-box coverage rather than replacing them. A strong strategy blends both — systematic techniques for measurable coverage, experience-based techniques to probe the gaps and assumptions.

Choosing Among the Three, and Strengths vs Weaknesses

The three experience-based techniques solve different problems, and the exam expects you to match each to its scenario:

Strengths shared by all three: they exploit human judgement to find realistic, high-impact defects; they cope with missing or unreliable documentation; and they are fast to start, which helps under deadline pressure. They are also a strong complement to systematic techniques, probing assumptions the formal tests bake in.

Weaknesses the exam highlights: coverage is hard to quantify (there are no neat coverage items like partitions or branches), reproducibility is lower, and effectiveness depends heavily on the individual tester's experience and domain knowledge. Two testers may design quite different tests, and a novice may miss what an expert spots.

How they fit the strategy

A balanced approach typically runs systematic black-box and white-box techniques to establish measurable coverage, then layers error guessing, checklist-based testing, and exploratory sessions on top to attack what those techniques assume away — odd data, unusual sequences, environmental edge cases, and the defects that history says recur. Crucially, the syllabus frames experience-based testing as a complement, never a replacement: it does not produce the defensible coverage numbers stakeholders and regulators expect, so it works alongside, not instead of, the systematic techniques.

On the exam, pick the experience-based technique whose trigger words match — 'likely defects' → error guessing; 'charter / learn-and-adapt' → exploratory; 'curated list of checks' → checklist-based.