Software Testing Glossary: 100+ Terms

This software testing glossary is a practical dictionary of 100+ software testing terms and definitions for beginners, career changers, and anyone prepping interviews. QA conversations move fast: STLC, flake, shift-left, boundary value, contract test, severity. If the vocabulary is fuzzy, the work feels harder than it is. Use this page as a reference, not a script to memorize word-for-word. For each term, try to attach one example from an app you know.

For deeper dives after a definition, continue with the software testing life cycle, how to write test cases, smoke vs sanity vs regression testing, and manual testing interview questions. Practice applying terms on real scenarios in QABattle.

How to Use This Software Testing Glossary

1. Skim section headings and mark gaps.
2. Read a cluster (for example defect terms) in one sitting.
3. Write your own one-line example under five terms per day.
4. Explain three terms aloud without looking.
5. Revisit weekly until interview language feels natural.

Terms are grouped by theme. Some words have contested definitions in the industry; where that happens, the entry notes common usage.

A. Core Ideas

Actual result
What the system did during a test, observed and recorded by the tester.

Assertion
An automated check that a condition is true, for example an element is visible or a status code equals 201.

Baseline
A reference version of behavior, data, or performance used for comparison in later tests.

Bug / Defect / Issue
A problem where the product behaves in a way that could negatively affect a stakeholder relative to expectations, requirements, or reasonable use. Teams use the words interchangeably; process fields may distinguish types.

Debugging
The developer activity of finding and fixing the root cause of a defect. Testing finds and reports; debugging repairs. Testers may help isolate causes without owning production code fixes.

Expected result
The observable outcome that should happen if the product is correct for the case being run.

Failure
A deviation of actual behavior from expected behavior during execution. A defect in code may cause a failure when exercised.

False negative (testing)
A run that reports pass (or misses a bug) when a problem exists. Dangerous because it creates false confidence.

False positive (testing)
A run that reports fail when the product is actually acceptable, often due to brittle tests, bad data, or environment noise.

Quality
Value to some person under some conditions. In practice, teams operationalize quality as reliability, usefulness, security, performance, and maintainability tradeoffs.

Quality assurance (QA)
Activities and processes aimed at building confidence that quality goals will be met, including prevention and process improvement, not only end-stage detection.

Quality control (QC)
Product-oriented checks that detect defects in deliverables. Testing is a major QC activity. Everyday speech often blurs QA and QC.

Regression
When a change causes previously working behavior to break, or the practice of testing to detect such breaks.

Requirement
A statement of needed product behavior or constraint. May be formal specs, user stories, acceptance criteria, or implied standards.

Risk
The possibility of a negative outcome and its impact. Risk-based testing focuses effort where failure would hurt most.

Software testing
Empirical, technical investigation of a product to provide information about quality and risk, usually by operating the system under controlled conditions.

Test
An activity or artifact that exercises the product to learn whether expectations hold.

Test basis
The sources used to derive tests: requirements, designs, risks, standards, user feedback, or the product itself.

Test objective
The reason a test exists: verify a rule, expose a risk, confirm a fix, measure performance, and so on.

Traceability
The ability to link requirements, risks, tests, and defects so coverage and impact analysis stay visible.

B. Lifecycle and Process

Acceptance criteria
Conditions a story or feature must satisfy to be accepted by product stakeholders.

Agile testing
Testing integrated continuously into iterative delivery rather than only a final phase.

Definition of Done (DoD)
Team checklist for when work is complete, often including tests, review, and documentation.

Definition of Ready (DoR)
Checklist for whether a backlog item is clear enough to start, including testability.

Entry criteria
Conditions that must be true before a test phase or activity should start.

Exit criteria
Conditions that must be true before a phase is considered complete or a release is advisable from a testing view.

Release candidate (RC)
A build being evaluated as potentially shippable.

SDLC (Software Development Life Cycle)
The end-to-end process of conceiving, building, delivering, and maintaining software.

Shift-left testing
Moving testing and quality activities earlier in development to find issues sooner and cheaper.

Shift-right testing
Learning from production via monitoring, progressive delivery, synthetics, and feedback after release.

Sprint
A timeboxed iteration in Scrum-like Agile, commonly one or two weeks.

STLC (Software Testing Life Cycle)
Structured testing phases such as requirement analysis, planning, design, environment setup, execution, and closure.

Test closure
Activities at the end of a cycle: reports, archives, lessons learned, residual risk communication.

Test management
Planning, estimating, monitoring, and controlling test activities and assets.

Test plan
Document describing scope, approach, resources, and schedule for testing a release or project.

Test strategy
High-level approach to testing across a product or organization: principles, levels, types, tools, and risk stance.

UAT (User Acceptance Testing)
Validation by business users or proxies that the software meets business needs in realistic scenarios.

Waterfall
Sequential delivery model where testing often concentrates after long build phases. Still appears in regulated contexts.

C. Test Levels

Component / unit testing
Tests of small units of code in isolation, usually by developers with frameworks like JUnit, pytest, or Jest.

Integration testing
Tests of interactions between components, services, or systems.

System testing
Tests of the complete integrated system against requirements and risks.

End-to-end (E2E) testing
Tests that exercise full user or business journeys across UI and backend boundaries.

Alpha testing
Internal acceptance-like testing before external users see the product.

Beta testing
Limited external user testing before general availability.

D. Test Types (What Kind of Quality)

Functional testing
Checks what the system does against functional expectations.

Non-functional testing
Checks how the system behaves: performance, usability, security, reliability, accessibility, and similar attributes.

Smoke testing
A small set of critical checks to decide if a build is stable enough for deeper testing.

Sanity testing
Focused checks around a change area to confirm a fix or feature behaves reasonably before broader effort.

Regression testing
Re-testing existing functionality after changes to catch unintended breaks.

Retesting
Running tests again for a specific defect fix to confirm the issue is resolved.

Exploratory testing
Simultaneous learning, test design, and execution under a charter and time box.

Ad hoc testing
Informal testing without much structure or documentation. Weaker cousin of exploratory testing when unaccountable.

Positive testing
Using valid inputs and conditions to show the system works as intended for legitimate use.

Negative testing
Using invalid inputs, states, or permissions to check graceful handling and protection.

Boundary testing
Focus on edge values of ranges and limits.

Compatibility testing
Checks across browsers, devices, OS versions, or dependent systems.

Localization / internationalization testing
Checks language, locale formats, and global readiness.

Accessibility testing
Evaluates usability for people with disabilities against standards like WCAG.

Security testing
Evaluates resistance to misuse, attacks, and data exposure.

Performance testing
Evaluates speed, scalability, and stability under load conditions.

Usability testing
Evaluates how learnable and efficient the product is for real users.

Installation testing
Verifies install, upgrade, and uninstall flows.

Recovery testing
Checks behavior after crashes, restarts, or partial failures.

Compliance testing
Checks against regulatory or policy requirements.

E. Design Techniques

Black-box testing
Designing tests from external behavior without using internal code structure.

White-box testing
Designing tests with knowledge of internal code paths, structure, or logic.

Gray-box testing
Mix of external behavior focus with partial internal knowledge (APIs, logs, architecture).

Equivalence partitioning
Dividing inputs into groups expected to behave the same, then sampling from each group.

Boundary value analysis (BVA)
Choosing tests at minimum and maximum edges of partitions where defects cluster.

Decision table testing
Modeling combinations of conditions and actions in a table to derive cases.

State transition testing
Designing tests from valid and invalid transitions between system states.

Use case testing
Deriving tests from actor goals and main/alternate flows.

Pairwise testing
Combinatorial technique that covers all pairs of parameter values efficiently.

Error guessing
Experience-based technique using intuition about where the product might fail.

Checklist-based testing
Execution guided by structured lists of risks or conditions.

F. Test Artifacts

Test scenario
A high-level testing idea or journey, broader than a single detailed case.

Test case
A documented set of preconditions, inputs/steps, and expected results for a specific check.

Test suite
A collection of test cases or automated tests grouped for a purpose.

Test data
Inputs, accounts, files, and database states used during testing.

Test environment
Hardware, software, data, and configuration where tests run (local, staging, prod-like).

Test charter
A mission statement for an exploratory session: scope, goals, risks, time box.

Bug report / defect report
Document describing a problem with steps, expected vs actual, evidence, and impact.

Test summary report
Communication of what was tested, results, residual risks, and recommendations.

Requirement traceability matrix (RTM)
Grid linking requirements to tests (and sometimes defects).

Mock / stub / fake
Controlled stand-ins for dependencies so tests can run without full real systems. Nuances differ by team vocabulary.

G. Defect Management Terms

Severity
Impact of the defect on the system or user capability.

Priority
Business urgency of fixing the defect.

Severity vs priority
Not the same axis; high severity is not automatically high priority and vice versa.

Blocked
A test or task cannot proceed due to a dependency or defect.

Root cause
Underlying reason a defect was introduced or escaped.

Workaround
Temporary way users or testers avoid a defect's impact.

Duplicate defect
Report that describes an already known issue.

Cannot reproduce (CNR)
Status when the team cannot make the failure happen again with given info.

Deferred
Acknowledged defect postponed to a later release by decision.

Escaped defect
Bug found in production (or later phase) that earlier testing missed.

Bug life cycle
States a defect moves through: new, assigned, fixed, verified, closed, reopened, and variations.

Hotfix
Urgent fix released outside the normal cadence for a serious issue.

H. Automation Terms

Test automation
Using software to execute checks, compare results, and report outcomes with reduced human execution effort.

Automated test script
Code that performs a test and asserts expectations.

Framework
Reusable structure, libraries, conventions, and utilities supporting many tests.

Page Object Model (POM)
Pattern that encapsulates page structure and interactions to reduce duplication and brittle selectors.

Locator / selector
Strategy to find UI elements (CSS, role, text, XPath, test IDs).

Flaky test
A test that fails intermittently without product changes, eroding trust.

Explicit wait
Waiting for a condition before continuing in UI automation.

Headless browser
Browser mode without visible UI, common in CI.

CI (Continuous Integration)
Frequently merging code and running automated checks on each change.

CD (Continuous Delivery/Deployment)
Practices for releasing software reliably and frequently; deployment may be automated to production.

Test pyramid
Heuristic favoring more fast low-level tests and fewer slow broad UI tests.

Code coverage
Metric of code exercised by tests. Useful signal, not a complete quality score.

Snapshot / screenshot testing
Comparing UI images or DOM snapshots to baselines (can be brittle if misused).

Record and playback
Generating tests by recording actions. Fine for learning; often weak for long-term maintenance.

Data-driven testing
Running the same test logic across many input sets.

Keyword-driven testing
Tests expressed with reusable action keywords, sometimes in tables.

Self-healing locators
Tool features that try alternate ways to find elements when locators break. Helpful cautiously; can hide product issues.

I. API and Integration Terms

API (Application Programming Interface)
Contract for software components to communicate, often HTTP JSON in web systems.

Endpoint
A specific URL + method combination exposing an API operation.

Status code
HTTP response code such as 200, 201, 400, 401, 403, 404, 500 indicating outcome class.

Payload / request body
Data sent in a request.

Schema validation
Checking response structure against an expected schema.

Contract testing
Verifying that service providers and consumers agree on interface expectations (for example Pact).

Mock server
Simulated API for testing clients when the real service is unavailable or costly.

Idempotency
Property where repeating the same request does not cause unintended additional effects (important for retries).

Authentication
Proving identity (who you are).

Authorization
Enforcing permissions (what you may do).

Token
Credential artifact such as JWT or opaque session token used after login.

Rate limiting
Restricting how many requests a client can make in a period.

J. Performance Terms

Latency
Time to process a request, often measured as response time.

Throughput
Work completed per unit time, for example requests per second.

Load testing
Testing under expected concurrent usage.

Stress testing
Pushing beyond expected limits to find breaking points and recovery behavior.

Soak / endurance testing
Sustained load over long periods to find leaks and degradation.

Spike testing
Sudden sharp increases in load.

Bottleneck
Resource or component that limits overall performance.

Baseline performance
Reference measurements used to detect regressions.

Percentile (p95, p99)
Statistical way to express that 95% or 99% of requests were faster than a value; better than averages alone.

K. Security Terms (Tester-Facing)

Vulnerability
Weakness that could be exploited to violate security goals.

OWASP Top 10
Widely referenced list of common web application security risks.

XSS (Cross-Site Scripting)
Injecting script into pages viewed by others.

SQL injection
Inserting hostile SQL through inputs to manipulate databases.

CSRF
Tricking a logged-in browser into unwanted actions on another site.

IDOR
Insecure direct object reference; accessing others' objects by changing IDs.

Privilege escalation
Gaining higher permissions than intended.

Session fixation / hijacking
Attacks against session handling.

Penetration testing
Authorized simulated attack to find exploitable weaknesses, often by specialists.

Security regression
Re-checking that fixed security issues stay fixed.

L. Roles and Career Terms

QA engineer
Professional focused on product quality through testing, process, and often automation.

SDET
Software Development Engineer in Test: stronger software engineering emphasis on test infrastructure and tools.

Test lead / QA lead
Person coordinating test strategy, people, and release readiness for a team or project.

Manual tester
Role emphasis on human-designed and human-executed evaluation (usually still technical).

Automation engineer
Role emphasis on designing and maintaining automated checks and pipelines.

Build verification tester
Person or role focused on smoke and candidate validation (title varies).

M. Collaboration and Reporting Terms

Triage
Reviewing new defects or alerts to assign severity, priority, and ownership.

War room
Focused cross-functional response during major incidents.

Residual risk
Risk remaining after testing and mitigation; should be explicit at release time.

Go/No-go
Release decision meeting or moment informed by quality evidence.

RCA (Root Cause Analysis)
Structured investigation into why a serious issue happened and how to prevent recurrence.

Postmortem / incident review
Blameless learning process after production failures.

Stakeholder
Anyone with interest in product outcomes: users, PMs, support, compliance, revenue owners.

Quick Comparison Tables

Smoke vs Sanity vs Regression

Term	Main question	Size
Smoke	Is the build testable?	Very small critical set
Sanity	Does this change area look okay?	Small focused set
Regression	Did old behavior break?	Broader, risk-based set

Severity vs Priority Examples

Scenario	Severity	Priority
Checkout crash for all users	High	High
Rare typo on about page	Low	Low
Wrong festival banner day-of campaign	Low/Med	High
Data corruption in obscure export	High	Medium/High depending on users

Test Case vs Test Scenario

	Scenario	Case
Detail	Broad	Specific
Example	User resets password	Reset with expired link shows error X
Count	Fewer	Many per scenario

Interview Study Clusters

Use these clusters when preparing:

1. Lifecycle: SDLC, STLC, Agile testing, entry/exit criteria
2. Artifacts: plan, strategy, case, scenario, bug report
3. Types: smoke, sanity, regression, retesting, UAT
4. Techniques: BVA, EP, decision tables, exploratory
5. Defects: severity, priority, life cycle, escaped defect
6. Automation: flake, pyramid, CI, POM
7. API/security/performance: status codes, auth vs authZ, load vs stress, XSS

For each cluster, write one story: "In my project/demo, I used X when Y."

Common Mistakes When Learning Testing Vocabulary

Mistake 1: Memorizing Without Examples

Interviewers detect empty definitions instantly.

Mistake 2: Treating All Terms as Universal Law

Companies redefine words. Ask how they use "QA" or "sanity."

Mistake 3: Confusing Retesting and Regression

Retesting checks a fix. Regression checks for collateral damage more broadly.

Mistake 4: Equating Code Coverage with Quality

Coverage can be high while assertions are weak.

Mistake 5: Calling Random Clicking "Exploratory"

Exploratory testing is skilled and accountable, not aimless.

Mistake 6: Mixing Severity and Priority

Learn the axes separately with examples.

Mistake 7: Overusing Buzzwords on Resumes

If you list contract testing, be ready to explain it simply.

How to Build a Personal Living Glossary

1. Create a note file with terms you actually hear at work or in courses.
2. Add your product-specific meaning beside the industry meaning.
3. Include a link to an internal doc or a public deep guide.
4. Review before interviews and performance conversations.
5. Teach a junior five terms; teaching exposes gaps.

This software testing glossary is a starting map. Your living glossary becomes company-fluent over time.

Practice Exercise (30 Minutes)

Pick a login feature and write which terms apply:

• Two positive and two negative test cases
• One boundary idea for password length
• One exploratory charter
• One possible high severity defect example
• One smoke check vs one regression check
• One API check idea
• One note on authn vs authz if roles exist

You just used more than a dozen glossary terms in context. That is the point.

Final Notes

Language shapes how teams argue about risk. When someone says "we need more regression" or "that is only cosmetic severity," shared definitions prevent wasted debate. Keep this software testing glossary bookmarked, but invest most energy in applying terms on real products. Definitions open the door. Judgment walks through it.

When you are ready to convert vocabulary into skill, practice structured challenges on QABattle battles and write artifacts using the words precisely: cases, bugs, risks, and residual notes your future teammates will trust.