Software Testing Terms Every Beginner Should Know 2026

Glossary · Software Testing · 2026

Software Testing Terms Every Beginner Should Know

MK Meera Kapoor · Lead Trainer, QA & Automation | Updated 12 September 2026 | 14 min read Free · Glossary

Quick summary — the testing vocabulary you actually need

Software testing has its own vocabulary, and beginners who don't learn it struggle in interviews and on the job — even when they understand the concepts. The terms fall into four buckets: test design (test case, test plan, test scenario, positive/negative testing), defects (defect, severity vs priority, defect lifecycle, root cause), testing types (unit, integration, system, UAT, smoke, sanity, regression), and process (SDLC, STLC, entry/exit criteria, traceability). You do not need to memorise every term — you need to understand enough to follow a conversation, ask a good question, and know which term you are unsure about. This guide covers the vocabulary you will hear in your first month on any QA team, in plain English, with examples.

In this guide you will learn:

Test design terms — test case, test plan, scenario, and how they differ.
Defect terms — defect vs bug, severity vs priority, defect lifecycle.
Testing types — unit, integration, system, UAT, smoke, sanity, regression.
Process terms — SDLC, STLC, entry/exit criteria, traceability.
Terms that beginners confuse — with the difference explained.

SECTION 01Test design terms

These are the terms you use when you plan what to test. They are the foundation of every QA conversation.

Term	What It Means	Example
Test case	A specific check — steps, preconditions, expected result	"Login with valid email and password → redirected to dashboard"
Test scenario	A high-level thing to test — one line	"Test login"
Test plan	The document describing scope, approach, resources, schedule	"Sprint 14 test plan for checkout"
Test suite	A group of related test cases	"Login test suite"
Positive testing	Testing the happy path — valid inputs	Valid login succeeds
Negative testing	Testing invalid inputs and error cases	Empty password shows error
Test data	The inputs you use to run tests	A specific email and password
Boundary value	Testing at the edges of valid ranges	Password of 7, 8, 9 characters when min is 8
Equivalence partition	Testing one value from each valid/invalid group	Age 5, 25, 100 for a 0–120 field

# A written test case — the deliverable every QA produces.
# This format is used in spreadsheets, Jira, TestRail, and Zephyr.

Test Case ID:      TC_LOGIN_001
Title:             Login with valid credentials
Priority:          High
Severity:          Critical
Type:              Positive

Preconditions:
  - User exists with email priya@example.com
  - Password is Test@1234
  - Browser: Chrome 120, Firefox 121

Test Steps:
  1. Navigate to https://app.example.com/login
  2. Enter "priya@example.com" in Email field
  3. Enter "Test@1234" in Password field
  4. Click "Sign In" button

Expected Result:
  - User is redirected to /dashboard
  - Header shows "Welcome, Priya"
  - Session cookie is set (expires in 24 hours)

Actual Result:      [Fill in after execution]
Status:             Pass / Fail
Tested By:          [Your name]
Date:               [Date]

---

TC_LOGIN_002
Title:             Login with invalid password
Type:              Negative
Expected Result:   Inline error: "Incorrect email or password."
                   User remains on /login page.

---

TC_LOGIN_003
Title:             Login with empty fields
Type:              Negative
Expected Result:   Client-side validation blocks submission.
                   Email field shows: "Email is required."

# What this shows:
# - Test cases are specific enough for anyone to execute
# - Every test has a clear expected result
# - Positive and negative cases are separate test cases
# - The ID makes the test traceable to a requirement

# A defect report — the most-used document in QA.
# Every defect you write should follow this pattern.

Defect ID:         BUG-2026-0142
Title:             Discount field accepts negative values
Reporter:          Meera K.
Reported On:       2026-09-12
Environment:       Chrome 120, Windows 11, Staging build 4.2.7

Severity:          High
Priority:          P1

Steps to Reproduce:
  1. Log in as a customer
  2. Add any product to the cart
  3. Proceed to checkout
  4. In the "Discount code" field, enter "-500"
  5. Click "Apply"

Actual Result:
  - Discount is applied as -₹500
  - Order total increases by ₹500
  - No validation error shown

Expected Result:
  - Discount code field rejects negative values
  - Error message: "Invalid discount code"
  - Order total remains unchanged

Attachments:
  - screenshot_checkout_negative_discount.png
  - console_log.txt

Additional Notes:
  - Reproduces on Chrome 120 and Firefox 121
  - Does not reproduce on mobile Safari
  - Likely a missing validation in the discount service

# Why this format matters:
# - Developers need steps, not vague descriptions
# - Severity and priority drive the fix order
# - Screenshots and logs speed up debugging
# - Poor reports get ignored; good ones get fixed

# Boundary value and equivalence partitioning — the two
# test design techniques every QA interview asks about.

# ── The scenario ──
# A password field must be 8–20 characters.

# ── Equivalence partitioning ──
# Divide inputs into groups that should behave the same.
# Test one value from each group.

#   Invalid group 1: length < 8       → test with "Abc123" (6 chars)
#   Valid group:     length 8–20      → test with "Abcd1234" (8 chars)
#   Invalid group 2: length > 20      → test with "A" * 25 (25 chars)

# Three tests cover the whole range — not every possible input.

# ── Boundary value analysis ──
# Bugs usually hide at the edges. Test exactly at the boundary.

#   Length = 7   (just below min)     → should fail
#   Length = 8   (exactly min)        → should pass
#   Length = 9   (just above min)     → should pass
#   Length = 19  (just below max)     → should pass
#   Length = 20  (exactly max)        → should pass
#   Length = 21  (just above max)     → should fail

# Six tests catch the boundary bugs that a single "valid input"
# test would miss.

# ── Why interviewers love this ──
# "How would you test a password field that must be 8–20 chars?"
#
# Weak answer:
#   "I would try some passwords."
#
# Strong answer:
#   "I would use equivalence partitioning to test one value
#    from each valid/invalid group, then boundary value analysis
#    at 7, 8, 9, 19, 20, 21. That is nine tests total, and they
#    cover the range without testing every length."
#
# The technique is more valuable than the number of tests.

testing-terms-examples

Key insight: The three artefacts above — a test case, a defect report, and a boundary analysis — are the three most-tested skills in entry-level QA interviews. If you can write all three clearly, you can interview confidently this week.

SECTION 02Defect terms

These are the terms you use when something goes wrong. They are often confused — especially severity vs priority, which is the most-asked QA interview question.

Term	What It Means	Example
Defect	A flaw in the software that causes incorrect behaviour	Discount applied as negative value
Bug	Informally used as a synonym for defect	Same as above
Error	A human mistake that produces a defect	Developer forgets to validate input
Failure	The visible incorrect behaviour caused by a defect	Order total increases instead of decreasing
Severity	How bad the defect is technically	Critical, High, Medium, Low
Priority	How urgently it should be fixed	P1, P2, P3, P4
Defect lifecycle	The states a defect passes through	New → Assigned → Open → Fixed → Retest → Closed
Root cause	The actual reason the defect exists	Missing validation in the discount service
Reproducibility	Whether the defect can be triggered consistently	"Always" or "intermittent, ~10% of attempts"

Key insight: Severity vs priority is the most confusing pair in QA. A crash on a rarely-used admin page has high severity (it is a crash) but low priority (only one internal user hits it). A typo in the company name on the homepage has low severity (a spelling mistake) but high priority (it's the first thing every user sees). This is the exact example to use in an interview.

SECTION 03Testing types

These are the terms you use when someone asks "what kind of testing do you do?" — and the answer depends on what you are testing and when.

Type	What It Tests	Who Runs It
Unit testing	A single function or class in isolation	Developers
Integration testing	How two or more modules work together	Developers + QA
System testing	The entire application, end to end	QA
UAT (User Acceptance Testing)	Whether the product meets business needs	Business users / clients
Smoke testing	Whether the build is stable enough to test further	QA (first test after deploy)
Sanity testing	Whether a specific fix works, without a full regression	QA (after a bug fix)
Regression testing	Whether new changes broke existing features	QA (every release)
Exploratory testing	Free-form investigation without pre-written scripts	QA (experienced testers)
Performance testing	Speed, throughput, and stability under load	QA + DevOps
Security testing	Vulnerabilities and access controls	Security QA

Key insight: Smoke vs sanity is another classic confusion. Smoke testing is broad but shallow — "does the app load without catching fire?" Sanity testing is narrow but deeper — "does the specific fix actually work?" Smoke decides whether to test at all; sanity decides whether to release a fix.

SECTION 04Process terms

These are the terms you use when someone asks about the QA process — how testing fits into the development lifecycle.

Term	What It Means
SDLC	Software Development Life Cycle — the phases from idea to release
STLC	Software Testing Life Cycle — the phases of testing within SDLC
Entry criteria	What must be true before testing can begin (build ready, test data ready)
Exit criteria	What must be true before testing can end (all tests pass, no open P1s)
Traceability matrix	A mapping from requirements → test cases → defects
Test coverage	The percentage of requirements or code that has been tested
UAT sign-off	Formal approval from business users that the product meets requirements
Release criteria	The bar that must be met before the product can ship

Key insight: Entry and exit criteria are the most useful process terms for a beginner. They tell you clearly when testing starts and when it stops — and they stop the classic QA problem of "the build arrived broken, and now we are blamed for being late."

SECTION 05Terms that beginners confuse

These are the pairs that are routinely mixed up — even by people who have been in QA for a year. Knowing the difference puts you ahead of most candidates.

Pair	The Difference
Test case vs test scenario	Scenario is high-level ("test login"); test case has steps and expected results.
Severity vs priority	Severity = technical impact; priority = urgency of fixing.
Smoke vs sanity	Smoke is broad and shallow; sanity is narrow and deep.
Defect vs failure	Defect = the flaw in code; failure = the visible wrong behaviour.
Unit vs integration	Unit tests one component alone; integration tests two or more together.
Regression vs retest	Retest confirms a specific fix; regression checks nothing else broke.
Verification vs validation	Verification = "did we build it right?"; validation = "did we build the right thing?"
Quality assurance vs quality control	QA is process-oriented (prevent defects); QC is product-oriented (find defects).

Pro tip: If you can clearly explain three of these pairs in an interview, you already sound more credible than most candidates. Pick the ones you find most useful in real work — I recommend severity vs priority, smoke vs sanity, and regression vs retest — and be ready to give an example of each.

SECTION 06How to actually remember these

The problem with glossaries is that you read them once and forget them. Here is how to make them stick.

Approach	Why It Works
Use them in a real project	Writing a test case teaches you more than reading ten definitions
Attach each term to an example	"Severity = crash; priority = typo in the company name"
Test yourself out loud	Explain the term to someone — it reveals what you do not actually know
Notice them in interviews	When an interviewer says a term you know, your confidence grows
Keep a running glossary	A one-page doc of terms you have learned in your first month

Pro tip: Do not try to learn the whole glossary in one sitting. Learn five terms today, use them on a small project this week, and add five more next week. The vocabulary is not the hard part of QA — using it correctly in a real conversation is.

SECTION 07Interview Q&A

Q1What is the difference between a test case and a test scenario?

A test scenario is a one-line description of what needs to be tested — like "test login". A test case is the detailed version: preconditions, steps, expected results, and status. Test scenarios are the map; test cases are the turn-by-turn directions. Every test case maps back to a scenario, and every scenario should be traceable to a requirement.

Q2What is the difference between severity and priority?

Severity is the technical impact — how bad the defect is. Priority is the urgency of fixing it. They are not always aligned. A crash on a rarely-used admin page has high severity but low priority. A typo in the company name on the homepage has low severity but high priority. The classic interview answer requires giving an example of each.

Q3What is the difference between smoke testing and sanity testing?

Smoke testing is broad but shallow — it checks whether the build is stable enough to test. It runs after every deploy and covers major functionality in a shallow way. Sanity testing is narrow but deeper — it checks whether a specific fix works, usually after a bug fix or a small change. Smoke decides whether to test; sanity decides whether to release.

Q4What is regression testing?

Regression testing checks whether new changes broke existing features. It runs before every release, and it is the reason test suites grow over time. The goal is not to test new functionality — that is already covered by new tests — but to make sure that the features that worked yesterday still work today. Most QA teams automate regression so it runs in CI on every pull request.

Q5What are entry and exit criteria?

Entry criteria are what must be true before testing can begin — build available, test data ready, environments set up. Exit criteria are what must be true before testing can end — all planned tests executed, no open P1 defects, UAT sign-off received. They exist to stop testing from being an open-ended process and to protect QA from being blamed for late builds. Every test plan should define both.

SECTION 08Test yourself — software testing terms

Five questions. No sign-up.

0 / 5

Pick an answer to see why it is right or wrong.

SECTION 09Frequently asked questions

What is the most important software testing term to learn first?

Test case and severity vs priority. A test case is the artefact you produce every day — if you cannot write a clear one, you cannot test. Severity vs priority is the most-asked interview question, and it reveals whether you understand the tradeoffs in real QA work. Both are essential starting points.

Do I need to know all the testing types to get hired?

No. You need to know the ones that appear in the job description — typically manual testing, regression, smoke, sanity, and UAT for entry-level roles. Automation types (unit, integration) matter when you move into automation. Do not try to memorise every type; focus on the ones that map to the role you are applying for.

What is the difference between QA and testing?

QA is process-oriented — it is about preventing defects through good processes, standards, and reviews. Testing is product-oriented — it is the activity of executing tests to find defects. QA is broader and includes testing. Confusing the two is common, but knowing the difference is a strong signal in interviews.

How long does it take to learn the testing vocabulary?

The core terms — test case, defect, severity, priority, smoke, sanity, regression, UAT — can be learned in a week. Using them correctly on a real project takes a month. The vocabulary itself is not the hard part of QA; the hard part is applying it to real software under real constraints.

What is the difference between verification and validation?

Verification is "did we build it right?" — checking that the software matches the spec, usually through reviews and static analysis. Validation is "did we build the right thing?" — checking that the software meets the user's actual needs, usually through testing. Verification is about the requirements; validation is about the user.

What I would do in the first 30 daysLayoff · 14 min Why sending 500 resumes won't workJob Search · 14 min Rebuild your resume for the AI job marketResume · 15 min Which skills to learn before applyingSkills · 14 min 90-day career recovery roadmapRecovery · 16 min How AI can help you prepare for interviewsAI · 11 min

Classroom & online · Noida

Master QA vocabulary — with Uncodemy

Our Software Testing Training Course covers test design, defect reporting, testing types, and real project work — with mentor reviews and mock interviews. Built for beginners who want to be hired as QA testers, not just to learn vocabulary.

₹28,000 · full programme ~~₹40,000~~

Explore the course Download the syllabus

Test design + defect reporting
Testing types + process
Manual + automation QA
Weekday & weekend batches