Software Testing · Glossary for Beginners
Software Testing Glossary — Key Words Explained Simply
Quick summary — software testing, in plain English
Software testing has its own vocabulary — and it can feel like a different language on your first day. This glossary walks through the terms that actually matter: what they mean, where they fit, and how to explain them in an interview without tripping over the jargon.
In this guide you will learn:
- Fundamentals — testing, QA, QC, test case, test plan and the words you'll use every day.
- Test levels — unit, integration, system and acceptance, plus smoke, sanity and regression.
- Test techniques — black box, white box, equivalence partitioning, boundary value analysis and more.
- Defects & metrics — defect life cycle, severity vs priority, coverage and traceability.
- Agile & automation terms — TDD, BDD, CI testing, test pyramid and flaky tests.
SECTION 01Testing fundamentals — the basic vocabulary
Before you can discuss test levels or techniques, you need the building blocks straight. These are the terms you'll use every single day.
| Term | Plain-English meaning | Example |
|---|---|---|
| Software testing | The process of checking that software behaves as expected — and finding places where it doesn't | Checking that a login form rejects wrong passwords |
| Verification vs validation | Verification asks "did we build it right?"; validation asks "did we build the right thing?" | Verification = code matches spec; validation = the feature actually solves the user's problem |
| QA vs QC vs testing | QA = process-focused and prevention; QC = product-focused and detection; testing = a subset of QC | QA defines the review process; QC runs the tests; testing is the act of executing them |
| Test case | A set of steps, inputs and expected results that verifies a specific behaviour | "Enter a valid email and a 8-character password → account created" |
| Test scenario | A one-line description of what to test, without the detailed steps | "Verify login with valid credentials" |
| Test plan | The document that defines scope, approach, resources and schedule for testing | "Test login, signup and reset password for the 2.3 release" |
| Test strategy | The high-level approach an organisation uses to test software across projects | "All new features require automated regression and manual exploratory testing" |
| Test script | A detailed, often automated, sequence of steps executed by a tool | A Selenium script that fills out the login form and asserts the redirect |
SECTION 02Test levels & types
Not all tests are the same size. Test levels describe the stage where testing happens; test types describe the purpose of the test.
| Term | Plain-English meaning | Who typically runs it |
|---|---|---|
| Unit testing | Testing the smallest piece of code — usually one function or one class — in isolation | Developers |
| Integration testing | Testing how two or more components work together — e.g. your service and its database | Developers, SDETs |
| System testing | Testing the whole application end-to-end in an environment close to production | QA engineers |
| Acceptance testing | Confirming the software meets business needs — often by users or the client | Product owners, users |
| Smoke testing | A quick check that the most critical features work — "is the build even usable?" | QA, often automated |
| Sanity testing | A narrow test after a fix, checking that the fix works and nothing nearby broke | QA |
| Regression testing | Re-running tests to confirm new changes didn't break existing features | QA (usually automated) |
| Exploratory testing | Learning and testing at the same time, without pre-written scripts — following curiosity | Experienced testers |
Test levels — how a feature gets tested
1. Unit test
- Developer writes tests for a function
- Fast, isolated, run on every commit
2. Integration test
- Service talks to database / external API
- Slower, fewer tests
3. System test
- Full application in staging
- End-to-end user flows
4. Acceptance test
- Business owner / end user signs off
- "Does this solve the problem we set out to solve?"
Each level is more expensive and slower than the one below.
That's why the "test pyramid" pushes most tests to the unit level.Smoke vs Sanity vs Regression — clear examples
Smoke testing
When: every new build
Goal: is the build usable at all?
Example:
- Can I log in?
- Does the home page load?
- Does a checkout complete?
Usually automated, 15–30 minutes.
Sanity testing
When: after a specific bug fix
Goal: does the fix work, and nearby features still work?
Example:
- Bug: "password reset email not sent"
- Fix: updated SMTP config
- Sanity: reset flow works for 2–3 accounts
Narrow, manual, fast.
Regression testing
When: after changes anywhere in the system
Goal: did we break anything that used to work?
Example:
- Full login, checkout, profile, search suites
- Run automatically in CI on every pull request
Broad, automated, re-run constantly.SECTION 03Test design techniques
Test design techniques are the ways testers pick which cases to run. You can't test everything — techniques help you test the right things.
| Term | Plain-English meaning | Example |
|---|---|---|
| Black box testing | Testing without looking at the code — only inputs and outputs matter | Testing a login form without knowing how it's implemented |
| White box testing | Testing with visibility into the code — branches, paths and conditions | Writing tests to cover every if/else branch |
| Grey box testing | Testing with partial knowledge of the code — often used for integration testing | Knowing the API structure but not the internal logic |
| Equivalence partitioning | Splitting inputs into groups where behaviour should be identical — then testing one from each group | Age field: 0–17, 18–60, 61+ — test one value from each group |
| Boundary value analysis | Testing values exactly at the edges of each range — because most bugs hide there | Age limits: test 17, 18, 60, 61 |
| Decision table testing | Listing combinations of conditions and expected outcomes in a table | Discount rules: membership × coupon × payment method |
| State transition testing | Testing how a system moves between states — especially valid and invalid transitions | Order states: created → paid → shipped → delivered → cancelled |
| Pairwise testing | Testing combinations of two inputs at a time instead of every combination — practical coverage | Browser × OS × payment method — test pairwise, not all 64 combos |
Boundary value analysis — quick examples
Field: Age (valid range 18–60)
Test cases:
17 → invalid (just below)
18 → valid (lower boundary)
59 → valid (just inside upper)
60 → valid (upper boundary)
61 → invalid (just above)
Field: Password length (valid 8–20)
Test:
7 → invalid
8 → valid
19 → valid
20 → valid
21 → invalid
Why boundaries?
Most off-by-one bugs, "< vs <=" mistakes,
and validation issues appear exactly at
the boundaries — not in the middle.Decision table — discount example
Conditions
Member? Y Y N N Y Y N N
Has coupon? Y N Y N Y N Y N
Actions
Discount 20 10 15 0 20 10 15 0
Rows are combinations of conditions.
Each row must be tested once.
In practice:
- 2 conditions × 2 values = 4 rows minimum
- With 3 conditions = 8 rows
- If rules are complex, decision tables
catch combinations manual testers miss
Good for: pricing rules, permission matrices,
conditional workflows.SECTION 04Defects, severity & metrics
Finding bugs is only half the job. The other half is describing them clearly and measuring the quality of the testing itself.
| Term | Plain-English meaning | Why it matters |
|---|---|---|
| Defect / bug | A flaw in the software that causes it to behave incorrectly | Every defect should be logged with steps, expected vs actual result, and environment |
| Error vs defect vs failure | Error = human mistake; defect = flaw in code; failure = the defect showing up at runtime | Interviewers love this distinction — it shows you understand where bugs come from |
| Severity | How much damage the defect does to the system | Severity is technical — "checkout crashes" is critical |
| Priority | How urgently the business wants it fixed | Priority is business — "logo is wrong" can be high priority with low severity |
| Defect life cycle | The states a defect goes through: new → assigned → open → fixed → retest → closed (or reopened) | Knowing the states keeps the workflow clear and the bug tracker clean |
| Test coverage | How much of the code or requirements is exercised by tests | Coverage isn't a guarantee of quality — but low coverage is a warning |
| Traceability matrix | A table that maps requirements to test cases and defects | Proves every requirement was tested — and which tests cover which requirement |
| Test report | A summary at the end of a cycle: what was tested, pass/fail, defects, coverage and risks | Stakeholders read the report, not the test cases — make it readable |
A good defect report — the checklist
Title
Login fails with 500 error when password
contains a space
Environment
Chrome 126, staging, API v2.3.1
Steps to reproduce
1. Go to /login
2. Enter email: a@b.com
3. Enter password: "pass word 123"
4. Click Login
Expected result
User logs in successfully
Actual result
Page shows 500 Internal Server Error;
API log: NullPointerException in
PasswordValidator
Severity: High
Priority: High
Attachments: screenshot, API log
Reporter: QA name
Why it matters:
A developer can reproduce this in
under 2 minutes — no back-and-forth.Severity vs Priority — with examples
Severity = technical impact
Priority = business urgency
1. High severity, high priority
Checkout page crashes for all users
2. High severity, low priority
Admin-only export crashes — rarely used,
low business impact right now
3. Low severity, high priority
Company logo wrong on the homepage —
cosmetic, but CEO wants it fixed today
4. Low severity, low priority
Typo in a footer on page 7
Interview answer template:
"Severity is about impact to the system;
priority is about when the business wants
it fixed. They can differ — e.g. a crash
in a rarely used admin page has high
severity but may have lower priority than
a cosmetic issue on a launch page."SECTION 05Agile, automation & shift-left terms
Modern QA teams use a set of agile and automation terms that show up in almost every job description. Here they are, without the buzzwords.
| Term | Plain-English meaning | Where you'll see it |
|---|---|---|
| Shift left | Testing earlier in the development cycle instead of only at the end | Unit tests written alongside code; QA in sprint planning |
| TDD (test-driven development) | Write the failing test first, then write code to make it pass | Red → green → refactor cycle; used heavily by developers |
| BDD (behaviour-driven development) | Write tests in plain-language scenarios ("Given / When / Then") that everyone can read | Cucumber, SpecFlow, business-readable specs |
| ATDD (acceptance test-driven development) | Write acceptance tests from requirements before building the feature | Agile teams building to a definition of done |
| CI testing | Automated tests that run every time someone pushes code — usually in a pipeline | GitHub Actions, GitLab CI, Jenkins |
| Test pyramid | Many unit tests at the base, fewer integration tests in the middle, a small number of UI tests at the top | A guideline for how to balance a test suite |
| Flaky test | A test that sometimes passes and sometimes fails without any code change | Usually caused by timing, environment or shared state — a real source of pain |
| SDET | Software Development Engineer in Test — a tester who writes code and builds test infrastructure | Common in product companies; bridges dev and QA |
SECTION 06Interview Q&A — testing glossary
Q1What's the difference between QA, QC and testing?
QA is process-focused — it prevents defects by improving how software is built. QC is product-focused — it detects defects in the built product. Testing is a subset of QC: the act of executing tests. QA is the broadest, testing is the narrowest.
Q2Explain severity vs priority with an example.
Severity is the technical impact of a defect; priority is how urgently the business wants it fixed. A crash in a rarely used admin page has high severity but low priority. A wrong company logo on the homepage has low severity but high priority.
Q3What's the difference between smoke, sanity and regression testing?
Smoke testing checks whether a build is worth testing at all. Sanity testing checks whether a specific fix works and nothing nearby broke. Regression testing re-runs a broad suite to confirm nothing that used to work broke after new changes.
Q4What is boundary value analysis, and why is it useful?
BVA tests values exactly at the edges of valid ranges — like 17, 18, 60 and 61 for an age field that accepts 18–60. It's useful because most off-by-one and validation bugs appear exactly at the boundaries, not in the middle.
Q5What's a flaky test, and how do you fix one?
A flaky test sometimes passes and sometimes fails without any code change. Common causes: timing issues, shared test data, environment dependencies and order-of-execution bugs. Fix by removing hard waits, isolating test data and making tests deterministic.
SECTION 07Test yourself — testing glossary quiz
Five questions. No sign-up.
0 / 5Pick an answer to see why it is right or wrong.
SECTION 08Frequently asked questions
What's the difference between a test scenario and a test case?
A test scenario is a one-line description of what to test — e.g. "verify login with valid credentials". A test case adds the details: preconditions, steps, inputs and expected results. One scenario can produce many test cases.
What is a test plan, and do I really need one?
A test plan defines the scope, approach, resources and schedule for a testing effort. For small projects a light version may be enough, but for anything with multiple stakeholders, having one in writing prevents misunderstandings about what will and won't be tested.
What's the difference between black box and white box testing?
Black box testing treats the software as opaque — you only see inputs and outputs. White box testing gives you visibility into the code so you can test paths and branches. Both are useful; black box is closer to how users experience the app, white box is closer to how developers think.
What is a defect life cycle?
The set of states a defect moves through, typically: new → assigned → open → fixed → retest → closed. If the retest fails, it may go back to "reopened". Knowing the states keeps the bug tracker clean and the workflow clear.
What is the test pyramid?
A guideline that says you should have many fast unit tests at the base, a moderate number of integration tests in the middle, and a small number of slower UI/end-to-end tests at the top. It pushes most of your testing toward the cheapest, fastest layer.
SECTION 09Related reads
Classroom & online · Noida
Turn this glossary into a QA career
Our Software Testing & Automation Training Course covers manual testing, Selenium, API testing and CI — with real projects, interview prep and a portfolio that gets you hired.
₹15,500 · full programme- Manual testing fundamentals
- Selenium · API testing · CI
- Real project + interview prep
- Weekday & weekend batches