How to Write Test Cases for Beginners: A Practical Walkthrough

Test cases are how the rest of engineering measures your craft. Get them right and your reputation grows quietly with every release. Get them wrong and nobody trusts your work, even when the bugs are real.

What a test case actually is

A test case is a documented, repeatable procedure that validates a specific piece of behavior in a system. It is not a checklist. It is not a wishlist. It is a recipe a stranger could follow and reach the same conclusion you reached.

The structure that has worked for fifty years

Frameworks change. Tools change. The fields a good test case needs have not changed in half a century. They are:

• Test case ID. A unique identifier. TC_LOGIN_001, TC_CART_014, whatever scheme your team uses. It needs to be searchable.
• Title. Short, specific, action-oriented. “Verify login fails with invalid password” is good. “Login test” is not.
• Module or feature. What part of the product this case belongs to.
• Preconditions. What must be true before this test can run. User must be logged out. Cart must be empty. Test data must exist.
• Test steps. Numbered, plain language, one action per step.
• Test data. Specific values, not “valid email” but “test@example.com” or “any email matching the pattern in section 3.2 of the requirements”.
• Expected result. What the system should do after the steps complete.
• Actual result. Filled in at execution time.
• Status. Pass, fail, blocked, skip.
• Severity if failed. A separate field that captures how bad the failure is.
• Tester and execution date. Who ran it and when.

A complete example: login feature

Here is a real test case at the level of detail a hiring manager would want to see.

ID: TC_LOGIN_003

Title: Verify login fails with valid email and incorrect password

Module: Authentication

Preconditions: User account exists with email registered@example.com. User is currently logged out. Browser is at the login page URL.

Steps:

1. Enter “registered@example.com” in the Email field
2. Enter “WrongPassword!23” in the Password field
3. Click the “Sign In” button

Expected result: An error message reading “Invalid email or password” appears below the form. The user remains on the login page. The Email field retains its value. The Password field is cleared. No authentication token is set in the browser.

Notice the precision. We do not just say “login fails”. We specify exactly what the user should see and what should happen behind the scenes. That precision is what separates a useful test case from a vague one.

Positive, negative, and edge cases

Every feature deserves cases in three categories.

Positive cases. What does the happy path look like. The user does what they are supposed to do, and the system does what it is supposed to do.

Negative cases. What happens when the user does the wrong thing. Wrong password. Empty field. Invalid format.

Edge cases. The boundaries. Maximum field length plus one. The exact moment a session expires. Special characters that broke a different feature six months ago.

For the login example, you should have at least 15 to 20 cases covering all three categories. If you have only three or four, you are not done.

Equivalence partitioning and boundary value analysis

Two techniques you will hear in interviews. They sound formal. They are simple.

Equivalence partitioning. Group inputs into classes that should behave the same way. For an age field that accepts 18 to 65, you have three classes: under 18 (invalid), 18 to 65 (valid), over 65 (invalid). Test one value from each class. You do not need 50 cases for one field.

Boundary value analysis. The bugs hide at the edges. For the same age field, test 17, 18, 19, 64, 65, 66. The boundary cases catch off-by-one errors that the middle cases will not.

Common beginner mistakes

The patterns I see most in junior testers are easy to fix once you know to look for them.

• Steps that combine multiple actions (“Enter email and password and click submit”) instead of separating them
• Vague expected results (“login should work”) instead of specific outcomes
• Missing preconditions, so the test cannot be run from scratch by another tester
• Test data that is dependent on previous test runs, making cases non-repeatable
• Overly long titles that read like sentences instead of summaries
• One giant case that should be five smaller ones

How many test cases is enough

The honest answer is: enough to cover the requirements, the edge cases, and the failure modes that matter. For a single login form, expect 20 to 30 cases. For a checkout flow, 50 to 100. For a complex dashboard, 100 plus. If your case count looks light, you are missing scenarios.

Where test cases live

Most teams use a test management tool: TestRail, Zephyr, qTest, or Xray for JIRA users. Knowing one of these is helpful but not mandatory. Many teams still use Google Sheets or Excel for early-stage projects. The format matters more than the platform. If you can write a clean case in a spreadsheet, you can write one in any tool.

The interview test

If you are preparing for QA interviews, here is the question you will get in some form. “Walk me through how you would test a login page.” This is not a trick question. It is a structure question. The answer should sound like:

“I would identify the requirements. I would map out positive, negative, and edge cases. I would prioritize by user impact. I would write the cases in a clear format with preconditions, steps, and expected results. Let me show you what that would look like.” Then walk through five or six cases out loud. The interviewer is not testing your memory. They are testing your structure.

Practice writing test cases until the structure becomes muscle memory. Once it is automatic, you will never freeze in an interview again.

Written by

Anveet Singh Chhabda

QA engineer and software testing educator. Manual testing, Playwright automation, and API testing taught from real-world product experience.