How To Write Test Cases? Detailed Guide With Examples

Test case is the backbone of any testing project. The art of software testing is to write the right test case. Firstly it’s not about how you write it, but rather what scenarios you are writing for. After that, we need to closely tie our test cases with test design and test execution.
Let’s explore how to write test cases in the most strategic fashion.

What is a Test Case?

A test case is a specific set of conditions or variables under which a tester determines whether a system, software application, or one of its features is working as intended.
Here’s an example. You are testing the Login pop-up of Etsy, one of the leading E-commerce platforms currently. You’ll need several test cases to check if all features of this page are working smoothly.
Brainstorming time: what features do you want to test for this Login pop-up?
Let’s list down some of them:

1. Verify Login with Valid Credentials
2. Verify Login with Invalid Credentials
3. Verify "Forgot Password" Functionality
4. Verify "Trouble Signing In" Link
5. Verify "Continue with Google" Functionality
6. Verify "Continue with Facebook" Functionality
7. Verify "Continue with Apple" Functionality
8. Verify "Register" Button Redirect
9. Verify Empty Email Field Handling
10. Verify Empty Password Field Handling
11. Verify Error Message for Unregistered Email
12. Verify Session Timeout Handling
    

That’s just a quick and immediate list. As a matter of fact, the more complex a system is, the more test cases are needed.

Before You Write a Test Case

Before you write a test case, ask yourself 3 questions:

1. Choose your approach to test case design: your approach influences your test case design. Are you doing black box testing (you don’t have access to the code source) or white box testing (you have access to the source code)? Are you doing manual testing or automation testing?
2. Choose your tool/framework for test case authoring: are you using frameworks or tools to test? What level of expertise do these tools/frameworks require?
3. Choose your execution environment: this ties up closely with your test strategy. Do you want to execute across browsers/OS/environments? How can you incorporate that into your test script?

Once all of those 3 questions have been answered, you can start the test case design and eventually test authoring. It’s safe to say that 80% of writing a test case belongs to the planning and designing part, and only 20% is actually scripting. Good test case design is key to achieving good test coverage.

Let’s start with the first steps.

How To Design a Test Case?

Why we need to design before we write though?

It's simple. There are way more things to test than it appears. Taking from the example above, the Login page alone has required you 10 test cases to almost cover all scenarios. You need techniques to list down all test cases in a given scenario before you start writing those tests.

First question: do you have access to the internal code?

You are doing black box testing if you don’t have access to internal code. The entire system is essentially a black box. You can only see and test what the system is programmed to show you.

When testers don’t need to understand the algorithm, they can concentrate on determining whether the software meets user expectations. They must explore and learn about the system to generate test case ideas. However, this approach can result in limited test coverage, as some features with non-obvious behavior might be overlooked.

In that case, here are some techniques for you to design your test cases:

1. Equivalence Class Testing: you divide input data into groups where all values in a group should be treated the same way by the system.

• Example: For an age input field that accepts ages from 18 to 65, you can choose 3 values for 3 equivalence classes and test with one value from each group. That means you have 3 test cases. You can choose:
  • 17 (below 18-65 range)
  • 30 (within 18-65 range)
  • 70 (above 18-65 range)

  2. Boundary Value Analysis: this is a more granular version of equivalence class testing. Here you test values at the edges of input ranges to find errors at the boundaries.

  • Example: For an age input that accepts values from 18 to 65, you choose up to 6 values to test (which means you have 6 test cases):
    • 17 (just below)
    • 18 (at the boundary)
    • 19 (just above)
    • 64 (just below)
    • 65 (at the boundary)
    • 66 (just above)

    3. Decision Table Testing: you use a table to test different combinations of input conditions and their corresponding actions or results.

    • Example: Here’s a decision table for a simple loan approval system. The system approves or denies loans based on two conditions: the applicant's credit score and the applicant's income . From this table, you can write 6 test cases:

    Rule

    Rule-1

    Rule-2

    Rule-3

    Rule-4

    Rule-5

    Rule-6

    Conditions