Skip to main content
QA Glossary
GLOSSARY

QA testing glossary.

Clear definitions, real-world examples, and interview tips for every concept QA engineers and SDETs need to know. From testing fundamentals to chaos engineering.

Start a Free Mock Interview

Free to start · 7-day trial on paid plans

Testing Fundamentals

Flaky TestA flaky test is an automated test that produces inconsistent pass/fail results across multiple runs without any changes to the source code or test itself.
Test PyramidThe Test Pyramid is a testing strategy that prescribes a large base of fast, isolated unit tests, a smaller middle layer of integration tests, and a thin top layer of end-to-end tests.
Regression TestingRegression testing is the practice of re-running existing tests after code changes to verify that previously working functionality has not been broken by new commits.
Smoke TestingSmoke testing is a shallow, broad test run that verifies that the most critical features of an application are working after a new build or deployment, acting as a quick go/no-go decision.
Exploratory TestingExploratory testing is a testing approach where the tester simultaneously learns about the system, designs tests, and executes them in real time without predefined scripts.
Boundary Value AnalysisBoundary value analysis (BVA) is a test design technique that focuses on testing at the edges of input ranges, where defects are statistically most likely to occur.
Equivalence PartitioningEquivalence partitioning is a test design technique that divides input data into groups (partitions) where all values within a partition are expected to be treated the same way by the system.
Test CoverageTest coverage is a metric that measures the extent to which a test suite exercises the application, expressed as a percentage of code lines, branches, requirements, or features verified by tests.
Test CaseA test case is a documented set of preconditions, inputs, execution steps, and expected results designed to verify that a specific feature or behavior of the application works correctly.
Defect LifecycleThe defect lifecycle (also called the bug lifecycle) is the series of stages a defect passes through from initial discovery to final closure, typically including New, Assigned, Open, Fixed, Verified, and Closed.
Test OracleA test oracle is the mechanism a tester uses to determine whether the actual output of a system under test matches the expected output, effectively deciding whether a test has passed or failed.
Sanity TestingSanity testing is a targeted, narrow test pass performed after a specific bug fix or change to confirm that the affected functionality works correctly without testing the broader application.
Property-Based TestingProperty-based testing is an approach where the test framework automatically generates many input values to verify that a property (a general statement about correct behavior) holds true across all of them.
Pairwise TestingPairwise testing is a combinatorial test design technique that generates the minimum set of test cases needed to cover every possible combination of any two input parameters at least once.
Test AutomationTest automation is the practice of using software tools and scripts to execute tests, compare actual outcomes to expected outcomes, and report results, replacing or augmenting manual test execution.
End-to-End TestingEnd-to-end (E2E) testing validates complete user workflows from start to finish, simulating real user behavior across the entire application stack, frontend, backend, database, and external integrations.
Integration TestingIntegration testing verifies that individual software modules or components work correctly when combined, focusing on the interfaces and interactions between them rather than their internal logic.
Unit TestingUnit testing is the practice of testing individual units of code, typically functions, methods, or classes - in isolation from their dependencies to verify they produce correct outputs for given inputs.
Test-Driven Development (TDD)Test-driven development (TDD) is a software development methodology where tests are written before the production code, following a red-green-refactor cycle: write a failing test, write the minimum code to pass it, then refactor.
Negative TestingNegative testing verifies that a system handles invalid input, unexpected conditions, and misuse gracefully, returning proper errors instead of crashing, corrupting data, or exposing vulnerabilities.
Happy Path TestingHappy path testing verifies that a feature works as intended when everything goes right, valid inputs, expected sequence, no errors, confirming the primary success scenario end to end.
Retesting vs Regression TestingRetesting (confirmation testing) verifies that a specific fixed defect is actually resolved, while regression testing verifies that the fix, or any change, did not break previously working functionality elsewhere.
Ad-hoc TestingAd-hoc testing is informal, unstructured testing performed without a plan, documentation, or predefined test cases, the tester simply explores the application to find defects that scripted tests might miss.
Monkey TestingMonkey testing is a technique where random inputs and actions are fed to an application, often automatically, to see whether it crashes or behaves unexpectedly, without regard to valid workflows.
Static TestingStatic testing finds defects without executing the code, through reviews of work products (requirements, design, code) and automated static analysis, catching issues earlier and more cheaply than running the software.
Black-Box TestingBlack-box testing evaluates software through its inputs and outputs against requirements, without any knowledge of the internal code or structure, the tester treats the system as an opaque box.
White-Box TestingWhite-box testing (also called clear-box or structural testing) uses knowledge of the internal code and structure to design tests that exercise specific statements, branches, paths, and conditions.
Gray-Box TestingGray-box testing combines black-box and white-box approaches: the tester designs tests from the user perspective but uses partial knowledge of the internals, architecture, database schema, APIs, or algorithms, to target tests more effectively.
Verification vs ValidationVerification asks "are we building the product right?", checking work against its specifications, while validation asks "are we building the right product?", checking that it actually meets user needs.
Decision Table TestingDecision table testing is a black-box test design technique that maps combinations of input conditions to expected actions in a table, ensuring every meaningful combination of conditions is tested systematically rather than by guesswork.
State Transition TestingState transition testing is a test design technique for systems that behave differently depending on their current state, modeling the states, the events that trigger transitions, and the resulting states, then deriving tests that exercise valid and invalid transitions.
Error GuessingError guessing is an experience-based testing technique where the tester uses intuition, past experience, and knowledge of common failure patterns to anticipate where defects are likely and design tests that target those weak spots.
Functional TestingFunctional testing verifies that a system behaves according to its functional requirements, that each feature does what it is supposed to do, by giving it inputs and checking the outputs against expected results, without regard to internal implementation.
Non-Functional TestingNon-functional testing verifies how well a system performs rather than what it does, evaluating quality attributes such as performance, scalability, security, usability, reliability, and compatibility against non-functional requirements.
System TestingSystem testing evaluates the complete, integrated application as a whole against its specified requirements, verifying that all components work together correctly in an environment that resembles production.
Alpha TestingAlpha testing is internal testing of a near-complete product performed by the organization's own staff (often QA, and sometimes other internal users) before the product is released to any external users, to catch bugs and usability issues in a controlled setting.
Beta TestingBeta testing is the release of a near-final product to a limited group of real external users who use it in their own environments and provide feedback, surfacing real-world issues before general availability.
Test ScenarioA test scenario is a high-level description of a functionality or user situation to be tested, capturing what to verify (the "what") without the step-by-step detail of a test case, so the team can ensure broad coverage before drilling into specifics.
Use Case TestingUse case testing is a black-box technique that derives test cases from use cases, descriptions of how a user (actor) interacts with the system to achieve a goal, ensuring the main success flow and all alternate and exception flows are exercised.
Pesticide ParadoxThe pesticide paradox is the testing principle that running the same set of tests repeatedly eventually stops finding new defects, just as pests develop resistance to a repeatedly used pesticide, so test cases must be regularly reviewed and revised to remain effective.
Seven Principles of TestingThe seven principles of testing are a set of foundational ISTQB guidelines that summarize hard-won truths about how testing works: what it can and cannot prove, where defects concentrate, and why testing must be risk-driven and context-dependent rather than exhaustive.
GUI TestingGUI testing verifies that an application's graphical user interface, its screens, controls, layout, and visual behavior, works correctly and behaves as the user expects, checking both that controls function and that the interface looks and responds properly.
Incremental Integration TestingIncremental integration testing combines and tests software modules step by step, adding and verifying a few at a time, rather than assembling the whole system at once, so that defects in module interactions are isolated and found early.
Stubs and DriversStubs and drivers are temporary scaffolding programs used in integration testing to stand in for modules that are not yet built: a stub simulates a module that is called by the code under test, while a driver simulates a module that calls the code under test.
Test BedA test bed is the complete environment configured to execute tests, the combination of hardware, software, operating system, network, databases, test data, and configuration, set up to mirror the conditions under which the application will run.
Big Bang Integration TestingBig bang integration testing is an approach where all (or most) modules are combined at once and tested together as a whole, rather than integrated and tested incrementally, so integration testing begins only after every component is ready.
Positive vs Negative TestingPositive testing verifies that a system behaves correctly when given valid inputs and used as intended, confirming the "happy path" works, while negative testing checks that it handles invalid inputs and misuse gracefully.
Smoke vs Sanity TestingSmoke testing is a broad, shallow check that a new build's core functions work well enough to justify further testing, while sanity testing is a narrow, deeper check that a specific function or fix behaves correctly after a change.
Test SuiteA test suite is an organized collection of test cases grouped together for a common purpose, such as a smoke suite, a regression suite, or a feature suite, so they can be managed, executed, and reported on as a unit.
Edge CaseAn edge case is an input or condition at the extreme boundary of a system's operating range, such as the minimum or maximum value, empty input, or a limit, where behavior is most likely to be wrong because these extremes are easy to overlook when writing code.
Configuration TestingConfiguration testing verifies that software works correctly across different combinations of hardware, software, operating systems, browsers, devices, and settings, ensuring it behaves properly in the varied environments where real users run it.
Installation TestingInstallation testing verifies that software installs, upgrades, and uninstalls correctly across the supported environments and conditions, confirming that the very first experience, getting the product onto a system and into a working state, succeeds reliably.
Corner CaseA corner case is a condition that occurs only when multiple variables or parameters simultaneously reach their extreme or unusual values, a rarer, often nastier situation than an edge case, which involves a single variable at an extreme.
Reproducibility (of a Bug)Reproducibility is the degree to which a bug can be made to occur again by following a known set of steps and conditions, a reproducible bug happens reliably when the steps are repeated, while a non-reproducible (intermittent) bug occurs only sometimes or under unknown conditions.
HeisenbugA heisenbug is a software defect that seems to change its behavior or disappear when you attempt to observe or debug it, named, with a nod to the Heisenberg uncertainty principle, because the act of measurement alters the result.

Automation

Page Object Model (POM)The Page Object Model (POM) is a design pattern in test automation where each web page or component is represented by a class that encapsulates its elements and interactions, separating test logic from UI details.
Test FixtureA test fixture is the fixed baseline state or environment used as a starting point for test execution, including setup logic that prepares the system and teardown logic that cleans up afterward.
Test HarnessA test harness is the collection of software, tools, and configuration that enables automated tests to execute, including the test runner, assertion libraries, reporting tools, and supporting infrastructure.
Data-Driven TestingData-driven testing is a test automation approach where the same test logic is executed multiple times with different input data sets, separating test data from test scripts.
Keyword-Driven TestingKeyword-driven testing is a test automation approach where test steps are represented as keywords (action words) in a table, abstracting the underlying automation code so that non-technical testers can design and maintain tests.
Mocking vs StubbingMocking and stubbing are both techniques for replacing real dependencies with test doubles, but stubs provide canned responses to calls while mocks additionally verify that specific interactions occurred.
Code CoverageCode coverage is a metric that measures which lines, branches, or paths of source code are executed by automated tests, typically expressed as a percentage and generated by instrumentation tools.
Mutation TestingMutation testing is a technique that evaluates the quality of a test suite by introducing small, deliberate changes (mutants) to the source code and checking whether the tests detect and fail on those changes.
PlaywrightPlaywright is an open-source browser automation framework developed by Microsoft that enables reliable end-to-end testing across Chromium, Firefox, and WebKit with a single API.
SeleniumSelenium is an open-source browser automation framework that uses the WebDriver protocol to control browsers programmatically, enabling automated testing of web applications across multiple browsers and programming languages.
CypressCypress is a JavaScript-based end-to-end testing framework that runs directly inside the browser, providing real-time reloading, automatic waiting, and a visual test runner for web application testing.
GherkinGherkin is a plain-language, structured syntax for writing Behavior-Driven Development scenarios using keywords like Feature, Scenario, Given, When, Then, And, and But.
Screenplay PatternThe Screenplay Pattern is a test automation design pattern that models tests as Actors who have Abilities and perform Tasks and ask Questions, favoring composition over the inheritance-heavy Page Object Model.
Arrange-Act-Assert (AAA)Arrange-Act-Assert (AAA) is a pattern for structuring a test in three clear phases: arrange the preconditions and inputs, act by invoking the behavior under test, and assert the expected outcome.
Snapshot TestingSnapshot testing captures a serialized representation of a component's or function's output (for example, rendered UI markup) as a stored baseline, then on later runs compares the new output to the saved snapshot and flags any difference for review.
Test DoubleA test double is any object that stands in for a real dependency during testing, replacing a database, service, or collaborator with a controllable substitute so a test can run in isolation, deterministically, and fast.
Parallel TestingParallel testing is the practice of running multiple tests (or test suites) at the same time across threads, processes, or machines, rather than sequentially, to dramatically reduce total execution time.
Headless TestingHeadless testing runs browser-based tests using a browser without its visible graphical interface, executing all the real rendering and scripting in the background, which makes tests faster and well suited to CI servers that have no display.
Consumer-Driven Contract TestingConsumer-driven contract testing (CDC) is an approach where each consumer of a service defines its expectations of the provider's API as a contract, and the provider verifies it can satisfy all consumer contracts, so services can evolve independently without breaking integrations or needing full end-to-end tests.
Golden Master TestingGolden master testing (a form of characterization or approval testing) captures the current output of a system for a wide range of inputs as a trusted baseline (the "golden master"), then flags any future deviation, letting you safely refactor code whose exact behavior is not formally specified.
AssertionAn assertion is a statement in a test that checks whether an actual result matches an expected result, if the condition holds, the test continues or passes; if not, the assertion fails and marks the test as failed.
Test RunnerA test runner is the tool that finds your test files, executes the tests (handling setup, teardown, and order), and reports the results, the engine that actually drives a test run, as opposed to the libraries that make assertions or create mocks.
Test QuarantineTest quarantine is the practice of moving a flaky or unreliable test out of the main pass/fail gate, so it no longer blocks the build, while keeping it running and tracked separately so it is fixed rather than forgotten.

Strategy & Process

Shift-Left TestingShift-left testing is the practice of moving testing activities earlier in the software development lifecycle, catching defects during requirements, design, and development rather than after deployment.
Shift-Right TestingShift-right testing is the practice of extending testing activities into production and post-deployment phases, using monitoring, observability, and controlled rollouts to detect issues that pre-production testing cannot catch.
Test StrategyA test strategy is a high-level document that defines the testing approach, objectives, scope, types of testing, environments, tools, and risk mitigation for a project or organization.
Test PlanA test plan is a detailed document that describes the scope, approach, resources, schedule, and deliverables for testing a specific feature, release, or project.
Risk-Based TestingRisk-based testing is an approach that prioritizes testing efforts based on the probability of failure and the business impact of that failure, focusing resources on the highest-risk areas first.
Acceptance CriteriaAcceptance criteria are specific, testable conditions that a user story or feature must satisfy to be considered complete and accepted by the product owner.
Definition of DoneThe Definition of Done (DoD) is a shared checklist of quality conditions that every user story, feature, or increment must meet before it can be considered complete, covering aspects like testing, documentation, code review, and deployment readiness.
Quality GatesQuality gates are checkpoints in the software delivery process where predefined quality criteria must be met before work can proceed to the next stage, enforcing minimum standards at each phase.
Test Environment ManagementTest environment management is the practice of provisioning, configuring, maintaining, and monitoring the infrastructure where automated and manual tests execute, ensuring environments are consistent, available, and representative of production.
Mobile TestingMobile testing is the process of testing applications on mobile devices (smartphones and tablets) for functionality, usability, performance, security, and compatibility across different operating systems, screen sizes, and network conditions.
Security TestingSecurity testing is the process of identifying vulnerabilities, threats, and risks in a software application to ensure that data and resources are protected from potential attacks and unauthorized access.
Agile TestingAgile testing is a software testing approach that follows agile development principles, continuous testing throughout the sprint, collaboration between testers and developers, and fast feedback loops rather than a separate testing phase at the end.
Behavior-Driven Development (BDD)Behavior-Driven Development (BDD) is a collaborative practice where teams describe software behavior in plain-language Given-When-Then scenarios that double as living documentation and automated acceptance tests.
Severity vs PrioritySeverity measures the technical impact of a defect on the system, while priority measures how urgently it should be fixed relative to other work.
Defect TriageDefect triage is the process of reviewing reported bugs and deciding, for each, whether it is valid, how severe and urgent it is, who owns it, and when it should be fixed.
Root Cause Analysis (RCA)Root cause analysis (RCA) is a structured process for finding the underlying cause of a defect or incident, the thing that, if fixed, prevents the whole class of problem from recurring, rather than just patching the visible symptom.
Defect DensityDefect density is a quality metric that measures the number of confirmed defects divided by the size of the component, commonly per thousand lines of code (KLOC) or per function point or module.
Requirements Traceability Matrix (RTM)A requirements traceability matrix (RTM) is a document that maps each requirement to the test cases that verify it, proving every requirement is covered and showing the impact of any change.
Entry and Exit CriteriaEntry criteria are the conditions that must be met before a testing phase can begin; exit criteria are the conditions that must be met before it can be considered complete and the team can move on.
Test ClosureTest closure is the final phase of the testing process, where the team confirms testing is complete against its exit criteria, archives artifacts, captures metrics and lessons learned, and produces a test closure (or test summary) report.
Defect LeakageDefect leakage (also called defect escape) measures the share of defects that were missed in testing and found later, in a higher test phase or in production, indicating how effective the earlier testing was.
QA vs QC (Quality Assurance vs Quality Control)Quality Assurance (QA) is a process-oriented, preventive activity focused on improving how software is built so defects are less likely, while Quality Control (QC) is a product-oriented, detective activity focused on finding defects in the built software.
STLC (Software Testing Life Cycle)The Software Testing Life Cycle (STLC) is the sequence of phases that structure a testing effort: requirement analysis, test planning, test case design, test environment setup, test execution, and test closure, each with defined entry and exit criteria.
SDLC (Software Development Life Cycle)The Software Development Life Cycle (SDLC) is the end-to-end process for building software, from requirements through design, development, testing, deployment, and maintenance, structured into phases so teams can plan, build, and ship in a repeatable way.
V-ModelThe V-model is a software development and testing model that pairs each development phase with a corresponding testing phase, drawn as a V with development descending one side and testing ascending the other, emphasizing that test planning happens alongside each development stage.
Bug BashA bug bash is a time-boxed event where many people, often the whole team including developers, designers, and product, test a product together to find as many defects as possible in a short, focused window before a release.
DogfoodingDogfooding (eating your own dog food) is the practice of a company using its own product internally, in real daily work, before or alongside releasing it to customers, so the team experiences the bugs and rough edges firsthand.
Acceptance Test-Driven Development (ATDD)Acceptance Test-Driven Development (ATDD) is a collaborative practice where the team defines acceptance tests for a feature, agreed on by business, development, and testing, before development starts, so everyone shares a concrete understanding of "done" and builds to those tests.
Agile Testing QuadrantsThe agile testing quadrants are a model (popularized by Brian Marick and Lisa Crispin and Janet Gregory) that organizes testing activities along two axes, business-facing vs technology-facing, and supporting the team vs critiquing the product, producing four quadrants that together ensure balanced test coverage.
Session-Based Test ManagementSession-based test management (SBTM) is a structured approach to exploratory testing in which testing is organized into time-boxed, chartered sessions with defined goals, recorded notes, and a debrief, making otherwise unstructured exploration measurable, accountable, and reportable.
Three AmigosThe three amigos is an agile practice in which three perspectives, business (what problem to solve), development (how to build it), and testing (what could go wrong), meet to discuss a user story before development begins, building shared understanding and surfacing ambiguities early.
Specification by ExampleSpecification by example (SBE) is a collaborative approach to defining requirements using concrete, realistic examples of system behavior, which are refined into executable acceptance tests that double as always-current, living documentation.
Ice Cream Cone Anti-PatternThe ice cream cone anti-pattern is an inverted test pyramid: a test suite weighted toward slow, brittle end-to-end and manual tests at the top, with few fast unit tests at the bottom, producing slow, flaky, expensive-to-maintain testing.
Maintainability TestingMaintainability testing evaluates how easily software can be modified, corrected, improved, or adapted, assessing qualities like code clarity, modularity, test coverage, and documentation that determine the effort required to change the system over its life.
A/B TestingA/B testing is an experimentation method that compares two (or more) variants of a feature by showing each to a randomly assigned segment of real users and measuring which performs better on a chosen metric, used to make data-driven product decisions.
Defect Removal Efficiency (DRE)Defect removal efficiency (DRE) is a quality metric that measures the percentage of defects a team finds and removes before release, calculated as defects found before release divided by total defects (those found before release plus those found by users afterward), times 100.
Technical DebtTechnical debt is the implied future cost of choosing an easier or quicker solution now instead of a better one that would take longer, accumulating as code, design, or test shortcuts that make the system progressively harder and riskier to change.
Pair TestingPair testing is a collaborative technique where two people work together at one workstation to test the same feature at the same time, combining their perspectives to find more and deeper issues than either would alone.
CrowdtestingCrowdtesting (crowdsourced testing) is an approach that uses a large, geographically distributed group of external testers, often on their own real devices, networks, and locales, to test software under diverse real-world conditions that are hard to replicate in-house.
Data MaskingData masking is the practice of replacing sensitive information (such as names, emails, payment details, and health records) with realistic but fictitious values, so that test environments can use production-like data without exposing real, private information.
Cyclomatic ComplexityCyclomatic complexity is a software metric that measures the number of linearly independent paths through a piece of code, derived from its control-flow graph, giving a quantitative indicator of how complex the code is and roughly how many test cases are needed to cover its branches.
Mob TestingMob testing is a collaborative practice where a whole group, often the entire team, tests the same feature together at one shared screen at the same time, combining many perspectives to explore deeply, share knowledge, and align quickly.
Defect AgeDefect age is a measure of how long a defect has existed, either as elapsed time (from when it was introduced or detected to when it was fixed or closed) or as the number of phases between where it was introduced and where it was found.
Risk MatrixA risk matrix is a grid that plots risks by their likelihood (probability of occurring) against their impact (severity of consequences), producing a prioritized view that helps teams focus testing effort on the highest-risk areas.
Test Effort EstimationTest effort estimation is the process of predicting how much time, people, and resources will be needed to test a feature or release, so testing can be planned, scheduled, and resourced realistically rather than squeezed into whatever time remains.
Definition of ReadyThe Definition of Ready (DoR) is a shared checklist of criteria a user story or work item must meet before the team commits to working on it, ensuring the item is clear, feasible, and testable enough to start without immediate blockers.

DevOps & CI/CD

Continuous TestingContinuous testing is the practice of executing automated tests at every stage of the CI/CD pipeline, providing immediate feedback on the risk level of each code change as it moves toward production.
Test EnvironmentA test environment is the configured infrastructure (servers, databases, services, and network settings) where tests are executed, designed to simulate production conditions at the appropriate fidelity for each testing level.
Test Data ManagementTest data management is the practice of creating, maintaining, and governing the data used in testing, ensuring tests have reliable, realistic, and compliant data across all environments.
Canary DeploymentA canary deployment is a release strategy that rolls out changes to a small subset of users or servers first, monitors for issues, and gradually expands to the full user base only after confirming stability.
Blue-Green DeploymentBlue-green deployment is a release strategy that maintains two identical production environments (blue and green), deploys the new version to the inactive environment, and switches traffic from the active to the inactive environment once verification is complete.
Feature FlagsFeature flags (also called feature toggles) are conditional switches in code that allow teams to enable or disable features at runtime without deploying new code, supporting controlled rollouts, A/B testing, and quick rollback.
ObservabilityObservability is the ability to understand the internal state of a system from its external outputs, primarily through three pillars: structured logs, metrics (time-series data), and distributed traces.
TestOpsTestOps is the discipline of applying DevOps principles, automation, continuous delivery, infrastructure as code, and observability - specifically to the management, execution, and maintenance of test infrastructure and test pipelines.
Docker for TestingDocker for testing is the practice of using Docker containers to create isolated, reproducible, and disposable test environments that ensure tests run consistently across local machines, CI/CD pipelines, and team members.
GitHub Actions for TestingGitHub Actions for testing is the use of GitHub's built-in CI/CD platform to automatically run test suites on code changes, triggered by pushes, pull requests, or schedules - with support for parallel execution, artifacts, and environment management.
Synthetic MonitoringSynthetic monitoring runs scripted, automated checks against a live system on a schedule to verify that critical user journeys and endpoints work and meet performance targets, before real users hit a problem.
IdempotencyAn operation is idempotent if performing it multiple times has the same effect as performing it once.
Service Level Objective (SLO)A Service Level Objective (SLO) is a target value or range for a measured aspect of service reliability, for example "99.
Error BudgetAn error budget is the amount of unreliability a service is allowed over a window, the gap between its Service Level Objective and 100%.
Continuous Integration (CI)Continuous Integration (CI) is the practice of merging code changes into a shared branch frequently, where each change automatically triggers a build and an automated test suite so integration problems are caught within minutes instead of at the end of a release.
Continuous Delivery (CD)Continuous Delivery (CD) is the practice of keeping software in a releasable state at all times through an automated pipeline, so that any build that passes all stages could be released to production at the push of a button.
Continuous DeploymentContinuous Deployment is the practice of automatically releasing every code change that passes the automated pipeline straight to production, with no manual approval step.
Service Level Agreement (SLA)A Service Level Agreement (SLA) is a formal, often contractual commitment to customers about the level of service they will receive, such as 99.
Dark LaunchA dark launch is the practice of deploying a feature to production but keeping it hidden from users (or running it in the background without exposing its output), so the team can test it under real production load and data before an actual user-facing release.
Rollback TestingRollback testing verifies that a system can be safely reverted from a new version or change back to the previous known-good state, restoring correct functionality without data loss or corruption, so a bad deployment can be undone with confidence.
Environment ParityEnvironment parity is the degree to which non-production environments (development, test, staging) match production in configuration, data, dependencies, and infrastructure, the closer the parity, the more reliably tests predict real production behavior.
The Four Golden SignalsThe four golden signals, popularized by Google's SRE practice, are latency, traffic, errors, and saturation: the core set of metrics that, monitored together, give a high-level picture of a production service's health and user experience.

Specialized Testing

Contract TestingContract testing is a technique that verifies that two services (a consumer and a provider) can communicate correctly by testing each side independently against a shared contract that defines the expected request and response structure.
Chaos EngineeringChaos engineering is the discipline of deliberately injecting controlled failures into a system in production or pre-production to proactively discover weaknesses before they cause unplanned outages.
Performance BudgetA performance budget is a set of measurable limits on web performance metrics (such as page load time, bundle size, or Core Web Vitals) that a team commits to not exceeding, enforced through automated checks.
Accessibility TestingAccessibility testing is the practice of evaluating software to ensure it is usable by people with disabilities, including visual, auditory, motor, and cognitive impairments, typically measured against WCAG (Web Content Accessibility Guidelines) standards.
Visual Regression TestingVisual regression testing is the practice of capturing screenshots or visual snapshots of UI components or pages and comparing them against approved baselines to detect unintended visual changes.
API TestingAPI testing is the practice of verifying that application programming interfaces work correctly by sending requests directly to endpoints and validating responses for functionality, reliability, performance, and security.
Load TestingLoad testing is the practice of simulating expected or peak user traffic against a system to verify that it meets performance requirements (response time, throughput, error rate) under realistic load conditions.
Shadow TestingShadow testing is the practice of routing real production traffic to both the existing system and a new version simultaneously, comparing their outputs without the new version affecting the user experience.
Observability TestingObservability testing is the practice of verifying that a system produces sufficient, accurate, and actionable telemetry (logs, metrics, and traces) to enable engineers to understand its internal state and diagnose problems in production.
Database TestingDatabase testing is the practice of verifying that data stored in databases is accurate, consistent, and complete, checking schema structure, data integrity constraints, CRUD operations, stored procedures, and migration scripts.
Cross-Browser TestingCross-browser testing is the practice of verifying that a web application works correctly and looks consistent across different browsers (Chrome, Firefox, Safari, Edge), browser versions, and operating systems.
Stress TestingStress testing pushes a system beyond its expected capacity to find its breaking point and observe how it fails and recovers under extreme load.
Service VirtualizationService virtualization is the practice of simulating the behavior of real but unavailable, costly, or hard-to-configure dependencies (APIs, third parties, mainframes) so teams can develop and test against them on demand.
Compatibility TestingCompatibility testing verifies that software behaves correctly across different environments, browsers, operating systems, devices, screen sizes, and sometimes networks or hardware, rather than only on the developer's setup.
Fuzz TestingFuzz testing (fuzzing) is an automated technique that feeds large volumes of malformed, unexpected, or random input to a program to find crashes, hangs, memory errors, and security vulnerabilities.
Usability TestingUsability testing evaluates how easily real users can complete tasks with a product, focusing on the experience, clarity, efficiency, and satisfaction, rather than on whether the software is functionally correct.
Localization TestingLocalization testing (L10n) verifies that software has been correctly adapted for a specific language, region, and culture, translations, formats, layout, and locale-specific behavior, so it feels native to that market.
Recovery TestingRecovery testing deliberately forces a system to fail, crashes, network loss, power or service outages, and verifies that it recovers gracefully: restoring state, resuming operations, and not losing or corrupting data.
Soak TestingSoak testing (also called endurance or longevity testing) runs a system under a sustained, typical load for an extended period, hours or days, to surface problems that only appear over time, such as memory leaks, resource exhaustion, and gradual performance degradation.
Spike TestingSpike testing subjects a system to a sudden, sharp increase (and often decrease) in load over a very short time, to verify it handles abrupt traffic surges without failing and recovers gracefully afterward.
Penetration TestingPenetration testing (pentesting) is an authorized, simulated attack on a system performed to find and exploit security vulnerabilities the way a real attacker would, demonstrating actual impact rather than just listing potential weaknesses.
Internationalization TestingInternationalization (i18n) testing verifies that software is designed and built to support multiple languages, regions, and cultural conventions, checking that the architecture can handle different character sets, formats, and text directions, without yet adapting to any specific locale.
Scalability TestingScalability testing measures how effectively a system handles increasing load and how well its performance and capacity grow when resources are added (scaling up or out), identifying the point at which it stops scaling efficiently.
Volume TestingVolume testing (sometimes called flood testing) verifies how a system behaves when it processes or stores large volumes of data, checking that performance, stability, and correctness hold as the data set grows very large, independent of how many concurrent users there are.
Concurrency TestingConcurrency testing verifies that an application behaves correctly when multiple users, threads, or processes access shared resources at the same time, deliberately exercising simultaneous operations to expose race conditions, deadlocks, and data-corruption bugs.
Reliability TestingReliability testing verifies that a system performs its required functions correctly over an extended period and under expected conditions without failing, measuring how consistently and dependably it operates rather than just whether it works once.
Interoperability TestingInteroperability testing verifies that a system can exchange data and work correctly together with other systems, devices, platforms, or software, confirming that integrations function across boundaries and conform to shared standards or protocols.
Conformance TestingConformance testing (compliance testing) verifies that a product, system, or implementation adheres to a defined standard, specification, or regulation, confirming it follows the prescribed rules so it will interoperate and be accepted where that standard is required.
Portability TestingPortability testing evaluates how easily software can be transferred from one environment, platform, or configuration to another, assessing whether it can be adapted, installed, and run correctly in new settings without excessive effort.
Baseline TestingBaseline testing establishes a reference set of results, a baseline, that captures the system's current accepted behavior or performance, so that future test runs can be compared against it to detect regressions or unexpected changes.
WCAG (Web Content Accessibility Guidelines)WCAG (Web Content Accessibility Guidelines) is the internationally recognized standard, published by the W3C, that defines how to make web content accessible to people with disabilities, organized around four principles and three conformance levels (A, AA, AAA).
ARIA (Accessible Rich Internet Applications)ARIA (Accessible Rich Internet Applications), or WAI-ARIA, is a set of HTML attributes, roles, states, and properties that convey the meaning and state of dynamic, custom web components to assistive technologies like screen readers when native HTML semantics are not enough.
Bug Bounty ProgramA bug bounty program is an initiative where an organization invites external security researchers to find and responsibly report security vulnerabilities in its systems in exchange for recognition and monetary rewards (bounties) scaled to the severity of what they find.

More Interview Prep Resources

Explore our role-specific interview prep guides.

QA Mock Interview PracticeSDET Interview PrepAutomation Testing InterviewSoftware Testing Interview
FREE TOOLS  /  no signup

Free QA career tools, no account needed

Instant and private, everything runs in your browser. Try them before you sign up.

QA Resume Checker

QA Cover Letter Generator

QA Application Tracker

QA Take-Home Test Generator

QA LinkedIn Headline Generator

QA STAR Story Builder

QA Bug Report Generator

Boundary Value Analysis Generator

QA Metrics Calculator

QA Test Plan Generator

QA Salary Calculator

QA Offer Evaluator

Browse all free QA tools
EXEC.NOW

Ready to Ace Your QA Interview?

Practice with AI that asks real questions about the concepts that matter.

Join 1,200+ QA engineers already practicing with AssertHired.

Start your free QA interview

Curious how it works first? See the QA mock interview

FREE.TO.START  ·  7.DAY.TRIAL ON PAID PLANS
Written by Aston Cook, Senior QA EngineerLast updated: March 2026