Creating effective test cases is a pivotal skill for QA Engineers at all levels. Test cases allow us to verify the application adheres to requirements and to catch bugs before they are promoted to higher-level environments. Test cases can be used for all testing types.
Everyone has their own flavor when it comes to creating test cases. In this article, we will discuss what a test case is, why test cases are important, test case structure, and view an example.
What is a test case?
A test case is comprised of a sequential set of actions on an application based on a given requirement. The test case helps us determine whether or not the application is functioning correctly.
Multiple test cases used for the same application create a test suite. The test suite is used as a guide to testing through an application.
Why are test cases important?
Test cases are the backbone of testing any application. They provide a way for us to systematically make our way through an application and its requirements without missing any checks for functionality.
Creating test cases allows us to:
- Log and maintain our test results
- Measure key metrics such as completion percentage, fail rates, failed requirements, etc.
- Create transparency with other non-QA members of the team
- Share the testing effort with other QA Engineers
Test Case Structure
Test cases can be written in a variety of ways. We will go over some of the more common column headings. A testing tool can assist with adding default columns to a test case. In this article, we assume our testing tool is Excel.
- ID — This is typically a unique identifier associated with a specific test case. The Test Case ID allows us to group test cases into test suites or to quickly identify the test cases we are working with. The ID is normally auto-generated when using a testing tool.
- Description — Use this column to identify the purpose of the test case. It is typically short and sweet.
- Test Data — Here we can input any outputs from the test. This allows us to reference the created data in the future.
- Assumptions — Use this column to provide anything the person executing the test case should know if you don’t plan on mentioning it elsewhere in the test case.
- Prerequisites — Use this column to list anything the engineers may need to do before executing the test case.
- Steps — This is a sequential list of actions the user must take to reach the expected result.
- Expected Result — Enter a brief statement on what the outcome of the execution of this test case should be
- Actual Result — Enter a brief statement on what happened after the execution of this test case. This column will determine if the test case passed or failed.
- Status — This is where we input our findings. Did the test case Pass or Fail? Is it Blocked or Not Applicable?
- Bug ID — This should be used for failed test cases. Logging the bug ID will allow us to track which bugs are associated with which test cases.
Tips for writing effective test cases
- Stick to the requirements. Do not make assumptions about how the system should behave. One requirement can have many test cases.
- Keep your test case specific and concise. Smaller test cases make everything simpler.
- Make your test case repeatable. You may have to complete multiple runs against the same test case.
- Make your test case reusable. Writing test cases is time-consuming. Help yourself out and use each test case in the future.
Test Case Examples
We will go over a simple test suite. This example assumes we are using Excel to input our data.
Using the test case structure previously mentioned, we can see our test cases come to life. Taking the time to write descriptive test cases will make them easier for anyone to execute. It will also make it easier to re-execute the test cases should you need them in the future. Ensure your test cases map to defined requirements.
Conclusion
Test cases provide us a way to systematically make our way through an application and its requirements without missing any checks for functionality.
A test case is comprised of a sequential set of actions on an application based on a given requirement. One requirement can have many test cases.
Taking the time to write descriptive test cases will make them easier to understand and revisit.
Do you have any tips for writing effective test cases?
Curious to hear your thoughts! Let’s ensure quality together by sharing your insights.