Test Case Template, Examples & Format (Free Download)

This guide includes prewritten templates for software test cases, actual examples, and document samples that can be downloaded to suit your QA tasks.

Every day, I get several requests for a Test Case Template. I’m surprised to see that many testers still document test cases with Word docs or Excel files. But I’m sure that as the volume of your tests goes on increasing, you will find it extremely difficult to manage. No matter whether you are a beginner QA professional or a seasoned software tester.

The templates that I have provided in the following section are going to help you write better test cases, increase your test coverage, minimize your errors, and overall optimize your QA process.

If you are not using any test case management tool, then I would strongly recommend, based on my 20 years of testing experience, that you use an open-source tool to manage and execute your test cases. 

What is a Test Case? (Beginner Clarity Section)

Test Case consists of several variables, preconditions, and actions that are used to test whether a particular function or a set of functions performs correctly. It could be compared to an experiment in science where we know what we have, what we do, and what we expect.

In case the actual outcome does not coincide with the expected one, the test case fails.

Test Case vs. Test Scenario

These phrases are typically considered synonyms; however, in a professional QA process, they denote varying degrees of detail.

• Test Scenario: The broad categorization of what should be tested. It is normally described by a single line (for example, “Test the Login Functionality”).
• Test Case: The fine-grained information related to that test scenario. There may be tens of test cases for each scenario (such as “Test login using valid credentials,” “Test login with an expired password,” etc.).

Why Test Cases Matter in QA?

Test cases are an essential part of an advanced Software Testing Life Cycle (STLC). Test cases include:

1. Consistency: Test cases make sure that regardless of who runs the test (even an AI bot), he does it in the same manner, without any personal bias.
2. Regression Testing: Whenever additional code gets introduced into the system, previous test cases make sure that nothing has been damaged by the new code.
3. Compliance: For regulated sectors like Fintech or Healthcare, documented test cases act as the proof that the application was thoroughly tested.
4. Training and Reference: They become the “manual” of your application. A newly hired Quality Assurance Engineer could look through your test cases and get acquainted with complex logic of the app.

Test Case Template & Examples: The Ultimate Guide for QA Teams

Test case templates and practical test cases serve an important role in creating an efficient testing process within QA. Rather than having to rely on imprecise or ambiguous documentation, testers can follow structured approaches that guarantee the accurate testing of all product features.

Test case formats may vary from one organization to another. However, using a standard test case format for writing test cases is one step closer to setting up a testing process for your project.

It also minimizes Ad-hoc testing that is done without proper test case documentation. But even if you use standard templates, you need to set up test case writing, review & approve, test execution, and most importantly, the test report preparation process, etc., by using manual methods.

---

Here is how to make the manual test case management process a bit easier with the help of simple testing templates.

Standard Fields for a Sample Test Case Template

There are certain standard fields that need to be considered while preparing a Test case template.

Several standard fields for a sample Test Case template are listed below.

Test case ID: Unique ID is required for each test case. Follow some conventions to indicate the types of the test. For Example, ‘TC_UI_1’ indicates ‘user interface test case #1’.

Test priority (Low/Medium/High): This is very useful during test execution. Test priorities for business rules and functional test cases can be medium or higher, whereas minor user interface cases can be of a low priority. Testing priorities should always be set by the reviewer.

Module Name: Mention the name of the main module or the sub-module.

Test Designed By Name of the Tester.

Test Designed Date: Date when it was written.

Test Executed By Name of the Tester who executed this test. To be filled only after test execution.

Test Execution Date: Date when the test was executed.

Test Title/Name: Test case title. For example, verify the login page with a valid username and password.

Test Summary/Description: Describe the test objective in brief.

Pre-conditions: Any prerequisite that must be fulfilled before the execution of this test case. List all the preconditions to execute this test case successfully.

Dependencies: Mention any dependencies on other test cases or test requirements.

Test Steps: List all the test execution steps in detail. Write test steps in the order in which they should be executed. Make sure to provide as many details as you can.

Test Data: Use test data as an input for this test case. You can provide different data sets with exact values to be used as an input.

Expected Result:  What should be the system output after test execution? Describe the expected result in detail, including the message/error that should be displayed on the screen.

Post-condition: What should be the state of the system after executing this test case?

Actual result: The actual test result should be filled after test execution. Describe the system behavior after test execution.

Status (Pass/Fail): If the actual result is not as per the expected result, then mark this test as failed. Otherwise, update it as passed.

Notes/Comments/Questions: If there are any special conditions to support the above fields that can’t be described above, or if there are any questions related to expected or actual results, then mention them here.

Add the following fields if necessary:

Defect ID/Link: If the test status fails, then include the link to the defect log or mention the defect number.

Test Type/Keywords: This field can classify tests based on test types. For Example, functional, usability, business rules, etc.

Requirements: Requirements for which this test case is being written. Preferably the precise section number in the requirements document.

Attachments/References: This field is useful for complex test scenarios in order to explain the test steps or expected results using a Visio diagram as a reference. Provide a link or location to the actual path of the diagram or document.

Automation? (Yes/No): Whether this test case is automated or not. It is useful to track automation status when test cases are automated.

With the help of the above fields, I’ve prepared an example test case template for your reference.

Format #1: Download Test Case Template with Example

– Test case DOC file template and
– Test case Excel file template

Also, here you can refer to a few more articles on writing effective test cases. Use these test writing guidelines and the above template to write and manage the test cases effectively on your project.

Format #2: Download Test Case Template with Example

Undoubtedly, the test cases will differ depending on the functionality of the software for which it is intended. However, given below is a template that you can always use to document the test cases without bothering about what your application is doing.

Sample Test Cases

Based on the above template, below is an example that showcases the concept in a much more understandable way.

Let’s assume that you are testing the login functionality of any web application, say Facebook.

Below are the Test Cases for the same:

=> Download the above Test case format with example data

Sample Test Cases (Ready-to-Use)

 180+ Sample Test Cases for Web and Desktop Applications

Test Case Example for Manual Testing

Below is an example of a live project that demonstrates how all the above-listed tips and tricks are implemented.

[Note: Click on any image for an enlarged view]

---

Test Case Examples (Real-World)

To get away from theoretical discussion, let us consider the way QA professionals design the documentation for scenarios for some basic functionalities of websites. Below are test case examples for two different types of scenarios, “Happy Path,” and “Edge Case.”

Login Page Test Case Example

The login page is the entry point into your application. It should be tested for its security and functionality.

Test Case ID	Test Scenario	Steps	Expected Result
TC_L_01	Valid Login	Enter valid email/pass, click Login.	Dashboard page should load.
TC_L_02	Invalid Password	Enter valid email + wrong password.	Error: "Invalid credentials" appears.
TC_L_03	Masked Password	Type into the password field.	Characters should be dots or asterisks.
TC_L_04	Account Lockout	Enter wrong password 5 times.	Account should temporarily lock for security.

E-commerce Checkout Test Cases

The checkout flow is complicated due to the need for managing inventory, sessions, and pricing.

• TC_CH_01: Verify that “Add to Cart” shows the right number of items in the header.
• TC_CH_02: Verify that the removal of an item from the cart causes the immediate recalculating of the total price.
• TC_CH_03: Verify that users cannot checkout when their shopping cart is empty.
• TC_CH_04: Verify that the checkout procedure works for guests who have no account.

Payment Gateway Test Cases

This is the most critical part of an e-commerce site. Reliability and security are the top priorities here.

Feature	Test Case Scenario	Expected Result
Credit Card	Submit expired card details.	Transaction declined with "Card Expired" error.
CVV Security	Enter 2 digits instead of 3 for CVV.	Field should show validation error.
Currency	Verify total matches the selected currency.	Conversion rate is applied correctly.
Interrupt	Close browser during "Processing."	Transaction should fail or hold; no double charge.

Form Validation Test Cases

Validation checks guarantee that the data inserted in your database are clean and in proper format. This is where bugs will usually be located when manually tested.

• Mandatory Fields: Insert no value in the required field such as “Email” and try to submit the form. The field will then become highlighted in red.
• Character Limits: Type more than 50 characters on a “First Name” field which is limited to 50 characters. There should be character truncation.
• Data Format: Insert a wrong format, such as “test.com,” which is missing the “@.” You will get an error message stating “Enter valid email address.”
• Numeric Fields: Input alphabetic characters in a “Phone Number” or “Zip Code” field.

---

How to Write Test Cases (Step-by-Step)

Creating a test case is both an art and a science. It calls for profound knowledge of the application and thoroughness in writing documents. Below are four important principles for creating quality test cases.

Step 1: Understand Requirements

Before you even start writing test cases, you have to comprehend what the application should do. Use such documents as the Business Requirement Document (BRD) or Software Requirement Specification (SRS).

• The Target: Specify “Success Criteria” for the feature.
• Traceability: Relate each test case to the corresponding requirement through RTM (Requirements Traceability Matrix). It will ensure 100% coverage by tests and prove to the stakeholders that all features were tested.

Step 2: Define Test Data

Input data quality determines test case success. Identify the type of inputs needed to run your test cases.

• Valid Input Data: Regular inputs that will normally work (for example, a regular 10 digit telephone number input).
• Invalid Input Data: Inputs intended to “crash” the system (for example, entering symbols for a field designated for a name input).
• Boundary Input Data: Testing the boundaries of an input (for example, testing exactly 8 digits of password if it ranges from 8 to 16 digits).

Step 3: Write Clear Steps

Execution steps need to be unambiguous enough that even a first-time user without prior experience using the software is able to understand them.

• Be Precise: Replace “Access the website” with “Go to [https://example.com](https://example.com)” 
• Stay Atomic: Ensure that each individual step is a single action only.
• No Ambiguity: Use verbs like Click, Enter, Select, and Verify.
• Bad Step: “Login into the application.” Good Step: “Enter admin@test.com in the email address field and Pass123 in the password field and then click Sign In button.”

Step 4: Define Expected Results

This is where success criteria for the test case come in. The success criteria define precisely what “success” means in this situation. Otherwise, the tester will not be able to determine whether they have discovered a defect or a feature.

• Be Specific: The statement “System should work” is not enough; instead say, “User will be redirected to the Dashboard screen and a welcome message will pop up.”
• State What Is No Longer There: If something gets deleted, then this state needs to be reflected in the success criteria.

---

Common Mistakes in Test Case Writing

Even seasoned QA engineers make mistakes related to documentation, which cause the discovery of bugs to fail and result in “flaky” testing sessions. In case your team often asks you questions regarding your bug reports, you probably commit any of these crucial mistakes.

Too Generic Steps (The “Guesswork” Trap)

The biggest mistake people make is that they believe their knowledge equals the tester’s knowledge. For instance, “Log in and open the profile” is not a step by step guide.

• The Risk: Different testers perform different tests, leading to inconsistent results.
• The Fix: Provide precise instructions. Specify what buttons should be clicked and what navigation options should be used.
  • Instead of: “Open the settings.”
  • Use: “Click on the ‘Gear’ icon in the top-right corner of the Dashboard.”

Missing Edge Cases (The “Happy Path” Bias)

Testers usually create test cases to verify the proper working of the application (Positive Testing) and totally neglect the scenario of incorrect information (Negative Testing).

• What’s the risk? 80% of critical data integrity/security defects reside in the edge cases.
• How to solve it? Use methods like Boundary Value Analysis and Equivalence Partitioning.
• Check for: Blank fields, special characters, maximum file sizes, and quick double clicks on submission buttons.
• No Expected Result Clarity: A test scenario lacking an explicit “Expected Result” is nothing but a sequence of steps; it is not a test at all. Never use a general statement such as “The system must operate properly.”
• The Risk: The tester may spot an error message and regard it as a “functionality” since there was no mention of how the user interface would react to a particular issue in the documentation.
• The Fix: Specify exactly what UI change, message, or data alteration is expected..
  • Example: ” “The system should present the following validation error in red color: ‘Invalid email format.’ The submit button will be disabled.”

---

Recommended Test Case Writing Tool

Before continuing with the Test case writing process, we recommend downloading this test case management tool. This will ease your test plan and test case writing process, as mentioned in this tutorial.

1) Testiny

Testiny – a new, straightforward test management tool. It is a fast-growing web application built on the latest technologies and aims to make manual testing and QA management as seamless as possible.

Its design is extremely intuitive, making writing and maintaining test cases easy, and it helps testers perform tests without adding bulky overhead to the testing process.

Don’t just take our word for it; take a look at Testiny yourself.

Testiny is perfect for small to mid-sized QA teams looking to integrate manual and automated testing into their development process.

Features:

• User-Friendly Interface: Intuitive and simple out of the box
• Flexible Test Case Creation: Write test cases using a rich-text editor, copy & paste screenshots, drag & drop to move items
• Customizable Templates: Choose between different test case templates; add your own custom fields to fit them to your needs
• Structured Test Organization: Organize tests in a tree structure for better maintenance; easily search and filter for tests
• Test Planning and Execution: Manage test cases in test plans and test runs
• Tool Integrations: Powerful integrations (e.g. Jira, GitLab, Azure DevOps) for linking requirements and defects
• Real-Time Collaboration: Instant updates for all browser sessions to stay in sync.
• Live Activity Tracking: Immediately see if a colleague made changes, completed a test, etc.
• Enterprise-Grade Security & Access: Powerful REST API, SSO, audit logs.
• Free for open-source projects and small teams with up to 3 people.

---

Frequently Asked Questions

Conclusion

Personally, I prefer to use a Test Case Management tool. You can start with an open-source tool. It will be a good addition to your efforts to set up the testing process, and meanwhile, it will also save a lot of time instead of manually maintaining these documents.

We have also seen test case templates and a few examples using very good quality documentation. I hope this article was helpful to you.

Research Process:

Total Time taken for research and publishing this guide: 40 Hours (approx).

This guide is based on real testing practices used by QA professionals. We reviewed commonly used test case templates, examined how teams document test cases in day-to-day projects, and created examples that reflect practical testing scenarios. The templates were refined to ensure they’re easy to use, adaptable, and suitable for both manual and tool-based testing workflows.

We would be glad to know your thoughts, comments/suggestions about this article.

For more Test Case Templates-related guides, you can explore our range of tutorials below:

• Test Plan Template with Format and Contents
• Test Execution Report Template
• Ready To Use Free And Paid Standard Testing Templates
• ERP Test Plan and Test Cases with Template and Example
• Premium Software Testing Templates

PREV Tutorial | NEXT Tutorial