Turn your manual testers into automation experts! Request a DemoStart testRigor Free

How to Write Test Cases? (+ Detailed Examples)

The initial yet critical phase of structuring the testing process involves writing test cases. While this may appear overwhelming to some, the benefits are too significant to ignore. These include enabling decentralized testing, securing test coverage, enhancing understanding of requirements among team members during collaboration, and, most crucially, spotting bugs in the early stages of testing. This article guides you through the advantages that test cases offer and the art of crafting them.

What is a Test Case?

Before beginning to test the application, the first step is to know what to test. This is what a test case helps with. It is a specific scenario or condition that is designed to verify the functionality, correctness, or quality of a software application or feature. It describes inputs, preconditions, expected outcomes, and postconditions for testing a particular aspect of the software. Thus, test cases act as a set of instructions or guidelines for executing tests. Writing test cases is not specific to manual or automated testing. In fact, doing so in both forms of testing can prove beneficial for your application.

Test cases are essential for:

  • Validating functionality: Ensuring software performs as expected.
  • Identifying defects: Highlighting issues for resolution.
  • Maintaining consistency: Providing a repeatable process for testing.
  • Supporting collaboration: Facilitating communication between teams by offering detailed documentation.

Test Cases in Software Testing: Key Parts

Field Description
Test case ID A unique identifier for the test case, such as a number or code, to easily reference and track it.
Test case title A concise and descriptive title that summarizes the purpose or objective of the test case.
Test case description A detailed explanation of the scenario or functionality being tested. It should provide sufficient context for the tester to understand the purpose of the test case.
Preconditions Any necessary conditions or prerequisites that must be fulfilled before executing the test case, such as specific configurations, data setup, or system states.
Test inputs The specific inputs or data values required to execute the test case. This includes providing the necessary information, parameters, or test data to drive the desired behavior.
Expected outcomes Clear and measurable expectations of the results, output, or behavior that should be observed when the test is executed correctly. This can include both functional and non-functional aspects.
Test steps A step-by-step sequence of actions or operations that need to be followed to execute the test case. This includes interacting with the software, entering data, navigating through screens or functionalities, and verifying results.
Test environment Details about the specific test environment required to execute the test case, such as software versions, hardware configurations, operating systems, browsers, or network settings.
Test data Specific test data values, including both valid and invalid inputs, boundary conditions, and edge cases, need to be tested to ensure proper functionality. Read about Test Data Generation Automation.
Postconditions Any expected conditions, states, or side effects of the system or application after executing the test case. This can include database changes, log entries, notifications, or system behavior changes.
Test dependencies Any dependencies or specific conditions that need to be met before executing the test case, such as prerequisite tests or related functionalities.
Test priority The priority level assigned to the test case, indicating its importance or urgency. This helps in prioritizing testing efforts based on criticality or business impact. Read: Severity vs. Priority.

Test Case vs. Test Scenario vs. Test Script

We saw what a test case is. Now, coming to a test scenario, it is an overview of what needs to be tested. So, one test scenario can have multiple test cases. For example, if your test scenario is to verify the login operation, you can write different test cases under it, such as ‘To verify if login is successful on entering correct credentials’, ‘To verify if login is unsuccessful on entering an incorrect password’, and so on.

Test scripts are what bring test cases to life. Essentially, it is another way to refer to test steps, i.e., what exactly needs to be done within the test case. Test scripts are more commonly seen within automation frameworks, where test cases need to be defined in a manner the system can comprehend.

Test Cases for Different Types of Testing

Understanding the different types of test cases is crucial for ensuring comprehensive test coverage:

  • Functional Test Cases: Focus on verifying the application’s functionality against the requirements. For example, test whether a login feature works correctly when valid credentials are entered. Read more: Functional Testing Types.
  • Negative Test Cases: Validate the application’s behavior when incorrect or unexpected inputs are provided. For example, attempting to log in with an incorrect password. Read about Positive and Negative Testing.
  • Boundary Test Cases: Ensure the application handles edge values of input data appropriately. As an example, testing a field that accepts values between 1 and 100 by entering 0 and 101.
  • Performance Test Cases: Assess how the system behaves under specific performance conditions, such as heavy load or stress.
  • Security Test Cases: Verify whether the application protects data and prevents unauthorized access. Read more about Security Testing.
  • Integration Test Cases: Test the interaction between different modules or components of the software. Read: Integration Testing vs End-to-End Testing.
  • Regression Test Cases: Validate that recent changes have not adversely affected existing functionality. Read: What is Regression Testing?

Why Should You Write Test Cases?

Test case writing might seem tedious, but it pays off in the long run. How? Let’s try to understand that from the below points.

  • Making the testing process systematic: Test cases help streamline the testing process by giving it a structure. It is as simple as knowing what to test and how to do it; you will be able to do it quickly and much easily.
  • Promotes brainstorming better tests: Writing test cases encourages one to think about what they are writing, which in turn encourages thinking about what is actually being tested. This calls for the tester’s creativity as well as the design of test cases that are likely to break and be put down in a written format. If done in a group setting, it helps improve the quality of the test cases.
  • Allows for easy delegation of testing activities: Since the test cases are documented in a systematic format, it is no longer necessary that the one writing the test case needs to test it. Thus, test cases can be delegated among team members and even used by developers and business analysts to test the application in their respective environments.
  • Promotes better test coverage: Since writing test cases encourages testers to brainstorm and come up with more creative test cases, one can rest assured knowing this also means that the test coverage is being improved.
  • Higher chances of detecting defects: At the base of it, we write test cases to test the application. If the quality of test cases is good involving larger test coverage, chances of unearthing bugs and glitches at an earlier stage are likely. Though some bugs might slip through, this definitely helps prevent higher costs of fixing too many issues in production.
  • Offers documentation: Test cases in a written format can act as documentation and can be used to references in the future. In fact, this documentation is a great way to share knowledge amongst testers during hand-overs or new joinee onboarding.
  • Verification of requirements: Test cases act as a checklist for verifying if the functional and non-functional requirements are being met by the developed application.
  • Aids regression testing: The documentation created for test cases can be used for regression testing. When combined with automation testing, this acts as a powerful quality control measure.
  • Easier to collaborate: For functional requirements, test cases might require inputs or review from business analysts. Likewise, you might need your development team’s assistance for non-functional requirements. Having test cases documented makes it easier to do this.

Tips to Write Test Cases

You can use these tips to help you create well-structured, comprehensive, and effective test cases that contribute to your testing endeavors.

  • Use a consistent format for writing test cases: When writing test cases, try to stick to the same format. This will ensure that your documentation is well-organized and easy for others to use and understand.
  • Understand the requirements: Before jumping into writing gain a clear understanding of the requirements and functionalities being tested. This will help you define the scope and objectives of your test cases accurately.
  • Have atomic test steps: Test steps should be clear and concise.
  • Keep the expected outcome of the test case clear: Avoid using a single test case to verify multiple outcomes. Keep your test case revolving around a single outcome and validation. It’s important to ensure that the test case is clear, unambiguous, and easily understandable by other testers or stakeholders. Well-written test cases can significantly improve the efficiency and effectiveness of the testing process.
  • Consider the type of testing that is being done: Based on the type of testing you are doing, your test case’s outlook will change. If it is a functional test case, it will focus on that functionality. If it is related to performance testing, the test cases will revolve around testing that aspect.
  • Think of positive and negative scenarios: To ensure full coverage, try to think of negative scenarios as well during writing test cases.
  • Pay attention to the test data: Clearly define the required test data and the necessary setup steps to ensure that the test environment is properly configured. You can study the production data for this and then generate your own test data.
  • Maintain traceability: Ensure traceability between test cases and requirements. This helps in validating that all requirements are covered by test cases and provides a clear link between the two.
  • Have a review process: Reviewing test cases is a good idea to ensure maximum coverage. In fact, if you can get other team members, like business analysts, involved in the process of collaboration, then the chances of identifying more unexplored grounds are higher.

How to Write Test Cases

Let us review the test case writing steps one by one:

Step 1: Understand the Requirements

  • Review project documentation such as user stories, functional specifications, and acceptance criteria.
  • Engage with stakeholders to clarify ambiguous requirements.
  • Focus on both functional and non-functional aspects of the requirements.

Step 2: Identify Test Scenarios

  • Break down high-level requirements into testable scenarios.
  • Prioritize scenarios based on the functionality’s criticality.

Step 3: Define Pre-conditions

Specify any setup or prerequisites required before the test case can be executed. Example: For a shopping cart test case, ensure the user is logged in and has items in their cart.

Step 4: Write Detailed Test Steps

  • Outline each step in a clear and sequential manner.
  • Provide specific actions and inputs. Example: “Click the Login button after entering valid credentials.”

Step 5: Specify Test Data

  • Define all necessary data for the test case, such as usernames, passwords, and input values.
  • Include boundary values and invalid data for comprehensive testing.

Step 6: Define Expected Results

  • Clearly state the expected outcome for each step.
  • Ensure the expected result aligns with the requirements.

Step 7: Review and Update

  • Have the test case reviewed by peers or stakeholders.
  • Regularly update test cases to accommodate requirement changes.

Test Case Examples

The structure of a test case, along with the required fields, will differ based on the requirements and the tool you’re using. Below are two examples:

Functional Regression Testing – Login Functionality

  • Test Case ID: TC001
  • Test Case Title: Verify Login Functionality
  • Description: This test case verifies that a user can log into the application using valid credentials.
  • Preconditions: The user must be registered and have a valid username and password.
  • Test Steps:
    1. Launch the application.
    2. Navigate to the login page.
    3. Enter the valid username and password.
    4. Click on the “Login” button.
  • Expected Result: The user is successfully logged in and is redirected to the user’s dashboard/home page.
  • Test Data: Username: Valid, User Password: Password123
  • Postcondition: The user’s dashboard/home page is displayed.
  • Test Priority: High

API Testing – Put Request

  • Test Case ID: TC002
  • Test Case Title: Verify API PUT Request
  • Description: This test case verifies that the API correctly updates a user’s information and returns the correct status and response when a PUT request is made.
  • Preconditions:
    1. The API endpoint is accessible and functioning properly.
    2. A user entity exists in the database that can be updated.
  • Test Steps:
    1. Use a GET request to the API endpoint to obtain the user’s current details.
    2. Check that the API returns a status code 200 and the correct user details.
    3. Change one or more details of the user data retrieved, such as updating the user’s email or name.
    4. Send a PUT request to the API endpoint with the updated user data in the request body.
    5. Use another GET request to retrieve the user’s details again.
  • Expected Result:
    1. The initial GET request returns the original user details.
    2. The PUT request returns a status code 200 and the updated user data in the response.
    3. The subsequent GET request returns the updated user details.
  • Test Data: API Endpoint: http://api.example.com/users/{id}
  • Postcondition:
    1. The user’s details have been updated in the database.
    2. The API server has processed the PUT and GET requests.
  • Test Priority: High

Reusing Manual Test Cases

In the testing process, using automation testing is a great idea for repetitive testing, such as regression testing after every release. The document of test cases that are written for manual testing can be reused for automation testing but with tweaks. You can use the manual test cases as a starting point for your automation test cases. In each of the automation test cases, you will need to rephrase the steps in a way that the test automation framework understands them, that is, as a test script. The expected outcomes will then be validated along the way.

These test cases that are generated for automated testing are also optimized in a way that the code can be reused across other similar test cases. They can also process a larger data set for testing within the same test case just by playing around with the parameters. The starting point for automation testing is writing test cases; without that, the framework cannot verify anything. Though test cases for manual and automated testing are not mutually exclusive, they do differ in the way they are written and for whom they are written, as one is for humans while the other is for machines.

Intelligent tools such as testRigor work on SDD (Specification Driven Development), where product specification acts as the starting point for developers, and the same specifications can be used as automation test cases. Read TDD vs.SDD vs. BDD.

testRigor to Create or Generate Test Cases

We previously said that many test automation frameworks, like Selenium, require you to write test scripts in the form of code. Test management tools, such as TestRail, allow you to maintain test cases in plain English but need to be integrated with test automation frameworks that implement and execute those test cases. Such options are good for manual testing, where your only focus is on documenting the test cases.

However, if you want to form a strong testing process, you should make use of both manual and automated testing. Using a no-code framework like testRigor will most likely give you the experience of writing your test cases as close to manual testing as possible. Read about a Test Automation Tool For Manual Testers.

Let’s see how testRigor makes that possible.

  • Allows you to write tests in plain English: Unlike most other frameworks that might allow you to write test cases in plain English but then expect you to code the meaning of that statement as well, testRigor has no such caveat. You can simply write the steps in plain English to the editor.
  • Cross-platform and browser testing: testRigor enables you to test web, mobile (hybrid, native), API, and desktop apps with minimum effort, cost, and maintenance. Moreover, you can run your test cases across different browsers and devices, too.
  • No reference to UI elements: Just like how you would mention a UI element in manual testing using relative locations, the same is applicable in testRigor as well. Its generative AI-powered engine makes it possible. For example, if there is a ‘Skip’ button at the bottom of the page, you can tell testRigor to “click “Skip” at the bottom of the page”.
  • User-friendly interface: The interface lets you add labels, descriptions, test data, and other such parameters to your test cases and suites. This makes it easier to group test cases.
  • Integration with other frameworks: You can integrate with other test case management frameworks like TestRail or CI/CD tools to ensure that continuous testing is happening after every release.
  • Features for action and verification: testRigor offers many capabilities to interact and verify outcomes on the screen using plain English commands for simple interactions with tables, email, phone calls, SMS, 2FA scenarios, QR Code, Captcha resolution, and many more.
  • Copy or import manual tests: As discussed earlier, if you are already using another test management tool and would like to import or copy the test cases to testRigor and execute them as automated tests, you can easily do so. Here are a few guides: XRay, Zephyr, Azure DevOps, and TestRail.
Here’s how a simple automated test case will look like in testRigor:
login
enter "Kindle" into "Search"
press enter
click "Kindle"
click "Add to cart"

With testRigor, you can cover mobile (hybrid/native), web, API, and desktop testing singlehandedly. It is the easiest way to build robust end-to-end automated test cases, so we highly advise you to check it out. You will thank us later!

If you are new to testRigor and would like to create your first test case but need help figuring out how to start, you can read our All-Inclusive Guide to Test Case Creation in testRigor.

Summary

Writing test cases before starting the testing activity is a good way to ensure efficient and high-quality outcomes. Moreover, when combined with automation testing, you can achieve much more in very little time while freeing up resources to focus on exploratory testing and creating test cases for new functionalities in your application.

You're 15 Minutes Away From Automated Test Maintenance and Fewer Bugs in Production
Simply fill out your information and create your first test suite in seconds, with AI to help you do it easily and quickly.
Achieve More Than 90% Test Automation
Step by Step Walkthroughs and Help
14 Day Free Trial, Cancel Anytime
“We spent so much time on maintenance when using Selenium, and we spend nearly zero time with maintenance using testRigor.”
Keith Powe VP Of Engineering - IDT
Related Articles

Maps or GIS Testing – How To Guide

Maps and Geographic Information Systems (GIS) have evolved into essential components of modern websites and applications. The ...

Manual Testing: A Beginner’s Guide

The global software testing market exceeded $40 billion in 2020 and is expected to grow between 7% to 12% CAGR between 2021 and ...

Requirement Traceability Matrix RTM: Is it Still Relevant?

The Requirement Traceability Matrix or RTM has traditionally done the heavy lifting in software development and QA as a ...
On our website, we utilize cookies to ensure that your browsing experience is tailored to your preferences and needs. By clicking "Accept," you agree to the use of all cookies. Learn more.
Cookie settings
Privacy Overview
This site utilizes cookies to enhance your browsing experience. Among these, essential cookies are stored on your browser as they are necessary for ...
Read more
Strictly Necessary CookiesAlways Enabled
Essential cookies are crucial for the proper functioning and security of the website.
Non-NecessaryEnabled
Cookies that are not essential for the website's functionality but are employed to gather additional data. You can choose to opt out by using this toggle switch. These cookies gather data for analytics and performance tracking purposes.