ISTQB Glossary — Chapter 3: Static Testing

In plain English

Reviewers just read the work product freely with no checklist or roles.

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 ad hoc review 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

Anything unexpected the reviewer or tester notices — may or may not be a real defect.

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

An external, formal check that a team is following the documented process and standards.

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

Whoever wrote the document or code under review.

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

The person whose document or code is under review.

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 author 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 diagram showing which functions call which other functions.

From real testing work

Where you meet this in real work: during a sprint, call graph 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. Call graphs come from static analysis and help scope regression testing after a change.

In plain English

Reviewers use a pre-made checklist of common defect types to guide what to look for.

From real testing work

Before a release the team books two 90-minute sessions against the new payments screen. Checklist-Based Review 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

Another engineer reading your code before it merges.

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 code review 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 pattern in code (long function, duplicate code, huge class) that suggests a design problem.

From real testing work

Where you meet this in real work: during a sprint, code smell 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. Code smells are found by static analysis tools like SonarQube — they aren't defects yet but predict future ones.

In plain English

Team-agreed rules for naming, formatting and structuring code so everyone writes it the same way.

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

In plain English

Static analysis that maps every possible execution path to check for unreachable or infinite loops.

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 control flow analysis 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 metric that counts branches in code — higher number means the code is harder to test.

From real testing work

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

In plain English

Static-analysis technique that tracks where variables are set and read to find bugs like use-before-define.

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 data flow analysis 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 many defects per 1,000 lines of code, page of spec, or story point.

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 Density 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 a work product must pass before it enters review — spellcheck done, template followed, etc.

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 entry criteria 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

The mistake a person made — the wrong requirement, wrong design, wrong line of code.

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 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 rules that say the review is finished — all major defects logged, checklist covered, sign-off given.

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 exit criteria 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

Any review with defined roles, checklists, metrics and entry/exit criteria.

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 formal review 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

Each reviewer reads the work product on their own before the group meeting.

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 individual review 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 quick, unstructured read-through with no checklists, roles or logged results.

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 informal review 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

The most formal review type — trained moderator, defined roles, entry/exit criteria, metrics collected.

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 inspection 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 fast the review team is covering material.

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 inspection rate 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

The opening meeting where the moderator explains the review objectives and hands out material.

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 kickoff 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 tool like ESLint or Pylint that reads code and warns about likely problems.

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 lint 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 easily developers can change, fix or extend the software later.

From real testing work

Where you meet this in real work: during a sprint, maintainability 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. Maintainability is a non-functional quality — improved by refactoring, coding standards and static analysis.

In plain English

A review that focuses on progress, risks and process — not on defects in the product.

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 management review 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

Testing where test cases are derived automatically from a model of the system's behaviour.

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

The person who runs the review meeting, keeps discussion on track and ensures the process is followed.

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

Any review where the reviewers are the author's peers — walkthroughs, technical reviews and inspections all qualify.

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 peer review 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

Each reviewer reads the document as if they were a specific stakeholder — user, tester, developer, operator.

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 perspective-based reading 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 easy it is for another person to understand the code or document.

From real testing work

Where you meet this in real work: during a sprint, readability 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. Reviews and static analysis both improve readability — high readability lowers maintenance cost.

In plain English

A statement of what the system must do or how well it must do it.

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

Someone reads or discusses a document (requirements, code, test cases) to find problems before running the software.

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

The formal group session where reviewers discuss what they found individually.

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 review meeting 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

The plan for what will be reviewed, by whom, and when.

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 review plan 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

The output of the review — list of defects found, metrics, and any process improvement suggestions.

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 review report 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

Anyone in the review meeting whose job is to find and describe defects.

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

Similar to perspective-based reading — each reviewer takes a role such as end-user or admin.

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 role-based review 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

The underlying reason a defect exists — fix this and the whole class of defect goes away.

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. Root Cause 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 structured investigation (5 Whys, fishbone) to find why a defect was introduced.

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. Root Cause 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

Reviewers walk realistic use scenarios through the document to check it supports them.

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 scenario-based review 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

The note-taker who logs every defect and comment raised during the review.

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 scribe 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 detailed document describing exactly what the system must do — the input to test design.

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

Tools scan source code, models or documents to find defects without running the software.

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 static analysis 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 examine the work product — requirements, design, code — without running it, using reviews or tools like linters.

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 static testing 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

Tools that check code, requirements or models without running them — linters, review platforms, SAST scanners.

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 static testing tool 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

Peers with technical expertise review a work product to agree it is technically sound.

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 technical review 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 grid that shows which test case covers which requirement.

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. Traceability Matrix 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 author walks the team through the document while others ask questions and spot defects.

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