QA Glossary
Testing Fundamentals glossary.
55 testing fundamentals terms every QA engineer and SDET should know, each defined with a real-world example and an interview tip.
Browse the full QA glossaryFlaky 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.
Other glossary categories
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
Instant 0-100 score on automation keywords, impact, and ATS formatting.
QA Cover Letter Generator
A tailored 3-paragraph QA cover letter from your resume and a job post.
QA Application Tracker
Drag-and-drop kanban to track every QA application from Applied to Offer.
QA Take-Home Test Generator
A realistic take-home assignment with a scenario, tasks, and a rubric.
QA LinkedIn Headline Generator
A recruiter-searchable headline, About section, and skills list.
QA STAR Story Builder
Structure a QA behavioral answer with the STAR method and instant checks.
QA Bug Report Generator
Build a clean, reproducible bug report for Markdown, Jira, or plain text.
Boundary Value Analysis Generator
Generate boundary value and equivalence partitioning test cases from a range.
QA Metrics Calculator
Calculate DRE, defect leakage, defect density, and pass rate with interpretation.
QA Test Plan Generator
Build a structured test plan (scope, approach, criteria, risks) in Markdown.
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 interviewFREE.TO.START · 7.DAY.TRIAL ON PAID PLANS
Written by Aston Cook, Senior QA EngineerStart a free mock interview