Start free

The same word. The same meaning.

The vocabulary that comes up around bug reports, testing and release. Each term is defined in one sentence first, then explained. No statistics anybody would have to take on trust.

167

Each term is defined in one sentence first, then explained.

A shared vocabulary for the people who report, investigate and resolve.

All 167 terms

  • Acceptance criteria

    What acceptance criteria are, how to write conditions two people can check independently, and why they are agreed before the work starts rather than after.

  • Acceptance test-driven development

    What acceptance test-driven development is, how the acceptance tests are agreed before coding, how it differs from BDD and TDD, and what happens when it slips.

  • Accessibility testing

    What accessibility testing checks, automated scans versus assistive-technology testing, who is responsible for it, and why a clean scan is not a pass.

  • Ad hoc testing

    What ad hoc testing is, why it has no plan, charter or record, how it differs from exploratory and monkey testing, when it earns its place, and what it reports.

  • Agile spike

    What an agile spike is, the time-boxed story that produces knowledge instead of a feature, its Extreme Programming origin, and why it is not spike testing.

  • Agile testing quadrants

    What the agile testing quadrants are: Brian Marick's two-by-two matrix of business-facing and technology-facing tests, what goes in Q1 to Q4, and its use.

  • Alpha testing

    What alpha testing is, who does it and where, how it differs from beta testing and UAT, and why an alpha run by people who built the product proves little.

  • Behavior-driven development

    What behavior-driven development is, how Given/When/Then scenarios become executable tests, how it differs from TDD and ATDD, and where the practice decays.

  • Beta testing

    What beta testing is, open versus closed betas, how it differs from alpha testing and UAT, why beta reports arrive without context, and what makes them usable.

  • Boundary value analysis

    What boundary value analysis is, how to pick values around each edge, how it pairs with equivalence partitioning, and where boundary bugs hide in real forms.

  • Bug bash

    What a bug bash is, how to run one that produces triageable reports instead of a pile of duplicates, who to invite, and when in a release it earns its cost.

  • Bug life cycle

    The bug life cycle state by state, from reported to closed: what each state means, who moves a report between them, and where reports usually stall.

  • Bug reproduction

    What bug reproduction is, why a fix cannot be verified without it, which conditions have to match, and what to do with a defect that only happens sometimes.

  • Bug severity vs priority

    Bug severity measures damage, priority measures urgency. What each one means, who sets it, and why blending the two into one field breaks a triage queue.

  • Bug testing

    What bug testing means in practice, the techniques that actually surface defects, where bugs cluster in a system, and why an unreported finding is lost.

  • Bug tracking

    What bug tracking means as a practice, what makes a report genuinely tracked, how it differs from triage and the life cycle, and where records drift.

  • Bug triage

    What bug triage is, the four decisions every report gets, who should be in the meeting, and why a report that arrives with evidence is triaged the same day.

  • Build verification test

    What a build verification test is, how it relates to smoke testing, what belongs in the set and what does not, and why a failing BVT rejects the whole build.

  • Cache busting

    What cache busting is, how fingerprinted filenames and query strings force a fresh download, why a fixed bug is still visible to a tester, and where it fails.

  • Canary testing

    What canary testing is, how a change goes to a small share of real traffic and is compared with the current version, when to widen or roll back, and limits.

  • Changelog

    What a changelog is, how a CHANGELOG file groups notable changes by version with the newest first, what belongs in it, and how to keep one a person can read.

  • Characterization testing

    What characterization testing is, why it records current rather than correct behaviour, the golden master and approval variants, and when to write these tests.

  • Client-side error

    What a client-side error is, how it differs from a server-side error, why it is invisible to server logs, and what evidence a report needs to reproduce one.

  • Compatibility testing

    What compatibility testing checks, the browser and device matrix, how it differs from cross-browser testing, and why the failing cell is so hard to name.

  • Console error

    What a console error is as a tester sees it, how it differs from a warning and from the console.error() method, and what a report gains by attaching it.

  • Continuous delivery

    What continuous delivery is, how it differs from continuous integration and continuous deployment, what the pipeline does, and where the practice fails.

  • Contract testing

    What contract testing is in software, consumer-driven contracts, how it differs from integration testing and mocking, and what the physical-testing sense means.

  • Cross-device testing

    What cross-device testing is, how it differs from cross-browser testing, which device properties change a page's behaviour, and how to choose the set to cover.

  • Dark launch

    What a dark launch is, how code is deployed to production with the feature hidden to exercise it under real load, how shadow traffic is used, and what it risks.

  • Data-driven testing

    What data-driven testing is in test automation, how one script reads rows of inputs and expected results from a table, and where it saves effort or hides gaps.

  • Decision table testing

    What decision table testing is, how to build a table of conditions, combinations and actions, how it differs from boundary analysis, and where logic bugs hide.

  • Defect management

    What defect management is, the policies it sets around a bug tracker: classification, ownership, escalation and measurement, and where it differs from tracking.

  • Defect removal efficiency

    What defect removal efficiency is, how the ratio is calculated from defects found before and after release, what a low figure means, and its blind spots.

  • Defect vs bug

    Defect vs bug: what the two words mean in everyday use, how formal testing vocabulary separates error, defect and failure, and when the distinction matters.

  • Definition of done

    What a definition of done is, the shared checklist every increment must meet, how it differs from acceptance criteria, who owns it, and how it decays.

  • Definition of ready

    What a definition of ready is, what teams put on the checklist, why the Scrum Guide does not prescribe one, and how a ready gate turns into a hand-off.

  • Definition of ready vs definition of done

    Definition of ready vs definition of done: what each checklist gates, which one the Scrum Guide 2020 defines, who writes them, and how strictly each applies.

  • Design QA

    What design QA is, how it differs from functional QA and from a design review, who does it, when it runs, and why a note needs the element, not the screen.

  • Device fragmentation

    What device fragmentation is, what it varies across a user base, how it differs from browser fragmentation, and how teams bound it with a supported matrix.

  • Device pixel ratio

    What device pixel ratio is, how CSS pixels differ from physical pixels, why a screenshot is larger than the viewport it shows, and what a bug report records.

  • Dogfooding

    What dogfooding is, how it differs from alpha testing, beta testing and a bug bash, why companies do it, and when staff stop resembling customers.

  • Edge case

    What an edge case is in software testing, how it differs from a corner case and a boundary value, how testers find them, and why behaviour breaks at the limits.

  • Endurance testing

    What endurance testing (soak testing) is in software, how a long run at steady load exposes memory leaks and slow degradation, and what to watch while it runs.

  • Entry and exit criteria

    What entry and exit criteria are, examples for a test phase, who agrees them, how they differ from acceptance criteria, and why a phase without them never ends.

  • Ephemeral environment

    What an ephemeral environment is, how short-lived copies of an application are created on demand for a change and destroyed after, plus costs and failures.

  • Epic vs feature

    Epic vs feature vs user story: where a feature sits in the backlog hierarchy, and how Azure Boards, Jira and SAFe each define the levels Scrum leaves out.

  • Epic vs user story

    Epic vs user story in agile: how big each one is, how an epic is split into stories, and where issue trackers place them in the backlog hierarchy.

  • Equivalence partitioning

    What equivalence partitioning is in software testing, how to split inputs into classes, how to pick one value per class, and where boundary testing takes over.

  • Error guessing

    What error guessing is, the experience-based technique of anticipating likely defects, where the guesses come from, and why it complements formal techniques.

  • Escaped defect

    What an escaped defect is, how it differs from a regression, why counting escapes is the honest measure of a test process, and what to do with each one.

  • Example mapping

    What example mapping is, how Matt Wynne's four card colours turn a user story into rules, examples and open questions, and what the finished map tells a team.

  • Exhaustive testing

    What exhaustive testing is, a worked count showing why testing every input combination is impossible in practice, and what testers do in its place.

  • Expected vs actual result

    What expected and actual results are, why the expected side is written first, how the pair differs from steps to reproduce, and what a vague actual costs.

  • Experience-based testing

    What experience-based testing is, the ISTQB category covering error guessing, exploratory and checklist-based testing, and when a tester's knowledge fits.

  • Exploratory testing

    What exploratory testing is, how a charter guides it, how it differs from ad hoc and scripted testing, and why the notes are the deliverable, not the bug count.

  • Feature flag

    What a feature flag is, how it separates deploying from releasing, how it differs from configuration and branches, and why every flag needs an expiry.

  • Five whys

    What the five whys technique is, its roots in the Toyota Production System, how a team applies it to a bug or incident, and where one chain falls short.

  • Functional testing

    What functional testing is, how it checks behaviour against requirements without reading the code, how it differs from non-functional testing, and its levels.

  • Functional vs non-functional requirements

    Functional vs non-functional requirements: what each kind states, side-by-side examples, how each is tested, and where each one lives in an agile backlog.

  • Given-When-Then

    What Given-When-Then is, how its three steps and the Gherkin keywords write an acceptance scenario, and when a plain checklist is enough instead.

  • Go/no-go decision

    What a go/no-go decision is in a software release, who calls it and on what evidence, how it differs from a quality gate, and why a no-go needs an exit.

  • Grey box testing

    What grey box testing is, how it sits between black box and white box, what partial knowledge of the internals is used for, and where it is most often applied.

  • Happy path

    What the happy path means in software testing, why it is the first case and never the last, what the unhappy paths are, and how happy-path-only testing fails.

  • HAR file

    What a HAR file is, what the HTTP Archive format records about a page's network requests, how to export one from a browser, and what to strip before sharing it.

  • Headless browser

    What a headless browser is, what it shares with a normal browser and what it lacks, where it runs in a test pipeline, and which bugs it cannot see.

  • Heisenbug

    What a heisenbug is in software, why attaching a debugger or adding a log line makes it vanish, the common causes, and how to capture one in the wild.

  • Internationalization testing

    What internationalization (i18n) testing is, how it checks that a product can adapt to languages and regions, and what text expansion and right-to-left reveal.

  • INVEST criteria

    What the INVEST criteria are, what each of the six letters asks of a user story, and how Bill Wake's 2003 mnemonic is used to split or reject a draft.

  • Issue vs bug

    How an issue differs from a bug: issue is the tracker's word for any work item, bug is the subset that describes a defect, and why it matters at triage.

  • Keyword-driven testing

    What keyword-driven testing is, how action keywords map to code in an automation framework, who benefits from it, and the maintenance cost it brings with it.

  • Largest contentful paint

    What largest contentful paint measures, how it differs from first contentful paint and full load, what delays it, and how lab and field values differ.

  • Load testing

    What load testing is, how virtual users drive a system at expected volume, what to measure, and how it relates to scalability, endurance and spike testing.

  • Manual testing

    What manual testing is, what a tester does that a script cannot, how it differs from automated and exploratory testing, and where it breaks down at scale.

  • Manual vs automated testing

    Manual vs automated testing compared: what each is for, how to split a test effort between them, what each costs, and why neither is the upgrade.

  • Mean time to resolution

    What mean time to resolution measures, how to calculate it, why MTTR is also read as repair, recovery or respond, and what the average hides about slow tickets.

  • Mock vs stub

    Mock vs stub in unit testing: what each stand-in does, how the assertion differs, where fakes and spies sit, and why mocking everything makes brittle tests.

  • Monkey testing

    What monkey testing is, dumb versus smart monkeys, how it differs from ad hoc and fuzz testing, what it can find, and why its crashes are hard to reproduce.

  • Non-functional requirements

    What non-functional requirements are, with examples in performance, security, accessibility and reliability, and how to word them so a test can check them.

  • Non-functional testing

    What non-functional testing covers, how it differs from functional testing, the qualities it measures, who runs it, and why it is scheduled too late.

  • Pairwise testing

    What pairwise testing is, how covering every pair of parameter values shrinks a test matrix, where the method stops being safe, and where it fits best.

  • Pesticide paradox

    What the pesticide paradox is, why a test suite repeated unchanged stops finding new defects, how it differs from flakiness, and how teams refresh a suite.

  • Phased rollout

    What a phased rollout is, how a release reaches users in stages by percentage, region or cohort, what decides whether to continue, and how app stores handle it.

  • PII masking

    What PII masking is, how it differs from anonymisation and encryption, where personal data leaks into test artefacts, and how replay and logs apply it.

  • Pixel perfect

    What pixel perfect means in web design and front-end work, how it is checked against a design file, why browsers rarely match exactly, and what teams accept.

  • Preview environment

    What a preview environment is, how it differs from staging, what it is good for reviewing and what it cannot prove, and why a stale preview misleads a tester.

  • Progression testing

    What progression testing is, how checking new and changed behaviour differs from regression testing, and when a progression test becomes a regression test.

  • QA testing

    What QA testing is, how quality assurance differs from testing, what a QA process covers before a release, and where defects are cheapest to find.

  • Quality assurance vs quality control

    How software quality assurance differs from quality control: QA sets the process that prevents defects, QC inspects the product to find them. Who does which.

  • Quality gate

    What a quality gate is in a software pipeline, the conditions it checks, how it differs from a go/no-go decision, and why a gate you can bypass is not a gate.

  • Real user monitoring

    What real user monitoring is, how a script in the visitor's browser reports load times and errors, how it complements synthetic checks, and where it goes blind.

  • Regression bug

    What separates a regression from any other defect, where regressions come from, how triage weighs them, and why the last working build belongs in the report.

  • Regression testing

    What regression testing is, why the suite gains a test for every bug already fixed once, and how to choose what to re-run when a full pass is too slow.

  • Regression testing vs retesting

    Retesting checks one fixed defect, regression testing checks everything around it. Which runs first, which one gets automated, and where smoke and sanity sit.

  • Release management

    What release management covers, from scope and calendar to go/no-go and rollback, how it differs from deployment and continuous delivery, and where it fails.

  • Release notes

    What release notes are, how they differ from a changelog, who writes them, what each entry should say, and why copied ticket titles make notes nobody reads.

  • Release planning

    What release planning is, the inputs a team uses (velocity or throughput, priorities, dependencies), what a release plan holds, and why it stays a forecast.

  • Release readiness

    What release readiness means, who supplies the evidence, how it differs from the go/no-go decision and the definition of done, and when to start the list.

  • Requirements traceability matrix

    What a requirements traceability matrix is, which columns it holds, what forward and backward traceability show, and how teams keep one from drifting.

  • Requirements validation

    What requirements validation is, which techniques check a specification against real needs, how it relates to verification, and what a review looks for.

  • Risk-based testing

    What risk-based testing is, how likelihood and impact rank what to test first, who scores the risk, where scores go stale, and how it differs from bug priority.

  • Rollback plan

    What a rollback plan contains, who triggers it and on what signal, when to roll forward instead, and why database changes are where most rollbacks break.

  • Sanity testing

    What sanity testing is, how a narrow check after one change differs from a smoke test over a whole build, and when a team runs one instead of the full suite.

  • Scalability testing

    What scalability testing is, how stepping up load or adding resources shows where capacity stops growing, and what it finds that a single load test cannot.

  • SDET

    What an SDET (Software Development Engineer in Test) is, what the role builds, how it sits next to QA and developers, and why the title means different things.

  • Session-based testing

    What session-based testing is, the charter, time box and session report that structure it, how it makes exploratory testing accountable, and the debrief.

  • Severity levels

    What bug severity levels are, the common five-step scale from blocker to trivial, who assigns the level, what each means, and why it stays apart from priority.

  • Smoke testing

    What smoke testing is, how a go or no-go pass over the critical paths of a build differs from regression testing, and how long one should take to run.

  • Software bug

    What a software bug is, how it differs from the failure a user sees and from a feature request, where bugs come from, and what a report needs to be fixable.

  • Software failure

    What a software failure is, how it differs from the error that caused it and the defect that carries it, why users report failures, and how to trace one back.

  • Software testing life cycle (STLC)

    What the software testing life cycle (STLC) is: the six phases commonly listed from requirement analysis to closure, and how the STLC relates to the SDLC.

  • Spike testing

    What spike testing is: a performance test of sudden surges in traffic and the recovery afterwards. Not to be confused with the agile spike, a research story.

  • Sprint backlog

    What a sprint backlog is in Scrum: the Sprint Goal, the selected items and the plan to deliver them, who owns it, and how it compares with a product backlog.

  • Sprint demo

    What a sprint demo is, how it fits inside the Scrum Sprint Review, what to show and who presents, and why the demo is only part of the end-of-sprint event.

  • Sprint review

    What a sprint review is in Scrum, who attends, what the team and stakeholders inspect, how it differs from the retrospective, and why it is not a sign-off gate.

  • Sprint review vs retrospective

    Sprint review vs retrospective: what each Scrum event inspects, who attends, which comes first, and the timeboxes the Scrum Guide 2020 sets for the two.

  • Staging environment

    What a staging environment is, why every way it differs from production weakens what a passing test proves, and what to mirror first when you cannot mirror it.

  • State transition testing

    What state transition testing is, how a state table turns into test cases, why the invalid transitions matter most, and how it differs from decision tables.

  • Statement coverage

    What statement coverage is, how the percentage is worked out, why full coverage still leaves branches untested, and how it differs from line coverage.

  • Static testing

    What static testing is in software, how reviews and static analysis find defects without running the code, how it differs from dynamic testing, and its limits.

  • Steps to reproduce

    How to write steps to reproduce that work on somebody else's machine, why a report without them is usually closed, and what to record besides the clicks.

  • Story points

    What story points are, how teams size user stories relatively with a scale and planning poker, why points are not hours, and what they cannot tell you.

  • Synthetic test data

    What synthetic test data is, how it is generated, how it compares with masked production data, and why generated data misses the records that break software.

  • System integration testing (SIT)

    What system integration testing (SIT) is, why interfaces fail when every unit passes its own tests, and how SIT differs from unit and acceptance testing.

  • Test artifacts

    What test artifacts are: the plan, cases, scripts, data, logs, defect reports and test reports that testing produces, who reads each one, and how many to keep.

  • Test automation

    What test automation is, what a script can and cannot check, how it differs from manual testing and from CI, and why automated suites decay without maintenance.

  • Test case design

    What test case design is, the black-box, white-box and experience-based techniques used to derive test cases, and what a technique adds over intuition.

  • Test case prioritization

    What test case prioritization is, which signals order a regression suite, how it differs from test impact analysis, and how a stale ordering hides failures.

  • Test charter

    What a test charter is, the one-line mission that aims a session of exploratory testing, the Explore-With-To discover template, and what a good charter covers.

  • Test closure

    What test closure is, the checks that end a testing effort, what the closure report records, how it differs from a test report, and why skipping it costs later.

  • Test condition

    What a test condition is in software testing, where it sits between the test basis and a test case, with examples of conditions and the cases under them.

  • Test coverage

    What test coverage measures, how it differs from code coverage, why a high number can hide untested behaviour, and what to do with the figure once you have it.

  • Test data

    What test data is, where it comes from, how it differs from a fixture and from production data, and why convenient data misses the bugs real records cause.

  • Test data management

    What test data management covers, the three sources and their trade-offs, how it differs from environment management, and how unmanaged data blocks releases.

  • Test environment

    What a test environment is, how development, QA, staging and production differ, and why an environment that drifts produces passes that mean nothing.

  • Test execution

    What test execution is, what has to be true before it starts, how outcomes are logged, how it differs from test design and the test report, and why it stalls.

  • Test fixture

    What a test fixture is in software testing, what it sets up and tears down, how it differs from test data and a mock, and why shared fixtures fail by order.

  • Test impact analysis

    What test impact analysis is, how a map from code to tests picks the regression subset a change can affect, where the map goes stale, and what it never skips.

  • Test matrix

    What a test matrix is, how the browser and device matrix is built and pruned, how it differs from a traceability matrix, and why an unpruned one never runs.

  • Test oracle

    What a test oracle is, the common kinds from specification to human judgement, how it differs from an expected result, and what the oracle problem means.

  • Test plan vs test strategy

    Test plan vs test strategy: what each document contains, who owns it, how often each changes, and why merging the two hides a release's scope under fixed rules.

  • Test procedure

    What a test procedure is in software testing: test cases in execution order with setup and teardown, and how it differs from a test case and a test script.

  • Test readiness review

    What a test readiness review is, the checkpoint before a test phase that confirms build, environment, data and test cases are ready, and what it decides.

  • Test report

    What a test report is, what a useful one contains, how it differs from the execution log and closure report, who reads it, and why pass counts alone mislead.

  • Test scenario

    What a test scenario is, how it differs from a test case, how one scenario becomes several cases, and why scenarios written as features cannot be run.

  • Test scenario vs test case

    Test scenario vs test case: a scenario names what to test in one line, a case says how with steps and data. When each is enough, and how one becomes many.

  • Test script

    What a test script is: the step list a tester follows or the code a tool runs, how a script relates to a test case, and how much detail one needs.

  • Test suite

    What a test suite is, how suites are grouped by purpose rather than feature, how a suite differs from a test plan, and why an unpruned suite loses trust.

  • Three Amigos

    What the Three Amigos practice is in agile, which three perspectives it brings together, when the talk happens, and what comes out of it before a sprint.

  • Two-way sync

    What two-way sync means for workflow records, how it differs from a one-way push, how the state mapping works, and where conflicts and unmapped states break it.

  • Types of software bugs

    The eight bug families QA teams recognise, what separates a functional bug from a logic bug, and which piece of evidence identifies each one on a report.

  • UAT environment

    What a UAT environment is, how it differs from staging, the data and access it needs, and why a build that changes mid-session invalidates the findings.

  • UAT sign-off

    What a UAT sign-off is, who may sign, what the record contains, how it differs from a go/no-go decision and test closure, and why silence is not acceptance.

  • UAT test case

    What a UAT test case contains, how to write one in business language with steps and expected results, and how the results feed the sign-off for a release.

  • UAT vs QA

    How UAT and QA differ in who tests, what they test against and what comes out, why UAT is not a final QA round, and what has to be true before UAT starts.

  • Uncaught exception

    What an uncaught exception is, how it differs from a handled one and from a promise rejection, what it does to the rest of a script, and how to read one.

  • Unhandled promise rejection

    What an unhandled promise rejection is, how it differs from an uncaught exception, why its stack trace is short, and how it shows up as a bug a tester can see.

  • Use case testing

    What use case testing is, how each flow of a use case becomes a test, with a checkout example, and why it is paired with input-level techniques.

  • User acceptance testing (UAT)

    What user acceptance testing (UAT) is, who runs it, how it differs from QA testing, and what to agree in writing before the first tester opens the build.

  • User story

    What a user story is, how the As a, I want, so that format and the three Cs work, and where a story ends and a task, an epic or a requirement begins.

  • Verification and validation

    Verification asks whether software was built correctly; validation asks whether the right thing was specified. What each covers and who performs it.

  • Visual bug

    What a visual bug is, how it differs from a functional defect, why it shows in one browser and not another, and what a report needs to pin one down.

  • Visual feedback

    What visual feedback means in website and design review, how it differs from the interface sense and from written notes, and why a mark without an anchor fails.

  • Visual regression testing

    What visual regression testing is, how screenshot diffs against an approved baseline work, why they raise false alarms, and where a person still has to look.

  • Website feedback

    What website feedback is as a practice, how it differs from surveys and bug reports, who gives it, and why a report without its context costs a reply.

  • White box testing

    What white box testing is, which techniques derive tests from the code, how it sits beside black box and grey box testing, and what it cannot find on its own.

  • WIP limit

    What a WIP limit is in kanban, how it differs from a WIP column and from a sprint commitment, how a team sets one, and what happens when a column is full.

  • Zero bug policy

    What a zero bug policy is, how it forces a fix-or-close decision on every report, why it differs from zero defects, and where teams adopting it go wrong.

Looking for the artefact rather than the definition? The templates put the same vocabulary into something you can copy off the page.

QA and bug report templates

Reports that arrive ready to triage.

Replay, console, network and environment attached, on the free plan.

Start free
<script src="…/widget.js" data-key="pb_pub_…">