AAA (Arrange-Act-Assert)
A three-phase structure for a test body: arrange inputs and preconditions, act by calling the unit once, and assert the outcome. Keeping the phases distinct makes intent obvious and exposes tests that try to verify too much.
ATDD (Acceptance Test-Driven Development)
A collaborative practice in which the team agrees on acceptance tests for a feature - usually in Given/When/Then form - before implementation begins. The agreed tests become the executable definition of done, aligning developers, testers, and business stakeholders.
BDD (Behaviour-Driven Development)
An approach that expresses requirements as concrete behaviour examples in a shared, near-natural language (Gherkin), readable by technical and non-technical stakeholders alike. Tools such as Cucumber bind those scenarios to step definitions that drive the system.
CI (Continuous Integration)
The practice of integrating code into a shared mainline frequently, with each integration verified by an automated build and test run. It depends on a fast, reliable test suite to give quick feedback and keep the mainline releasable.
CD (Continuous Delivery/Deployment)
Continuous Delivery keeps software in an always-releasable state via automated pipelines; Continuous Deployment goes further by releasing every passing change automatically. Both rely on a trustworthy automated test gate to release without manual QA bottlenecks.
DAST (Dynamic Application Security Testing)
A security-testing technique that probes a running application from the outside, sending crafted requests to find vulnerabilities such as injection and broken authentication. It complements SAST, which inspects source code statically without executing it.
E2E (End-to-End)
Testing that drives a complete, integrated system through a real user journey, usually via the UI. E2E tests give the highest confidence but are the slowest and most brittle, so they belong at the narrow top of the test pyramid.
SUT (System Under Test)
The specific code a test exercises, whether a single class, a slice of services, or the whole application. Naming the SUT precisely clarifies the test's scope and which collaborators are real versus doubled.
TDD (Test-Driven Development)
A red-green-refactor cycle: write a failing test, write the minimal code to pass it, then refactor under the test's protection. It drives small, decoupled designs and yields a regression suite as a by-product.
DDT (Data-Driven Testing)
A technique that runs the same test logic across many input/expected-output rows supplied from a table or external source, instead of duplicating the test per case. Frameworks support it via parameterised tests, keeping cases concise and easy to extend.
DoD (Definition of Done)
The shared, explicit checklist a work item must satisfy to be considered complete - typically including tests written and passing, code reviewed, and acceptance criteria met. A clear DoD prevents "done" from being negotiated after the fact.
SLA / SLO / SLI
A Service Level Indicator is a measured signal (e.g. p99 latency); a Service Level Objective is the target for that indicator (e.g. p99 < 300 ms 99.9% of the time); a Service Level Agreement is the externally promised, often contractual, commitment. Performance and reliability tests validate that the system can meet its SLOs.
SAST (Static Application Security Testing)
Analysis of source code, bytecode, or binaries for security defects without executing the program, typically integrated into CI to flag issues like injection sinks and hardcoded secrets early. It pairs with DAST, which tests the running application.
QA (Quality Assurance)
The process-oriented discipline of building quality into how software is produced - requirements clarity, reviews, test strategy, and continuous improvement - as distinct from quality control, which inspects the finished product.
QC (Quality Control)
The product-oriented activity of inspecting and testing finished or in-progress software to detect defects against specifications. QC is a subset of the broader quality-assurance effort.
MTTR (Mean Time To Recovery)
The average time taken to restore service after a failure, a key reliability metric used alongside change failure rate in the DORA set. Good observability and tested rollback paths shorten MTTR.
MTBF (Mean Time Between Failures)
The average operational time between failures of a system, a reliability measure for which soak and stress testing provide evidence. Higher MTBF indicates a more dependable system under sustained use.
POM (Page Object Model)
A UI-test pattern that encapsulates each page or component behind an object exposing intention-revealing methods and hiding selectors. It localises UI changes so a changed locator is fixed in one place rather than across many tests.
RAGAS
An open-source evaluation framework for retrieval-augmented generation that scores answers on metrics such as faithfulness, answer relevancy, and context recall/precision. It is widely used to build automated quality gates for LLM and RAG systems.
p95 / p99 (Percentile Latency)
The latency value below which 95% (or 99%) of requests complete. Tail percentiles expose the slow-request experience that averages hide, so performance tests assert on p95/p99 rather than the mean.
SLA Burn Rate
The rate at which an error budget (the allowance of failures permitted by an SLO) is being consumed. Fast burn triggers alerts; reliability testing and chaos experiments help validate that the system stays within its budget.
VRT (Visual Regression Testing)
Automated comparison of rendered screenshots against approved baselines to catch unintended visual changes (layout shifts, colour, missing elements). It guards UI appearance that functional assertions do not cover, and requires disciplined baseline review.
CDC (Consumer-Driven Contracts)
A contract-testing style where consumers publish the expectations they depend on, and each provider verifies it can satisfy them independently. It catches integration breakage between services without full end-to-end environments.
SbE (Specification by Example)
A collaborative requirements technique that uses concrete examples to specify expected behaviour, which then double as automated acceptance tests. It reduces ambiguity by replacing abstract statements with executable illustrations.
HiL / SiL (Hardware/Software-in-the-Loop)
Test setups, common in embedded and automotive systems, where real hardware (HiL) or a software model (SiL) of a component runs in a simulated environment to validate behaviour before full integration. They let teams test control logic against realistic conditions safely.
DORA Metrics
The four delivery-performance metrics from the DevOps Research and Assessment program: deployment frequency, lead time for changes, change failure rate, and time to restore service. Test automation and quality gates strongly influence change failure rate and recovery time.
Pact
A widely used contract-testing tool and file format for consumer-driven contracts. A consumer generates a pact describing the interactions it expects, which the provider then verifies, decoupling integration validation from shared environments.
A/B Test
A controlled online experiment that splits live traffic between variants to measure the causal effect of a change on a metric. It is a production-validation technique distinct from pre-release functional testing, used to confirm a change delivers its intended impact.
Canary Release
A deployment strategy that routes a small fraction of traffic to a new version first, watching error rates and latency before widening the rollout. It is a form of testing in production that limits the blast radius of a bad release.
Chaos Testing
The practice of deliberately injecting failures (killing instances, adding latency, dropping packets) into a system to verify that it degrades gracefully and recovers. It validates resilience assumptions that ordinary tests assume rather than exercise.