In financial services, it’s called a ‘maker-checker process.’ In risk management, it’s popularly known as the ‘4-Eyes principle.’ In the management of US nuclear weapons, it’s called ‘the two-person concept.’
In essence, they all do the same thing: These processes include an additional level of evaluation, confirmation, authorization, or approval to ensure the accuracy, quality, or relevance of the output.
In software development, this is called testing or quality assurance. Simply put, software testing evaluates code to ensure it is working as expected. To perform this activity effectively, quality teams use a powerful tool called the test case.
In this blog post, we explore what it is, why it’s needed, when to use it, and most importantly, how to write test cases.
What Is a Test Case?
A test case is a set of actions, conditions, and input data used to evaluate the quality of a software application.
Let’s say you have built a form to capture the name and email ID of the user for a newsletter subscription. Its test case will specify the following:
Actions [both user-facing and internal]: Everything that the user or the software is expected to do to complete the workflow in the software being built.
- The user enters a name
- The user enters an email address
- The user clicks ‘Submit’
- Confirmation email sent to the user
- Data saved in the corresponding database
- Data added to respective newsletter email list
Conditions: The requirements the user or the system is expected to meet while performing their actions.
- Save if validation for the name field is accepted, else show error message
- Save if validation for the email address field is accepted, else show error message
- Add to newsletter list only if the user has confirmed their email address
- If the user already exists, show the corresponding error message
Input data: Samples of what is acceptable input for the feature. Typically, Quality Assurance [QA] teams create test data that can test positive and negative results.
For example, if a condition for name field validation is “can only contain letters of the alphabet and space,” the test data would be
- Jane Doe, which meets the criteria
- Ad@m Sand!er, which doesn’t meet the criteria
Role of test cases in software engineering
The test case method is a comprehensive, systematic, and repeatable approach to software testing. While its primary purpose is to ensure quality of the application, it adds multiple levels of robustness and reliability to the software engineering process itself.
✅ Identifying defects: Test cases help identify defects in software. They hold the fort on whether the application is safe to move to production.
✅ Validating requirements: Test cases ensure what you have built is what you intended to all along. This is especially important if you’re a service organization building software for external stakeholders who have specific requirements.
✅ Mitigating risk: Test cases evaluate a feature for security, performance, and financial risks. The quality analyst also includes conditions regarding regulatory compliance, industry standards, etc. to make sure all your bases are covered.
✅ Balancing the big picture: A new feature might work well in isolation. But when integrated into the rest of the software, it might break or cause some other feature to break. Test cases ensure this is caught before it affects user experience in production.
Can one test case do all of the above? Not really. Depending on the feature, software, systems, needs, and organizational goals, there are several types of test cases that QA teams write.
Types of test cases
There is a test case for each type of software testing. Some of the most commonly used ones are as follows.
Functionality test case: This basic and foundational test case evaluates whether a software works as intended. At the bare minimum, every QA writes this.
Unit test cases: Unit testing evaluates a part of the feature or a single unit. For example, a QA might write unit tests to verify that the email address field meets various conditions.
Security test cases: This evaluates if the feature meets the security standards to go to production. Typically, this would include tests for authorization, authentication, compliance with OWASP standards, etc.
Performance test cases: This validates that the new feature meets the speed, reliability, scalability, and resource utilization requirements.
Regression test cases: Regression testing ensures that the new feature you’ve developed doesn’t affect any of the existing ones in the product.
In addition to these, specific test cases can also be run. For example, design-driven organizations might include user interface [UI] test cases. Products that perform part of a larger workflow might write many integration test cases. Others might create specific usability test cases around heuristics, accessibility, inclusion, etc.
As a product owner, you get to decide what your software needs to do and create test cases applicable to that. You must cover every scenario that is important to you.
Does that mean a test case is simply a test scenario? Not at all.
Test case vs. test scenario
A test case is a comprehensive record of how your new feature should behave [and how to test it]. A test scenario is a high-level description of what actions may happen [and therefore be tested].
Extending the previous example, the test scenario would be “test the newsletter subscription.” However, the test cases would be:
- Test name field with an acceptable name
- Test name field with special characters
- Test name field for celebrity names
- Test name field with numbers
- Test name field for placeholder or fictitious names like John Doe
Test case | Test scenario | |
---|---|---|
Definition | Comprehensive documentation of how to test a feature | Brief outline of how the feature should work from the end-user perspective |
Level | Low-level actions with granular responsibility | High-level actions with big picture responsibility |
Focus | How to test [detailed record of intended functionality] | What to test [brief record of intended outcomes] |
Source | Derived from test scenarios | Derived from user stories and business use cases |
Approach | Consider a higher resolution of possibilities and test thoroughly | Imitate real-life scenarios and test accordingly |
Now that we know the differences, let’s turn our focus back to the test case and zoom in.
Components of a Test Case
To recap, a test case is a detailed documentation of everything that needs to be tested to ensure that the software is working as intended. This makes it comprehensive, granular, and multi-faceted, involving multiple components.
Some of the critical components of a test case are:
Test case ID: Every test case has a number. This might sound simple, but to test an application thoroughly, you’ll be performing various tests that appear similar. The test case ID helps differentiate between them.
Description: Description of what you’re testing for. In the above example, this might be, “Adding real, interested prospects to our newsletter database.”
Preconditions: All prerequisites that should be met for using this feature. For example, we discussed validation for each field above. In addition to that, other conditions might include:
- The user should not have already subscribed to the newsletter
- The user should not have unsubscribed from the newsletter
Steps: Steps the user or the system should follow to complete the evaluation and mark it successful.
- The user enters valid name
- The user enters valid email ID
- The user checks privacy checkbox
- The user clicks submit button
Expected results: List of what the system needs to do next.
- If the user name is invalid, show an error message
- If the email ID is invalid, show an error message
- If the username and email ID are valid, save to respective database
- Once saved to the database, send a confirmation email to the user
Actual results: These are the tester’s observations after they have run the test case. This is what will be sent back to the developer in case something doesn’t work right.
- Tested name field with Katy P3rry and it was accepted as a valid input [though it contains a number]
With that, you’re all set to write effective test cases. Here’s how.
How to Write Effective Test Cases with Examples
Writing a good test case requires both business logic and technology acumen. You need to understand it from the user’s point of view in the real world as well as the technological perspective in the digital world. Below is a robust framework to get you started on that journey.
1. Identify test scenarios
Before you write test cases, understand the real-world scenarios in which the feature will be used. Read the user story, study the requirements document, or even discuss the specifications with the developer.
For example, the test scenarios in the previous example would be: User successfully subscribes to the newsletter.
In this step, it’s important to ask whether the requirements document describes the user in any specific way.
For example, if you’re creating a newsletter functionality for only paying customers, you’ll have a scenario where non-paying users might try to subscribe.
So, look through requirements, specifications, and user stories thoroughly.
2. Define test case objectives
At this stage, define what you’re looking to achieve by running your tests. For example, if you’re just testing whether the feature is working as planned, you’ll write functional test cases.
However, if you also need it to be secure and performant, you’ll write corresponding test cases as well. This will help streamline your agile testing process and present results to the development team.
3. Write clear and concise steps
This stage is more than just outlining the workflow. It is everything that the QA needs to do to ensure the feature works as expected.
Make it thorough: Go into as much detail as possible. Include what needs to happen based on the user/system action. For example, you might write:
- Enter the name in the name field
- If the name contains a number, show an error message, “Please enter a name with only letters and space”
- If the name contains special characters, show an error message, “Please enter a name with only letters and space”
- If the name is a placeholder, show an error message, “Please enter a valid name”
- If the name is validated, allow the user to submit
Make it reusable: Most features have overlaps with other features in the past. For example, the fields for newsletter subscriptions might be similar to those for creating new user accounts. Reuse them as much as possible to maintain consistency and efficiency.
In fact, you can also create reusable product requirements document templates from which it’s easier to extract test scenarios and test cases.
Draw the process: For complex features, you might find it difficult to document all test cases in a linear fashion. In such cases, try a flowchart.
ClickUp Whiteboards offers a highly customizable blank canvas to visualize your feature workflow. Don’t feel the pressure to do it alone. Create your flowcharts and share them with all stakeholders—business analysts, developers, testing managers, etc.—and get their buy-in before you get started!
Set context: While the test scenario outlines the business context, you need to outline the testing setup clearly. Include the software version, OS/browser, hardware, date/time formats, time zone, etc. Also, link any documents and resources that may be helpful during test execution.
4. Specify expected results
This is the answer to what happens if! So, what happens if the name field is validated? What happens if the name field is not validated?
- What if the user is already a subscriber? Should you reject their subscription or resubscribe?
- What if the user is not a paying customer—should you ask them to pay now?
- What if the user unsubscribed before? Should you double-check before resubscribing?
In this manner, outline expected results for every possibility. The more complex your feature, the longer your list will be.
5. Include preconditions and postconditions
Now, no feature is an island. In software development, every feature is connected to something else, which means testing has a number of preconditions and postconditions.
Precondition examples
- Needs to be a paying customer
- Needs to provide a valid name and email address
- Needs to accept terms and conditions
- Needs to use the latest version of Chrome
- Needs to be logged in from mobile
Postcondition examples
- Needs to be added to the database
- Needs to accept subscription on confirmation email
- Needs to be added to the newsletter list on the CRM
If you’re a product leader looking to get a hang of testing, here are some no-code tools for product managers.
Those were the basics, let’s get to some nitty gritty.
Best Practices for Writing Test Cases
Let’s face it: Writing test cases is an art. A good test case will throw up bugs and defects that weren’t even visualized in the requirements. For example, what if the name field had two spaces? Or what if the user’s last name had a hyphen?
To ensure that your test cases are geared toward delivering high-quality software, consider the following best practices.
🧠 Think like a user
Before writing your test cases, think from a user’s perspective. Be critical and granular. In the example we’ve discussed so far, you might ask:
- What does ‘name’ mean? First name? Last name? Or both?
- Whose name is this? Should the field name text say, “your name” instead?
- Should there be a placeholder text to guide the reader?
- If the user enters an invalid name, should the error message identify what is wrong?
Walk in the shoes of the user. Explore various possibilities and even edge cases. You might not create test cases for all, but exploring them helps strengthen the feature.
🎯 Focus on one thing at a time
Don’t write a functional test case that is also a usability test case and a database test case. Do one thing at a time. This way, when a test result is pass/fail, you know exactly what worked or what went wrong.
Including too many variables in one test will complicate the issues when the test fails.
👫 Don’t do it alone
Test cases define software quality. Even though it is the checker in the maker-checker process, it needs another layer of two-person review. So, once you’ve written the test cases, get it peer-reviewed.
Ask a colleague to look through what you’ve written. Encourage them to find faults and give critical feedback. It also helps to do this in collaboration with business analysts and developers to get a clearer understanding of their intent.
♻️ Create reusable templates
Among all the best practices in writing test cases, the most valuable one is to create templates. Whether you’re testing similar features or completely different ones, a template provides structure to your thoughts. Include key components, an automated numbering mechanism, or a framework to present all test results.
ClickUp’s Test Case Template is a simple, yet powerful, example of how you can dramatically improve efficiency and visibility with a repeatable framework. This beginner-level template is customizable, enabling your teams to get more done faster. What’s more? You can also use this template to identify candidates for automation and double-down on your QA efforts.
🛠️ Use the right tools
In a software development team, writing comprehensive test cases for complex features can be a time-consuming task. To say nothing of documenting and organizing them for easy access.
To do this, choose the right tool.
Tools and Resources for Test Case Management
Good test case management enables you to create, organize, execute, record, and monitor what you’re testing. It helps testing teams ensure thoroughness without losing efficiency. It helps development teams see the bugs clearly.
While the benefits are endless, the challenges are too. The rule of thumb for the number of test cases per feature is “as many as needed.” Depending on your feature, it can be two—i.e., one positive and one negative. It can be three, if the test case is conditional. Or can be multiple.
To manage this, you need a robust tool. Some of the best modern QA testing tools are:
TestRail
TestRail is a test management platform for documenting and tracking testing plans. It includes features for traceability, coverage, test automation, and analytics. It natively integrates with a number of software development tools and offers an extensive API.
BrowserStack
BrowserStack is an app and browser testing tool. It offers testing for iOS and Android apps as well as websites on multiple browsers. It includes specific modules for visual testing, accessibility testing, test observability, low-code automation, and more.
Jira
As one of the most popular agile project management tools, Jira also doubles up as a bug tracking software. With Jira, you can write test cases, linking them to user stories, known bugs, or other issues.
However, as Jira isn’t designed for test case management, the reporting and automation features may be limited.
ClickUp
ClickUp for software teams is an all-in-one project management tool, designed to support every aspect of the engineering process. Test case management is no exception.
Writing test cases: ClickUp enables teams to manage their backlog efficiency with robust bug and issue tracking features. Manage existing test cases as well as create new ones with ClickUp. Use forms for software teams to capture requests/bugs and automatically convert them into tasks for the team.
Visibility for operations: You can view it as a Kanban board across statuses or use the calendar view to schedule them. Manage the QA team’s tasks with the ClickUp Workload view and move things to production faster. Use ClickUp’s Bug and Issues Tracking Template for a bird’s eye view of all things testing in your software development project.
Automation in project management: Seamlessly integrate test case management into your product development process.
Use ClickUp Automations to assign the right tester to each test case. When the QA changes status, automatically assign it back to the developer for review.
With ClickUp for Agile teams, build reusable checklists to be added automatically to tasks. Set up ClickUp Brain to help QA teams write reports faster.
Best practices already set up: Use the dozens of pre-designed templates to bring structure to your testing process. Start with the various test case templates or bug report templates.
Then, try ClickUp’s Test Management Template to streamlining your test scenarios, test cases, and test runs. With this template, track process, evaluate results, and collaborate with the development team on bugs/issues.
For beginners, this template also has a comprehensive ‘How to get started’ doc to walk you through the process.
Wondering how to write a test report? We’ve got a template for you. Download and use the beginner-friendly ClickUp Test Report Template to summarize the results of your tests and hand them off to developers.
Build Great Software for Every Case with ClickUp
In software development, testing plays the crucial role of making sure everything is
alright. It provides 360-degree support.
It validates the development team’s work. It confirms suitability to the business team’s intent. It stays loyal to the user’s needs of functionality, performance, security, and privacy.
Managing a process so critical and comprehensive demands a thoughtful suite of tools. This is precisely what ClickUp is.
Whether you’re following agile, Waterfall, or a hybrid model of software development, ClickUp is packed with features, designed to be highly customizable to adapt to your unique needs.
In addition to powerful, multi-faceted task management, ClickUp also includes a test suite, DevOps automations, integrations, and templates that pack a punch. See it for yourself. Try ClickUp for free today.