How to Write Test Cases

A test case is a documented set of steps, test data, and expected results used to verify a specific behavior or requirement of a software application.

A well-written test case should be clear, precise, reproducible, independent, and unambiguous. Any competent tester should be able to execute the test case and understand what to verify without needing additional explanation from the person who created it.

The main purpose of a test case is to make testing consistent and repeatable.

Basic Structure of a Test Case

A test case commonly contains the following information:

1. Test Case ID

A unique identifier used to identify and track the test case.

Example: TC-LOGIN-001

2. Test Case Title

A short description of what is being tested.

Example:
Verify login with valid credentials

3. Preconditions

Conditions that must be satisfied before the test begins.

Example:

• User has a registered account.

• User is on the login page.

4. Test Data

The specific data required to execute the test.

Example:

• Username: user@example.com

• Password: ValidPassword123

5. Test Steps

The actions the tester needs to perform.

Example:

1. Open the login page.

2. Enter a registered email address.

3. Enter the correct password.

4. Click the Login button.

6. Expected Result

The behavior that should occur if the application is working correctly.

Example:
The user should be successfully logged in and redirected to the dashboard.

7. Actual Result

The behavior that actually occurred during test execution.

This is normally recorded after executing the test case.

Example:
The user was redirected to the dashboard.

8. Status

The result of the test execution.

Common statuses include:

• Pass – Actual result matches the expected result.

• Fail – Actual result does not match the expected result.

• Blocked – The test cannot be executed because of a blocking condition.

• Not Executed – The test has not yet been executed.

Example Test Case

Test Case ID: TC-LOGIN-001

Title: Verify login with valid credentials

Preconditions:

• User has a registered account.

• Login page is accessible.

Test Data:

• Email: user@example.com

• Password: ValidPassword123

Steps:

1. Open the login page.

2. Enter the registered email address.

3. Enter the correct password.

4. Click Login.

Expected Result:
The user should be successfully logged in and redirected to the dashboard.

Actual Result:
The user was redirected to the dashboard.

Status:
Pass

Characteristics of a Good Test Case

1. Clear

The test case should be easy to understand.

Avoid vague instructions such as:

"Enter the information and check the result."

Instead, specify exactly what information should be entered and what should be checked.

2. Precise

Each step should describe a specific action.

Instead of:

"Check login."

Use:

"Enter a registered email address and the correct password, then click Login."

3. Reproducible

Another tester should be able to follow the same steps and obtain the same expected behavior under the same conditions.

4. Independent

A test case should ideally not depend unnecessarily on another test case.

For example, if a test requires a logged-in user, clearly define the login condition as a precondition or setup rather than assuming another test case was executed first.

5. Unambiguous

The expected result should have only one clear interpretation.

Avoid:

"The page should work correctly."

Prefer:

"The user should be redirected to the dashboard, and the user's name should be displayed in the profile section."

Positive and Negative Test Cases

A good test suite should consider both expected and unexpected inputs.

Positive Test Case

Tests the application using valid or expected conditions.

Example:

• Enter a valid email and valid password.

• Expected result: User is successfully logged in.

Negative Test Case

Tests how the application handles invalid or unexpected conditions.

Example:

• Enter a valid email and incorrect password.

• Expected result: An appropriate error message is displayed and the user is not logged in.

Boundary and Edge Cases

Test cases should also consider values at or near important limits.

For example, if a username allows 5 to 20 characters, consider testing:

• 4 characters → Invalid

• 5 characters → Valid

• 6 characters → Valid

• 20 characters → Valid

• 21 characters → Invalid

This helps identify problems around validation boundaries.

Common Mistakes When Writing Test Cases

Avoid:

• Writing vague test steps.

• Combining too many actions into one step.

• Missing required test data.

• Writing unclear expected results.

• Assuming the tester already knows the feature.

• Creating duplicate test cases unnecessarily.

• Depending on another test case without documenting the dependency.

• Describing the expected result based on assumptions rather than requirements.

• Making test cases unnecessarily long or complicated.