ISTQB Glossary — Chapter 4: Test Analysis and Design

In plain English

Poking around the app with no plan, just intuition.

From real testing work

Two weeks before a release the test manager compares planned versus executed cases, open defects by severity, and remaining effort. Ad-hoc Testing is where that number comes from — and the exam cares that it is used to inform a decision, not just published.

In plain English

Cover every pair of parameter values instead of every combination.

From real testing work

Where you meet this in real work: during a sprint, all-pairs testing is the piece of vocabulary a tester reaches for when explaining a decision to a developer or a stakeholder — for example, justifying in a stand-up why a specific check belongs in this build rather than the next. Same as pairwise testing; huge reduction in test count with strong defect detection.

In plain English

Deliberately attack the system the way a real attacker would — SQL injection, XSS, buffer overflows.

From real testing work

During a pre-release security pass, a tester submits `' OR 1=1 --` into a search box and watches the response. Work like that sits under attack testing: deliberately behaving like an attacker against your own system, in a controlled environment, with written permission.

curl -s "https://staging.example.com/api/search?q=%27%20OR%201%3D1%20--" \
  -H "Authorization: Bearer $TOKEN" | jq '.results | length'
# a jump from 12 to 4,812 results is the finding

In plain English

Test only the minimum set of paths that combine to form all other paths — that count equals cyclomatic complexity.

From real testing work

After a sprint of bug fixes the team runs the unit suite with coverage on and finds the discount calculator sits at 62%. Basis Path Testing tells them which lines or branches never executed — usually the error paths nobody wrote a test for.

npx vitest run --coverage
# ---------------------|---------|----------|
# File                 | % Stmts | % Branch |
# discount.ts          |   62.5  |   41.6   |

In plain English

You design tests only from the spec or behaviour — inputs and expected outputs — without looking at the code.

From real testing work

Where you meet this in real work: during a sprint, black-box testing is the piece of vocabulary a tester reaches for when explaining a decision to a developer or a stakeholder — for example, justifying in a stand-up why a specific check belongs in this build rather than the next. BVA, EP, decision tables, state transition and use-case testing are all black-box techniques in CTFL v4.0.

In plain English

Bugs cluster at the edges of allowed ranges. So if a field accepts 1–100, you test 0, 1, 100, and 101 instead of only picking a value from the middle.

From real testing work

On a checkout form that accepts a quantity between 1 and 99, boundary value analysis is what stops you writing 99 test cases. You pick one value from inside the valid range and the values sitting either side of each edge, then let the rest of the range go untested on purpose.

// quantity field: valid 1..99
test.each([0, 1, 2, 98, 99, 100])("quantity %i", (qty) => {
  const res = validateQuantity(qty);
  expect(res.valid).toBe(qty >= 1 && qty <= 99);
});

In plain English

Executed branches ÷ total branches × 100 — covers both true and false outcomes of each decision.

From real testing work

After a sprint of bug fixes the team runs the unit suite with coverage on and finds the discount calculator sits at 62%. Branch Coverage tells them which lines or branches never executed — usually the error paths nobody wrote a test for.

npx vitest run --coverage
# ---------------------|---------|----------|
# File                 | % Stmts | % Branch |
# discount.ts          |   62.5  |   41.6   |

In plain English

Design tests so every possible outcome of every decision (true and false) is exercised.

From real testing work

After a sprint of bug fixes the team runs the unit suite with coverage on and finds the discount calculator sits at 62%. Branch Testing tells them which lines or branches never executed — usually the error paths nobody wrote a test for.

npx vitest run --coverage
# ---------------------|---------|----------|
# File                 | % Stmts | % Branch |
# discount.ts          |   62.5  |   41.6   |

In plain English

A policy from the business (e.g. 'orders over $500 need approval') that the software must enforce.

From real testing work

Two weeks before a release the test manager compares planned versus executed cases, open defects by severity, and remaining effort. Business Rule is where that number comes from — and the exam cares that it is used to inform a decision, not just published.

In plain English

A diagram linking each input condition to the outputs it triggers — used to generate a decision table.

From real testing work

A loan-approval rule that depends on income, credit score and existing debt has eight input combinations. Modelling it with cause-effect graph turns an argument in a refinement meeting into a table the BA, the developer and the tester all sign off on, and each row becomes one test case.

Income OK | Score >700 | Debt <40% | Expected
    Y     |     Y      |    Y     | APPROVE
    Y     |     Y      |    N     | REFER
    Y     |     N      |    Y     | REFER
    N     |     -      |    -     | DECLINE

In plain English

Work through a curated checklist of common issues (accessibility, security, edge cases) rather than free-form exploring.

From real testing work

Before a release the team books two 90-minute sessions against the new payments screen. Checklist-Based Testing is what they are doing: no scripted steps, a written charter ("probe refund handling on expired cards"), notes taken as they go, and a debrief that turns findings into defect reports.

In plain English

Start small with real objects and no mocks — grow outward.

From real testing work

The payment gateway sandbox is down for maintenance, but the checkout service still has to be tested. The team wires in a classicist tdd that returns canned success and decline responses, so the tests exercise their own code instead of a third party's uptime.

vi.mock("./gateway", () => ({
  charge: vi.fn(async (amount: number) =>
    amount > 5000 ? { status: "declined" } : { status: "approved" }),
}));

In plain English

A tree that breaks each input into partitions and sub-partitions so you can combine them systematically.

From real testing work

On a checkout form that accepts a quantity between 1 and 99, classification tree is what stops you writing 99 test cases. You pick one value from inside the valid range and the values sitting either side of each edge, then let the rest of the range go untested on purpose.

// quantity field: valid 1..99
test.each([0, 1, 2, 98, 99, 100])("quantity %i", (qty) => {
  const res = validateQuantity(qty);
  expect(res.valid).toBe(qty >= 1 && qty <= 99);
});

In plain English

The percentage of code your tests actually run — measured at statement, branch or condition level.

From real testing work

After a sprint of bug fixes the team runs the unit suite with coverage on and finds the discount calculator sits at 62%. Code Coverage tells them which lines or branches never executed — usually the error paths nobody wrote a test for.

npx vitest run --coverage
# ---------------------|---------|----------|
# File                 | % Stmts | % Branch |
# discount.ts          |   62.5  |   41.6   |

In plain English

A family of techniques (pairwise, orthogonal arrays, classification tree) that shrink an exploding combination space to a manageable subset.

From real testing work

A loan-approval rule that depends on income, credit score and existing debt has eight input combinations. Modelling it with combinatorial testing turns an argument in a refinement meeting into a table the BA, the developer and the tester all sign off on, and each row becomes one test case.

Income OK | Score >700 | Debt <40% | Expected
    Y     |     Y      |    Y     | APPROVE
    Y     |     Y      |    N     | REFER
    Y     |     N      |    Y     | REFER
    N     |     -      |    -     | DECLINE

In plain English

Testing how two or more components talk to each other.

From real testing work

A tester files: "Checkout returns HTTP 500 when the cart contains a gift card and a subscription." Steps, expected, actual, environment, build number. Component Integration Testing is one of the fields or states in that workflow, and getting the term right is what makes the report actionable for the developer picking it up at 9am.

In plain English

Percent of individual boolean sub-conditions that have been evaluated true and false.

From real testing work

After a sprint of bug fixes the team runs the unit suite with coverage on and finds the discount calculator sits at 62%. Condition Coverage tells them which lines or branches never executed — usually the error paths nobody wrote a test for.

npx vitest run --coverage
# ---------------------|---------|----------|
# File                 | % Stmts | % Branch |
# discount.ts          |   62.5  |   41.6   |

In plain English

Design tests so every atomic condition inside a decision takes both true and false values.

From real testing work

Where you meet this in real work: during a sprint, condition testing is the piece of vocabulary a tester reaches for when explaining a decision to a developer or a stakeholder — for example, justifying in a stand-up why a specific check belongs in this build rather than the next. Condition coverage alone does NOT guarantee decision coverage.

In plain English

A picture of a function where nodes are basic blocks and arrows are possible jumps.

From real testing work

Two weeks before a release the test manager compares planned versus executed cases, open defects by severity, and remaining effort. Control Flow Graph is where that number comes from — and the exam cares that it is used to inform a decision, not just published.

In plain English

The thing you're counting when you measure coverage — a statement, branch, requirement, partition, etc.

From real testing work

On a checkout form that accepts a quantity between 1 and 99, coverage item is what stops you writing 99 test cases. You pick one value from inside the valid range and the values sitting either side of each edge, then let the rest of the range go untested on purpose.

// quantity field: valid 1..99
test.each([0, 1, 2, 98, 99, 100])("quantity %i", (qty) => {
  const res = validateQuantity(qty);
  expect(res.valid).toBe(qty >= 1 && qty <= 99);
});

In plain English

One test script + many rows of data = many test cases.

From real testing work

The regression pack runs on every merge to main and blocks the deploy when it fails. Data-Driven Testing is the piece of that setup being named here — and the cost is not writing the tests, it is keeping them green when the UI changes next sprint.

- name: Regression suite
  run: npx playwright test --grep @regression
- name: Publish report
  if: always()
  uses: actions/upload-artifact@v4
  with: { name: playwright-report, path: playwright-report/ }

In plain English

Code that no execution path can ever reach — usually left over from refactoring or bad conditionals.

From real testing work

Where you meet this in real work: during a sprint, dead code is the piece of vocabulary a tester reaches for when explaining a decision to a developer or a stakeholder — for example, justifying in a stand-up why a specific check belongs in this build rather than the next. Static analyzers detect dead code; removing it lowers maintenance cost.

In plain English

Percent of decision outcomes (true/false) hit by your tests.

From real testing work

After a sprint of bug fixes the team runs the unit suite with coverage on and finds the discount calculator sits at 62%. Decision Coverage tells them which lines or branches never executed — usually the error paths nobody wrote a test for.

npx vitest run --coverage
# ---------------------|---------|----------|
# File                 | % Stmts | % Branch |
# discount.ts          |   62.5  |   41.6   |

In plain English

A grid where each column is a rule: which conditions are true and what the system should do about it.

From real testing work

A loan-approval rule that depends on income, credit score and existing debt has eight input combinations. Modelling it with decision table turns an argument in a refinement meeting into a table the BA, the developer and the tester all sign off on, and each row becomes one test case.

Income OK | Score >700 | Debt <40% | Expected
    Y     |     Y      |    Y     | APPROVE
    Y     |     Y      |    N     | REFER
    Y     |     N      |    Y     | REFER
    N     |     -      |    -     | DECLINE

In plain English

When behaviour depends on combinations of conditions (like discount rules), you list every condition and expected action in a table and turn each column into a test case.

From real testing work

A loan-approval rule that depends on income, credit score and existing debt has eight input combinations. Modelling it with decision table testing turns an argument in a refinement meeting into a table the BA, the developer and the tester all sign off on, and each row becomes one test case.

Income OK | Score >700 | Debt <40% | Expected
    Y     |     Y      |    Y     | APPROVE
    Y     |     Y      |    N     | REFER
    Y     |     N      |    Y     | REFER
    N     |     -      |    -     | DECLINE

In plain English

Design tests so each decision point (if / switch) is exercised for every possible outcome.

From real testing work

Where you meet this in real work: during a sprint, decision testing is the piece of vocabulary a tester reaches for when explaining a decision to a developer or a stakeholder — for example, justifying in a stand-up why a specific check belongs in this build rather than the next. Decision testing and branch testing are often used synonymously in the syllabus.

In plain English

Comparing two versions of the same thing against the same inputs and catching where they disagree.

From real testing work

Staging has last quarter's anonymised production snapshot, seeded with fifteen deliberately broken accounts. Differential Testing covers how that is created, versioned and restored — because a suite that passes only on Tuesday's data is not a suite you can trust.

make db-reset && make seed-fixtures ENV=staging
# fixtures are versioned with the tests, in the same commit

In plain English

Group inputs that the system should treat identically, then pick one value from each group. That way you cover behaviour without testing every possible value.

From real testing work

On a checkout form that accepts a quantity between 1 and 99, equivalence partitioning is what stops you writing 99 test cases. You pick one value from inside the valid range and the values sitting either side of each edge, then let the rest of the range go untested on purpose.

// quantity field: valid 1..99
test.each([0, 1, 2, 98, 99, 100])("quantity %i", (qty) => {
  const res = validateQuantity(qty);
  expect(res.valid).toBe(qty >= 1 && qty <= 99);
});

In plain English

Design tests based on where you (or history) know bugs usually hide — nulls, empty strings, zero, negatives, huge inputs.

From real testing work

Before a release the team books two 90-minute sessions against the new payments screen. Error Guessing is what they are doing: no scripted steps, a written charter ("probe refund handling on expired cards"), notes taken as they go, and a debrief that turns findings into defect reports.

In plain English

Verifying that errors produce useful, safe, and consistent behaviour.

From real testing work

A tester files: "Checkout returns HTTP 500 when the cart contains a gift card and a subscription." Steps, expected, actual, environment, build number. Error Handling Testing is one of the fields or states in that workflow, and getting the term right is what makes the report actionable for the developer picking it up at 9am.

In plain English

Code that catches and reacts to runtime errors without crashing.

From real testing work

A tester files: "Checkout returns HTTP 500 when the cart contains a gift card and a subscription." Steps, expected, actual, environment, build number. Exception Handling is one of the fields or states in that workflow, and getting the term right is what makes the report actionable for the developer picking it up at 9am.

In plain English

Tests come from what you’ve seen break before — error guessing, exploratory testing, checklist-based testing.

From real testing work

Before a release the team books two 90-minute sessions against the new payments screen. Experience-Based Testing is what they are doing: no scripted steps, a written charter ("probe refund handling on expired cards"), notes taken as they go, and a debrief that turns findings into defect reports.

In plain English

You learn the product while testing it, using your experience to decide what to try next instead of following a pre-written script.

From real testing work

Before a release the team books two 90-minute sessions against the new payments screen. Exploratory Testing is what they are doing: no scripted steps, a written charter ("probe refund handling on expired cards"), notes taken as they go, and a debrief that turns findings into defect reports.

In plain English

Bombard the system with malformed, random or unexpected inputs and see what breaks.

From real testing work

During a pre-release security pass, a tester submits `' OR 1=1 --` into a search box and watches the response. Work like that sits under fuzz testing: deliberately behaving like an attacker against your own system, in a controlled environment, with written permission.

curl -s "https://staging.example.com/api/search?q=%27%20OR%201%3D1%20--" \
  -H "Authorization: Bearer $TOKEN" | jq '.results | length'
# a jump from 12 to 4,812 results is the finding

In plain English

Hammering one specific module over and over to find weak spots.

From real testing work

A tester files: "Checkout returns HTTP 500 when the cart contains a gift card and a subscription." Steps, expected, actual, environment, build number. Gorilla Testing is one of the fields or states in that workflow, and getting the term right is what makes the report actionable for the developer picking it up at 9am.

In plain English

Testing that mixes user-view scenarios with some knowledge of the internals.

From real testing work

Where you meet this in real work: during a sprint, gray-box testing is the piece of vocabulary a tester reaches for when explaining a decision to a developer or a stakeholder — for example, justifying in a stand-up why a specific check belongs in this build rather than the next. Gray-box testing is common in integration and security testing.

In plain English

The main flow where everything goes right.

From real testing work

A tester files: "Checkout returns HTTP 500 when the cart contains a gift card and a subscription." Steps, expected, actual, environment, build number. Happy Path is one of the fields or states in that workflow, and getting the term right is what makes the report actionable for the developer picking it up at 9am.

In plain English

Test business logic through clean interfaces; test the plumbing separately.

From real testing work

Where you meet this in real work: during a sprint, hexagonal / ports & adapters testing is the piece of vocabulary a tester reaches for when explaining a decision to a developer or a stakeholder — for example, justifying in a stand-up why a specific check belongs in this build rather than the next. Enables fast, dependency-free unit tests and focused integration tests.

In plain English

A group of inputs the system should treat the same way — pick one representative to test the whole group.

From real testing work

On a checkout form that accepts a quantity between 1 and 99, input partition is what stops you writing 99 test cases. You pick one value from inside the valid range and the values sitting either side of each edge, then let the rest of the range go untested on purpose.

// quantity field: valid 1..99
test.each([0, 1, 2, 98, 99, 100])("quantity %i", (qty) => {
  const res = validateQuantity(qty);
  expect(res.valid).toBe(qty >= 1 && qty <= 99);
});

In plain English

A group of bad inputs the system is supposed to reject with an error — the negative-testing partition.

From real testing work

On a checkout form that accepts a quantity between 1 and 99, invalid partition is what stops you writing 99 test cases. You pick one value from inside the valid range and the values sitting either side of each edge, then let the rest of the range go untested on purpose.

// quantity field: valid 1..99
test.each([0, 1, 2, 98, 99, 100])("quantity %i", (qty) => {
  const res = validateQuantity(qty);
  expect(res.valid).toBe(qty >= 1 && qty <= 99);
});

In plain English

Test loops with zero, one, two, typical, N-1, N and N+1 iterations to catch boundary and off-by-one bugs.

From real testing work

On a checkout form that accepts a quantity between 1 and 99, loop testing is what stops you writing 99 test cases. You pick one value from inside the valid range and the values sitting either side of each edge, then let the rest of the range go untested on purpose.

// quantity field: valid 1..99
test.each([0, 1, 2, 98, 99, 100])("quantity %i", (qty) => {
  const res = validateQuantity(qty);
  expect(res.valid).toBe(qty >= 1 && qty <= 99);
});

In plain English

Every condition in an if-statement must be shown to independently change the result.

From real testing work

After a sprint of bug fixes the team runs the unit suite with coverage on and finds the discount calculator sits at 62%. MC/DC tells them which lines or branches never executed — usually the error paths nobody wrote a test for.

npx vitest run --coverage
# ---------------------|---------|----------|
# File                 | % Stmts | % Branch |
# discount.ts          |   62.5  |   41.6   |

In plain English

For each atomic condition, show one test where flipping just that condition flips the whole decision.

From real testing work

After a sprint of bug fixes the team runs the unit suite with coverage on and finds the discount calculator sits at 62%. Modified Condition/Decision Coverage tells them which lines or branches never executed — usually the error paths nobody wrote a test for.

npx vitest run --coverage
# ---------------------|---------|----------|
# File                 | % Stmts | % Branch |
# discount.ts          |   62.5  |   41.6   |

In plain English

Throwing random inputs at the app to see what breaks.

From real testing work

Where you meet this in real work: during a sprint, monkey testing is the piece of vocabulary a tester reaches for when explaining a decision to a developer or a stakeholder — for example, justifying in a stand-up why a specific check belongs in this build rather than the next. Android’s Monkey tool is the canonical example — great for mobile stability testing.

In plain English

Cover every combination of true/false values of the sub-conditions inside a compound decision.

From real testing work

Where you meet this in real work: during a sprint, multiple condition testing is the piece of vocabulary a tester reaches for when explaining a decision to a developer or a stakeholder — for example, justifying in a stand-up why a specific check belongs in this build rather than the next. For N conditions you get up to 2^N combinations — expensive; MC/DC is a cheaper alternative.

In plain English

Automatically tweak the code in tiny ways and check whether your tests catch each change — if not, tests are weak.

From real testing work

A signup form passes the automated scanner with zero violations, then fails the moment a tester unplugs the mouse: focus jumps from the email field straight to the footer. Mutation Testing work catches exactly that gap between tool output and a real person completing the task.

const results = await new AxeBuilder({ page }).analyze();
expect(results.violations).toEqual([]);
// then: keyboard-only pass, Tab order recorded in the charter notes

In plain English

How much of the state machine you've covered when you chain N+1 transitions together in one test.

From real testing work

After a sprint of bug fixes the team runs the unit suite with coverage on and finds the discount calculator sits at 62%. N-Switch Coverage tells them which lines or branches never executed — usually the error paths nobody wrote a test for.

npx vitest run --coverage
# ---------------------|---------|----------|
# File                 | % Stmts | % Branch |
# discount.ts          |   62.5  |   41.6   |

In plain English

Deliberately feeding the system bad or unexpected inputs to prove it fails gracefully instead of crashing.

From real testing work

Where you meet this in real work: during a sprint, negative testing is the piece of vocabulary a tester reaches for when explaining a decision to a developer or a stakeholder — for example, justifying in a stand-up why a specific check belongs in this build rather than the next. Negative tests belong in every suite — they catch security and robustness defects positive tests miss.

In plain English

A weighted map of how real users spend their time in the system — used to focus testing on high-usage flows.

From real testing work

Where you meet this in real work: during a sprint, operational profile is the piece of vocabulary a tester reaches for when explaining a decision to a developer or a stakeholder — for example, justifying in a stand-up why a specific check belongs in this build rather than the next. Reliability and performance tests should follow the operational profile, not developer intuition.

In plain English

A math-based way of picking a small, balanced set of test cases that still covers every pair of input values.

From real testing work

A loan-approval rule that depends on income, credit score and existing debt has eight input combinations. Modelling it with orthogonal array testing turns an argument in a refinement meeting into a table the BA, the developer and the tester all sign off on, and each row becomes one test case.

Income OK | Score >700 | Debt <40% | Expected
    Y     |     Y      |    Y     | APPROVE
    Y     |     Y      |    N     | REFER
    Y     |     N      |    Y     | REFER
    N     |     -      |    -     | DECLINE

In plain English

A group of outputs the system produces the same way — used when designing tests from expected results, not inputs.

From real testing work

On a checkout form that accepts a quantity between 1 and 99, output partition is what stops you writing 99 test cases. You pick one value from inside the valid range and the values sitting either side of each edge, then let the rest of the range go untested on purpose.

// quantity field: valid 1..99
test.each([0, 1, 2, 98, 99, 100])("quantity %i", (qty) => {
  const res = validateQuantity(qty);
  expect(res.valid).toBe(qty >= 1 && qty <= 99);
});

In plain English

Start with a big user-level test, then mock your way down to units.

From real testing work

The payment gateway sandbox is down for maintenance, but the checkout service still has to be tested. The team wires in a outside-in tdd that returns canned success and decline responses, so the tests exercise their own code instead of a third party's uptime.

vi.mock("./gateway", () => ({
  charge: vi.fn(async (amount: number) =>
    amount > 5000 ? { status: "declined" } : { status: "approved" }),
}));

In plain English

Instead of testing every combination, test every pair of inputs at least once — catches most combination bugs with far fewer tests.

From real testing work

A loan-approval rule that depends on income, credit score and existing debt has eight input combinations. Modelling it with pairwise testing turns an argument in a refinement meeting into a table the BA, the developer and the tester all sign off on, and each row becomes one test case.

Income OK | Score >700 | Debt <40% | Expected
    Y     |     Y      |    Y     | APPROVE
    Y     |     Y      |    N     | REFER
    Y     |     N      |    Y     | REFER
    N     |     -      |    -     | DECLINE

In plain English

Design tests so each independent path from entry to exit of a function is executed.

From real testing work

After a sprint of bug fixes the team runs the unit suite with coverage on and finds the discount calculator sits at 62%. Path Testing tells them which lines or branches never executed — usually the error paths nobody wrote a test for.

npx vitest run --coverage
# ---------------------|---------|----------|
# File                 | % Stmts | % Branch |
# discount.ts          |   62.5  |   41.6   |

In plain English

Testing the happy path with good inputs to confirm the system does what the spec says.

From real testing work

Where you meet this in real work: during a sprint, positive testing is the piece of vocabulary a tester reaches for when explaining a decision to a developer or a stakeholder — for example, justifying in a stand-up why a specific check belongs in this build rather than the next. Positive testing alone gives false confidence — always pair with negative testing.

In plain English

Generate inputs at random (often weighted by how users actually use the system) instead of hand-picking them.

From real testing work

Where you meet this in real work: during a sprint, random testing is the piece of vocabulary a tester reaches for when explaining a decision to a developer or a stakeholder — for example, justifying in a stand-up why a specific check belongs in this build rather than the next. Random testing complements systematic techniques — it finds surprises specification-based tests would miss.

In plain English

Write a failing test, make it pass, then clean it up. Repeat.

From real testing work

Where you meet this in real work: during a sprint, red-green-refactor is the piece of vocabulary a tester reaches for when explaining a decision to a developer or a stakeholder — for example, justifying in a stand-up why a specific check belongs in this build rather than the next. This tight loop is the essence of TDD — skip refactor and code rots.

In plain English

Design and process choices that stop regressions from being introduced in the first place.

From real testing work

The regression pack runs on every merge to main and blocks the deploy when it fails. Regression Avoidance is the piece of that setup being named here — and the cost is not writing the tests, it is keeping them green when the UI changes next sprint.

- name: Regression suite
  run: npx playwright test --grep @regression
- name: Publish report
  if: always()
  uses: actions/upload-artifact@v4
  with: { name: playwright-report, path: playwright-report/ }

In plain English

How many requirements have at least one test linked to them.

From real testing work

After a sprint of bug fixes the team runs the unit suite with coverage on and finds the discount calculator sits at 62%. Requirements Coverage tells them which lines or branches never executed — usually the error paths nobody wrote a test for.

npx vitest run --coverage
# ---------------------|---------|----------|
# File                 | % Stmts | % Branch |
# discount.ts          |   62.5  |   41.6   |

In plain English

Testing full user journeys, not just individual features.

From real testing work

After a bad release the team runs a root-cause session and changes the definition of done rather than adding more tests at the end. Scenario Testing sits on that side of the fence: preventive and process-oriented, distinct from executing tests against a build.

In plain English

Do exploratory testing in 60-90 minute charter-driven sessions and debrief afterwards for accountability.

From real testing work

Before a release the team books two 90-minute sessions against the new payments screen. Session-Based Test Management is what they are doing: no scripted steps, a written charter ("probe refund handling on expired cards"), notes taken as they go, and a debrief that turns findings into defect reports.

In plain English

Exploratory testing done in focused 60–120 minute blocks with a mission and notes.

From real testing work

Before a release the team books two 90-minute sessions against the new payments screen. Session-Based Test Management is what they are doing: no scripted steps, a written charter ("probe refund handling on expired cards"), notes taken as they go, and a debrief that turns findings into defect reports.

In plain English

Save the current output as the truth; fail if it ever changes.

From real testing work

Where you meet this in real work: during a sprint, snapshot testing is the piece of vocabulary a tester reaches for when explaining a decision to a developer or a stakeholder — for example, justifying in a stand-up why a specific check belongs in this build rather than the next. Great for UI, poor for logic — reviewers must actually read the diff.

In plain English

Write dramatic 'a day in the life' user stories that combine many features into one crazy scenario, then test it.

From real testing work

The regression pack runs on every merge to main and blocks the deploy when it fails. Soap Opera Testing is the piece of that setup being named here — and the cost is not writing the tests, it is keeping them green when the UI changes next sprint.

- name: Regression suite
  run: npx playwright test --grep @regression
- name: Publish report
  if: always()
  uses: actions/upload-artifact@v4
  with: { name: playwright-report, path: playwright-report/ }

In plain English

Design tests only from what the system is supposed to do (spec, story, requirement) — not from the code.

From real testing work

A story reads "As a returning customer I can reuse a saved card." Before estimating it, the three amigos add acceptance criteria for an expired card and a card removed from the account. Specification-Based Testing is the artefact or link involved, and it is what lets you prove later that every requirement has at least one test.

In plain English

A picture of all the modes the system can be in and the arrows showing how it switches between them.

From real testing work

Where you meet this in real work: during a sprint, state diagram is the piece of vocabulary a tester reaches for when explaining a decision to a developer or a stakeholder — for example, justifying in a stand-up why a specific check belongs in this build rather than the next. State diagrams are the source model for state transition testing — memorize the notation (states, transitions, events, actions).

In plain English

A table version of a state diagram — rows are states, columns are events, cells are the next state (or 'invalid').

From real testing work

Staging has last quarter's anonymised production snapshot, seeded with fifteen deliberately broken accounts. State Table covers how that is created, versioned and restored — because a suite that passes only on Tuesday's data is not a suite you can trust.

make db-reset && make seed-fixtures ENV=staging
# fixtures are versioned with the tests, in the same commit

In plain English

A picture of states and the events that move between them.

From real testing work

A loan-approval rule that depends on income, credit score and existing debt has eight input combinations. Modelling it with state transition diagram turns an argument in a refinement meeting into a table the BA, the developer and the tester all sign off on, and each row becomes one test case.

Income OK | Score >700 | Debt <40% | Expected
    Y     |     Y      |    Y     | APPROVE
    Y     |     Y      |    N     | REFER
    Y     |     N      |    Y     | REFER
    N     |     -      |    -     | DECLINE

In plain English

You model the system as states (Logged Out, Logged In, Locked) and design tests that trigger valid and invalid transitions between them.

From real testing work

A loan-approval rule that depends on income, credit score and existing debt has eight input combinations. Modelling it with state transition testing turns an argument in a refinement meeting into a table the BA, the developer and the tester all sign off on, and each row becomes one test case.

Income OK | Score >700 | Debt <40% | Expected
    Y     |     Y      |    Y     | APPROVE
    Y     |     Y      |    N     | REFER
    Y     |     N      |    Y     | REFER
    N     |     -      |    -     | DECLINE

In plain English

Executed statements ÷ total statements × 100. A basic code-coverage metric.

From real testing work

After a sprint of bug fixes the team runs the unit suite with coverage on and finds the discount calculator sits at 62%. Statement Coverage tells them which lines or branches never executed — usually the error paths nobody wrote a test for.

npx vitest run --coverage
# ---------------------|---------|----------|
# File                 | % Stmts | % Branch |
# discount.ts          |   62.5  |   41.6   |

In plain English

Design tests so every line of code runs at least once.

From real testing work

After a sprint of bug fixes the team runs the unit suite with coverage on and finds the discount calculator sits at 62%. Statement Testing tells them which lines or branches never executed — usually the error paths nobody wrote a test for.

npx vitest run --coverage
# ---------------------|---------|----------|
# File                 | % Stmts | % Branch |
# discount.ts          |   62.5  |   41.6   |

In plain English

Pick test inputs by sampling from a statistical model of real usage instead of choosing them by hand.

From real testing work

A résumé-screening model scores candidates from 0 to 1. There is no single expected value to assert against, so statistical testing is checked statistically: accuracy on a held-out set, score distribution compared across demographic slices, and an alert when the live distribution drifts from training.

assert accuracy_score(y_true, y_pred) >= 0.87
gap = abs(tpr(group_a) - tpr(group_b))
assert gap < 0.05, f"fairness gap too wide: {gap:.3f}"

In plain English

Another name for white-box testing — tests are designed from the code’s structure, not from the spec.

From real testing work

Where you meet this in real work: during a sprint, structural testing is the piece of vocabulary a tester reaches for when explaining a decision to a developer or a stakeholder — for example, justifying in a stand-up why a specific check belongs in this build rather than the next. Structural = white-box. Watch for exam questions that use the two terms as synonyms.

In plain English

Design tests using the code, control-flow, data-flow, or architecture — not just the spec.

From real testing work

Two weeks before a release the test manager compares planned versus executed cases, open defects by severity, and remaining effort. Structure-Based Testing is where that number comes from — and the exam cares that it is used to inform a decision, not just published.

In plain English

Generate tests from the grammar of the inputs (e.g. a BNF) — one test per production rule, plus invalid mutations.

From real testing work

Where you meet this in real work: during a sprint, syntax testing is the piece of vocabulary a tester reaches for when explaining a decision to a developer or a stakeholder — for example, justifying in a stand-up why a specific check belongs in this build rather than the next. Syntax testing is powerful for parsers, APIs and file-format processors.

In plain English

The source of truth you derive tests from — requirements, user stories, models, code, or standards.

From real testing work

A résumé-screening model scores candidates from 0 to 1. There is no single expected value to assert against, so test basis is checked statistically: accuracy on a held-out set, score distribution compared across demographic slices, and an alert when the live distribution drifts from training.

assert accuracy_score(y_true, y_pred) >= 0.87
gap = abs(tpr(group_a) - tpr(group_b))
assert gap < 0.05, f"fairness gap too wide: {gap:.3f}"

In plain English

A single, executable check with a clear setup, action, and expected outcome — the atomic unit of testing.

From real testing work

The same discount rule is verified three times: in a unit test on the calculator, in an API test against the pricing service, and once through the UI at checkout. Test Case names one of those layers — different test basis, different owner, different defects found.

// component level
expect(calcDiscount(100, "SAVE10")).toBe(90);
// system level
const res = await api.post("/cart/apply", { code: "SAVE10" });
expect(res.body.total).toBe(90);

In plain English

A short mission for an exploratory session — what to explore, for how long, and with what goal.

From real testing work

Before a release the team books two 90-minute sessions against the new payments screen. Test Charter is what they are doing: no scripted steps, a written charter ("probe refund handling on expired cards"), notes taken as they go, and a debrief that turns findings into defect reports.

In plain English

A ‘what to test’ statement — one idea, one risk, or one requirement — that later becomes one or more test cases.

From real testing work

In sprint planning, payment processing scores high likelihood and high impact while the marketing footer scores low on both. Test Condition is how the team justifies spending 60% of the test effort on 10% of the codebase — to a stakeholder, in one sentence.

In plain English

How much of a chosen coverage target (statements, branches, requirements, risks) your tests actually hit.

From real testing work

After a sprint of bug fixes the team runs the unit suite with coverage on and finds the discount calculator sits at 62%. Test Coverage tells them which lines or branches never executed — usually the error paths nobody wrote a test for.

npx vitest run --coverage
# ---------------------|---------|----------|
# File                 | % Stmts | % Branch |
# discount.ts          |   62.5  |   41.6   |

In plain English

The concrete inputs you feed into a test — users, products, edge-case values.

From real testing work

A story reads "As a returning customer I can reuse a saved card." Before estimating it, the three amigos add acceptance criteria for an expired card and a card removed from the account. Test Data is the artefact or link involved, and it is what lets you prove later that every requirement has at least one test.

In plain English

The ordered ‘recipe’ for running a batch of test cases end-to-end, including setup and cleanup.

From real testing work

Where you meet this in real work: during a sprint, test procedure is the piece of vocabulary a tester reaches for when explaining a decision to a developer or a stakeholder — for example, justifying in a stand-up why a specific check belongs in this build rather than the next. Test procedures are produced during test implementation; automated versions are called test scripts.

In plain English

An automated test procedure — code that a tool runs against the system.

From real testing work

The regression pack runs on every merge to main and blocks the deploy when it fails. Test Script is the piece of that setup being named here — and the cost is not writing the tests, it is keeping them green when the UI changes next sprint.

- name: Regression suite
  run: npx playwright test --grep @regression
- name: Publish report
  if: always()
  uses: actions/upload-artifact@v4
  with: { name: playwright-report, path: playwright-report/ }

In plain English

A grouped bundle of tests — e.g. ‘smoke suite’, ‘nightly regression suite’.

From real testing work

The regression pack runs on every merge to main and blocks the deploy when it fails. Test Suite is the piece of that setup being named here — and the cost is not writing the tests, it is keeping them green when the UI changes next sprint.

- name: Regression suite
  run: npx playwright test --grep @regression
- name: Publish report
  if: always()
  uses: actions/upload-artifact@v4
  with: { name: playwright-report, path: playwright-report/ }

In plain English

A named method (EP, BVA, decision table, exploratory, etc.) for coming up with test cases in a systematic way.

From real testing work

A loan-approval rule that depends on income, credit score and existing debt has eight input combinations. Modelling it with test technique turns an argument in a refinement meeting into a table the BA, the developer and the tester all sign off on, and each row becomes one test case.

Income OK | Score >700 | Debt <40% | Expected
    Y     |     Y      |    Y     | APPROVE
    Y     |     Y      |    N     | REFER
    Y     |     N      |    Y     | REFER
    N     |     -      |    -     | DECLINE

In plain English

Themed exploratory testing missions — e.g. the “money tour” visits every payment flow.

From real testing work

Before a release the team books two 90-minute sessions against the new payments screen. Testing Tours is what they are doing: no scripted steps, a written charter ("probe refund handling on expired cards"), notes taken as they go, and a debrief that turns findings into defect reports.

In plain English

Pick three values at each boundary: the value just below, the boundary itself, and the value just above. Catches off-by-one bugs on either side.

From real testing work

On a checkout form that accepts a quantity between 1 and 99, three-value boundary value analysis is what stops you writing 99 test cases. You pick one value from inside the valid range and the values sitting either side of each edge, then let the rest of the range go untested on purpose.

// quantity field: valid 1..99
test.each([0, 1, 2, 98, 99, 100])("quantity %i", (qty) => {
  const res = validateQuantity(qty);
  expect(res.valid).toBe(qty >= 1 && qty <= 99);
});

In plain English

Pick exactly two values at each boundary: the boundary itself and the one just past it. Cheaper coverage than the three-value variant.

From real testing work

On a checkout form that accepts a quantity between 1 and 99, two-value boundary value analysis is what stops you writing 99 test cases. You pick one value from inside the valid range and the values sitting either side of each edge, then let the rest of the range go untested on purpose.

// quantity field: valid 1..99
test.each([0, 1, 2, 98, 99, 100])("quantity %i", (qty) => {
  const res = validateQuantity(qty);
  expect(res.valid).toBe(qty >= 1 && qty <= 99);
});

In plain English

A step-by-step story of how a user gets something done with the system, including alternate and error paths.

From real testing work

A tester files: "Checkout returns HTTP 500 when the cart contains a gift card and a subscription." Steps, expected, actual, environment, build number. Use Case is one of the fields or states in that workflow, and getting the term right is what makes the report actionable for the developer picking it up at 9am.

In plain English

Take a real user journey — like ‘checkout with a coupon’ — and turn each main and alternative flow into a test case.

From real testing work

A loan-approval rule that depends on income, credit score and existing debt has eight input combinations. Modelling it with use case testing turns an argument in a refinement meeting into a table the BA, the developer and the tester all sign off on, and each row becomes one test case.

Income OK | Score >700 | Debt <40% | Expected
    Y     |     Y      |    Y     | APPROVE
    Y     |     Y      |    N     | REFER
    Y     |     N      |    Y     | REFER
    N     |     -      |    -     | DECLINE

In plain English

A group of good inputs the system is supposed to accept — the happy-path partition.

From real testing work

On a checkout form that accepts a quantity between 1 and 99, valid partition is what stops you writing 99 test cases. You pick one value from inside the valid range and the values sitting either side of each edge, then let the rest of the range go untested on purpose.

// quantity field: valid 1..99
test.each([0, 1, 2, 98, 99, 100])("quantity %i", (qty) => {
  const res = validateQuantity(qty);
  expect(res.valid).toBe(qty >= 1 && qty <= 99);
});

In plain English

Pixel-diff the UI against a saved baseline and flag anything that changed.

From real testing work

A fix goes in for a broken invoice total. The failed test is re-run to confirm the fix, and the surrounding billing suite is re-run to check nothing else moved. Visual Regression Testing is one half of that pair — mixing the two up is the single most common vocabulary slip in Chapter 2.

In plain English

You design tests using knowledge of the code — branches, statements, paths — to hit specific structural coverage targets.

From real testing work

After a sprint of bug fixes the team runs the unit suite with coverage on and finds the discount calculator sits at 62%. White-Box Testing tells them which lines or branches never executed — usually the error paths nobody wrote a test for.

npx vitest run --coverage
# ---------------------|---------|----------|
# File                 | % Stmts | % Branch |
# discount.ts          |   62.5  |   41.6   |