General

The percentage of source-code lines, branches, or statements executed during a test run. A useful but easy-to-game metric — high coverage doesn't guarantee good tests.

The practice of advancing clocks by one hour during warmer months and reverting them in autumn, creating two critical testing edge cases: the spring-forward transition, where one local hour does not exist, and the autumn fall-back, where one local hour occurs twice. Any system that stores, compares, schedules, or displays timestamps must be tested at these instants. Common failures include scheduled jobs skipping or running twice, timestamps stored in local time becoming ambiguous after fall-back, and duration calculations spanning a transition returning incorrect values. The safest approach is to store all timestamps in UTC and convert to local time only at display. Transition dates vary by region and change periodically by legislation — derive them programmatically rather than hardcoding.

Defects per unit of size — typically per thousand lines of code or per function point. Useful for spotting unusually buggy modules and tracking quality trends over time, with the usual caveats about goal-induced metric gaming.

The ratio of defects found in production to total defects (production + pre-release). Measures how well testing caught bugs before users did. Lower is better.

The code logic that intercepts and responds to failures — network timeouts, unexpected input, downstream service errors, and exceptions — preventing crashes and providing meaningful feedback. Error-handling paths are among the most under-tested surfaces: they are rarely exercised in the happy path but are critical for resilience and user experience under real-world conditions. Testing strategies: force the failure condition (inject a 500, disconnect the network, supply invalid input); verify the application surfaces a user-friendly message rather than a raw stack trace; confirm the app recovers correctly when the error clears; check error logs contain enough context to diagnose without exposing sensitive data (PII, tokens, internal paths).

A test that passes and fails intermittently without any code changes, often caused by timing issues, shared state, async race conditions, or external dependencies. The single largest source of CI noise.

An international standard that defines unambiguous string representations for dates, times, durations, and intervals, eliminating locale-specific ambiguity (01/02/03 means different dates in different countries). The canonical format for a datetime instant is YYYY-MM-DDTHH:mm:ss.sssZ, where T is a literal separator and Z indicates UTC; offsets are expressed as ±HH:mm (e.g. +05:30). QA relevance: use ISO 8601 strings in all API test fixtures and test data to avoid parser ambiguity across systems and locales; assert that APIs return ISO 8601 timestamps rather than locale-specific strings; and be aware of edge cases at leap-year February 29 boundaries and DST transition instants where a naive local-time string is ambiguous or non-existent.

A year with 366 days that adds 29 February to keep the calendar aligned with Earth's orbit. The rule: a year is a leap year if divisible by 4, except years divisible by 100 are not leap years — unless also divisible by 400 (2000 was a leap year; 1900 was not). This three-part rule is a frequent source of off-by-one bugs: developers who only check divisibility by 4 will incorrectly treat 1900, 2100, and 2200 as leap years. In QA, 29 February is a canonical boundary-value test case for any date field: it should be rejected in non-leap years and accepted in leap years. Systems that compute ages or date differences must also handle the February 29 to March 1 transition in non-leap years correctly. The unambiguous formula is: (year % 4 === 0) && (year % 100 !== 0 || year % 400 === 0).

A test double that records how it was called and lets the test assert on those interactions. Pre-programmed with expectations about which methods will be called and how.

A classification of how urgently a defect must be fixed, set by product management based on business impact, release schedule, and customer commitment. Priority answers 'when should this be fixed?' — a cosmetic defect on a high-traffic page may be P1 urgency despite low severity, while a rare data-loss bug may be deferred to a future release (P3) despite high severity. Priority drives sprint planning; severity drives technical risk assessment. The two dimensions are deliberately independent to give product and engineering separate levers.

A test that verifies previously fixed bugs haven't returned and existing features still work after new changes. Forms the safety net for refactoring and feature work.

A documented condition or capability a system must satisfy — functional (what it does) or non-functional (how well it does it). Requirements are the source material for test case design: every requirement with no linked test case is a coverage gap, and a requirements traceability matrix makes those gaps explicit.

The ability to link every requirement to the test cases that verify it, and trace every test case back to the requirement it covers. A requirements traceability matrix (RTM) makes gaps explicit: a requirement with no linked test case is a coverage hole; a test case with no requirement link is an orphan that may be testing undocumented behaviour. RTMs are a common audit artefact in regulated industries.

Re-running a test that previously failed, after a fix has been applied, to confirm the original defect is resolved. Distinct from regression testing, which checks unrelated areas.

A narrow, focused test run after a small change to confirm the change works as intended without breaking adjacent functionality. Lighter and more targeted than smoke testing.

A small, fast test suite that verifies the most critical functionality works after a build — ensures the app is healthy enough for further testing. The first signal in any pipeline.

A test double that wraps real behaviour and records calls, so the test can both let the real code run and inspect how it was used.

A test double that returns canned responses to method calls, replacing real behaviour without recording or asserting on calls.

A measure of which parts of the requirements or features have been exercised by tests. Distinct from code coverage — focuses on the spec, not the source.

Accumulated shortcuts in the test suite — flaky tests, missing coverage, slow feedback loops — that compound until every change is painful. A subset of technical debt, with the same dynamics: cheap to ignore, expensive to clear.

Umbrella term for any object that stands in for a real dependency in a test. Includes dummies, fakes, stubs, spies, and mocks — each with distinct semantics.

The infrastructure where tests run — hardware, OS, database, network, and configuration. Differences between test and production are a leading source of bugs that pass tests but fail in production.

The infrastructure that runs tests — the framework, runners, fixtures, mocks, and reporting tools that make tests executable and observable.

Each test sets up its own state and doesn't depend on others — order can change, parallelisation works, a single failure doesn't cascade. The non-negotiable property for a maintainable test suite.

The mechanism that decides whether a test passed or failed — a hard-coded expected value, a previous result snapshot, a reference implementation, or a property that must always hold. Hard oracle problems are why some systems are notoriously difficult to test.

A document describing the scope, approach, schedule, resources, and deliverables for testing a release or feature. Narrower and more time-bound than a test strategy.

The high-level, organisation-wide approach to testing — what gets tested, by whom, with what tools, at what stage. Broader and more permanent than a test plan.

A collection of related test cases organised for execution together — usually grouped by feature, layer (unit, integration, e2e), or test type (smoke, regression).

The process of reviewing newly filed defects to assess, categorise, and assign them — setting severity, priority, target release, and owner. Triage meetings bring together QA, product, and engineering to make these decisions collectively rather than leaving them to individuals. The goal is a prioritised, actionable backlog: critical issues routed immediately, lower-priority issues scheduled, and unclear reports returned for more information. Triage is also applied after a failed test run to sort failures into genuine new defects, known issues, flaky tests, and environment problems.

An HTTP request header that identifies the client software — browser name, version, rendering engine, operating system, and device type. Sent automatically by browsers; can be set to any value by non-browser clients and automation tools. Servers may respond differently based on the UA string (mobile redirects, bot-blocking, browser-specific assets). QA considerations: headless Playwright and Cypress send a recognisable headless UA that can trigger bot-detection or return a stripped response — set a realistic UA string when testing UA-gated paths. Parsing UA strings to infer device capabilities is fragile; prefer server-side feature detection. The Chrome UA Reduction initiative is progressively freezing minor version numbers to improve privacy, which can break UA-parsing-based analytics.