How to Write Test Cases: Format, Examples & Free Template

Knowing how to write test cases well is the foundation of every QA career. Good test cases find real bugs, are easy for anyone on the team to run, and become the base for automation later. In this guide you will learn what a test case is, the standard format used in Indian IT companies, test design techniques, real examples for a login page and a payment flow, and a free template you can copy.

Test case writing is asked in almost every fresher interview — often as a live exercise such as “write test cases for a pen” or “for a login page”. Pair this guide with our manual testing interview questions for complete preparation.

What is a test case?

A test case is a documented set of preconditions, steps, test data and expected results used to verify one specific behaviour of an application. A test scenario is a high-level idea of what to test (“verify login functionality”); test cases are the detailed checks under it (“verify login fails with a wrong password”).

Standard test case format

How to write test cases: step-by-step process

1. Understand the requirement. Read the user story and acceptance criteria. List questions and clarify them with the product owner before writing.
2. Identify scenarios. Break the feature into positive flows, negative flows, boundaries, error handling, UI, and integrations.
3. Apply test design techniques (below) to choose the right inputs without testing every possible value.
4. Write each case for one behaviour. One clear objective per test case makes failures easy to understand.
5. Make expected results measurable. “Error message ‘Invalid email or password’ is displayed below the form” — not “error should come”.
6. Prioritise. Mark business-critical flows as High so they run first in smoke and regression cycles.
7. Review. Get peer or developer review, then map cases to requirements in a traceability matrix.

Test design techniques you must know

Equivalence partitioning

Divide inputs into groups that should behave the same, then test one value from each group. For an age field accepting 18–60: one valid value (30), one below (10) and one above (70).

Boundary value analysis

Bugs cluster at edges. For the same 18–60 field, test 17, 18, 19 and 59, 60, 61. For a password of 8–16 characters, test lengths 7, 8, 16 and 17.

Decision table testing

Useful when results depend on combinations of conditions — for example, a discount that applies only if the user is a member and the cart value is above ₹1,000. List every combination of conditions with its expected action.

State transition testing

For features that move through states — an order going from Placed → Packed → Shipped → Delivered, or an account locked after three failed logins — test each valid transition and attempts at invalid ones.

Error guessing

Use experience to try likely problem inputs: empty fields, spaces only, very long text, special characters, emojis, copy-pasted values, double-clicking submit, or using the browser back button after payment.

Example: test cases for a login page

Example: one detailed test case for UPI payment

• ID: TC_PAY_004
• Title: Order is not confirmed when UPI payment fails
• Preconditions: Logged-in user with one item in cart; test payment gateway in sandbox mode
• Steps: 1) Go to checkout 2) Choose UPI 3) Enter the sandbox failure UPI ID 4) Approve payment
• Expected: “Payment failed” message with a Retry option; order status remains “Payment pending”; no confirmation email or SMS sent; cart items retained
• Priority: High  |  Type: Negative

Best practices for writing test cases

• Write for a new team member: someone unfamiliar with the feature should be able to execute it without asking questions.
• Keep steps short and start each with a verb — “Enter”, “Click”, “Verify”.
• Avoid dependencies between test cases wherever possible.
• Cover negative and boundary cases, not just the happy path — that is where most bugs hide.
• Keep test data separate and reusable; never use real customer data.
• Update cases when requirements change; outdated test cases are worse than none.
• Write with automation in mind: stable, deterministic steps and clear expected results are easy to convert into scripts later.

Free test case template you can copy

Create a spreadsheet with these columns in this order and you have a template used by many Indian QA teams: TC ID | Module | Title | Story ID | Preconditions | Steps | Test Data | Expected Result | Actual Result | Status | Priority | Type | Executed By | Date | Bug ID. Freeze the header row, add data validation drop-downs for Status, Priority and Type, and use one sheet per module. If you are learning how to write test cases for interviews, fill this template for two or three apps — it doubles as a portfolio sample you can share with recruiters.

Tip: add a “Bug ID” column so every failed case links directly to its defect in Jira. During regression, filter by Priority = High to build your smoke suite in seconds.

Tools for managing test cases

Freshers often start with Excel or Google Sheets. Most companies use a test management tool: Jira with plugins such as Xray or Zephyr, TestRail, qTest or Azure Test Plans. These link test cases to stories and bugs and produce execution reports. Learn the basics in our Jira for testers guide. For standard definitions of terms like “test condition” and “test case”, the ISTQB Glossary is a reliable reference.

Common mistakes

• Vague expected results such as “should work properly”.
• Combining many checks into one huge test case.
• Copying the requirement as the test case without thinking about edge cases.
• Missing preconditions or test data, so nobody can reproduce the result.

FAQs

How many test cases should I write for a feature?

There is no fixed number. Write enough to cover every acceptance criterion with positive, negative and boundary checks, and stop when new cases no longer add meaningful coverage.

What is the difference between a test case and a test scenario?

A scenario is a one-line description of what to test; a test case gives the exact steps, data and expected result to test it.

Should test cases be written in Excel?

Excel is fine for practice and small projects. Professional teams usually prefer test management tools for traceability and reporting.

How do I practise writing test cases as a fresher?

Pick everyday apps — login forms, a food-ordering checkout, a bus-ticket search — and write 15–20 cases for each using the techniques above. Share them in your portfolio and resume, as shown in our QA resume for freshers guide.

Conclusion

Once you know how to write test cases using a clear format, design techniques and measurable expected results, you will stand out in interviews and on the job. Practise on real apps every day, keep your best samples in a portfolio, and explore today’s QA jobs to start applying.