Glossary

The vocabulary four roles share when they are working from one set of requirements. Definitions are deliberately plain. Where a term carries a judgement worth arguing about, that sits below the definition rather than inside it.

Acceptance criteria: The conditions that must be true for a requirement to count as delivered, agreed before development starts.; Written before the build, they are a contract that aligns four roles. Written afterwards, they describe whatever got built and the agreement they were meant to create never happened.; Covered inWriting acceptance criteria that hold up; See also: Definition of done, Testability
Blocked: A test result meaning the test could not run. A statement about the environment, not about the product.; Recording blocked as a failure invents defects; recording it as a pass invents coverage. Kept separate, a rising blocked count becomes a signal about your environment in its own right.; Covered inRunning a test cycle: a TestExecute guide; See also: Coverage, Release readiness
Boundary value: An input at the exact edge of a rule, and the values immediately either side of it.; If a rule changes at fifty thousand rows, the interesting values are 49999, 50000, and 50001. Testing 100 tells you almost nothing about the rule.; Covered inWhat a QA Engineer actually does Writing acceptance criteria that hold up; See also: Negative testing, Test case
Coverage: The proportion of agreed behaviour that has tests verifying it. Only meaningful once you say coverage of what.; Coverage of requirements hides gaps, because a requirement with three tests can still have half its criteria unverified. Coverage of acceptance criteria is the number worth reporting.; Covered inA traceability matrix people actually use Generating test cases from requirements; See also: Traceability, Acceptance criteria
Defect triage: The regular review that assigns severity and priority to open defects and decides what happens to each.; Triage is faster when severity and priority are separate fields and when deferring is an explicit accepted-risk decision rather than a ticket quietly going silent.; Covered inTracking defects across the pipeline; See also: Severity, Priority
Definition of done: The agreed bar an item must clear before it counts as finished, applied to every item rather than negotiated per story.; Drawn in advance it is a decision. Drawn at the end under deadline pressure it is a negotiation, and pressure wins.; Covered inWhat a Product Owner actually owns A release readiness checklist worth using; See also: Definition of ready, Release readiness
Definition of ready: The agreed bar an item must clear before a team will start work on it.; Usually includes having acceptance criteria, no unresolved blocking dependency, and being small enough to finish. Its real function is giving the team a defensible reason to say not yet.; Covered inWhat a Product Owner actually owns; See also: Definition of done, Acceptance criteria
Elaboration: Turning a rough requirement into a structured one carrying criteria, rules, data expectations, negative paths, and stated assumptions.; The assumptions list is usually the most valuable part, because it converts a silent resolution in somebody's code into a visible question.; Covered inRequirement Studio: rough to testable; See also: Acceptance criteria, Use case
Epic: A body of work too large to finish in one iteration, intended to be broken into smaller items.; An epic that never gets decomposed is just a large ticket. The decomposition is where the team decides whether value can arrive incrementally or only at the end.; Covered inHow to decompose an epic into user stories Breaking a requirement into features; See also: User story, Vertical slice
INVEST: A checklist for user story quality: independent, negotiable, valuable, estimable, small, testable.; Independent and valuable are the two that catch bad slicing. A story that cannot ship alone or is worth nothing alone was cut along a technical layer rather than an outcome.; Covered inHow to decompose an epic into user stories; See also: User story, Vertical slice
MoSCoW: A prioritisation scheme sorting items into must have, should have, could have, and will not have.; The category doing the work is will not have. A scheme where nothing is ever declined is a queue with labels on it.; Covered inBreaking a requirement into features How to decompose an epic into user stories; See also: Priority
Negative testing: Testing what happens when things go wrong: invalid input, missing data, failed dependencies, insufficient permissions.; The happy path is the least likely source of defects because everyone has already thought about it. Negative paths are where late, expensive defects actually live.; Covered inWhat a QA Engineer actually does Writing acceptance criteria that hold up; See also: Boundary value, Testability
Priority: How soon a defect must be fixed. A commercial decision, not a technical one.; A low severity defect on the checkout button can legitimately be the most urgent thing you have. Priority belongs to the Product Owner because it depends on context no tester has.; Covered inTracking defects across the pipeline What a QA Engineer actually does; See also: Severity, MoSCoW
Release readiness: Whether the evidence supports shipping: scope agreed, criteria covered, defects understood, rollback tested.; A readiness review where no is not genuinely available is a briefing rather than a decision, and everyone in the room knows it.; Covered inA release readiness checklist worth using What a Delivery Manager actually tracks; See also: Definition of done, Coverage
Requirements traceability matrix: A view of the links between requirements, criteria, tests, results, and defects, usually abbreviated to RTM.; Maintained as a spreadsheet for auditors it goes stale within a week. Maintained as the thing the team uses to answer real questions, it stays current because letting it rot has an immediate cost.; Covered inA traceability matrix people actually use; See also: Traceability
Severity: How badly the system misbehaves when a defect occurs. A judgement about observed behaviour.; Severity belongs to whoever observed the failure, usually a QA Engineer. Keeping it separate from priority is what stops triage from averaging two incomparable judgements into one useless number.; Covered inTracking defects across the pipeline What a QA Engineer actually does; See also: Priority, Defect triage
Test case: A specific claim that if you do something under stated preconditions, a stated result follows.; Written from the requirement it is independent evidence. Written from the finished build it inherits whatever the developer assumed, including the wrong assumptions.; Covered inGenerating test cases from requirements What a QA Engineer actually does; See also: Coverage, Boundary value
Testability: The property of a requirement that lets someone design a test which the system could plausibly fail.; The practical check is whether you can describe a concrete failure. If you cannot, you have written a preference rather than a requirement, and nobody will verify it.; Covered inWriting acceptance criteria that hold up What a Business Analyst actually does; See also: Acceptance criteria, Negative testing
Traceability: The maintained links between a requirement, its acceptance criteria, the tests that verify them, the results, and any resulting defects.; It answers what breaks when a requirement changes, and what a failing test actually costs. It only survives if it is generated by doing the work rather than maintained as separate effort.; Covered inA traceability matrix people actually use Reporting coverage and traceability; See also: Coverage, Requirements traceability matrix
Use case: A described sequence: actors, preconditions, a trigger, numbered main flow steps, alternate flows, and outcomes.; Alternate flows carry the value. They are the branches a requirement implies without stating, and they will exist in the code whether or not anyone specified them.; Covered inFrom requirements to use cases; See also: Elaboration, Negative testing
User story: A small unit of work described in terms of who needs it and what outcome it delivers.; The format matters far less than the property underneath it: a story should be releasable on its own and worth something on its own. Tasks that fail that test are fine, they are just not stories.; Covered inHow to decompose an epic into user stories; See also: INVEST, Epic, Vertical slice
Vertical slice: A unit of work that goes through every layer it needs to and delivers one narrow but complete outcome.; The opposite of slicing by technical layer. A vertical slice can be released and judged; a horizontal one cannot be either until the last slice lands.; Covered inHow to decompose an epic into user stories; See also: User story, INVEST