A test case is a structured description of a specific check. Its purpose is to make the check unambiguous, reproducible, and useful to the team, rather than simply document something.
What a good case usually contains
- →A clear title expressing the check's purpose.
- →Preconditions: the required initial system state.
- →Test steps: actions performed by the tester or system.
- →Expected result: exactly what should happen.
- →Where needed, test data, priority, requirement links, and notes.
What makes a strong test case
- →It checks a specific rule or risk rather than everything at once.
- →Its expected result is measurable and unambiguous.
- →It contains enough steps for clarity without unnecessary detail.
- →A failure makes clear what went wrong.
Common mistakes
- →Writing overly long cases that cover several different ideas at once.
- →Using vague expected results such as "works correctly."
- →Failing to separate preconditions from steps.
- →Duplicating dozens of nearly identical cases where a checklist or parameterization would work better.
When a case is unnecessary
Not every check needs a separate test case. For quick smoke or sanity testing, unstable features, and exploratory sessions, detailed documentation may cost more than it contributes. Good QA chooses the format deliberately.
Worked login cases with explicit requirements
These cases use a fictional training specification, not universal login rules. Account learner@example.test is active and has a known valid password. A wrong password or unknown account shows the same message, “Invalid credentials”, without creating a session. Empty fields show field errors without sending a login request. The third consecutive wrong password for a known account locks it for 5 minutes; successful login resets the counter. A locked account cannot log in even with the correct password.
Run each case independently. Restore the stated failure counter, lock state and session before starting; otherwise the sequence of previous tests changes the expected result. Use synthetic credentials only.
ID Initial state Input / action Expected result
L01 Active, 0 failures, signed out Submit known account + correct password Session created; profile opens; counter is 0
L02 Active, 0 failures, signed out Submit known account + wrong password Invalid credentials; no session; counter is 1
L03 Unknown account, signed out Submit unknown@example.test + any password Invalid credentials; no session
L04 Signed out Submit with both fields empty Two field errors; no login request
L05 Active, 2 failures, signed out Submit known account + wrong password No session; account locked for 5 minutes
L06 Locked, before expiry, signed out Submit known account + correct password No session; lock remains in forceExpand one row into an executable manual case
Case: L02 — reject a wrong password
Preconditions: active account, failure counter 0, no session.
1. Open the login page.
2. Enter learner@example.test and a deliberately incorrect password.
3. Submit once.
Expected UI: “Invalid credentials”; profile does not open.
Expected state: no session; known-account failure counter becomes 1.
Evidence: sanitized response and state observation available in the test environment.The counter requires an agreed observation mechanism, such as a test-only administration view or authorized test fixture. If it is unavailable, mark that assertion unverified rather than inferring it from a message. Add recovery, lock expiry, concurrency and accessibility cases according to the actual product risks; the six rows are a starting set, not a complete authentication assessment.