Writing Test Cases and Test Plans

Writing Test Cases and Test Plans

From Requirement to Test Case

A test case is a single, precise check of one behavior. Good test cases are written before they are automated, and they follow a consistent structure: the precondition (starting state), the action (what the tester does), the expected result (what should happen), and the actual result (what did happen).

The Parts of a Test Case

• Test ID: a stable identifier such as LOGIN-001.
• Title: one line stating the behavior, for example login succeeds with valid credentials.
• Preconditions: the setup needed, such as a registered user and a fresh session.
• Steps: numbered, concrete actions the tester performs.
• Expected result: the observable outcome, written before running anything.

Covering More Than the Happy Path

Novice testers test only the success case. Professional test cases deliberately include:

• Boundary values: exactly at the minimum and maximum accepted input.
• Invalid values: wrong types, empty strings, negative numbers.
• Missing data: what happens when an optional value is absent.
• Unauthorized use: what the system does without proper permissions.

Test ID: CART-007
Title: Adding an item already in the cart increases its quantity
Precondition: user exists and the cart contains 1 copy of item X
Steps:   1) add item X to the cart
         2) open the cart
Expected: quantity for item X equals 2

The Test Plan Document

A test plan is the higher-level strategy. It describes scope (what is tested and what is skipped), the test approach (which test levels and tools), roles and responsibilities, the environment, and the schedule. It also defines exit criteria - the conditions the project must meet before testing is considered complete.

A Practical Rhythm

Start writing test cases while requirements are being finalized, because writing them exposes vague requirements immediately. Keep cases granular enough to fail alone, and review them with a second person; a test case nobody can understand will not be run faithfully.

Key Points

• A test case has preconditions, steps, and an expected result.
• Cover boundaries, invalid input, missing data, and unauthorized access.
• The test plan defines scope, approach, environment, and exit criteria.
• Writing cases early exposes unclear requirements.
• Cases must be precise enough to fail on their own.