Test Case Writing

A professional test case title must be unique, descriptive, and follow a consistent naming pattern.

Options A, B, and C are too vague and informal — they cannot be identified in a large test suite, give no indication of the test condition, and don't specify the interface under test. Option D is correct: it includes a unique identifier (TC-LOGIN-003) for traceability, the action under test (Verify that a registered user can log in), the exact condition (valid credentials), and the platform context (web interface). This format allows anyone to understand what the test covers without opening it.

Key vocabulary:
• Test case ID — a unique alphanumeric identifier used for traceability (e.g. TC-LOGIN-003)
• Test condition — the specific scenario or state being validated by the test case
• Traceability — the ability to link a test case back to a requirement or user story
• Naming convention — a standardised pattern for naming artefacts to ensure consistency across a test suite

Preconditions must be specific, verifiable, and complete enough that any tester can set up the test state independently.

Options A and D are too brief to be actionable — they identify the general idea but omit critical details like which account to use or what data must exist. Option B is better but still lacks specifics (which user? how many orders?). Option C is the most professional: it lists each precondition as a numbered, verifiable item with concrete test data (email address), authentication state, minimum data requirement, and environment verification — eliminating ambiguity for any tester picking up this case.

Key vocabulary:
• Preconditions — the state the system must be in before the test steps begin
• Test data — specific values used in a test case (email addresses, amounts, IDs)
• Session token — a credential stored in the browser that identifies an authenticated user
• Smoke-tested — confirmed to be in a stable, deployable state via a basic health-check test run

Test steps must be numbered, atomic, and include enough detail to be executed identically by any tester.

Option A uses the right structure but is too vague — "Check email" doesn't say how or where. Option B is a description, not a step sequence. Option C is incorrect — test steps are essential for repeatability and traceability. Option D is the professional standard: each step starts with an action verb, specifies where to navigate, includes exact test data (testuser@example.com), sets time constraints (within 2 min), and describes password complexity requirements — leaving nothing to interpretation.

Key vocabulary:
• Atomic step — a single, indivisible action in a test procedure (one click, one input)
• Password reset flow — the multi-step process for a user to recover access via email verification
• Complexity requirements — minimum password rules enforced by the application
• Repeatability — the ability for any tester to execute the same steps and get the same result

Expected results must be measurable, observable, and independent of subjective interpretation.

Options A and B are too vague — "results are shown" and "works correctly" cannot be objectively pass/failed. Option D introduces a subjective element ("is satisfied") that cannot be verified programmatically or consistently across testers. Option C is correct: it specifies minimum result count (≥1), the keyword under test ("invoice"), required UI elements per result (title, snippet, URL), and the expected count display format — every element can be objectively verified by any tester or automated assertion.

Key vocabulary:
• Expected result — the specific, measurable outcome the system must produce to pass the test
• Measurable — can be quantified or verified without subjective judgment
• Assertion — a programmatic check in automated tests corresponding to an expected result
• Description snippet — a short excerpt of page content shown in search result listings

Blocked and Not Run are distinct statuses — confusing them distorts sprint metrics.

Option A is wrong — Fail means the test was executed and the system produced an incorrect result. Option B is wrong — you cannot carry forward a Pass status from a previous sprint without re-execution. Option D ("Not Run") is used when a test case is simply not yet scheduled or skipped by intent, with no external impediment. Option C ("Blocked") is correct here: the feature hasn't been deployed, which is an external dependency issue — not a test failure. Using Blocked signals to the team that an action is needed to unblock progress.

Key vocabulary:
• Blocked — a test case that cannot be executed due to an unresolved dependency, environment issue, or upstream defect
• Not Run — a test case not yet executed in the current cycle with no external impediment
• Pass — the test was executed and the system met all expected results
• Fail — the test was executed and the system did not meet the expected results
• External dependency — something outside the QA team's control that affects test execution