Essential Testing Terminology — A Practical Glossary for QA Engineers

Walk into any QA standup and you will hear terms like “regression,” “smoke test,” “severity vs priority” and “test harness.” If you do not know the vocabulary, you cannot follow the conversation — and you certainly cannot contribute to it. This lesson is your practical glossary: the terms every QA engineer must know from day one, explained with context so you understand not just what they mean, but when and why they are used.

Core QA Vocabulary — From Test Case to Test Suite

Understanding testing terminology is not about memorising definitions for an exam. These terms are the shared language of QA teams worldwide. Using them correctly helps you write clear bug reports, understand test plans and communicate effectively with developers, product managers and other stakeholders.

# Modelling key testing concepts in code

class Defect:
    """A flaw in the software that may cause a failure."""
    def __init__(self, title, severity, priority, status="Open"):
        self.title    = title
        self.severity = severity   # Impact: Critical, Major, Minor, Trivial
        self.priority = priority   # Fix urgency: P1 (highest) to P4 (lowest)
        self.status   = status

class TestCase:
    """A single test with preconditions, steps and expected result."""
    def __init__(self, tc_id, title, preconditions, steps, expected):
        self.tc_id         = tc_id
        self.title         = title
        self.preconditions = preconditions
        self.steps         = steps
        self.expected      = expected
        self.actual        = None
        self.status        = "Not Run"

    def execute(self, actual_result):
        self.actual = actual_result
        self.status = "Pass" if actual_result == self.expected else "Fail"
        return self.status

# Example usage
tc = TestCase(
    tc_id="TC-001",
    title="Login with valid credentials",
    preconditions="User account exists with known password",
    steps=["Navigate to /login", "Enter username", "Enter password", "Click Submit"],
    expected="Dashboard page loads with welcome message"
)

result = tc.execute("Dashboard page loads with welcome message")
print(f"{tc.tc_id}: {tc.title} → {result}")
# Output: TC-001: Login with valid credentials → Pass
Note: Severity and priority are two different dimensions of a defect. Severity measures the technical impact (how badly the software is broken), while priority measures the business urgency (how soon it must be fixed). A cosmetic typo on the CEO’s bio page might be low severity but high priority; a crash in an obscure admin panel might be high severity but low priority. Understanding this distinction prevents miscommunication with product owners and development leads.
Tip: When writing bug reports, always include these fields: title, steps to reproduce, expected result, actual result, severity, environment and screenshots or logs. A well-structured bug report is the single fastest way to earn the trust of the development team, because it saves them time and reduces back-and-forth questions.
Warning: Do not confuse “error,” “defect,” “fault” and “failure” — they are related but distinct. An error is a human mistake in thinking or coding. That error produces a defect (bug) in the code. When the defective code executes, it may cause a failure (incorrect observable behaviour). This causal chain matters when you write root-cause analyses.

Common Mistakes

Mistake 1 — Confusing severity with priority

❌ Wrong: Marking a minor UI alignment issue as “Critical severity” because the product manager wants it fixed before launch.

✅ Correct: Setting severity to “Minor” (low technical impact) and priority to “P1” (high business urgency) so that both dimensions are accurately recorded.

Mistake 2 — Writing vague bug report titles

❌ Wrong: “Login doesn’t work.”

✅ Correct: “Login fails with 500 error when password contains special characters (&, <, >) on Chrome 120 / macOS Sonoma.”

🧠 Test Yourself

A crash in a rarely used admin report is classified as high severity but low priority. What does this mean?