How to Write Test Cases? (+ Detailed Examples)

Artem Golubev

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 you dive into testing the application, it’s paramount to understand what needs to be tested. This is where test cases come in. A test case is a defined scenario or condition created to check the functionality, accuracy, or quality of a software application or feature. It outlines inputs, preconditions, anticipated outcomes, and postconditions essential for testing a specific facet of the software. Essentially, test cases provide a framework of instructions or guidelines for conducting tests. They are not limited to manual or automated testing; rather, writing test cases for both types of testing can be incredibly beneficial to your application.

Key parts of a test case

• Test case ID: A unique code or number to easily reference and track the test case.
• Test case title: A concise yet 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 state.
• 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 outcome: 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.
• 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.

Test case vs. test scenario vs. test script

Having defined what a test case is, let’s shift our focus to a test scenario. It provides an overview of what requires testing. You can craft multiple test cases within a single test scenario. For instance, if the test scenario is verifying the login operation, you can develop several test cases such as ‘verifying successful login with correct credentials’, ‘verifying unsuccessful login with incorrect password’, and so on.

A test script is part of a test case. 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.

Why should you write test cases?

• Systematizing the Testing Process: Test cases help to organize the testing process by giving it a structure. Once you have a clear understanding of what to test and how, it speeds up the testing process significantly.
• Fostering Better Tests through Brainstorming: Creating test cases encourages critical thinking about what’s being tested. It calls upon a tester’s creativity to design comprehensive and potentially fail-proof test cases. This process, particularly in a group setting, enhances the quality of the test cases.
• Facilitating Delegation of Testing Activities: Since test cases are documented systematically, the author of the test case isn’t required to conduct the test. Test cases can be delegated among team members, and can even be used by developers and business analysts for testing the application in their environments.
• Improving Test Coverage: Writing test cases promotes brainstorming and encourages testers to devise more creative test cases, thus improving test coverage.
• Increasing the Probability of Defect Detection: Ultimately, the purpose of writing test cases is to test the application. If test cases are high-quality and ensure wide test coverage, the chances of detecting bugs and glitches at an early stage increase. Although some bugs might go unnoticed, this approach mitigates the high costs associated with fixing multiple issues in production.
• Providing Documentation: Documented test cases serve as future references and an excellent knowledge sharing tool during hand-overs or onboarding new team members.
• Verifying Requirements: Test cases function as a checklist, verifying if the application meets the functional and non-functional requirements.
• Supporting Regression Testing: Documented test cases can be reused for regression testing. Coupled with automation testing, this proves to be a powerful quality control strategy.
• Enabling Collaboration: Test cases for functional requirements might require input or review from business analysts. Similarly, non-functional requirements may need assistance from the development team. Documented test cases facilitate this collaboration.

Tips for writing test cases

• 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: Your test case’s outlook will change depending on the type of testing. 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, and so on.
• 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.

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:

1. 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: ValidUser Password: Password123

   Postcondition: The user’s dashboard/home page is displayed.

   Test Priority: High

2. 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 current details of the user.
   2. Check that the API returns a status code of 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 details of the user again.
   Expected Result:
   1. The initial GET request returns the original user details.
   2. The PUT request returns a status code of 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

Can you reuse manual tests for test automation?

Incorporating automation testing in the testing process, particularly for repetitive tasks like regression testing after each release, proves advantageous. Test cases initially written for manual testing can be repurposed for automation testing, albeit with some modifications. These manual test cases can form the foundation of your automation test cases. However, each automation test case must have its steps rephrased into a script, comprehensible to the test automation framework. Expected outcomes are then validated accordingly.

These automation-focused test cases are optimized to reuse code across similar test scenarios and can process large data sets within a single test case by manipulating parameters. It’s essential to note that the inception of automation testing relies on the drafting of test cases; without these, the framework can’t verify anything. While test cases for manual and automated testing aren’t mutually exclusive, they differ in their writing approach and their target audience: one targets humans, and the other, machines.

How to improve the process

• Writing Tests in Plain English: Unlike other frameworks, testRigor doesn’t require you to code the meaning of each statement. Simply draft the steps in the editor in plain English.
• Cross-Platform and Browser Testing: testRigor enables writing test cases for web, mobile, and desktop applications and executes them across all these platforms. It also supports running test cases across different browsers and devices.
• UI Elements Locating without Technical Complications: As in manual testing, testRigor lets you mention a UI element using relative locations. Its AI-powered engine makes this possible. For instance, you can instruct testRigor to ‘click “Skip” at the bottom of the page.’
• Grouping Test Cases into Test Suites: testRigor allows for the creation of test suites for different functionalities, within which you can write related test cases. This facilitates easier management and execution of test cases.
• User-Friendly Interface: The interface lets you add labels, descriptions, test data, and other parameters to your test cases and suites, making grouping easier.
• Integration with Other Frameworks: It offers integration with other test case management frameworks like TestRail or CI/CD tools, ensuring continuous testing after every release.
• Diverse Action and Verification Features: testRigor offers numerous capabilities to interact with and verify outcomes on the screen, such as interactions with tables, UI testing, 2FA login support, conditional execution, reusable rules written in plain English, test data management, and more.

login
click "Organization"
check that page contains "filter-multi-select-dropdown-Organization"

You can cover mobile, web, and desktop with testRigor. It is perhaps 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!

In Conclusion

Writing test cases before diving into testing activities ensures efficiency and high-quality outcomes. When combined with automation testing, you can achieve more in less time, thereby liberating resources to focus on exploratory testing and the creation of test cases for new features in your application.