Software Testing - How to write test cases

Writing good test cases is about being clear, specific, and testable so that anyone (not just you) can execute them and verify results without confusion.

Here’s a step-by-step approach:


1. Understand the Requirements

  • Read the SRS (Software Requirements Specification), user stories, or acceptance criteria.

  • Identify what needs testing (features, inputs, flows).

  • Clarify any unclear points before writing.


2. Use a Standard Test Case Structure

A simple and widely used format is:

Field Description
Test Case ID Unique identifier (e.g., TC_LOGIN_001).
Title Short, descriptive name of the test.
Description What the test is verifying.
Preconditions Setup or conditions needed before running the test.
Test Steps Step-by-step actions to perform.
Test Data Specific inputs required.
Expected Result What should happen if the system works correctly.
Actual Result Filled in after execution.
Status Pass/Fail/Blocked (filled after execution).
Remarks Notes about the test.

3. Writing Guidelines

  • Be clear and concise — avoid vague words like “check” or “verify” without detail.

  • One purpose per test case — don’t mix unrelated verifications.

  • Use consistent naming — easy to search/filter later.

  • Make them independent — one test case shouldn’t depend on another.

  • Cover positive and negative scenarios — test valid and invalid inputs.


4. Example Test Case

Test Case ID: TC_LOGIN_001
Title: Login with valid credentials
Description: Verify user can log in successfully with correct username and password.
Preconditions: User account exists and is active.
Test Steps:

  1. Navigate to the login page.

  2. Enter a valid username.

  3. Enter the correct password.

  4. Click on the “Login” button.
    Test Data:

  • Username: [email protected]

  • Password: Password123
    Expected Result: User is redirected to the dashboard page and sees a welcome message.
    Actual Result: (To be filled after execution)
    Status: (Pass/Fail)
    Remarks: (Optional notes)


5. Common Mistakes to Avoid

  • Writing overly generic steps like “Login to the system” without saying how.

  • Not specifying expected results in measurable terms.

  • Combining multiple flows into one test case.

  • Forgetting edge cases (empty inputs, invalid formats, max/min values).