Learn / Glossary
Software Testing Glossary
Plain-English definitions of the terms QA engineers and SDETs use every day, each with an example and links to the lessons, labs and interview questions that cover it.
77 terms · Testing fundamentals 26 · Test design 5 · UI automation 18 · API testing 8 · CI/CD and DevOps 5 · Performance 5 · Security 4 · AI in testing 6
A
- Acceptance criteria The specific, testable conditions a user story or feature must meet to be accepted as complete by the product owner.
- Auto-waiting A framework feature that waits for an element to be ready, for example visible, stable and enabled, before acting on it, instead of relying on fixed sleeps.
B
- Behavior-Driven Development A collaborative practice where business, development and testing agree on behavior through concrete examples, often written in Gherkin and automated.
- Black-box testing Testing a system through its inputs and outputs against the requirements, without looking at or relying on the internal code or design.
- Boundary value analysis A black-box test design technique that picks test inputs at and just around the edges of valid ranges, where off-by-one defects cluster.
- Bug priority How urgently a defect should be fixed relative to other work, decided by business need. Usually set by the product owner or during bug triage.
- Bug severity How much impact a defect has on the system or its users, from a full crash or data loss down to a cosmetic issue. Usually set by QA.
C
- Code coverage The percentage of source code (lines, statements, branches or functions) executed while tests run. It shows what is untested, not what is well tested.
- Continuous integration The practice of merging small changes into a shared branch often, with every push automatically built and tested so breakages surface within minutes.
- Contract testing Verifying that an API provider and its consumers agree on the requests and responses they exchange, without deploying both together for an end-to-end test.
- Cross-site scripting XSS is a vulnerability where untrusted input is rendered as executable script in another user's browser, letting an attacker act as that user.
- CSS selector A pattern from the CSS language that matches elements by tag, id, class, attribute or position, widely used as a fast and readable UI test locator.
D
- Data-driven testing Running the same test logic against many sets of inputs and expected outputs, kept in a table, file or data source rather than copied into each test.
- Decision table testing A test design technique that lists combinations of conditions and the action each one should trigger, so every business rule gets a test.
- Docker container A running, isolated instance of a Docker image that packages an app or service with its dependencies, so it behaves the same on a laptop and in CI.
E
- End-to-end test A test that drives a complete user journey through the real, fully deployed system, from the UI or public API down to the database and back.
- Equivalence partitioning A test design technique that divides inputs into groups the system should treat the same way, then tests one representative value from each group.
- Explicit wait A wait that polls for one specific condition, such as an element becoming clickable, up to a timeout. In Selenium it is written with WebDriverWait.
- Exploratory testing Testing where the tester designs and runs tests at the same time, using what each result reveals to decide what to try next.
F
- Feature flag A runtime switch that turns a code path on or off without a deploy, letting teams ship unfinished work dark, roll out gradually and roll back fast.
- Flaky test A test that passes and fails on the same code without any change, usually because of timing, shared state, test order or an unstable environment.
G
- Gherkin The plain-text Given-When-Then syntax used to write BDD scenarios in .feature files, which tools such as Cucumber run as automated tests.
- Golden dataset A curated, versioned set of inputs with verified expected outputs, used as the fixed benchmark for regression-testing models, prompts or pipelines.
H
- Headless browser A real browser engine running without a visible window, used to run UI tests on CI servers and other machines that have no display.
- HTTP status code The three-digit number in every HTTP response that says whether the request succeeded, was redirected, or failed because of the client or the server.
I
- Idempotency The property that sending the same request once or many times leaves the server in the same state. GET, PUT and DELETE are idempotent, POST is not.
- IDOR Insecure Direct Object Reference, an access-control flaw where changing an ID in a request lets a user read or modify another user's data.
- Implicit wait A global Selenium setting that makes every findElement call keep polling for up to a set time before throwing NoSuchElementException.
- Integration test A test that checks whether two or more components, such as a service and its database or two APIs, work correctly together through their real interfaces.
J
- JSON Schema A JSON vocabulary for describing the expected structure of JSON data, including types, required fields and formats, used to validate API responses.
- JWT A JSON Web Token is a compact, signed token of the form header.payload.signature that carries claims such as user id, expiry and audience.
L
- LLM evaluation Systematically measuring the quality of an LLM-powered feature against a fixed set of inputs and criteria, since outputs vary and exact asserts rarely fit.
- LLM-as-judge Using a language model with a written rubric to grade another model's outputs, a scalable but biased stand-in for human review in LLM evaluation.
- Load testing Performance testing that runs a system at its expected real-world traffic to check response times, error rates and throughput against agreed targets.
- Locator The query a UI test uses to find an element on the page, such as a role and name, a test id, a CSS selector or an XPath expression.
M
- Model Context Protocol MCP is an open protocol for connecting AI assistants and agents to external tools and data, such as a browser, a repo or a test management system.
- Mutation testing A technique that injects small deliberate bugs (mutants) into code and reruns the tests to measure whether the suite actually detects faults.
O
- OAuth 2.0 An authorization framework that lets an application get a limited access token to call an API on a user's or its own behalf, without handling passwords.
- OWASP Top 10 OWASP's awareness list of the ten most critical web application security risk categories, widely used to scope security testing and code review.
P
- Page Object Model A design pattern that wraps each page or component of the UI in a class, so tests call intent-level methods instead of repeating locators.
- Pairwise testing A combinatorial technique that picks a small set of test cases in which every pair of parameter values appears together at least once.
- Percentile latency A response-time measure such as p95 or p99 showing the time within which that share of requests finished, which exposes the slow tail averages hide.
- Prompt injection An attack where text supplied to an LLM, directly by a user or hidden in content it reads, overrides the developer's instructions to change its behaviour.
Q
R
- Rate limiting Capping how many requests a client can make to an API in a time window, rejecting the excess, usually with 429 Too Many Requests and a Retry-After header.
- Regression testing Re-running existing tests after a change to confirm that behavior which already worked still works, and that the fix or feature broke nothing else.
- Requirements traceability matrix A table that maps each requirement to the test cases that verify it and their results, so gaps in coverage and the impact of changes are visible.
- REST API An HTTP API designed around resources identified by URLs, manipulated with standard methods like GET, POST, PUT, PATCH and DELETE, with stateless requests.
- Risk-based testing An approach that prioritizes test effort by risk, the likelihood of failure times its impact, so the riskiest areas are tested first and deepest.
S
- Sanity testing A narrow, focused check after a small change or bug fix to confirm that the affected area works as intended before wider testing continues.
- Selenium Grid A Selenium server that routes WebDriver sessions to remote browser nodes, so tests can run in parallel across many browsers, versions and machines.
- Self-healing locator A locator that, when it no longer matches, has the test tool pick a likely replacement element from stored attributes or a model, and lets the test continue.
- Shift-left testing Moving testing and quality activities earlier in the delivery lifecycle, so defects are prevented or caught when they are cheapest to fix.
- Smoke testing A quick, shallow check of a new build's most critical functions to decide whether it is stable enough for deeper testing at all.
- Soak testing Performance testing that holds a normal, realistic load for many hours to expose problems that only build up over time, such as memory leaks.
- SQL injection A vulnerability where user input is concatenated into a SQL query, letting an attacker change the query's logic to read, alter or delete data.
- StaleElementReferenceException A Selenium error thrown when a test uses a WebElement whose DOM node was removed or replaced after it was found, typically after a re-render.
- State transition testing A test design technique that models a system as states and the events that move it between them, then tests valid and invalid transitions.
- Stress testing Performance testing that pushes load beyond expected levels to find the breaking point, see how the system fails and check that it recovers afterwards.
T
- Test case A specific set of preconditions, input data, steps and expected results that verifies one behavior of the system and produces a clear pass or fail.
- Test double Any object that stands in for a real dependency in a test, such as a dummy, stub, fake, spy or mock, so the code under test runs fast and predictably.
- Test fixture The fixed setup a test needs before it runs, such as a browser page, a seeded user or a database, plus the teardown that cleans it up afterwards.
- Test isolation The property that each test sets up its own state and can pass on its own, in any order and in parallel, without depending on or affecting other tests.
- Test oracle The source of truth a test uses to decide whether an output is correct, such as a specification, a previous version, a reference model or a rule.
- Test plan A document that defines the scope, approach, resources, schedule, environments, risks and entry and exit criteria for testing a release or project.
- Test pyramid A model for balancing an automated suite - many fast unit tests at the base, fewer integration tests above, and a small number of end-to-end tests at the top.
- Test scenario A high-level statement of a user goal or functionality to test, such as "verify checkout with a saved card", which is later broken down into test cases.
- Test sharding Splitting a test suite into slices, called shards, that run on separate machines at the same time, so a long suite finishes in a fraction of the time.
- Testcontainers A library that starts real dependencies such as databases, brokers or browsers in throwaway Docker containers from your test code, then removes them.
- Throughput The amount of work a system completes per unit of time, usually requests or transactions per second, measured together with latency and error rate.
U
- Unit test An automated test that checks a small piece of code, such as a function or class, in isolation from databases, networks and other services.
- User acceptance testing The final testing phase, in which real users or business representatives confirm that the system meets their needs and is ready to accept for release.
V
- Verification and validation Verification asks "are we building the product right?" against the spec. Validation asks "are we building the right product?" for real user needs.
- Visual regression testing Comparing screenshots of the UI against approved baseline images to catch unintended visual changes such as layout shifts, missing styles or overlaps.
W
- Web-first assertion A Playwright assertion that takes a locator and retries until the expected condition is met or the timeout expires, instead of checking a value once.
- White-box testing Testing designed from knowledge of the internal code, such as its branches, conditions and paths, to make sure the implementation behaves correctly.