Testing 101: A QA Glossary of Common Terms
A practical introduction to common software testing and QA terms, from SDLC and test cases to selectors, smoke tests, regression, and more.
If you spend enough time around software testing, you start hearing the same terms over and over again.
Some of them are straightforward. Some are overloaded. Some sound more complicated than they really are. And if you are newer to QA, testing, or even product delivery more broadly, it can feel like everyone else already knows the language.
This post is a simple glossary of testing and QA terms that come up all the time. It is not intended to be an academic definition list. It is meant to be practical, readable, and useful.
Common Terms
| Term | Simple Meaning | Why It Matters |
|---|---|---|
| SDLC | Software Development Life Cycle. The process a team follows to plan, build, test, release, and maintain software. | Helps people understand where testing fits into delivery. |
| Test Case | A defined set of steps, conditions, and expected results used to verify behaviour. | Makes testing clearer, repeatable, and easier to review. |
| Test Suite | A grouped collection of related test cases. | Helps organise coverage into meaningful areas such as login, checkout, or regression. |
| Test Run | The actual execution of a test or a set of tests. | Turns planning into evidence by showing what passed, failed, or behaved unexpectedly. |
| Regression Testing | Checking that existing functionality still works after changes have been made. | Helps catch unintended side effects when software changes. |
| Smoke Testing | A lightweight set of checks used to confirm a build is stable enough for deeper testing. | Helps teams fail fast before spending time on broader validation. |
| Exploratory Testing | Testing guided by judgement, curiosity, and investigation rather than only by scripted steps. | Useful for finding awkward edge cases, confusing flows, and unexpected behaviour. |
| Bug / Defect | A problem where actual behaviour does not match expected behaviour. | The core thing teams are trying to identify, understand, and fix. |
| Severity | How serious the impact of a defect is. | Helps teams understand how damaging an issue is from a quality perspective. |
| Priority | How urgently something should be addressed. | Helps teams decide what to deal with first, which is not always the same as severity. |
| UAT | User Acceptance Testing. Validation by business users or stakeholders before wider release. | Confirms that the software works for the people it is actually intended for. |
| E2E | End-to-end testing. A full user journey through the system. | Useful for protecting the most important workflows across multiple layers. |
| Unit Test | A test of a small piece of logic in isolation. | Usually fast and useful for catching regressions close to the code. |
| Integration Test | A test that checks different parts of the system working together. | Important because many real issues appear at boundaries between components or services. |
| Selector | The way a test identifies a UI element, such as a role, label, test id, CSS selector, or XPath. | Strong selectors make automation more stable. Weak selectors often lead to flaky tests. |
| Assertion | The check in a test that confirms the result is what was expected. | Without an assertion, a test is not really proving anything. |
| Environment | The place where software is deployed for testing, such as local, development, staging, or production. | Different environments help teams test safely before changes reach real users. |
| CI/CD | Continuous Integration / Continuous Delivery or Deployment. The automated pipelines used to build, test, and release software. | Helps teams release more consistently and with less manual overhead. |
| Flaky Test | A test that passes and fails inconsistently without a meaningful code change. | Damages trust in the test suite and creates noise in delivery. |
“Knowing the lingo doesn't automatically make you a better tester, but it does make conversations clearer, expectations sharper, and collaboration easier.”
Final Thought
The important thing with testing terminology is not sounding impressive. It is being clear.
The more clearly a team can talk about quality, risk, defects, test coverage, and delivery confidence, the easier it becomes to work well together.
That is one reason getting comfortable with the basics matters. A shared vocabulary helps teams make better decisions.