How to Write Test Cases?

• Test cases are step-by-step blueprints that help evaluate software, identify bugs, and ensure it works as expected.
• Test case types include positive test cases (valid input), negative test cases (invalid input), and error handling test cases(hardware/software issues).
• While anyone can write test cases in a development team, testers and developers are typically responsible.
• A well-structured test case includes a test case ID, description, pre-conditions, steps, test data, expected results, and pass/fail criteria.
• Best practices for writing good test cases include using user-centric test case scenarios, clear and concise language for description, traceability matrix, proper documentation, and peer reviews.

What are the different ways to save costs while developing software? Well, for starters, you can hire conservatively and get more work done. But the loss in productivity due to burnout will add more cost (or technical debt) later.

Apart from having clear requirements, using agile methodologies, prioritizing project tasks, using open source reusable components, training skills, and outsourcing; writing effective test cases helps identify issues early in the development lifecycle saving massive costs earlier.

A test case is a set of instructions a tester follows to find how the software functions and responds to all possible inputs or actions. Test cases describe how software should behave in various operating conditions. It tests how software behaves when the conditions are:

• Positive — valid input that leads to the expected behavior
• Negative — invalid input that the software should handle gracefully
• Faulty — unexpected hardware or software issue causing malfunction

Also Read: Getting Started with Software Testing

Test case writers are typically the members of the software development team. Ideally, members who aren’t involved directly in writing code create test cases. But it's not a hard rule. Test case writers can be:

• Developers — they often write unit tests for their program code (testing individual software modules or functions)
• QA testers — quality assurance testers typically write integration tests and user-acceptance tests (focussing on how different program modules interact through an interface and end-user experience)
• Devs + QA — higher-level testing methods like end-to-end testing require developers and testers to work together to write test cases.

Also Read: Unit Testing vs. Integration Testing

This role can vary depending on your team structure and development methodology like Agile, Scrum, and Waterfall. For example, testers write most test cases in Waterfall, whereas Agile promotes this as a shared responsibility between testers and developers.

Also Read: Agile Testing: Best Practices

Test scenarios and test cases might sound the same but that’s not the case. Some nuances need to be considered while using these terms.

Test scenarios focus on “what” needs testing, based on real-world user actions. These are the conditions in which your software runs and a user tries to accomplish something with your software. For instance, a user successfully completes a purchase on your online shopping platform. This is a “test scenario”.

Test cases define “how” to test the scenario with specific steps, data, inputs, and expected results. For example, in the test scenario where a user searches for an item and successfully purchases it on the shopping platform, the test cases can be:

• Test case 1 — the user logs in with valid credentials, adds an item to the cart, enters a valid shipping address and payment information, completes the purchase, and receives a confirmation email.
• Test case 2 — the user searches for a specific product using keywords, filters by category and brand, and lands on the correct product page.
• Test case 3 — the user tries to checkout with an empty cart and receives an appropriate error message.

Here’s how to structure a test case while writing one from scratch:

Test Case Template

• Test case ID — a unique identifier for reference.
• Description — a concise and clear explanation of what the test case aims to verify.
• Pre-conditions — the system state before executing the test case. Pre-conditions should be achievable within the test environment (e.g., specific software versions, hardware configurations, permission levels).
• Test steps —  clear, step-by-step list of actions to be performed.
• Test data — specific values you'll use during the test, such as usernames, passwords, or product IDs.
• Expected result — expected outcome after executing the test steps.
• Actual result — the actual outcome after running the test steps.
• Pass/fail criteria — clear instructions to evaluate if the test passed or failed based on the actual outcome.
• Post-conditions — the system state after the test execution. For example, logging out of the application.
• Status — test status (pass or fail) and the next steps.

Note: You can use the above as a test case template for your purposes.

Here’s an example to showcase how to write test cases for different variations of the login function to ensure it works as expected under various conditions. It covers:

• TC01 (tests a positive test case) — successful login with valid credentials.
• TC02 (tests a negative test case) — handling of an invalid username during login

These test cases specifically focus on verifying the test scenario in which a user tries to log in to an app:

Test Case ID: TC01

Description: Login to the app with a valid username and password.

Pre-Conditions: A valid user account exists.

Test Steps:

1. Launch the app.
2. Enter a valid username in the username field.
3. Enter the corresponding password in the password field.
4. Click the "Login" button.

Expected Result: The app redirects to the user's dashboard.

Pass/Fail Criteria: The user is successfully logged in and can access the dashboard.

Test Case ID: TC02

Description: Verify the app displays an error message for an invalid username.

Pre-Conditions: None

Test Steps:

1. Launch the app.
2. Enter an invalid username in the username field (e.g., non-existent username).
3. Enter a valid password in the password field.
4. Click the "Login" button.

Expected Result: The app displays an error message indicating the username is invalid.

Pass/Fail Criteria: A suitable error message is displayed.

These are just basic examples. You can create complex test cases depending on the functions and scenarios you're testing. Using a requirements traceability matrix (RTM) is certainly beneficial for keeping track of the testing requirements, artifacts, procedures, and results.

If the test fails, report the bug to the concerned team. The reported bug is typically resolved through a bug life cycle. After that, the function is re-tested, following the same test case steps, and the status is updated accordingly.

Also Read: How to Report a Bug

Here are the test case writing tips you can borrow:

User-Centric Approach

It’s best to keep the end user in mind while writing test cases. Users may use your product in different ways. Several user actions may be hard to replicate beforehand. Design test scenarios with a user-centric approach and then write suitable test cases that cover most scenarios.  

Easy to Understand Language

Write test cases that are easy to understand, update, and reuse. Avoid using irrelevant jargon or confusing language for maximum readability and higher maintainability. It not only saves time and effort in the long run but also saves dollars by minimizing re-works.

Requirements Traceability Matrix

Start maintaining an RTM as soon as a project kicks off. It links test cases to specific software requirements, ensures optimum testing coverage, provides info on the current test execution status, and simplifies impact analysis when requirements change.

Read More: What is a Requirements Traceability Matrix (RTM)?

Prioritization and Risk Management

Focus your testing efforts on critical features and areas with high risks. This ensures you spend time testing the most important functions first.

Central Repository

Maintain test cases in a central repository for easy access and collaboration. This ensures everyone on the team has access to the latest versions of test cases and they are aware of the current progress.

Clear Documentation

Document your test cases clearly and concisely. A well-maintained and updated document helps understand the purpose, steps, and expected outcomes of each test case. Just like an RTM document, you can refer to it and keep track of the project progress when required.

Peer Reviews

Peer review is a brilliant way to keep an extra set of eyes on your test cases. It helps ensure the latest changes or additions in the test cases and identify any issues that may have been overlooked.

Version Control

Use version control systems to track changes made to test cases. This allows you to revert to previous versions, if necessary.

Also Read: GitHub vs GitLab

Automation Tools

Consider automating repetitive test cases using automation testing tools — whenever possible. This frees up your time for more exploratory testing and complex scenarios that are best suited to manual methods and expertise.

• Test environment — mention the environment in which the test is executed, such as the operating system, browser version, etc. It can be crucial for evaluating test results.
• Accurate test data — consider using accurate test data that reflects real-world conditions and app usage by end users.
• Assumptions and dependencies — make sure to document any assumptions made during the test case creation or dependencies on other test cases.
• Test execution history — keep a record of when the test was executed and by whom. It can be useful for project tracking and bug management purposes.