QA & SDET Glossary

Formal testing conducted to determine whether a system satisfies its acceptance criteria and to enable a customer or stakeholder to decide whether to accept the system. Includes UAT, business acceptance testing, and contractual acceptance testing.

A testing approach where the tester has no knowledge of the internal structure or code of the system under test. Tests are derived entirely from external specifications, requirements, and observed behaviour.

The sequence of states a defect moves through from discovery to closure: New → Assigned → Open → Fixed → Retest → Verified → Closed (or Rejected / Deferred / Reopened). The exact states vary by team process.

A flaw in a component or system that can cause it to fail to perform its required function. Also called a bug or fault. Defects are distinguished by severity (impact on the system) and priority (urgency of fixing).

Testing that validates the complete workflow of a feature or system from start to finish, simulating real user scenarios across all layers (UI, API, database). E2E tests provide high confidence but are slower and more brittle than unit or integration tests.

A simultaneous learning, test design, and test execution approach where testers use their knowledge, creativity, and intuition to explore the system. Documented as session-based testing with charters. Highly effective for uncovering usability issues and edge cases.

Testing that verifies the software performs the functions specified in its requirements. It focuses on what the system does — inputs, outputs, and behaviour — rather than how it does it internally.

A testing approach combining elements of black-box and white-box testing. The tester has partial knowledge of the internal structure — enough to design better tests — but still tests from the external interface.

Testing performed to verify that interfaces between components or between systems work correctly. Catches issues that unit tests miss: mismatched contracts, incorrect data transformation, and communication errors between modules.

Testing that evaluates attributes of the system other than its functional behaviour — performance, security, accessibility, usability, reliability, and scalability. Often overlooked in sprint testing but critical for production readiness.

Testing to confirm that recent code changes have not adversely affected existing functionality. A regression suite selects tests from across the system most likely to reveal regressions, balancing coverage against execution time.

A narrow regression check focused on verifying that a specific bug fix or small change works correctly without breaking adjacent functionality. Performed after a fix, before broader regression testing. Faster and more targeted than a full smoke test.

The degree of impact a defect has on the operation of the product — typically classified as Critical, Major, Minor, or Trivial. Severity is set by the tester. A critical defect causes data loss or system crash; trivial is a cosmetic issue with no functional impact.

A shallow, broad test run executed on a new build to verify that the most critical functions work before deeper testing begins. Acts as a build verification gate. If smoke fails, the build is rejected and returned to development.

Testing of a complete, integrated system to evaluate compliance with its specified requirements. Tests the system as a whole, including integration between components, end-to-end flows, and non-functional attributes.

A set of preconditions, inputs, actions, expected results, and postconditions that specifies how to verify a particular requirement. A well-written test case is atomic, independent, traceable to a requirement, and produces a clear pass/fail outcome.

A measure of the extent to which the test suite exercises the system. Coverage types include requirements coverage (what requirements have tests), code coverage (what lines/branches are executed), and risk coverage. Coverage metrics guide test adequacy decisions.

Data used to execute test cases. Good test data covers valid inputs, invalid inputs, boundary values, and realistic representative values. Test data management involves creation, masking of production data, and teardown to keep environments clean.

A document describing the scope, objectives, schedule, resources, approach, and risks of a testing effort. It defines what will be tested, who will test it, when, and how success is measured. Typically maintained at the project or release level.

A model that recommends having many fast unit tests at the base, fewer integration tests in the middle, and even fewer slow end-to-end tests at the top. The pyramid guides investment in the right test types to maximise confidence while keeping feedback loops fast.

A high-level description of how testing will be approached across the organisation or project. Defines testing levels, types, environments, tools, entry/exit criteria, and responsibilities. Lives above the test plan.

User Acceptance Testing. Testing performed by end users or stakeholders in a realistic environment to confirm the system meets business requirements and is ready for production. UAT is the final gate before go-live.

Testing of individual software components in isolation from the rest of the system. Fast, cheap, and precise — unit tests verify logic at the function or class level. Typically written and run by developers using frameworks like JUnit, pytest, or Jest.

A testing approach where the tester has full knowledge of the internal structure, code, and logic of the system. Tests are designed to exercise specific paths, branches, conditions, and code statements. Also called glass-box or structural testing.

A test design technique that selects test values at the boundaries of equivalence partitions — the minimum, maximum, and values just inside or outside the boundary. Defects cluster at boundaries more often than in the middle of valid ranges.

A test design technique that models complex business rules as a table of conditions and resulting actions. Each column represents a unique combination of conditions, making it easy to identify missing test cases and ensure all rule combinations are covered.

A test design technique that divides input data into partitions of equivalent data where the application should behave the same way. One representative value from each partition is selected, reducing the total number of test cases while maintaining coverage.

A combinatorial test design technique that ensures every pair of input parameters is covered by at least one test case. Reduces the exponential explosion of exhaustive combination testing while still catching most defects caused by parameter interactions.

A strategy that prioritises test effort based on the likelihood and impact of defects. High-risk areas (complex code, frequent changes, critical business paths) receive deeper coverage; low-risk areas receive less. Ensures quality within time constraints.

A test design technique used when a system changes behaviour based on its current state and an event. Tests are designed to cover all valid state transitions, invalid transitions, and boundary states in the state machine.

Behaviour-Driven Development. An agile practice that extends TDD by writing tests in a business-readable language (Given/When/Then). Bridges communication between developers, testers, and stakeholders. Tools: Cucumber, SpecFlow, Behave.

An automation approach where test logic is separated from test data. A single test script is executed multiple times with different input/expected-output combinations sourced from CSV files, JSON, databases, or spreadsheets. Reduces code duplication and increases coverage.

Setup and teardown mechanisms in test frameworks that establish a known, consistent state before tests run and clean up afterwards. In Playwright and pytest, fixtures are reusable, composable, and scope-controlled (function, module, session).

A test that produces inconsistent results — passing and failing across runs without any code change. Common causes include timing issues, shared state, network dependency, random data, and order-dependent tests. Flaky tests erode trust in the test suite.

An automation approach where test cases are written using high-level keywords that map to reusable action methods. Non-technical stakeholders can contribute test scenarios using keywords like 'Login', 'AddToCart', 'VerifyTotal' without writing code.

A design pattern for UI automation that creates a class for each page or component of the application. The class encapsulates locators and interactions, exposing methods that represent user actions. Tests call POM methods, making tests readable and centralising selector maintenance.

Running multiple tests simultaneously across workers, browsers, or machines to reduce total test suite duration. Requires tests to be fully isolated with no shared state. Tools like Playwright, JUnit 5, pytest-xdist, and Selenium Grid support parallel execution.

An advanced test automation pattern built on SOLID principles where actors perform tasks using abilities. More expressive than POM for complex multi-actor workflows. Popular in Serenity BDD and growing in Playwright ecosystems.

The approach used to locate UI elements in automation. Preference order: accessible roles and labels > test IDs > CSS selectors > XPath. Avoiding brittle selectors (positional XPath, auto-generated classes) makes tests maintainable.

Dividing a test suite into shards (subsets) that run in parallel across multiple CI workers. Reduces total pipeline time proportionally to the number of shards. Playwright's --shard flag and pytest-split support this natively.

Test-Driven Development. A development practice where tests are written before the production code they test. The cycle is Red (write a failing test) → Green (write minimal code to pass) → Refactor. TDD improves design, documentation, and test coverage.

The principle that each test should set up its own state, run independently, and clean up after itself. Isolated tests can run in any order, in parallel, and produce the same result every time — preventing shared-state bugs and flakiness.

The practice of isolating flaky or unreliable tests from the main suite so they no longer block CI while the underlying issue is investigated and fixed. Quarantine prevents flaky tests from eroding team confidence without permanently disabling coverage.

Testing that validates the functionality, reliability, performance, and security of application programming interfaces. Covers HTTP status codes, request/response structure, authentication, error handling, latency, and contract adherence — without using a UI.

Testing that ensures a consumer and provider agree on the interface contract between them. Consumer-driven contract testing (via Pact) generates contracts from consumer tests and verifies the provider can satisfy them — preventing integration failures without full E2E tests.

Testing GraphQL APIs for query correctness, schema compliance, resolver logic, error handling, and performance. Unique challenges include introspection security, N+1 query problems, variable validation, and deeply nested response structures.

The property of an HTTP operation where making the same request multiple times produces the same result as making it once. GET, PUT, and DELETE are idempotent. POST is generally not. Testing for idempotency verifies safe retry behaviour.

Replacing a real dependency (service, database, API) with a controlled substitute that returns predefined responses. Mocks enable testing in isolation without real infrastructure. Over-mocking risks test/production divergence — prefer integration tests where possible.

Representational State Transfer. An architectural style for distributed systems using stateless HTTP operations (GET, POST, PUT, PATCH, DELETE) on resource URLs. Responses typically use JSON or XML. RESTful API testing validates status codes, headers, body schemas, and error responses.

Verifying that an API response conforms to a defined contract or schema (JSON Schema, OpenAPI/Swagger, Avro). Catches breaking changes in response structure before they reach consumers. Can be automated as part of CI using tools like Ajv, Spectral, or Pact.

Simulating the behaviour of dependent services that are unavailable, unreliable, or costly to use in test environments. More sophisticated than mocking — virtual services can be stateful, record/replay real traffic, and simulate latency or failures.

Performance testing that applies the expected production load to a system to measure behaviour under normal and peak conditions. Metrics collected include throughput, response time, error rate, and resource utilisation (CPU, memory, I/O).

Testing that evaluates how a system behaves under a given workload. Umbrella term covering load, stress, soak, spike, and volume testing. Goal is to identify bottlenecks, validate SLAs, and ensure reliability under production conditions.

Service Level Agreement. A formal commitment defining expected performance characteristics — typically response time thresholds (e.g., p95 < 500ms) and availability (e.g., 99.9% uptime). Performance tests validate that the system meets its SLA under load.

Performance testing that applies a sustained load over a long period (hours to days) to detect slow memory leaks, connection pool exhaustion, and degradation over time. Also called endurance testing.

Performance testing that applies a sudden, extreme increase in load to evaluate how quickly the system scales and recovers. Tests auto-scaling, circuit breakers, and graceful degradation under unexpected traffic surges.

Performance testing that pushes the system beyond its specified capacity to find its breaking point and observe how it fails. Goal is to understand failure modes, not just confirm SLA compliance — informing capacity planning and resilience design.

A cloud-based service providing access to real physical devices for mobile testing at scale. Examples: AWS Device Farm, BrowserStack, Sauce Labs. Enables testing across diverse OS versions and hardware configurations without maintaining physical inventory.

A software that mimics an Android device on a desktop computer, simulating hardware and OS. Faster to provision than physical devices but may not replicate all hardware behaviours (sensors, camera, NFC). Used for development and early testing.

An iOS tool (part of Xcode) that simulates an Apple device's environment on macOS, running the same compiled code as a real device. Unlike emulators, simulators do not emulate hardware — some behaviours differ from physical devices.

Apple's native UI testing framework for iOS and macOS, built into Xcode. Tests are written in Swift or Objective-C and run directly on device or simulator. Provides the most accurate simulation of user interaction for iOS apps. Used as the backend driver for Appium on iOS.

Continuous Integration / Continuous Delivery (or Deployment). CI automates building and testing code on every commit. CD automates releasing verified builds to staging or production. Together they shorten feedback loops, reduce integration risk, and enable frequent safe deployments.

The practice of frequently merging developer code into a shared branch, triggering automated builds and tests on every commit. CI catches integration defects early and prevents long merge conflicts. The pipeline should complete in under 10–15 minutes.

A containerisation platform that packages applications and their dependencies into lightweight, portable containers. In testing, Docker enables reproducible test environments, database containers for integration tests, and consistent CI execution regardless of the host machine.

An automated sequence of steps (stages) that code goes through from commit to deployment — typically: lint → build → unit test → integration test → E2E test → deploy. Pipeline design determines test feedback speed and release confidence.

Moving testing activities earlier in the development lifecycle — writing tests before or alongside code, reviewing requirements for testability, and running fast tests on every commit. Catches defects when they are cheapest to fix and shortens feedback loops.

A set of conditions that a user story or feature must satisfy for the product owner to accept it as complete. Well-written acceptance criteria are testable, unambiguous, and agreed upon by the whole team before development starts.

A shared agreement on the criteria a user story must meet to be considered complete — typically including code review, unit tests passing, E2E tests passing, documentation updated, and no open critical bugs. The DoD ensures consistent quality across the team.

A set of conditions that must be satisfied before work can progress to the next stage — e.g., code coverage > 80%, no critical vulnerabilities, all tests passing. Quality gates are enforced in CI pipelines and review processes.

A fixed-length iteration in Scrum (typically 1–2 weeks) during which the team delivers a potentially shippable product increment. Testers participate in sprint planning, daily standups, exploratory testing, and sprint review.

A collaborative requirements refinement session involving a business analyst (what), developer (how), and tester (what could go wrong). The goal is to align understanding of a user story before development starts, reducing rework and ambiguity.

An open-source, cross-platform mobile automation framework that uses the WebDriver protocol to automate native, hybrid, and mobile web apps on iOS and Android. Tests are written in any language; Appium communicates with apps via platform-specific drivers (XCUITest, UIAutomator2).

A BDD tool that executes feature files written in Gherkin (Given/When/Then). Step definitions map Gherkin steps to automation code. Bridges communication between technical and non-technical team members by using business-readable test specifications.

A JavaScript E2E testing framework designed for web applications. Runs in the same process as the browser, enabling real-time reloads, automatic waiting, and built-in time-travel debugging. Best suited for single-domain web apps; has limitations with multi-origin and native file dialogs.

A plain-language syntax used to write BDD scenarios in Cucumber and SpecFlow. Uses keywords: Feature, Scenario, Given, When, Then, And, But, Background, Scenario Outline, Examples. Designed to be readable by non-programmers.

An open-source automation server used to build CI/CD pipelines. Highly extensible via plugins. Common in enterprises for orchestrating test runs, deployments, and build notifications. Typically configured via Jenkinsfile (declarative or scripted pipeline).

An Apache open-source load testing tool written in Java. Used for performance, load, and stress testing of web applications, APIs, and databases. Supports recording, parameterisation, listeners for reporting, and distributed testing across multiple nodes.

A modern, developer-friendly open-source load testing tool from Grafana Labs. Scripts are written in JavaScript. Outputs metrics like VUs, RPS, p95 response time, and error rate. Cloud execution, Prometheus integration, and CI-native design make it popular in modern stacks.

A Microsoft open-source E2E testing framework supporting Chromium, Firefox, and WebKit. Written in TypeScript/JavaScript (also Python, Java, .NET). Features: auto-waiting, browser contexts for parallelism, network interception, tracing, and a powerful built-in test runner.

An API development and testing platform. Features: request building, environment variables, collection runner for automation, pre/post request scripting in JavaScript, schema validation, and mock servers. Newman is Postman's CLI runner for CI integration.

A Java DSL library for testing REST APIs. Provides a fluent interface for building HTTP requests, asserting responses, and validating JSON/XML bodies using GPath/JsonPath. Integrates with JUnit and TestNG for CI reporting.

The industry-standard open-source browser automation library. Provides a WebDriver API to control browsers programmatically across languages (Java, Python, C#, JS). The W3C WebDriver standard it defines is the foundation for Appium and other tools.

A Java testing framework inspired by JUnit but with additional features: test groups, parallel execution, data providers, listeners, and dependency injection. Widely used with Selenium in enterprise Java stacks. Configuration via XML or annotations.

A testing framework for systematically evaluating the outputs of AI/ML models against labelled datasets or expected behaviours. Measures accuracy, precision, recall, hallucination rate, and task-specific metrics. Used to detect model regressions after retraining.

Testing AI language models for responses that are factually incorrect, fabricated, or not grounded in provided context. Techniques include adversarial prompts, factual consistency checks, and RAG-specific retrieval accuracy metrics.

Systematic testing of LLM prompts for correctness, consistency, safety, and robustness. Covers: correct output format, refusal of harmful requests, handling of adversarial inputs, and regression testing when prompts or models change.