Writing good, well-documented test cases is as crucial as writing the code itself, if not more so. This is because test cases often serve as the single source of truth for requirements. They also act as an initial onboarding resource for new engineers joining the project. Furthermore, like code, test cases require ongoing maintenance and updates.

This article will explain how to write effective test cases for medium to large projects. We will also explore test plans and test execution, and their interrelationship.

What is a Test Case?

At its core, a test case is a concise document outlining a single user journey from start to finish. This journey should explicitly reflect the expected behavior of the software and align with its functional requirements. In essence, a test case describes a specific happy path. Each journey should be documented clearly, enabling anyone unfamiliar with the project to execute it successfully, mimicking a typical user’s interaction.

Test cases are focused and target a single aspect of functionality. By mirroring user behavior, they are invaluable for regression and smoke testing. They also serve as excellent resources for new engineers to quickly understand the project and provide valuable documentation for the entire team. Test cases are a living source of truth, consistently updated and utilized by everyone involved.

For instance, developers can employ test cases to guide their coding through Test-Driven Development (TDD) or to verify their code against requirements before submitting it to Quality Engineering (QE). Importantly, test cases are distinct from unit tests; they represent black-box testing. The underlying code implementation, language, or framework is irrelevant as long as the test passes, confirming the expected functionality.

Quality Engineers (QE) design and create test plans that encompass one or more test cases. However, test cases should not replace exploratory testing. QE professionals should employ diverse testing techniques to ensure the software meets high standards. Ultimately, test cases are one of many essential methods for verifying that your software aligns with organizational standards.

Test Cases, Test Plans, Test Execution, and Test Reports

A Test Plan is a document that compiles all relevant test cases alongside crucial information such as the release version, specific notes, and the testing environment. A single test plan can include multiple test cases.

When a tester executes a test plan, this process generates a Test Execution. A test execution is uniquely linked to a single test plan. While a test plan can be executed multiple times, resulting in numerous test executions, the reverse is not true.

Upon completion of a test execution, an engineer generates a Test Report. These reports are output artifacts detailing the outcome of each test (pass or fail). Test reports are shareable resources for the entire team and stakeholders.

Writing Your First Test Case

Test cases, like many forms of documentation, are customizable. Each team can design their own test case structure, provided it remains consistent and clear. However, every test case should clearly define its Definition of Done (DoD) or Completion Criteria. This explains the primary goals that must be achieved to mark the test as complete. Unlike individual test steps, the Definition of Done must be evaluated regardless of whether the test passes or fails.

Each test case must include Test Steps. A test step typically comprises three key columns:

Action: A concise description of a user interaction or system operation. For example: “Enter email address in the ‘Email’ field” or “Click the ‘Login’ button.” Each element involved in the action should be clearly identified. For instance, if multiple email input fields exist, the action should precisely specify the intended one: “Enter email address in the email input field with the green background.”

Data: The specific input required to perform the action. For example, “[email address removed].” Note that not all actions require data; for instance, clicking a button usually doesn’t, in which case this field can be marked as “N/A” or left blank.

Expected Result: The anticipated outcome after the action is performed. Even the absence of a visible change or error is a valid result. For example: “The email address is successfully entered, and no error message is displayed.”

Below is a basic test case template. However, as mentioned earlier, teams should design their own test case structures to suit their specific needs. Quality Engineers (QE) typically take the lead in creating these templates and ensuring their appropriate adoption across the team.

## Test Title

The test title should be brief and focus on one specific requirement.  
Example: User Email Validation on the Login Page

#### 𝗗𝗲𝘀𝗰𝗿𝗶𝗽𝘁𝗶𝗼𝗻:

Provide a concise paragraph outlining the test's objective. This section should expand on the test title.  
Example: A valid email address must include the following characters: (@, .). 
The email should be longer than 5 characters and match the email regex pattern: `^[\w\-\.]+@([\w-]+\.)+[\w-]{2,}$`. 
Additionally, the email must be registered in the database and not locked.

#### 𝗣𝗿𝗲𝗿𝗲𝗾𝘂𝗶𝘀𝗶𝘁𝗲𝘀:

List any access or knowledge the tester should have before starting the test.  
Do not include test artefacts in this section.

#### 𝗧𝗲𝘀𝘁 𝗔𝗿𝘁𝗲𝗳𝗮𝗰𝘁𝘀:

Include all relevant artefacts needed to complete the test case, such as Postman collections, resources, or test data.

---

#### 𝗗𝗲𝗳𝗶𝗻𝗶𝘁𝗶𝗼𝗻 𝗼𝗳 𝗖𝗼𝗺𝗽𝗹𝗲𝘁𝗲:

A brief list or description of what constitutes completion.  
**Note**: Do not include or list the expected outcomes.  
Example:  
1. All types of email addresses (valid and invalid) have been tested.  
2. At least 5 different invalid email formats are tested and fail the regex.  
3. At least one valid email address is tested.

#### 𝗥𝗲𝗾𝘂𝗶𝗿𝗲𝗱 𝗘𝘃𝗶𝗱𝗲𝗻𝗰𝗲:

List the required evidence that should be attached to the test report after executing this test.

| Evidence                    | Type            |
|-----------------------------|-----------------|
| Successful login             | Screen recording|
| Failed login message         | Screenshot      |

---

#### 𝗧𝗲𝘀𝘁 𝗦𝘁𝗲𝗽𝘀:

**Scenario #1:** Brief title for the scenario.  
| Action      | Data        | Expected Result  |
|-------------|-------------|------------------|
| Perform X   | Example data| Expected outcome |
| Click Y     | Example data| Expected outcome |

---

#### 𝗘𝘅𝗽𝗲𝗰𝘁𝗲𝗱 𝗥𝗲𝘀𝘂𝗹𝘁:

(Describe the expected result of the test here)

In conclusion, the creation and diligent maintenance of well-structured test cases are not merely a supplementary task but a cornerstone of robust software development. They serve as a living blueprint of requirements, a vital tool for onboarding new team members, and a crucial asset for ensuring the ongoing quality and stability of your project. By understanding the principles of effective test case writing, the role of test plans and executions, and the importance of clear documentation, teams can significantly enhance their testing efforts, leading to higher quality software and a more efficient development lifecycle. Embracing test cases as a valuable and dynamic resource will undoubtedly contribute to the long-term success and reliability of any software project.