QA Glossary

Terms I use day to day, explained briefly. In alphabetical order.

Acceptance criteria — Concrete, verifiable conditions a user story must meet to be considered done. If they aren't testable, they aren't acceptance criteria.

Bug (defect) — Discrepancy between actual and expected behavior. The usual chain: human error → defect in the code → observable failure at runtime.

Contract testing — Verifying that the "contract" (request/response format) between an API consumer and provider is honored, without needing to spin up both systems together. Key in microservices.

Coverage — A measure of how much of the system the tests exercise (lines, branches, requirements). High coverage ≠ good tests: you can execute all the code without verifying anything.

DoD (Definition of Done) — A team-agreed checklist defining when a piece of work is truly finished (code + tests + review + documentation…).

DoR (Definition of Ready) — A checklist defining when a story is ready to be started: clear requirements, testable acceptance criteria, resolved dependencies. The mirror of the DoD, at the start of the cycle.

E2E (End to End) — A test that walks through a complete system flow from the user's perspective, crossing every layer.

Environment — Each instance where the application lives: local, development, staging (pre-production), production.

Flaky test — A test that sometimes passes and sometimes fails without any code change. Typical causes: poorly managed waits, dependence on shared data, execution order, unstable environment.

Given-When-Then — A structure for expressing test cases and acceptance criteria: Given (initial state), When (action), Then (expected result). It makes cases readable and unambiguous.

Happy path — The main flow where everything goes right: valid data, correct user, no errors. The opposite is edge cases and negative testing.

Hotfix — An urgent fix deployed to production outside the normal release cycle.

IDOR (Insecure Direct Object Reference) — An authorization vulnerability: accessing another user's resources by changing an ID in the request.

Mock / Stub — Controlled stand-ins for real dependencies (services, APIs) to isolate what's being tested.

POM (Page Object Model) — A design pattern for UI automation: each page/component is modeled as a class encapsulating its locators and actions. Tests talk to the page in business language (loginPage.login(user)), not in selectors.

Quality gate — An automatic quality threshold (coverage, bugs, code smells, duplication) that code must pass in CI to be mergeable.

Regression — A defect in something that used to work, introduced by a later change. Regression testing: re-running tests to catch them.

Release — A version of the software that gets published. Release notes: what it includes.

Root cause — The real origin of a defect, beyond the symptom. Classifying the root causes of bugs (ambiguous requirement, unhandled case, regression, data…) reveals patterns that steer the testing strategy.

Sharding — Splitting the test suite across several CI machines running in parallel. Total time is set by the slowest shard, which is why balancing the split by duration matters.

Shift-left — Moving quality activities as early as possible in the cycle: reviewing requirements, testing designs, automating from the first commit.

Smoke test — A minimal, fast check that the essentials work, before investing in deeper testing.

Test case — A set of preconditions, steps, data and expected result that verifies a specific behavior.

Test plan — A document defining the scope, approach, resources and schedule of testing activities.

Traceability — The relationship between requirements ↔ test cases ↔ bugs. It lets you answer "which requirements are covered?" and "which tests should I re-run if this requirement changes?".

UAT (User Acceptance Testing) — Acceptance testing performed by the customer or end users to validate that the product solves their need.