ISTQB Glossary — Chapter 5: Managing the Test Activities

In plain English

Ask 'why?' five times to drill from symptom to root cause.

From real testing work

Where you meet this in real work: during a sprint, 5 whys 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. Simple, cheap, and often the first RCA technique to try.

In plain English

Estimate this project by looking at how long a similar one took.

From real testing work

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

In plain English

Base your testing on a formal analysis of requirements, risks or the code — the most common test strategy.

From real testing work

In sprint planning, payment processing scores high likelihood and high impact while the marketing footer scores low on both. Analytical Test Strategy 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

The written output of an audit — what was checked, what's compliant, what isn't.

From real testing work

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

In plain English

Percentage of time the system is up and usable — the 'nines' number.

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. Availability 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

A frozen version of a document or build that becomes the reference point for everything after it.

From real testing work

A requirements review on a "forgot password" story raises that the acceptance criteria never say what happens to an unverified email address. That is baseline in practice — an issue found in a document, before a single line of code exists, at a fraction of the cost of finding it in UAT.

In plain English

A specific compiled version of the software ready to be tested or deployed.

From real testing work

The regression pack runs on every merge to main and blocks the deploy when it fails. Build 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

Quick pass/fail check that a new build is stable enough to test further.

From real testing work

The regression pack runs on every merge to main and blocks the deploy when it fails. Build Verification Test 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

The formal process for proposing, approving, and tracking changes.

From real testing work

A requirements review on a "forgot password" story raises that the acceptance criteria never say what happens to an unverified email address. That is change management in practice — an issue found in a document, before a single line of code exists, at a fraction of the cost of finding it in UAT.

In plain English

A ticket that asks for a specific change to be considered.

From real testing work

Where you meet this in real work: during a sprint, change request 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. Every accepted change request should trigger an impact analysis.

In plain English

A staged model that rates how mature an organisation's processes are.

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 cmmi 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

Anything under version/change control: a source file, a doc, a test script, a build.

From real testing work

The regression pack runs on every merge to main and blocks the deploy when it fails. Configuration Item 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

The process that keeps track of what code, data, docs and environments belong together at every point in time.

From real testing work

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

In plain English

Let SMEs and stakeholders dictate what to test — used when the testers lack domain knowledge.

From real testing work

Where you meet this in real work: during a sprint, consultative test strategy 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. Consultative strategies are common in specialized domains (finance, medical, telecom).

In plain English

Prevention + appraisal + internal failure + external failure costs.

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. Cost of Quality 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

How long a bug lived before it was found or resolved.

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. Defect Age 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

How many new bugs are being logged per day / sprint / build.

From real testing work

The regression pack runs on every merge to main and blocks the deploy when it fails. Defect Arrival Rate 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

What share of eventual bugs did this test level catch? Higher is better.

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. Defect Detection Percentage 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

The journey a bug takes from being reported to being closed.

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. Defect Lifecycle 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

The end-to-end workflow of finding, logging, triaging, fixing and closing bugs.

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. Defect Management 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

How many of the eventual bugs did this phase catch?

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. Defect Removal Efficiency 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

The written record of a bug — title, steps, expected vs. actual, severity, priority, environment.

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. Defect Report 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

A regular meeting where the team looks at new bugs and decides which to fix now, later or never.

From real testing work

A requirements review on a "forgot password" story raises that the acceptance criteria never say what happens to an unverified email address. That is defect triage in practice — an issue found in a document, before a single line of code exists, at a fraction of the cost of finding it in UAT.

In plain English

Getting the software running in an environment (test, staging, prod).

From real testing work

Staging has last quarter's anonymised production snapshot, seeded with fifteen deliberately broken accounts. Deployment 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

The checklist that must be true before a test level or activity can start — e.g. build deployed, smoke passed.

From real testing work

The regression pack runs on every merge to main and blocks the deploy when it fails. Entry Criteria 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 bug that slipped past your tests and reached the next stage or production.

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. Escaped Defect 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

The checklist that must be true before you can declare testing done — coverage hit, no open blockers, etc.

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%. Exit Criteria 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

Ask someone experienced how long it will take.

From real testing work

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

In plain English

For each component, brainstorm how it could fail, what happens if it does, and how to prevent or detect it.

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. Failure Mode and Effects Analysis 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

How often the software fails per hour, per transaction, per run.

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. Failure Rate 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 says pass, but there is a real bug — the worst kind of miss.

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. False Negative 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 says fail, but the software is actually fine — often flaky tests or bad data.

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. False Positive 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

Ishikawa / cause-and-effect diagram: brainstorm causes into people / process / tools / environment.

From real testing work

Staging has last quarter's anonymised production snapshot, seeded with fifteen deliberately broken accounts. Fishbone Diagram 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

Sizing software by counting inputs, outputs, inquiries, files, and interfaces.

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. Function Point Analysis sits on that side of the fence: preventive and process-oriented, distinct from executing tests against a build.

In plain English

A checklist of five quality dimensions: F, U, R, P, S.

From real testing work

Before a Black Friday sale, the team models 5,000 concurrent shoppers against staging. FURPS is the part of that exercise that answers a specific question — not "is it fast", but "at what point does it stop being fast, and what breaks first".

// k6 scenario
export const options = {
  stages: [
    { duration: "2m", target: 500 },
    { duration: "5m", target: 5000 },
    { duration: "2m", target: 0 },
  ],
  thresholds: { http_req_duration: ["p(95)<800"] },
};

In plain English

The IEEE standard for classifying software bugs.

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. IEEE 1044 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

The classic template list for test docs: plan, design, case, procedure, log, incident, summary.

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. IEEE 829 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

Anything unexpected in test or production that needs looking into.

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. Incident 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

The umbrella standard describing all software life-cycle processes.

From real testing work

The regression pack runs on every merge to main and blocks the deploy when it fails. ISO/IEC 12207 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

The old quality model — replaced by ISO 25010 but still cited.

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 iso/iec 9126 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

The modern successor to IEEE 829 — covers processes, docs, techniques.

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. ISO/IEC/IEEE 29119 sits on that side of the fence: preventive and process-oriented, distinct from executing tests against a build.

In plain English

Any open question — a possible defect, a doc discrepancy, a process problem — that needs a decision.

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. Issue 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

The insights captured at the end of a project so the next one doesn't repeat mistakes.

From real testing work

Where you meet this in real work: during a sprint, lessons learned 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. Lessons learned belong in test completion, not in someone's private notes.

In plain English

The test plan for a single level (e.g. system testing) — scope, entry/exit, environment, schedule.

From real testing work

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

In plain English

One plan that covers unit, integration, system and acceptance testing at the program level.

From real testing work

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

In plain English

For a system that gets fixed, the average uptime between two failures.

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. Mean Time Between Failures 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

On average, how long the system runs between failures.

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. Mean Time Between Failures 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

On average, how long the system runs before it fails.

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. Mean Time To Failure 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

On average, how fast we get back up after breaking.

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. Mean Time to Recover 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

The average time from a failure to the system being back up.

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. Mean Time To Repair 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

Reuse a standard checklist (e.g. accessibility, security, quality attributes) as the test baseline.

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 methodical test strategy: 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

Build a model (state machine, business process) and let the tool generate tests from it.

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 model-based test strategy 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

The blameless review meeting after a major incident or release.

From real testing work

A requirements review on a "forgot password" story raises that the acceptance criteria never say what happens to an unverified email address. That is postmortem in practice — an issue found in a document, before a single line of code exists, at a fraction of the cost of finding it in UAT.

In plain English

How urgently the bug should be fixed from a business point of view — a low-severity blocker for a demo can still be top priority.

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. Priority 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

Do exactly what a standard (ISO 29119, DO-178C, IEC 62304) says — common in regulated industries.

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. Process-Compliant Test Strategy sits on that side of the fence: preventive and process-oriented, distinct from executing tests against a build.

In plain English

Things that could go wrong with the product itself — a bug, a data loss, a security flaw.

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 product risk: 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

A bug found in live use — usually the most expensive kind.

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. Production Defect 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

Things that could derail the project itself — late environments, sick team members, unclear scope.

From real testing work

In sprint planning, payment processing scores high likelihood and high impact while the marketing footer scores low on both. Project Risk 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

A published rulebook for quality (ISO 25010, IEEE 829, etc.) you can measure your product against.

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. Quality Standard sits on that side of the fence: preventive and process-oriented, distinct from executing tests against a build.

In plain English

Don't pre-design tests — react to the build in front of you (exploratory, error guessing, attacks).

From real testing work

Before a release the team books two 90-minute sessions against the new payments screen. Reactive Test Strategy 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

Prioritize keeping working features working — heavy automation, wide regression packs, impact analysis.

From real testing work

The regression pack runs on every merge to main and blocks the deploy when it fails. Regression-Averse Test Strategy 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

The end-to-end process for moving software from dev to production.

From real testing work

The regression pack runs on every merge to main and blocks the deploy when it fails. Release Management 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

Something that might happen and would hurt the project, product or business if it did.

From real testing work

In sprint planning, payment processing scores high likelihood and high impact while the marketing footer scores low on both. Risk 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

Find risks, judge how bad and how likely each one is, and decide what to do about them.

From real testing work

In sprint planning, payment processing scores high likelihood and high impact while the marketing footer scores low on both. Risk Analysis 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

Score each risk on likelihood × impact so you can rank them.

From real testing work

In sprint planning, payment processing scores high likelihood and high impact while the marketing footer scores low on both. Risk Assessment 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 many of the known product risks actually have tests behind 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%. Risk 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 single number (often likelihood × impact) that says how much attention a risk deserves.

From real testing work

In sprint planning, payment processing scores high likelihood and high impact while the marketing footer scores low on both. Risk Level 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

The actions you take to shrink a risk — extra testing, code review, redesign, insurance.

From real testing work

A requirements review on a "forgot password" story raises that the acceptance criteria never say what happens to an unverified email address. That is risk mitigation in practice — an issue found in a document, before a single line of code exists, at a fraction of the cost of finding it in UAT.

In plain English

You test the risky stuff first and hardest. Low-risk areas get lighter coverage.

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%. Risk-Based 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

Undo the release and put the previous version back.

From real testing work

Staging has last quarter's anonymised production snapshot, seeded with fifteen deliberately broken accounts. Rollback 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

How bad the bug is technically — does it crash the app, corrupt data, or just misalign a label?

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. Severity 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

Anyone who has skin in the game — product owner, users, ops, compliance, marketing.

From real testing work

Where you meet this in real work: during a sprint, stakeholder 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 reports should be tailored to the stakeholder's concerns, not one-size-fits-all.

In plain English

A rulebook everyone in a domain agrees to follow — can be industry, national or international.

From real testing work

A requirements review on a "forgot password" story raises that the acceptance criteria never say what happens to an unverified email address. That is standard in practice — an issue found in a document, before a single line of code exists, at a fraction of the cost of finding it in UAT.

In plain English

Common shorthand for whatever you're testing right now.

From real testing work

Where you meet this in real work: during a sprint, system under test 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. SUT is standard vocabulary in automation and performance testing.

In plain English

The role that turns requirements and risks into detailed test conditions and 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 Analyst 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 this project actually applies the organisation’s test strategy — tailored to its risks and constraints.

From real testing work

In sprint planning, payment processing scores high likelihood and high impact while the marketing footer scores low on both. Test Approach 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

Reacting to what monitoring shows — adding testers, rescoping, prioritizing risks, changing the plan.

From real testing work

In sprint planning, payment processing scores high likelihood and high impact while the marketing footer scores low on both. Test Control 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

What share of the target items your tests hit — code, requirements, risks, etc.

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

Estimate how much time and how many people the testing will need, using metrics, expert judgment or comparison to past projects.

From real testing work

Two weeks before a release the test manager compares planned versus executed cases, open defects by severity, and remaining effort. Test Effort Estimation 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 setup where tests run — servers, browsers, DBs, feature flags — ideally close to production.

From real testing work

The Android app works perfectly on the team's Pixel and crashes on a three-year-old budget device on a 3G connection. Test Environment is what keeps that from reaching production: a device matrix chosen from real analytics, not from what is on people's desks.

In plain English

Predicting how much time, money, and effort testing will take.

From real testing work

Two weeks before a release the test manager compares planned versus executed cases, open defects by severity, and remaining effort. Test Estimation 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 one-line note about a test worth running, before it becomes a formal case.

From real testing work

Where you meet this in real work: during a sprint, test idea 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 ideas are the raw material that grow into charters and test cases.

In plain English

The senior tester who coordinates work, mentors the team, and interfaces with dev leads and PMs.

From real testing work

Where you meet this in real work: during a sprint, test lead 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 lead is often confused with test manager — lead is technical, manager is planning/reporting.

In plain English

One of the layers of testing: unit, integration, system, acceptance.

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 Level 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

The receipt of a test run — which tests ran, when, on what build, and what they returned.

From real testing work

The regression pack runs on every merge to main and blocks the deploy when it fails. Test Log 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

Owns test planning, staffing, budget and reporting for a project or release.

From real testing work

Two weeks before a release the test manager compares planned versus executed cases, open defects by severity, and remaining effort. Test Manager 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 number you track to know how testing is going — coverage %, defects found, tests passed.

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 Metric 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

Keeping an eye on how testing is going — coverage, pass rates, defects — against the plan.

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 Monitoring 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

Watch how testing is going against the plan and steer it back on course when it drifts.

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 monitoring and control 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

Numbers you watch during a test cycle — cases run, pass rate, defects.

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. Test Monitoring Metric 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

The document that answers ‘what, when, how, and by whom’ for the testing effort — scope, schedule, risks, entry and exit criteria.

From real testing work

In sprint planning, payment processing scores high likelihood and high impact while the marketing footer scores low on both. Test Plan 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

The company-wide statement of why and how testing happens — signed off by senior management.

From real testing work

Where you meet this in real work: during a sprint, test policy 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 policy sits above test strategy: policy = organization-level, strategy = program-level.

In plain English

The seven ISTQB activities that together make up testing on a project.

From real testing work

Two weeks before a release the test manager compares planned versus executed cases, open defects by severity, and remaining effort. Test Process 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 number that tells you how far testing has progressed — tests run, tests passed, defects open.

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. Test Progress Metric 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

A recurring status report during testing — usually weekly or per sprint — showing burn-down and risks.

From real testing work

In sprint planning, payment processing scores high likelihood and high impact while the marketing footer scores low on both. Test Progress Report 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

The write-up that tells stakeholders how testing went and whether the product is ready to ship.

From real testing work

Two weeks before a release the test manager compares planned versus executed cases, open defects by severity, and remaining effort. Test Report 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 organisation-wide ‘how we test’ document — reused across projects — that project test plans reference.

From real testing work

The regression pack runs on every merge to main and blocks the deploy when it fails. Test Strategy 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

The final report at the end of a test level or release — what shipped, what didn’t, and why.

From real testing work

Two weeks before a release the test manager compares planned versus executed cases, open defects by severity, and remaining effort. Test Summary Report 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 category of testing — functional, non-functional, structural, change-related.

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. Test Type sits on that side of the fence: preventive and process-oriented, distinct from executing tests against a build.

In plain English

The individual contributor who plans, builds and runs tests day-to-day.

From real testing work

The regression pack runs on every merge to main and blocks the deploy when it fails. Tester 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

Estimate best-case, worst-case and most-likely, then combine: E = (O + 4M + P) / 6.

From real testing work

Two weeks before a release the test manager compares planned versus executed cases, open defects by severity, and remaining effort. Three-Point Estimation 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 Sogeti-originated test management method used mainly in Europe.

From real testing work

Where you meet this in real work: during a sprint, tmap 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. TMap emphasizes structured planning, techniques, and roles — a classical alternative to ISTQB’s framework.

In plain English

CMMI's testing-focused sibling — 5 levels of test process maturity.

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 tmmi 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 framework for grading and improving how your test team works.

From real testing work

The regression pack runs on every merge to main and blocks the deploy when it fails. TPI Next 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

Being able to prove which tests cover which requirement, story or risk — both ways.

From real testing work

In sprint planning, payment processing scores high likelihood and high impact while the marketing footer scores low on both. Traceability 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

Sizing effort by counting weighted use cases and actors.

From real testing work

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

In plain English

Git, SVN — the tool that lets many people edit the same code without losing changes.

From real testing work

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

In plain English

Experts estimate anonymously in rounds, discuss the outliers, and repeat until they converge.

From real testing work

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

In plain English

Break the work into tiny tasks, estimate each, add them up.

From real testing work

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