ISTQB Glossary
ISTQB Glossary 2026 – 700+ Software Testing Terms
Last Updated: July 12, 2026 · SoftwareTestPilot QA Team
The ISTQB glossary is the shared vocabulary every QA engineer, test lead and SDET is expected to speak — and it is the single most useful revision asset for the ISTQB Foundation Level (CTFL v4.0), Agile Tester and advanced-level exams. On this page we publish clean, exam-aligned definitions for the software testing terms that show up most often in interviews and on the CTFL exam itself, from boundary value analysis and equivalence partitioning to pesticide paradox and the seven testing principles.
Every entry follows the same 4-part structure: the official ISTQB v4.0 definition, a plain-English explanation for real projects, a one-line exam tip, and three related terms so you can hop through the glossary the way examiners actually think about it. Use the search box below to jump straight to a term, or scroll the A–Z index. This is the growing hub — we launch with 30 high-frequency terms and add the remaining 670+ in batches so every page stays fast, static and genuinely useful.
Ready to test yourself on the terminology in a live exam simulator? Take the free ISTQB Foundation Mock Test — 40 CTFL v4.0 questions, 60-minute timer, instant scoring and a chapter-wise breakdown.
872 terms shown
A
- A/B TestingShow version A to some users and version B to others, then compare metrics.
- A/B TestingShowing version A to some users and B to others to see which wins.
- Acceptance CriteriaThe checklist that says a user story is done and shippable.
- Acceptance Test-Driven Development (ATDD)The team agrees on acceptance tests up front and only writes code that makes those tests pass.
- Acceptance TestingThe ‘go / no-go’ testing that confirms the system meets business needs and is ready to be released to real users.
- Accessibility (a11y)Common abbreviation for accessibility (a + 11 letters + y).
- Accessibility TestingCheck the software works for users with visual, motor or cognitive disabilities.
- Accuracy (ML)The percentage of predictions the model got right overall.
- ACIDThe four properties that make database transactions safe.
- Actions Class (Selenium)Selenium’s API for complex interactions like drag-and-drop and hovering.
- Ad Hoc ReviewReviewers just read the work product freely with no checklist or roles.
- Ad-hoc TestingPoking around the app with no plan, just intuition.
- AdaptabilityHow easily the app adapts to a new environment without code changes.
- Agile DevelopmentShort sprints, close collaboration, working software over documentation, and continuous change.
- Agile ManifestoThe 2001 document that started agile: individuals over process, working software over docs, collaboration over contracts, response to change over following a plan.
- Agile Test ApproachTesting tailored to agile: short cycles, in-sprint automation, early involvement, whole-team quality.
- Agile Test QuadrantsA 2x2 grid mapping tests: unit/component (Q1), functional (Q2), exploratory/UAT (Q3), non-functional (Q4).
- Agile Tester MindsetThe soft skills the syllabus asks of testers on agile teams: adaptable, collaborative, curious, unblockable.
- AI TestingTesting apps built on AI models — including whether the model itself gives good answers.
- AI-Based TestingUsing AI/ML in the test process itself — auto-generating tests, self-healing selectors, predicting risky areas.
- All-Pairs TestingCover every pair of parameter values instead of every combination.
- Allure ReportA polished test report with charts, history, and step-level detail.
- Alpha EnvironmentInternal ‘pre-beta’ environment where developers and internal testers try the software.
- Alpha TestingEarly real-world testing done on the developer’s premises, usually by a separate QA team or invited customers, before shipping.
- Amazon DynamoDBAmazon’s managed NoSQL database.
- Amazon S3Amazon’s object storage service.
- Amazon SQSAmazon’s managed message queue service.
- Analogy-Based EstimationEstimate this project by looking at how long a similar one took.
- AnalysabilityHow easy it is to figure out why something broke or what a change will affect.
- Analytical Test StrategyBase your testing on a formal analysis of requirements, risks or the code — the most common test strategy.
- AnomalyAnything unexpected the reviewer or tester notices — may or may not be a real defect.
- AnsibleA YAML-based automation tool for configuring servers.
- Apache JMeterThe most widely used open-source performance testing tool.
- Apache KafkaA high-throughput system for streaming events between services.
- API GatewayA front door for your APIs handling auth, routing, and rate limits.
- API KeyA long secret string used to identify the caller of an API.
- API TestingTesting at the service boundary — sending requests to endpoints and asserting responses — without a UI.
- AppDynamicsCisco’s enterprise APM platform.
- AppiumThe Selenium equivalent for mobile apps — one API, iOS and Android.
- ApplitoolsA visual testing platform that uses AI to filter out irrelevant diffs.
- Argo CDA GitOps tool that keeps your Kubernetes cluster in sync with what’s in Git.
- ARIAExtra attributes that tell assistive tech what a widget is and does.
- AssertionThe check inside a test that decides pass or fail.
- ATDD CycleDiscuss the story, distill acceptance tests, develop code + tests, demo to stakeholders.
- Attack TestingDeliberately attack the system the way a real attacker would — SQL injection, XSS, buffer overflows.
- AuditAn external, formal check that a team is following the documented process and standards.
- Audit ReportThe written output of an audit — what was checked, what's compliant, what isn't.
- Authentication TestingVerifying login, password rules, MFA, session, and lockout behaviour.
- AuthorWhoever wrote the document or code under review.
- Author (Review)The person whose document or code is under review.
- Authorization TestingVerifying role- and permission-based access controls.
- AvailabilityPercentage of time the system is up and usable — the 'nines' number.
- AWS LambdaRun code in AWS without managing servers.
- axe-coreThe most widely used engine for automated accessibility checks.
- Azure DevOps Test PlansMicrosoft’s test management inside Azure DevOps.
- Azure FunctionsAzure’s serverless functions — the equivalent of AWS Lambda.
B
- BacklogThe single ordered to-do list the Agile team pulls work from.
- Backlog RefinementA regular meeting to break down, estimate and prioritize upcoming backlog items.
- BaselineA frozen version of a document or build that becomes the reference point for everything after it.
- Baseline Performance TestThe first clean run whose numbers become the yardstick for future runs.
- Basis Path TestingTest only the minimum set of paths that combine to form all other paths — that count equals cyclomatic complexity.
- Battery TestingChecking whether an app kills your phone battery.
- BehaveCucumber for Python.
- Behavior-Driven Development (BDD)BDD writes tests as plain-English scenarios so business, devs and QA agree on what the feature should do before code is written.
- Benchmark TestA repeatable test used to compare versions, releases, or products head-to-head.
- Benefits of Test AutomationSpeed, repeatability, wider coverage, faster feedback, fewer manual errors.
- Beta TestingReal users try the product in their own environment before the general launch, and their feedback drives last-minute fixes.
- Bias TestingChecking whether an AI treats different groups of people fairly.
- Big Data TestingTesting pipelines that process huge datasets across many machines.
- Big-Bang IntegrationSlam everything together and test — cheap but painful to debug when it breaks.
- Black-Box TestingYou design tests only from the spec or behaviour — inputs and expected outputs — without looking at the code.
- Blameless PostmortemA safe, no-blame incident review that focuses on process and system fixes.
- BlazeMeterA cloud service for running JMeter-style perf tests at massive scale.
- Blue-Green DeploymentDeploy the new version to an idle stack, then flip the router to it.
- BottleneckThe single slowest step that caps overall throughput.
- Bottom-Up IntegrationIntegrate from the bottom upward, using drivers to call low-level modules.
- Boundary Value AnalysisBugs cluster at the edges of allowed ranges. So if a field accepts 1–100, you test 0, 1, 100, and 101 instead of only picking a value from the middle.
- Branch CoverageExecuted branches ÷ total branches × 100 — covers both true and false outcomes of each decision.
- Branch TestingDesign tests so every possible outcome of every decision (true and false) is exercised.
- Bug BashEveryone drops their normal work and hunts bugs together for a few hours.
- BuildA specific compiled version of the software ready to be tested or deployed.
- Build Verification Test (BVT)Quick pass/fail check that a new build is stable enough to test further.
- Bulkhead PatternWalling off resources so one failure can’t sink the whole system.
- Burn-Down ChartA graph that goes down each day as the team finishes work — projects when the sprint will complete.
- Burn-Up ChartA graph with two lines: total scope and work completed — makes scope changes visible.
- Business ContinuityMaking sure the business keeps running even when tech, people, or facilities are hit.
- Business RuleA policy from the business (e.g. 'orders over $500 need approval') that the software must enforce.
C
- Call GraphA diagram showing which functions call which other functions.
- Canary ReleaseShip the new version to 1% of traffic, watch it, then ramp up.
- Capacity TestingFind the maximum load at which response times still meet targets.
- Capture / Replay ToolRecord actions once, replay them as an automated test.
- Cause-Effect GraphA diagram linking each input condition to the outputs it triggers — used to generate a decision table.
- CDNA network of servers around the world that speeds up static content delivery.
- Change ManagementThe formal process for proposing, approving, and tracking changes.
- Change RequestA ticket that asks for a specific change to be considered.
- Change-Related TestingUmbrella term for confirmation and regression testing — anything you run because something changed.
- Chaos EngineeringIntentionally break parts of a live system to check it handles failure gracefully.
- Chaos MonkeyA bot that kills random servers in production so the system is forced to survive failure.
- Charles ProxyA GUI proxy for inspecting HTTP traffic during mobile and web testing.
- Checklist-Based ReviewReviewers use a pre-made checklist of common defect types to guide what to look for.
- Checklist-Based TestingWork through a curated checklist of common issues (accessibility, security, edge cases) rather than free-form exploring.
- ChromaticA visual testing platform designed for Storybook-based component libraries.
- CI/CDThe automated pipeline that builds, tests, and ships code on every change.
- CircleCIA popular cloud CI/CD platform.
- Circuit BreakerA pattern that stops hammering a broken service so it can recover.
- Classicist TDD (Detroit School)Start small with real objects and no mocks — grow outward.
- Classification TreeA tree that breaks each input into partitions and sub-partitions so you can combine them systematically.
- Cloud TestingTesting apps that run in the cloud — AWS, Azure, GCP — including scaling and cost behavior.
- CMMIA staged model that rates how mature an organisation's processes are.
- Code CoverageThe percentage of code your tests actually run — measured at statement, branch or condition level.
- Code Coverage ToolMeasures which lines/branches your tests actually ran.
- Code ReviewAnother engineer reading your code before it merges.
- Code SmellA pattern in code (long function, duplicate code, huge class) that suggests a design problem.
- CodegenA recorder that writes Playwright test code as you click around.
- Coding StandardTeam-agreed rules for naming, formatting and structuring code so everyone writes it the same way.
- Cognitive WalkthroughSimulate a first-time user step by step and note where they'd get stuck.
- Color Contrast TestingChecking that text stands out enough from its background to be readable.
- Combinatorial TestingA family of techniques (pairwise, orthogonal arrays, classification tree) that shrink an exploding combination space to a manageable subset.
- Commercial ToolUFT/QTP, TestComplete, LoadRunner — paid tools with vendor support.
- ComparatorA diff engine used to compare actual vs expected output automatically.
- CompatibilityDoes it play well with other systems and share resources cleanly?
- Compatibility TestingVerify the app plays nicely with other browsers, OSes or apps.
- Compliance TestingCheck the software follows the rules it must follow.
- Component Integration TestingTesting how two or more components talk to each other.
- Component TestingTesting the smallest testable pieces of code (a function, class, or module) in isolation, usually by developers.
- Concurrency TestingTest that the system behaves correctly when many things happen at the exact same time.
- Condition CoveragePercent of individual boolean sub-conditions that have been evaluated true and false.
- Condition TestingDesign tests so every atomic condition inside a decision takes both true and false values.
- ConfidentialityOnly the right people can read the data.
- Configuration ItemAnything under version/change control: a source file, a doc, a test script, a build.
- Configuration ManagementThe process that keeps track of what code, data, docs and environments belong together at every point in time.
- Configuration TestingCheck the app works on every supported OS/browser/DB combination.
- Confirmation TestingAlso called re-testing — you rerun the exact steps that reproduced the bug to prove the fix works.
- Confusion MatrixA 2×2 table showing what the model got right and wrong for each class.
- Consultative Test StrategyLet SMEs and stakeholders dictate what to test — used when the testers lack domain knowledge.
- Consumer-Driven Contract TestingConsumers publish what they need; providers verify they still meet it.
- ContainerA portable, isolated bundle of an app and its dependencies.
- Content Security Policy (CSP)A browser policy that blocks scripts and resources from unapproved sources.
- Continuous Delivery (CD)The pipeline can push any commit to production, but a human clicks ‘go’.
- Continuous DeploymentEvery green build goes straight to real users, no manual approval.
- Continuous FeedbackGive the team fast, ongoing signals — reviews, tests, monitoring, retrospectives.
- Continuous ImprovementA culture of small, regular changes that compound into big quality gains.
- Continuous Integration (CI)Every code push triggers a build + automated tests so problems surface within minutes.
- Continuous Integration ToolJenkins, GitHub Actions, GitLab CI, CircleCI — build, test and report on every commit.
- Continuous TestingEvery commit triggers tests — unit, integration, sometimes end-to-end — so risks surface within minutes.
- Contract Acceptance TestingVerify the system meets what the signed contract promises.
- Contract TestingTest that each API consumer and provider still honor the shared schema — great for microservices.
- Contract TestingProducer and consumer each publish and verify a shared contract so integrations don't silently break.
- Control Flow AnalysisStatic analysis that maps every possible execution path to check for unreachable or infinite loops.
- Control Flow GraphA picture of a function where nodes are basic blocks and arrows are possible jumps.
- Core Web VitalsGoogle’s three metrics for real user page experience: LCP, INP, CLS.
- Correlation IDA shared ID that lets you follow one request across many services.
- Cost of QualityPrevention + appraisal + internal failure + external failure costs.
- Coverage ItemThe thing you're counting when you measure coverage — a statement, branch, requirement, partition, etc.
- Coverage ToolJaCoCo, Istanbul, Coverage.py — reports which lines/branches your tests actually hit.
- CQRSSplitting the write side and read side of your data model into separate services.
- Cross-Browser TestingRun the app across Chrome, Firefox, Safari, Edge and old versions to confirm consistent behavior.
- Cross-Platform TestingTest the same app across Windows, macOS, Linux, iOS, Android — behavior should match.
- Cross-Site Request Forgery (CSRF)Malicious page makes your browser send a real, authenticated request to another site.
- Cross-Site Scripting (XSS)Attacker gets their JavaScript to run in another user's browser session.
- Crowd TestingPay a large pool of external testers to hit your product on real devices.
- CSATA short customer satisfaction rating.
- CSS SelectorA syntax for finding elements the way CSS styles them.
- Cucumber FrameworkA tool that ties Gherkin scenarios to executable code (step definitions).
- Cucumber-JVMCucumber for Java projects.
- Cumulative Layout Shift (CLS)How much the page jumps around while loading.
- cy.interceptCypress’s network-mocking command.
- Cycle TimeHow long it actually takes to finish one work item once you start it.
- Cyclomatic ComplexityA metric that counts branches in code — higher number means the code is harder to test.
- CypressA developer-friendly E2E test framework built for modern JavaScript apps.
- Cypress RetriesCypress feature to auto-retry failing tests.
D
- Daily Stand-upThe 15-minute daily meeting where each team member says what they did, will do and any blockers.
- Dark LaunchShip the code live but keep it hidden so you can test it in production without users seeing it.
- DAST (Dynamic Application Security Testing)Security scanning of a live system — finds issues SAST can't see.
- Data Flow AnalysisStatic-analysis technique that tracks where variables are set and read to find bugs like use-before-define.
- Data MaskingTake real data and scramble the sensitive bits (names, SSNs) so the shape is real but the values are fake.
- Data Migration TestingMaking sure nothing is lost or corrupted when moving data to a new system.
- Data QualityHow trustworthy your data is — right values, no gaps, no duplicates, up to date.
- Data SubsettingCopying just a slice of production data — with all relationships intact — for testing.
- Data TestingTesting that data moving through pipelines and dashboards is accurate, complete, and on time.
- Data-Driven TestingOne test script + a table of inputs and expected outputs = many test runs.
- Data-Driven Testing (Modern)One test script + many rows of data = many test cases.
- Database IndexA lookup structure that makes SELECTs fast.
- Database ReplicationKeeping copies of the database on multiple servers.
- Database TestingTesting the database directly — schemas, queries, procedures — not just through the UI.
- DatabricksA cloud platform for big data engineering and ML on top of Spark.
- DatadogA commercial all-in-one monitoring and observability platform.
- Dead CodeCode that no execution path can ever reach — usually left over from refactoring or bad conditionals.
- DeadlockTwo processes each hold a lock the other needs — both freeze forever.
- Debugging ToolChrome DevTools, gdb, IDE debuggers — step through code and inspect state.
- Decision CoveragePercent of decision outcomes (true/false) hit by your tests.
- Decision TableA grid where each column is a rule: which conditions are true and what the system should do about it.
- Decision Table TestingWhen behaviour depends on combinations of conditions (like discount rules), you list every condition and expected action in a table and turn each column into a test case.
- Decision TestingDesign tests so each decision point (if / switch) is exercised for every possible outcome.
- DefectA flaw in the product — code, requirement, or design — that could cause a failure when executed.
- Defect AgeHow long a bug lived before it was found or resolved.
- Defect Arrival RateHow many new bugs are being logged per day / sprint / build.
- Defect ClusteringBugs are not spread evenly — a few risky modules host most of them, so focus extra testing there.
- Defect DensityHow many defects per 1,000 lines of code, page of spec, or story point.
- Defect Detection Percentage (DDP)What share of eventual bugs did this test level catch? Higher is better.
- Defect LifecycleThe journey a bug takes from being reported to being closed.
- Defect ManagementThe end-to-end workflow of finding, logging, triaging, fixing and closing bugs.
- Defect Removal Efficiency (DRE)How many of the eventual bugs did this phase catch?
- Defect ReportThe written record of a bug — title, steps, expected vs. actual, severity, priority, environment.
- Defect Tracking ToolJIRA, Bugzilla, Mantis — where bug reports live and move through their state model.
- Defect TriageA regular meeting where the team looks at new bugs and decides which to fix now, later or never.
- Definition of DoneAn Agile team’s shared checklist for ‘this work is really done, including tests, docs and deployment’.
- Definition of Done (Agile)The team’s checklist of everything true before a story is called ‘done’.
- Definition of ReadyAn Agile team’s shared checklist for ‘this story is clear enough to work on’.
- Dependency Scanning (SCA)Scan your libraries for known CVEs, usually as part of CI.
- Dependency TestingMaking sure upgrades to libraries don't break your app.
- DeploymentGetting the software running in an environment (test, staging, prod).
- Deployment ToolAnsible, Terraform, ArgoCD, Octopus — push builds into environments consistently.
- DetoxAn E2E testing framework built specifically for React Native apps.
- Development TeamThe self-organizing, cross-functional group (devs + testers + designers) that builds the increment.
- Device FarmA cloud service that lets you run tests on hundreds of real phones at once.
- DevOpsDev and Ops share ownership of building, shipping and running the product — automation and CI/CD glue it together.
- Differential TestingComparing two versions of the same thing against the same inputs and catching where they disagree.
- Disaster Recovery (DR)The plan for bringing systems back after major outages, region failures, or data loss.
- Distributed TracingA tool that shows how a single request travels across all your microservices.
- DO-178CThe avionics software safety standard.
- DockerA tool that packages an app and everything it needs into a portable container.
- Docker ComposeA YAML file that starts many containers together as one app.
- DockerfileThe recipe file that tells Docker how to build an image.
- Done-Done"Done for real" — including tests, review, and deploy — not just "code written".
- DORA MetricsDeployment frequency, lead time, change failure rate, mean time to restore — the four DevOps performance KPIs.
- DriverFake caller code that invokes the module under test when the real caller doesn't exist yet.
- Driver (Test Driver)A piece of code that calls a low-level module so it can be tested in isolation.
- DSDM (Dynamic Systems Development Method)An agile method that fixes time and cost but flexes scope.
- Dummy ObjectAn empty placeholder object used to satisfy a signature.
- Dynamic Analysis ToolValgrind, AddressSanitizer — watches a running program for memory leaks, race conditions, undefined behavior.
- Dynamic TestingAny testing where the code actually runs — as opposed to reviews or static analysis.
- DynatraceA commercial observability platform known for its AI (Davis) root-cause engine.
E
- Edge ComputingRunning code closer to the user for lower latency.
- Efficiency TestingTest whether the system delivers its output using a reasonable amount of resources (CPU, memory, network).
- ElasticsearchA distributed search engine powering many app search bars and log platforms.
- ELK StackA popular log collection, storage, and search stack.
- Embedded TestingTesting software that runs on tiny chips inside cars, appliances, and medical devices.
- Embeddings TestingTesting the vector representations AI systems use to find similar items.
- EmulatorSoftware that pretends to be a different device or system for testing.
- End-to-End Testing (E2E)Test the whole app the way a user would, through the real UI and back-end.
- Endurance TestingLeave the system running for hours or days under load to see what slowly breaks.
- Entry CriteriaThe checklist that must be true before a test level or activity can start — e.g. build deployed, smoke passed.
- Entry Criteria (Review)The checklist a work product must pass before it enters review — spellcheck done, template followed, etc.
- Ephemeral EnvironmentA throw-away environment created for one PR or one test cycle.
- EpicAn epic is a big feature that is too large for one sprint and is split into stories.
- Equivalence PartitioningGroup inputs that the system should treat identically, then pick one value from each group. That way you cover behaviour without testing every possible value.
- ErrorThe mistake a person made — the wrong requirement, wrong design, wrong line of code.
- Error BudgetHow much unreliability you're allowed before you must slow down releases.
- Error Budget PolicyThe rules for what happens when a service uses up its error budget — e.g. release freeze.
- Error GuessingDesign tests based on where you (or history) know bugs usually hide — nulls, empty strings, zero, negatives, huge inputs.
- Error Handling TestingVerifying that errors produce useful, safe, and consistent behaviour.
- Escaped DefectA bug that slipped past your tests and reached the next stage or production.
- EspressoGoogle’s official framework for testing Android apps from inside the app.
- ETL TestingTesting the pipes that move and reshape data from one system to another.
- Event SourcingStoring every change as an event instead of overwriting rows.
- Example MappingWhiteboard exercise that turns a story into rules and concrete examples.
- Exception HandlingCode that catches and reacts to runtime errors without crashing.
- Exit CriteriaThe checklist that must be true before you can declare testing done — coverage hit, no open blockers, etc.
- Exit Criteria (Review)The rules that say the review is finished — all major defects logged, checklist covered, sign-off given.
- Experience-Based TestingTests come from what you’ve seen break before — error guessing, exploratory testing, checklist-based testing.
- Expert-Based EstimationAsk someone experienced how long it will take.
- Explicit WaitWaiting for a specific condition, like "button is clickable", before continuing.
- Exploratory TestingYou learn the product while testing it, using your experience to decide what to try next instead of following a pre-written script.
- ExtentReportsA popular Java library that generates rich HTML test reports.
- Extreme Programming (XP)An agile method focused on engineering practices: TDD, pair programming, refactoring, CI, small releases.
F
- F1 ScoreA single score that balances precision and recall.
- Fail FastCrash immediately on bad input instead of limping along.
- Fail SafeIf something fails, default to a safe outcome.
- FailureThe visible symptom — the app crashed, the calculation was wrong, the button did nothing.
- Failure Mode and Effects Analysis (FMEA)For each component, brainstorm how it could fail, what happens if it does, and how to prevent or detect it.
- Failure RateHow often the software fails per hour, per transaction, per run.
- FakeA working but simplified stand-in — e.g. an in-memory DB.
- False NegativeTest says pass, but there is a real bug — the worst kind of miss.
- False PositiveTest says fail, but the software is actually fine — often flaky tests or bad data.
- Fault ToleranceKeeps working even when parts fail.
- Feature (Agile)A user-facing capability of the product, bigger than a story but smaller than an epic.
- Feature FlagA switch in config that hides or shows a feature to users.
- Feature ToggleA switch that turns features on or off without redeploying.
- FiddlerA classic Windows HTTP debugging proxy from Progress (formerly Telerik).
- Fishbone DiagramIshikawa / cause-and-effect diagram: brainstorm causes into people / process / tools / environment.
- Flaky TestA test that sometimes passes and sometimes fails on the same build — usually a timing or environment issue.
- Fluent WaitA customizable wait that polls at set intervals and can ignore certain errors.
- Formal ReviewAny review with defined roles, checklists, metrics and entry/exit criteria.
- Formative Usability EvaluationUsability testing done while the UI is being designed — feedback goes straight into the next iteration.
- Function Point AnalysisSizing software by counting inputs, outputs, inquiries, files, and interfaces.
- Functional CompletenessDoes the software cover every promised feature and user goal?
- Functional CorrectnessDoes the function produce the right output for the given input?
- Functional SuitabilityDoes the software actually do what it should? Correctness, completeness, appropriateness.
- Functional TestingDoes the feature do what the spec says? Login logs you in, checkout charges the right amount.
- FURPSA checklist of five quality dimensions: F, U, R, P, S.
- Fuzz TestingBombard the system with malformed, random or unexpected inputs and see what breaks.
G
- GatlingA Scala-based performance testing tool known for beautiful reports.
- GC TuningTweaking Java garbage collector settings to reduce pauses.
- GDPRThe EU privacy law that governs how personal data is collected and processed.
- GherkinThe Given-When-Then syntax file format that Cucumber-family tools execute as tests.
- GitThe standard version control system used everywhere.
- Git BranchA separate line of development in Git.
- Git MergeCombining changes from one branch into another.
- Git RebaseRewriting your branch to sit on top of another branch for a clean history.
- GitHub ActionsBuilt-in CI/CD for GitHub repos, configured with YAML workflows.
- GitLab CI/CDGitLab’s built-in CI/CD system, configured in .gitlab-ci.yml.
- GitOpsManaging your infrastructure and deployments through Git commits.
- Given-When-ThenThe BDD scenario template: Given (context), When (action), Then (expected result).
- Google Cloud RunGoogle Cloud’s serverless container platform.
- Google Pub/SubGoogle Cloud’s managed messaging service.
- Gorilla TestingHammering one specific module over and over to find weak spots.
- Graceful DegradationThe system keeps working, just with fewer features, when something breaks.
- GrafanaThe standard dashboard tool for metrics and logs.
- GraphQL TestingTesting GraphQL APIs — one endpoint, flexible queries.
- Gray-Box TestingTesting that mixes user-view scenarios with some knowledge of the internals.
- GremlinA commercial tool for running safe chaos experiments in production.
- gRPC TestingTesting gRPC APIs — the high-performance protocol used between microservices.
- Guardrail TestingTesting the safety filters that stop the AI from saying harmful or off-topic things.
H
- HallucinationWhen the AI makes stuff up but sounds sure about it.
- Happy PathThe main flow where everything goes right.
- Hardening SprintA stabilization sprint dedicated to bug fixes and non-functional testing before release.
- Hardware-in-the-Loop (HIL) TestingPlugging real hardware into a simulated world to test the software driving it.
- Headless BrowserA browser with no visible window — perfect for running tests in CI.
- Heap DumpA snapshot of JVM memory used to hunt memory leaks.
- HelmThe package manager for Kubernetes.
- Heuristic EvaluationExperts walk the UI against a checklist of usability rules — usually Nielsen's 10.
- Hexagonal / Ports & Adapters TestingTest business logic through clean interfaces; test the plumbing separately.
- HIPAAThe US health-data privacy and security law.
- HydrationBringing a server-rendered page to life on the client with JavaScript.
- Hyperlink Testing ToolLink checkers like broken-link-checker or W3C Link Checker.
I
- IAST (Interactive Application Security Testing)A middle ground between SAST and DAST that watches the app from inside as tests run.
- Ice-Cream Cone Anti-PatternA test suite that is heavy on UI and manual, light on unit — the opposite of the pyramid.
- IdempotencyDoing the same thing twice has the same effect as doing it once.
- IEC 62304The lifecycle standard for medical device software.
- IEEE 1044The IEEE standard for classifying software bugs.
- IEEE 829The classic template list for test docs: plan, design, case, procedure, log, incident, summary.
- Impact AnalysisBefore making a change, work out what else it will touch so you can plan tests and effort.
- Implicit WaitA global wait telling Selenium to keep trying to find elements for N seconds.
- IncidentAnything unexpected in test or production that needs looking into.
- IncrementThe working, tested, potentially shippable piece of product delivered at the end of a sprint.
- Incremental Development ModelYou ship the product piece by piece, adding features over time instead of all at once.
- Individual ReviewEach reviewer reads the work product on their own before the group meeting.
- Informal ReviewA quick, unstructured read-through with no checklists, roles or logged results.
- Infrastructure as CodeDefine servers, networks and configs in code (Terraform, CloudFormation) so envs are versioned and reproducible.
- Input PartitionA group of inputs the system should treat the same way — pick one representative to test the whole group.
- InspectionThe most formal review type — trained moderator, defined roles, entry/exit criteria, metrics collected.
- Inspection RateHow fast the review team is covering material.
- InstallabilityHow smoothly the software installs, upgrades, and uninstalls.
- Installation TestingVerify the installer, upgrader and uninstaller all work cleanly.
- Integration TestingAfter units work alone, you plug them together and check the seams — API calls, data hand-offs, contracts.
- IntegrityData can't be tampered with by unauthorized parties.
- Interaction to Next Paint (INP)How quickly the page responds to user clicks and taps — replaces FID.
- Internationalization Testing (i18n)Test that the codebase is ready to be translated: date/number formats, RTL text, character encoding.
- Interoperability TestingCheck two systems can actually talk to each other and understand the data.
- Invalid PartitionA group of bad inputs the system is supposed to reject with an error — the negative-testing partition.
- INVESTThe six-letter test for a good user story: Independent, Negotiable, Valuable, Estimable, Small, Testable.
- IoT TestingTesting smart devices — thermostats, wearables, sensors — and how they talk to each other and the cloud.
- ISO 26262The functional safety standard for cars.
- ISO/IEC 12207The umbrella standard describing all software life-cycle processes.
- ISO/IEC 25010The reference model with 8 product quality characteristics and 5 quality-in-use characteristics.
- ISO/IEC 27001The main international standard for information security programs.
- ISO/IEC 9126The old quality model — replaced by ISO 25010 but still cited.
- ISO/IEC/IEEE 29119The modern successor to IEEE 829 — covers processes, docs, techniques.
- IssueAny open question — a possible defect, a doc discrepancy, a process problem — that needs a decision.
- IstioThe most widely used service mesh, built on Envoy.
- IterationA fixed-length development cycle that delivers a working increment (a.k.a. sprint in Scrum).
- Iteration PlanningSame idea as sprint planning — pick items and plan how to build them for one iteration.
- Iterative Development ModelYou build the product in loops, learning and refining each time, instead of one big waterfall.
J
- JavaScript Executor (Selenium)A Selenium hook to run JavaScript inside the tested page.
- JenkinsThe most widely used open-source CI/CD server.
- JestThe most popular JavaScript test framework, batteries included.
- JiraAtlassian’s issue and workflow tracker.
- JSON Web Token (JWT)A signed JSON blob used to prove who you are between services.
- JUnitThe standard unit testing framework for Java.
K
- k6A developer-friendly JS-based load testing tool.
- KanbanA visual board that limits how many items are ‘in progress’ at once.
- Karate DSLA Gherkin-based framework that tests APIs, mocks, and performance from one tool.
- Katalon StudioA commercial low-code automation platform covering web, mobile, and API.
- Keyboard Navigation TestingUnplug the mouse and try to reach every control — tab, shift+tab, enter, space.
- Keyword-Driven TestingWrite tests as spreadsheets of keywords ('login', 'add to cart') instead of code — non-coders can maintain them.
- KickoffThe opening meeting where the moderator explains the review objectives and hands out material.
- Kubernetes (K8s)The standard system for running and scaling containers in production.
- Kubernetes DeploymentA K8s resource that keeps a set of pods running and updates them safely.
- Kubernetes IngressThe Kubernetes resource that exposes services to outside traffic.
- Kubernetes ServiceA stable network address for a group of pods, even as they come and go.
L
- Largest Contentful Paint (LCP)How fast the biggest thing on the page finishes loading.
- LatencyThe wait time before data starts arriving — network-focused delay.
- Lead TimeHow long a customer waits from ‘I want this’ to ‘I got it’.
- LeanBuild only what customers value; cut everything that doesn’t add to that.
- LeSS (Large-Scale Scrum)Scrum, but stretched to many teams working on one product.
- Lessons LearnedThe insights captured at the end of a project so the next one doesn't repeat mistakes.
- Level Test PlanThe test plan for a single level (e.g. system testing) — scope, entry/exit, environment, schedule.
- LighthouseGoogle’s built-in tool that grades a page on perf, a11y, and SEO.
- LinkerdA lightweight alternative to Istio.
- LintA tool like ESLint or Pylint that reads code and warns about likely problems.
- LinterThe nagging tool that catches typos, unused vars, and style issues before they reach review.
- LLM as JudgeUsing a language model to grade the answers of another language model.
- LLM TestingTesting ChatGPT-style apps — accuracy, safety, cost, and speed.
- Load TestingSimulate the expected number of users to see if the system copes.
- Load Testing (Detail)Increase load in a controlled way to find how many users/transactions the system supports.
- LoadRunnerThe classic enterprise performance testing tool.
- Localization Testing (l10n)Test each localized version: strings translated, dates/currency correct, layout unbroken.
- LocatorHow your test finds a button, link, or field on the page.
- LocustA Python load testing tool where each virtual user is a class you write.
- LoggingThe app writes a diary of what it did, used later to debug or audit.
- Loop TestingTest loops with zero, one, two, typical, N-1, N and N+1 iterations to catch boundary and off-by-one bugs.
M
- Machine Learning TestingTest ML systems on data, model behavior, fairness and drift — not just standard functional tests.
- MaestroA new mobile test framework that uses simple YAML flows.
- MaintainabilityHow easily developers can change, fix or extend the software later.
- Maintainability TestingCheck how easy it is for developers to change the code safely.
- Maintenance TestingTesting done after go-live — patches, upgrades, migrations, retirements — to keep the running product safe.
- Management ReviewA review that focuses on progress, risks and process — not on defects in the product.
- Master Test PlanOne plan that covers unit, integration, system and acceptance testing at the program level.
- MC/DC (Modified Condition/Decision Coverage)Every condition in an if-statement must be shown to independently change the result.
- Mean Reciprocal Rank (MRR)How high up the first correct answer tends to appear in a ranked list.
- Mean Time Between Failures (MTBF)For a system that gets fixed, the average uptime between two failures.
- Mean Time Between Failures (MTBF)On average, how long the system runs between failures.
- Mean Time to Detect (MTTD)How long, on average, a bug lives in the system before someone notices it.
- Mean Time To Failure (MTTF)On average, how long the system runs before it fails.
- Mean Time to Recover (MTTR)On average, how fast we get back up after breaking.
- Mean Time To Repair (MTTR)The average time from a failure to the system being back up.
- Message QueueA buffer that holds messages while producers and consumers work at different speeds.
- Metamorphic TestingInstead of asserting an exact answer, assert that changing the input in a known way changes the output in a known way.
- Methodical Test StrategyReuse a standard checklist (e.g. accessibility, security, quality attributes) as the test baseline.
- MicroservicesAn app built from many small services, each with its own database and deployment pipeline.
- Microservices TestingTesting a system where dozens of small services talk over HTTP or messaging.
- Migration TestingTesting that everything still works after moving to a new platform.
- mitmproxyAn open-source proxy for capturing and tweaking HTTPS requests during testing.
- Mob ProgrammingWhole team on one screen — one driver, many navigators.
- Mobile Network TestingTesting how the app behaves on slow, spotty, or dropped connections.
- Mobile TestingTesting apps on real phones: functionality + performance + battery + network + interruptions.
- MochaA popular JS test runner, often paired with Chai for assertions.
- Mock ObjectA fake dependency you configure to expect specific calls and assert on them afterwards.
- Mock ServerA fake API you control so tests aren’t blocked by real backends.
- Mock Service Worker (MSW)A library that fakes API responses in browser and Node tests.
- MockoonA GUI tool to spin up fake REST APIs in minutes.
- Model DriftWhen an AI model gets worse over time because the real world changed.
- Model-Based Test StrategyBuild a model (state machine, business process) and let the tool generate tests from it.
- Model-Based TestingTesting where test cases are derived automatically from a model of the system's behaviour.
- ModeratorThe person who runs the review meeting, keeps discussion on track and ensures the process is followed.
- ModifiabilityHow safely you can change the code without breaking other things.
- Modified Condition/Decision Coverage (MC/DC)For each atomic condition, show one test where flipping just that condition flips the whole decision.
- ModularityWell-separated pieces that don't cause ripple effects when changed.
- MongoDBA popular document-oriented NoSQL database.
- MonitoringWatching logs, metrics and traces from the live system to catch problems fast.
- Monitoring ToolNew Relic, Datadog, Prometheus — watch the app in real time.
- Monkey TestingThrowing random inputs at the app to see what breaks.
- MoSCoW PrioritizationA ranking system: must, should, could, won’t.
- MSTestThe unit test framework built into Visual Studio.
- Multi-Factor Authentication (MFA)Logging in with more than just a password.
- Multiple Condition TestingCover every combination of true/false values of the sub-conditions inside a compound decision.
- Mutation TestingAutomatically tweak the code in tiny ways and check whether your tests catch each change — if not, tests are weak.
- Mutual TLS (mTLS)TLS where both sides prove who they are with certificates.
- MySQLA widely used open-source relational database, popular with LAMP-stack apps.
N
- N-Switch CoverageHow much of the state machine you've covered when you chain N+1 transitions together in one test.
- NDCGA metric for how well a ranked list puts the best results at the top.
- Negative TestingDeliberately feeding the system bad or unexpected inputs to prove it fails gracefully instead of crashing.
- NeoLoadA commercial perf testing platform used in enterprise DevOps pipelines.
- Net Promoter Score (NPS)A single-question customer loyalty score.
- New RelicA commercial APM and observability platform.
- NewmanThe CLI that runs Postman collections in your build pipeline.
- Nielsen's 10 Usability HeuristicsThe classic checklist for judging UI usability.
- Nightwatch.jsA JS E2E framework built on WebDriver.
- Non-Functional TestingHow fast, how secure, how usable, how reliable — the ‘qualities’ around the feature, not the feature itself.
- Non-RepudiationYou can prove who did what, so they can't deny it later.
- NUnitJUnit for .NET.
O
- OAuth 2.0The standard "Sign in with Google" style delegation protocol.
- ObservabilityHow well you can figure out what a live system is doing from outside.
- Offline TestingTesting that the app still works when there’s no internet.
- Open-Source ToolSelenium, JMeter, Playwright, JUnit — free tools with community support.
- OpenAPI (Swagger)A standard format for describing what an API can do.
- OpenID ConnectOAuth plus a standardized way to know who the user is.
- OpenTelemetry (OTel)The standard SDK for producing observability data in any language.
- Operational Acceptance Testing (OAT)Ops team checks that the system is deployable, monitorable and recoverable.
- Operational ProfileA weighted map of how real users spend their time in the system — used to focus testing on high-usage flows.
- Orthogonal Array TestingA math-based way of picking a small, balanced set of test cases that still covers every pair of input values.
- Output PartitionA group of outputs the system produces the same way — used when designing tests from expected results, not inputs.
- Outside-In TDD (London School)Start with a big user-level test, then mock your way down to units.
- OWASP Top 10The industry-standard hit list of the most dangerous web vulnerabilities.
P
- Pa11yA CLI tool for running accessibility checks in CI.
- PactThe most popular consumer-driven contract testing tool.
- Page FactoryA Selenium pattern that wires up page elements via annotations.
- Page Object ModelWrap each page/screen in a class so tests interact with methods (login()) not raw selectors.
- page.route (Playwright)Playwright’s network interception API.
- Pair ProgrammingTwo developers, one keyboard — instant code review and knowledge sharing.
- Pair TestingTwo testers (or a tester and dev) at one screen exploring together.
- Pairwise TestingInstead of testing every combination, test every pair of inputs at least once — catches most combination bugs with far fewer tests.
- Parallel ExecutionRunning tests at the same time instead of one after another.
- PasskeyA cryptographic replacement for passwords, synced across your devices.
- Path TestingDesign tests so each independent path from entry to exit of a function is executed.
- PCI DSSThe security standard for anyone handling credit card data.
- Peer ReviewAny review where the reviewers are the author's peers — walkthroughs, technical reviews and inspections all qualify.
- Penetration TesterThe ethical hacker who tries to break in on purpose.
- Penetration TestingSimulate a real attack on the system to find exploitable holes.
- Percentile Latency (p50/p95/p99)p95 = 95% of requests are faster than this number.
- PercyA tool that catches unintended visual changes across your app’s pages.
- Performance EfficiencyHow well the software performs given the CPU, memory, and bandwidth it consumes.
- Performance TestingHow fast, how many users, how stable under load — response time, throughput, resource usage.
- Performance Testing ToolJMeter, Gatling, k6, LoadRunner — drive high load and record response times.
- Personally Identifiable Information (PII)Data that identifies a specific person — must be protected.
- Perspective-Based ReadingEach reviewer reads the document as if they were a specific stakeholder — user, tester, developer, operator.
- Pesticide ParadoxRunning the same tests forever stops catching new bugs. You need to review and refresh test cases regularly.
- Pipeline as CodeThe pipeline lives in your repo as a YAML or DSL file.
- Planning PokerA game where everyone flips an estimate card at the same time to avoid anchoring.
- PlaywrightA modern, fast browser automation tool that competes with Selenium and Cypress.
- Playwright FixturesPlaywright’s way to inject browser context, pages, and helpers into tests.
- PodThe smallest deployable unit in Kubernetes — usually a single container.
- PortabilityHow easily the software moves to new OSes, browsers, devices, or clouds.
- Portability TestingCheck the app works on other browsers, OSes or hardware.
- Positive TestingTesting the happy path with good inputs to confirm the system does what the spec says.
- PostgreSQLA leading open-source relational database.
- PostmanThe most popular API testing and exploration tool.
- Postman CollectionA saved bundle of API requests you can share and run together.
- PostmortemThe blameless review meeting after a major incident or release.
- Power of ThreeAlso called Three Amigos — dev + tester + business talk each story through before it's built.
- Pre-Production EnvironmentThe last environment before production — mirrors it as closely as possible.
- PrecisionOf everything the model called positive, how many actually are?
- PriorityHow urgently the bug should be fixed from a business point of view — a low-severity blocker for a demo can still be top priority.
- Privacy TestingVerify the app follows GDPR, CCPA, HIPAA etc. — consent, minimization, retention, deletion.
- Process-Compliant Test StrategyDo exactly what a standard (ISO 29119, DO-178C, IEC 62304) says — common in regulated industries.
- Product BacklogThe prioritized, evolving list of everything the product might ever need — owned by the Product Owner.
- Product OwnerThe single voice of the customer who decides what the team builds next.
- Product RiskThings that could go wrong with the product itself — a bug, a data loss, a security flaw.
- Production DefectA bug found in live use — usually the most expensive kind.
- Production EnvironmentThe real system your customers actually use.
- ProfilerMeasures where your code spends its time and memory.
- Progressive DeliveryRolling out features to small groups first before everyone gets them.
- Project RiskThings that could derail the project itself — late environments, sick team members, unclear scope.
- PrometheusThe standard open-source metrics database in cloud-native stacks.
- Prompt TestingTesting whether your prompts reliably produce the answers you want.
- Proof of ConceptA small pilot to prove a tool actually works in your environment before you commit budget.
- Property-Based TestingInstead of writing example tests, describe rules that should always hold and let the tool try 1000s of inputs.
- Prototyping ModelBuilding a rough working version early to learn what users actually want.
- Pull RequestThe GitHub/GitLab mechanism used to propose and review code changes.
- PuppeteerGoogle’s Node library for automating Chrome.
- PWA TestingTesting web apps that install and work offline like native apps.
- pytestThe de-facto Python test framework.
Q
- qTestTricentis’ enterprise test management platform.
- QualityTwo lenses: does it match the spec, and does it delight the user? Both matter.
- Quality AssuranceQA = process focus — ‘are we working the right way so quality is likely?’.
- Quality ControlQC = product focus — ‘does this actual build meet our quality bar?’. Testing is a QC activity.
- Quality GateA pass/fail check the build must clear before moving to the next stage.
- Quality ModelA structured checklist of what 'quality' means, so requirements and tests can target it.
- Quality StandardA published rulebook for quality (ISO 25010, IEEE 829, etc.) you can measure your product against.
R
- RabbitMQA popular open-source message broker for queueing work between services.
- Race ConditionTwo threads or requests interfere because their timing wasn't controlled.
- RAG TestingTesting AI systems that look up documents and then answer questions.
- Ramp-UpBring users on slowly instead of hitting the system with full load instantly.
- Random TestingGenerate inputs at random (often weighted by how users actually use the system) instead of hand-picking them.
- Rapid Application Development (RAD)Building working prototypes fast, then refining based on user feedback.
- Rate LimitingCapping how many requests a client can make per minute.
- Reactive Test StrategyDon't pre-design tests — react to the build in front of you (exploratory, error guessing, attacks).
- ReadabilityHow easy it is for another person to understand the code or document.
- Real Device TestingRunning tests on actual phones instead of emulators to catch real-world issues.
- Real-Time TestingMaking sure a system responds within a guaranteed time — every time, no exceptions.
- Real-User Monitoring (RUM)Measure what real users actually experience, in the wild.
- RecallOf everything that is actually positive, how many did the model catch?
- Record & PlaybackModern name for capture/replay — great for smoke tests, poor for maintainable suites.
- Record and Playback ToolSelenium IDE, Katalon Recorder — record a browser session, replay it as a test.
- RecoverabilityCan the system bounce back cleanly after a crash without losing data?
- Recoverability TestingHow well the system restores itself and its data after a failure.
- Recovery TestingDeliberately crash it and time how cleanly it comes back.
- Red-Green-RefactorWrite a failing test, make it pass, then clean it up. Repeat.
- RedisAn extremely fast in-memory key-value store, used for caching and sessions.
- RefactoringClean up the code without changing what it does.
- Regression AvoidanceDesign and process choices that stop regressions from being introduced in the first place.
- Regression TestingAfter any change — bug fix, new feature, config update — you re-run existing tests to make sure nothing that used to work has broken.
- Regression-Averse Test StrategyPrioritize keeping working features working — heavy automation, wide regression packs, impact analysis.
- Regulation Acceptance TestingProve the system meets legal and regulatory requirements like GDPR or HIPAA.
- Release ManagementThe end-to-end process for moving software from dev to production.
- Release PlanThe multi-sprint plan showing which backlog items will ship in which release.
- Release PlanningDeciding which features go in which release across several sprints.
- Release TestingA last-mile pass on the release candidate — smoke, regression, non-functional spot checks.
- ReliabilityHow consistently the system stays up and correct over time.
- Reliability TestingCheck the system keeps working correctly over time under expected load.
- ReplaceabilityHow easily this component can swap in for another one doing the same job.
- RequirementA statement of what the system must do or how well it must do it.
- Requirements CoverageHow many requirements have at least one test linked to them.
- Requirements Management ToolJIRA, DOORS, Jama — where requirements are stored, versioned and traced.
- Resilience TestingCheck the system bounces back after crashes or lost dependencies.
- Resource UtilizationHow much CPU, memory, disk and bandwidth the software chews through under load.
- Response TimeTime from click to visible result — the classic user-perceived performance metric.
- REST API TestingTesting REST APIs — the URLs and JSON payloads behind most web apps.
- REST AssuredA Java library for writing readable REST API tests.
- Retest (Confirmation Testing)Running the same test again after a fix to confirm the bug is gone.
- RetrospectiveThe regular team meeting for ‘what went well, what didn’t, what to change’.
- Retry PatternAutomatically re-attempting failed calls, usually with a growing delay.
- ReusabilityHow easily a component can be used again elsewhere.
- ReviewSomeone reads or discusses a document (requirements, code, test cases) to find problems before running the software.
- Review MeetingThe formal group session where reviewers discuss what they found individually.
- Review PlanThe plan for what will be reviewed, by whom, and when.
- Review ReportThe output of the review — list of defects found, metrics, and any process improvement suggestions.
- ReviewerAnyone in the review meeting whose job is to find and describe defects.
- RICE PrioritizationA scoring formula: (Reach × Impact × Confidence) ÷ Effort.
- RiskSomething that might happen and would hurt the project, product or business if it did.
- Risk AnalysisFind risks, judge how bad and how likely each one is, and decide what to do about them.
- Risk AssessmentScore each risk on likelihood × impact so you can rank them.
- Risk CoverageHow many of the known product risks actually have tests behind them.
- Risk LevelA single number (often likelihood × impact) that says how much attention a risk deserves.
- Risk MitigationThe actions you take to shrink a risk — extra testing, code review, redesign, insurance.
- Risk-Based TestingYou test the risky stuff first and hardest. Low-risk areas get lighter coverage.
- Risks of Test AutomationUpfront cost, maintenance burden, false confidence, brittle scripts, wrong tests automated.
- Robot FrameworkA keyword-driven, human-readable automation framework.
- Role-Based ReviewSimilar to perspective-based reading — each reviewer takes a role such as end-user or admin.
- RollbackUndo the release and put the previous version back.
- Rolling DeploymentReplacing old servers with new ones a few at a time.
- Root CauseThe underlying reason a defect exists — fix this and the whole class of defect goes away.
- Root Cause AnalysisA structured investigation (5 Whys, fishbone) to find why a defect was introduced.
- RSpecThe standard BDD-style test framework for Ruby.
- RTO / RPORTO = how long you can be down. RPO = how much data you can lose.
S
- SAFe (Scaled Agile Framework)A method for running agile across many teams and many products.
- Saga PatternA way to keep data consistent across microservices without a global transaction.
- SAMLAn older XML-based SSO protocol, common in enterprise IdPs.
- Sandbox EnvironmentA safe playground environment isolated from production data.
- Sandwich IntegrationIntegrate from both ends toward the middle — hybrid of top-down and bottom-up.
- Sanity TestingA narrow, targeted check after a small change — did this specific fix work and did it not obviously break its immediate neighbours?
- SAST (Static Application Security Testing)Security scanning of source code — catches vulnerabilities before running.
- Scalability TestingCheck the system can handle growth by adding resources or nodes.
- Scenario TestingTesting full user journeys, not just individual features.
- Scenario-Based ReviewReviewers walk realistic use scenarios through the document to check it supports them.
- Screen Reader TestingActually navigating the app with NVDA, JAWS, or VoiceOver as a real user would.
- ScribeThe note-taker who logs every defect and comment raised during the review.
- ScrumThe most common Agile framework — short sprints, daily standups, reviews and retros.
- Scrum MasterThe servant-leader who removes impediments and coaches the team on Scrum.
- ScrumbanA blend of Scrum and Kanban.
- Secrets ManagementHow you safely store and rotate passwords, keys, and tokens used by code.
- Section 508The US federal accessibility law — requires WCAG-level access for federal IT.
- Security (ISO 25010)Confidentiality, integrity, non-repudiation, authenticity, accountability.
- Security TestingTrying to break in, leak data, or escalate privileges — before an attacker does.
- Security Testing ToolBurp Suite, OWASP ZAP, Nessus — scan for vulnerabilities and simulate attacks.
- SeleniumThe most widely used open-source browser automation toolkit.
- Selenium GridA cluster that runs Selenium tests on many browsers and machines at once.
- Selenium IDEA Selenium record-and-playback browser extension.
- Sequential Development ModelClassic phase-gate development — one stage finishes before the next starts. Waterfall and V-model are examples.
- Serverless TestingTesting Lambda-style functions where there’s no server to log into.
- Service Level Agreement (SLA)Contract that promises the customer a specific level of service.
- Service Level Indicator (SLI)A specific metric that shows how well the service is doing.
- Service Level Objective (SLO)The internal target for reliability or performance — e.g. 99.9% availability.
- Service MeshA layer under microservices that handles their talking-to-each-other.
- Service VirtualizationFake entire services (payments, third-party APIs) so tests aren't blocked by them.
- Service WorkerA script that runs behind a webpage to enable offline mode and push notifications.
- Session Management TestingTesting cookies, tokens, timeouts, and logout behaviour.
- Session-Based Test ManagementDo exploratory testing in 60-90 minute charter-driven sessions and debrief afterwards for accountability.
- Session-Based Test ManagementExploratory testing done in focused 60–120 minute blocks with a mission and notes.
- Setup and TeardownThe before-each and after-each hooks that prep and clean up around tests.
- Seven Testing PrinciplesSeven quick truths every tester should internalize — from ‘you can’t test everything’ to ‘no bugs found doesn’t mean the product is good enough’.
- SeverityHow bad the bug is technically — does it crash the app, corrupt data, or just misalign a label?
- Shadow DeploymentSending live traffic to a new version silently to test it under real load.
- ShardingSplitting a big database across many servers by some key.
- Shift EverywhereTesting early AND in production — quality everywhere in the pipeline.
- Shift-LeftTest as early as possible — reviews, unit tests, static analysis, dev-time checks.
- Shift-Left TestingStart testing — reviews, unit tests, static analysis — as early as possible, not at the end.
- Shift-Left TestingTest earlier — in design and dev, not just after code is done.
- Shift-RightKeep testing after release — with monitoring, feature flags, A/B tests and canaries.
- Shift-Right TestingKeep testing after release — observe real users, run experiments, catch issues in production safely.
- SimulatorA model that mimics part of a real system for testing.
- SimulatorAn iPhone stand-in that runs on macOS to test iOS apps without hardware.
- Single Sign-On (SSO)Log in once, use many apps.
- Site Reliability Engineering (SRE)Google-invented discipline that treats ops as a software problem.
- Smoke TestingA quick check that the build is stable enough to test — if login, home page, and basic navigation don’t crash, you go ahead with deeper testing.
- Snapshot TestingSave the current output as the truth; fail if it ever changes.
- SnowflakeA modern cloud data warehouse for analytics.
- Soak TestingRun heavy but normal load for hours or days to reveal memory leaks and slow degradation.
- SOAP API TestingTesting older XML-based web services.
- Soap Opera TestingWrite dramatic 'a day in the life' user stories that combine many features into one crazy scenario, then test it.
- SOC 2An audit report proving a SaaS company handles data safely.
- SpecFlowCucumber for .NET/C#.
- SpecificationA detailed document describing exactly what the system must do — the input to test design.
- Specification by ExampleInstead of vague requirements, the team writes real input/output examples that also run as tests.
- Specification-Based TestingDesign tests only from what the system is supposed to do (spec, story, requirement) — not from the code.
- SPIDR (Story Splitting)Five patterns for breaking big stories into small ones.
- Spike (Agile)A short, timeboxed investigation to answer a technical or design question.
- Spike TestingSlam the system with a sudden burst of traffic to see how it copes.
- Spiral ModelA repeating cycle of planning, risk analysis, engineering, and evaluation.
- SprintA short timebox in which the team delivers a working piece of the product.
- Sprint BacklogThe tasks and stories the team commits to during a sprint, owned by the Development Team.
- Sprint PlanningThe meeting at the start of a sprint where the team commits to what it will build.
- Sprint ReviewThe demo meeting where the team shows working software and gets feedback.
- SpyA stand-in that records calls made to it for later inspection.
- SQL InjectionUser input ends up as executable SQL and lets attackers read or change the database.
- SQL JOINCombining rows from two tables using a shared column.
- SSR TestingTesting that server-rendered pages match what the client shows after hydration.
- Stability TestingRun the system for a long time under normal load and watch for degradation.
- Staging EnvironmentThe last stop before production — same config, sanitized data, real integrations.
- StakeholderAnyone who has skin in the game — product owner, users, ops, compliance, marketing.
- StandardA rulebook everyone in a domain agrees to follow — can be industry, national or international.
- State DiagramA picture of all the modes the system can be in and the arrows showing how it switches between them.
- State TableA table version of a state diagram — rows are states, columns are events, cells are the next state (or 'invalid').
- State Transition DiagramA picture of states and the events that move between them.
- State Transition TestingYou model the system as states (Logged Out, Logged In, Locked) and design tests that trigger valid and invalid transitions between them.
- Statement CoverageExecuted statements ÷ total statements × 100. A basic code-coverage metric.
- Statement TestingDesign tests so every line of code runs at least once.
- Static AnalysisTools scan source code, models or documents to find defects without running the software.
- Static Analysis ToolSonarQube, ESLint, SpotBugs — analyzes code without running it and flags problems.
- Static TestingYou examine the work product — requirements, design, code — without running it, using reviews or tools like linters.
- Static Testing ToolTools that check code, requirements or models without running them — linters, review platforms, SAST scanners.
- Statistical TestingPick test inputs by sampling from a statistical model of real usage instead of choosing them by hand.
- Story MappingA wall of sticky notes that lays out user stories by user journey (top axis) and release (bottom axis).
- Story PointA relative size number the team gives a story, not hours.
- StorybookA tool for developing and testing UI components on their own.
- Stress TestingPush the system past its expected load to find the breaking point.
- Stripe TestingTesting Stripe payment flows with test cards and sandbox webhooks.
- Structural TestingAnother name for white-box testing — tests are designed from the code’s structure, not from the spec.
- Structure-Based TestingDesign tests using the code, control-flow, data-flow, or architecture — not just the spec.
- Structured LoggingLogging in JSON with named fields, not free-form text.
- StubFake code you drop in for a not-yet-built dependency so your module can be tested.
- Summative Usability EvaluationUsability testing on the near-finished product to see if it hit the design goals.
- SuperTestA Node library for writing HTTP tests against Express-style apps.
- SwaggerThe toolset that grew into OpenAPI — docs, editor, codegen.
- Syntax TestingGenerate tests from the grammar of the inputs (e.g. a BNF) — one test per production rule, plus invalid mutations.
- Synthetic DataFake but realistic data used in testing so you don't touch real PII.
- Synthetic MonitoringFake users running scripts against production 24/7 to detect issues.
- System Integration Testing (SIT)Once systems are combined, verify they talk to each other correctly.
- System TestingEnd-to-end testing of the fully integrated product against its requirements, usually in a production-like environment.
- System Under Test (SUT)Common shorthand for whatever you're testing right now.
- System Usability Scale (SUS)A quick 10-question survey turned into one usability score.
T
- Technical DebtShortcuts in code that cost you extra time later to fix or work around.
- Technical Debt QuadrantFowler's 2x2 for debt: reckless/prudent, deliberate/inadvertent — helps teams talk about which debt is OK.
- Technical ReviewPeers with technical expertise review a work product to agree it is technically sound.
- Technical User StoryA story for tech debt / infra / plumbing work — no direct business value but enables future stories.
- TerraformThe most popular tool for declaring cloud infrastructure as code.
- Test AnalysisReading requirements, user stories or code and figuring out ‘what should we test?’.
- Test AnalystThe role that turns requirements and risks into detailed test conditions and cases.
- Test ApproachHow this project actually applies the organisation’s test strategy — tailored to its risks and constraints.
- Test AutomationLetting tools do the repetitive parts of testing — usually execution, but also data generation and reporting.
- Test Automation FrameworkThe reusable structure around your automated tests: base classes, utilities, reporting, configuration.
- Test Automation PyramidBulk of tests at unit level, fewer at API level, fewest at UI — cheap, fast, stable.
- Test BasisThe source of truth you derive tests from — requirements, user stories, models, code, or standards.
- Test CaseA single, executable check with a clear setup, action, and expected outcome — the atomic unit of testing.
- Test CharterA short mission for an exploratory session — what to explore, for how long, and with what goal.
- Test CompletionThe wrap-up phase — archive assets, tear down environments, publish the summary, capture lessons learned.
- Test ConditionA ‘what to test’ statement — one idea, one risk, or one requirement — that later becomes one or more test cases.
- Test ControlReacting to what monitoring shows — adding testers, rescoping, prioritizing risks, changing the plan.
- Test CoverageHow much of a chosen coverage target (statements, branches, requirements, risks) your tests actually hit.
- Test CoverageWhat share of the target items your tests hit — code, requirements, risks, etc.
- Test DataThe concrete inputs you feed into a test — users, products, edge-case values.
- Test Data Preparation ToolSoftware that generates realistic, compliant test data (Faker, Mockaroo, GenRocket).
- Test DesignTurning ‘what to test’ into concrete, executable ‘how to test’ — with inputs, actions and expected outcomes.
- Test Design ToolTools that read a model, decision table or classification tree and generate test cases.
- Test DoubleAny stand-in object used in place of a real dependency.
- Test Effort EstimationEstimate how much time and how many people the testing will need, using metrics, expert judgment or comparison to past projects.
- Test EnvironmentThe setup where tests run — servers, browsers, DBs, feature flags — ideally close to production.
- Test Environment ManagementThe discipline of keeping test environments healthy, isolated, versioned and available on demand.
- Test Environment ProvisioningSpinning up a clean test environment on demand instead of hand-crafting one.
- Test EstimationPredicting how much time, money, and effort testing will take.
- Test ExecutionActually running the tests — manually or via automation — and recording what happened.
- Test Execution ToolSelenium, Cypress, Playwright — runs your automated scripts and reports pass/fail.
- Test FixtureThe setup and data a test needs to run reliably.
- Test HarnessThe scaffolding around the code under test — the drivers that call it and the stubs that fake its dependencies.
- Test IdeaA one-line note about a test worth running, before it becomes a formal case.
- Test ImplementationBuilding everything test execution needs — procedures, scripts, data, environments — before you press ‘run’.
- Test IndependenceThe tester is not the coder — objectivity comes from independence.
- Test IsolationEach test stands on its own — no leftover data or order dependency.
- Test ItemA specific piece of the test object you plan and track individually — e.g. one microservice inside a larger system.
- Test LeadThe senior tester who coordinates work, mentors the team, and interfaces with dev leads and PMs.
- Test LevelOne of the layers of testing: unit, integration, system, acceptance.
- Test LogThe receipt of a test run — which tests ran, when, on what build, and what they returned.
- Test Management ToolZephyr, TestRail, Xray, qTest — where test cases and results live.
- Test ManagerOwns test planning, staffing, budget and reporting for a project or release.
- Test MetricA number you track to know how testing is going — coverage %, defects found, tests passed.
- Test MonitoringKeeping an eye on how testing is going — coverage, pass rates, defects — against the plan.
- Test Monitoring and ControlWatch how testing is going against the plan and steer it back on course when it drifts.
- Test Monitoring MetricNumbers you watch during a test cycle — cases run, pass rate, defects.
- Test ObjectWhatever you are currently testing — a component, a service, an app, a document.
- Test ObservabilityRich telemetry from your test runs (timings, flake rate, root causes) so you can improve the suite over time.
- Test OracleWhatever tells you what the ‘right’ answer should be — a requirement, a spec, a previous version, or even an experienced user.
- Test Oracle ProblemThe struggle of knowing whether the test passed when the correct answer is hard to compute.
- Test PlanThe document that answers ‘what, when, how, and by whom’ for the testing effort — scope, schedule, risks, entry and exit criteria.
- Test PlanningDeciding scope, objectives, risks, resources, schedule and criteria for a testing effort.
- Test PolicyThe company-wide statement of why and how testing happens — signed off by senior management.
- Test ProcedureThe ordered ‘recipe’ for running a batch of test cases end-to-end, including setup and cleanup.
- Test ProcessThe seven ISTQB activities that together make up testing on a project.
- Test Progress MetricA number that tells you how far testing has progressed — tests run, tests passed, defects open.
- Test Progress ReportA recurring status report during testing — usually weekly or per sprint — showing burn-down and risks.
- Test PyramidLots of cheap unit tests, some integration tests, few slow UI tests.
- Test ReportThe write-up that tells stakeholders how testing went and whether the product is ready to ship.
- Test ScriptAn automated test procedure — code that a tool runs against the system.
- Test SmellA red flag in test code — like duplicate setup or unclear assertions.
- Test StrategyThe organisation-wide ‘how we test’ document — reused across projects — that project test plans reference.
- Test SuiteA grouped bundle of tests — e.g. ‘smoke suite’, ‘nightly regression suite’.
- Test Summary ReportThe final report at the end of a test level or release — what shipped, what didn’t, and why.
- Test TechniqueA named method (EP, BVA, decision table, exploratory, etc.) for coming up with test cases in a systematic way.
- Test ToolAny software that helps a tester — from JIRA to Selenium to JMeter.
- Test TrophyKent C. Dodds' variant of the pyramid that puts integration testing in the middle spotlight.
- Test TypeA category of testing — functional, non-functional, structural, change-related.
- Test-Driven DevelopmentRed-green-refactor: write a failing test, make it pass with the simplest code, then clean up.
- Test-First ProgrammingWrite the test before the code — the umbrella idea behind TDD, ATDD and BDD.
- TestabilityHow easy it is to write good tests for the software.
- TestCompleteA commercial UI automation tool from SmartBear covering web, desktop, and mobile.
- TestcontainersA library that spins up real databases/queues in Docker for your integration tests.
- Tester (Role)The individual contributor who plans, builds and runs tests day-to-day.
- Testing HoneycombMostly integration tests, few unit and E2E — the microservices distribution.
- Testing in ProductionPush code to real users behind flags, watch metrics and roll back fast if something breaks.
- Testing LibraryA library that pushes you to test the app the way a user would use it.
- Testing ToursThemed exploratory testing missions — e.g. the “money tour” visits every payment flow.
- TestNGA Java test framework with more advanced features than classic JUnit.
- TestRailA standalone commercial test case management platform.
- TestwareEverything testing creates or uses — plans, cases, scripts, data, environments, reports.
- Think TimeThe pause a real user takes between clicks — models human pacing.
- Thread DumpA snapshot of every thread in the JVM — used to find deadlocks and hangs.
- Threat ModelingSit down early and map what could go wrong and who might attack.
- Three AmigosBusiness, dev and tester talk through a story together before coding starts.
- Three-Point EstimationEstimate best-case, worst-case and most-likely, then combine: E = (O + 4M + P) / 6.
- Three-Value Boundary Value AnalysisPick three values at each boundary: the value just below, the boundary itself, and the value just above. Catches off-by-one bugs on either side.
- ThroughputHow many stories or tickets the team actually finishes each week.
- Time BehaviourHow fast the system responds and how much it processes per second.
- TimeoutA hard limit on how long an operation is allowed to run.
- TLSThe encryption that protects HTTPS connections.
- TMapA Sogeti-originated test management method used mainly in Europe.
- TMMiCMMI's testing-focused sibling — 5 levels of test process maturity.
- Toil (SRE)Boring, repetitive ops work that could and should be automated away.
- TokenizationSwapping real sensitive values for meaningless tokens that map back only in a vault.
- Tool AdoptionHow you get people actually using the tool: pilot, champions, training, integration.
- Tool SelectionStructured evaluation of test tools against needs, budget, integration, learning curve and vendor viability.
- Top-Down IntegrationIntegrate from the top downward, using stubs for anything not built yet.
- TOTPThe 6-digit rotating code from Google/Microsoft Authenticator apps.
- TPI NextA framework for grading and improving how your test team works.
- Trace ViewerA debugger that lets you scrub through a failed test like a movie.
- TraceabilityBeing able to prove which tests cover which requirement, story or risk — both ways.
- Traceability MatrixA grid that shows which test case covers which requirement.
- Transaction (DB)A group of database operations that all succeed or all fail together.
- Transactions Per Second (TPS)How many transactions the system handles each second.
- Tricentis ToscaA commercial model-based enterprise test automation tool.
- Trunk-Based DevelopmentEveryone commits to main every day; long-lived branches are avoided.
- Twelve-Factor AppA checklist of 12 principles for building cloud-native SaaS apps.
- Two-Value Boundary Value AnalysisPick exactly two values at each boundary: the boundary itself and the one just past it. Cheaper coverage than the three-value variant.
U
- UFT (Micro Focus)The classic enterprise GUI automation tool — formerly QTP.
- Unit Test Framework ToolJUnit, pytest, NUnit — lets developers run and assert on unit tests.
- Unit TestingSame as component testing: developers verify one small piece of code at a time with fast, automated tests.
- Upgrade TestingTesting that upgrading from v1 to v2 doesn’t break anything or lose data.
- UsabilityHow easy and pleasant the software is to use for its intended users.
- Usability MetricNumeric measures of how easy or effective a product is to use.
- Usability TestingWatch real users try the product to see if the UI actually works for them.
- Use CaseA step-by-step story of how a user gets something done with the system, including alternate and error paths.
- Use Case PointsSizing effort by counting weighted use cases and actors.
- Use Case TestingTake a real user journey — like ‘checkout with a coupon’ — and turn each main and alternative flow into a test case.
- User Acceptance Testing (UAT)Real users try the software and decide if it’s good enough to ship.
- User Acceptance Testing (UAT)The final round of testing done by real users before launch.
- User StoryA short, user-focused description of a feature the team will build in one sprint.
- UX TestingBroader than usability testing — includes emotion, satisfaction, and journey.
V
- V-ModelEach dev phase (requirements, design, code) has a matching test level (acceptance, system, component) drawn as a V.
- Valid PartitionA group of good inputs the system is supposed to accept — the happy-path partition.
- ValidationAre we building the right product? — checking that the system actually meets user needs and intended use.
- VelocityHow many story points the team typically finishes per sprint.
- VerificationAre we building the product right? — checking that the work product matches its specification.
- Version ControlGit, SVN — the tool that lets many people edit the same code without losing changes.
- Visual Regression TestingPixel-diff the UI against a saved baseline and flag anything that changed.
- Visual TestingCompare screenshots against baselines to catch UI regressions that functional tests miss.
- VitestA Vite-native, Jest-compatible test runner — faster in modern JS setups.
- Volume TestingLoad the system with huge datasets to see how it handles them.
- VPCA private, isolated network inside a public cloud.
- VulnerabilityA flaw that attackers can use to break in or cause damage.
- Vulnerability ScanningScan hosts, containers, dependencies against known CVE databases and misconfigurations.
W
- WalkthroughThe author walks the team through the document while others ask questions and spot defects.
- Waterfall ModelRequirements → design → build → test → release, in a straight line with limited backtracking.
- WCAGThe W3C standard for accessibility — three levels A, AA, AAA.
- WCAG A / AA / AAAThe three WCAG conformance tiers — most laws require AA.
- Web Application Firewall (WAF)A firewall specifically for web app traffic that blocks known attack patterns.
- WebAuthnThe browser standard behind passkeys and hardware-key logins.
- WebDriverThe standard protocol tools use to drive real browsers.
- Webhook TestingTesting outbound event notifications your system sends to third parties.
- White-Box TestingYou design tests using knowledge of the code — branches, statements, paths — to hit specific structural coverage targets.
- Whole-Team ApproachQuality is everyone's job — testers, devs, PO, ops all own it together.
- Wideband DelphiExperts estimate anonymously in rounds, discuss the outliers, and repeat until they converge.
- WireMockA tool to fake HTTP APIs so tests don’t hit real backends.
- Work Breakdown Structure (WBS) EstimationBreak the work into tiny tasks, estimate each, add them up.
- Work-in-Progress (WIP) LimitThe rule that says ‘no more than N items in this column’, forcing focus.
- Workload ModelA description of the mix of transactions, users, and think times used in a load test.
- WSJF (Weighted Shortest Job First)Do the shortest, most valuable work first.
X
Z
Test your glossary knowledge in a real exam simulator
40 CTFL v4.0 questions · 60-minute timer · instant scoring and chapter-wise breakdown.
Start Free ISTQB Mock Test