Do you maintain a set of software test cases that your team can use to run tests before releasing new features? If not, your team’s productivity is probably somewhat affected and worse, you may be shipping releases that are not comprehensively tested.
Software test cases are the hack every development team needs. They can streamline your testing process, helping testers run better tests at a faster pace. But, of course, it all comes down to how well-written the test cases are.
In this article, we’ll show you how to write software test cases that work in seven steps. You also want to stick to the end, where we’ll share a few software test case templates.
What Is a Test Case?
A test case is a series of actions performed to validate that a functionality of a software is working as expected and without bugs.
Test cases usually cover the test steps to be taken, test data, and pre- & post-conditions for the test scenario. These details help testers run comprehensive tests to confirm whether the actual results align with the expected results.
A test case is usually derived from a test scenario. A test scenario, on the other hand, is derived from a use case. A use case simply means how a given software is used. For instance, one needs to login into the software. Therefore, logging in is a use case.
While testing the software, the use case becomes a test scenario. Therefore one of our test scenarios could be “test the login to the software.”
The test case derived from the “test the login to the software” test scenario stipulates the executable steps to be followed while testing the test scenario. Each of those step executions to be followed is a test case. You’ll notice that test cases are way more specific than test scenarios.
For instance, you can have the following test cases if you are testing the login functionality of your requirements management software.
- Test Case 1: Enter a valid User Name and a valid Password
- Test Case 2: Enter a valid User Name and an invalid Password
- Test Case 3: Enter an invalid User Name and a valid Password
- Test Case 4: Enter an invalid User Name and an invalid Password
All these test cases can be written in a test case template that testers will use to test for the functionality.
Test cases are crucial because they make testing work easier, faster, and more efficient. That’s especially true, considering test cases can be reusable.
Test cases are also super helpful when testing software using a remote team. These templates ensure that your distributed team of testers and developers remains on the same page. We’ve seen this first-hand at Tara.
It’s also important to make a distinction between test cases and test scripts. Test cases are more of a manual approach to software testing. Test scripts, on the other hand, facilitate automated testing. Think of them as written programs that run to test a software application.
Why Do You Need a Software Test Case?
Software test cases elaborate on how to test the software. As much as a test scenario tells what would be tested, the test case elaborates on the exact steps to be followed to test for the test scenario.
As such, test cases give the testers actionable steps to test the application correctly.
Well-written test cases also ensure every functionality is tested and documented. That increases the chances of shipping a product free of defects and one that aligns with the end-user expectations.
That’s why you really need a software test case as much as you need a software design document.
How to Write a Software Test Case
When writing a test case, several fields are usually standard. It must have a test case name, pre-conditions and post-conditions, test steps, and expected results.
These details help you write reliable test cases that anyone can use to test the AUT (application under test).
That said, here’s how to write test cases:
- Specify a unique Testing ID
Each test case should be identified using a unique testing ID. We recommend writing a unique testing ID following the common naming convention. That’ll make it easier for testers and other stakeholders to know what exactly the test case is for. Tracking and retrieving the test cases will also be easier.
For example, we may use a test case ID such as “TC_login_01.” In this example, the first two letters indicate that it is a test case, the word login indicates that we are testing the login functionality, and the number shows that this is the first test case.
- Describe the Test case
After naming the test case, it needs a brief description. The description explains what is being tested in the test case.
For instance, it can be “testing the software’s login with valid username and password.” Or “check the response of the login page when an invalid username or password is entered.”
Make sure to write concise and easy-to-understand test descriptions. You don’t want to leave any room for misinterpretation here. The tester should clearly understand the goal of running the test from reading the description.
- Pre-requisites
The testing prerequisites or preconditions are special conditions that must be met before the test is executed. For instance, if we are testing the software’s login, a pre-condition could be “must have installed the software” or “must have registered with the software.”
It is essential to have these preconditions set to avoid any mishaps or unintended results. You should also highlight any dependencies on other tests if they are there. For example, should the tester wait for a particular test to be completed before initiating another test?
- Execution steps
Execution steps are the individual actions that must be taken when testing. Writing your execution steps from the end user’s perspective is highly advisable. We follow this best practice at Tara.
For example, instead of writing something like “the tester shall open the software,” we simply write the step as “open software.” This keeps our test cases neat and easy to follow.
It may sound obvious, but we’ll still point out that the execution steps should be written in the order in which they’ll be followed. Don’t mix up the steps.
Here’s what the execution steps of testing a login functionality may look like:
- Open software
- Enter Username
- Enter Password
- Click “Login” or “Enter”
The steps stipulated for execution should be straight to the point and easily repeatable. Also, bear in mind that the guy writing the test case may not be the one performing the actual tests. Therefore, the steps should be simple enough for anyone to come in and execute them.
- Relevant test data
While testing the software, you need different data sets to test the necessary functionality exhaustively. As indicated before, test cases are executed from the end user’s perspective. Therefore, relevant test data would be any data variation the user might try to use while using the software.
For instance, a user might use any combination of the following data sets during login.
- A valid username and a valid password
- A valid username and an invalid password
- An invalid username and a valid password
- An invalid username and an invalid password
All these are relevant data sets that need to be included in the test case. So you may provide the test data as:
- Username – mac01@folster.com
- Password – Kratos$$
Make sure your test data is accurate and complete. This is crucial lest the software ends up with a false fail due to mistyped test data.
- Desired Outcome
The desired outcome is where you describe test results. You can also write it as the expected result. For instance, the login should be successful if you enter a valid username and password.
In such a case, you can simply write the expected outcome as “successful login” or “user is logged in.” Once again, you want to keep things short and clear.
The desired outcomes will help you determine whether the test case was a pass or fail. It’s a pass if the expected results match the actual results.
- Actual Test Case result
The actual test case results show what happens after the execution steps have been completed.
Of course, you want the actual results to align with the desired outcome or expected results. That would mean your software test was a pass or successful.
Beyond the actual results, your test case may include two more sections on the test status and comments. The status section is where you’ll record whether the AUT passed or failed. The tester may also be forced to record “suspended” if the test is suspended midway.
Meanwhile, the comments section allows the tester to leave some remarks regarding the test. For example, they may record the type of browser they used to run the test.
They may also note down the timestamp when the test was completed. This can be helpful, especially if a developer releases an update after the test. That update may affect the initial test result.
Let’s look at some software test case templates.
Software Test Case Templates
Different software is created to address specific problems. However, some software functionalities are standard across most software. These functionalities are usually tested the same way.
The testing phase can be planned or ad-hoc testing. It can also be performance testing, automation testing, or boundary testing. We shall share three software test case templates in this section.
- Login page view templates
The example below shows a template of a login page test case.
The test case template shows two test cases, one using a valid username and password while the other uses a valid username and invalid password. It has a comments column in case additional remarks are needed.
- Access to the relevant browser
When creating software, it has to be at least compatible with the most common browsers. Therefore, you should thoroughly develop test cases to test your software’s compatibility with different browsers.
The template below shows a test case for access to Chrome Browser.
The test cases for the compatibility of these browsers can be categorized into:
- Browser general compatibility
- Browser layout and design compatibility
- Browser functionality compatibility
You should develop your test case templates depending on the use case of your software on different browsers.
- Manage file permissions
Different people will use AUT differently. Therefore, the software must grant permission levels depending on the use case of the software.
While creating permission for different user levels, each feature/button to give access or block someone has to be tested using its test case.
For instance, the above example indicates that the name field has to be filled. The test case should account for when the custom field is correctly filled and all the other scenarios that can be used to fill or not fill the standard field.
Bonus Tips for Writing Effective Test Cases
Here are some quick best practices to follow while writing software test cases:
- Keep your test cases simple, precise, and transparent. The tester shouldn’t scratch their heads trying to figure out what the test case is for and how to execute it.
- Always review your test cases after writing them. And don’t think like the test case writer. Instead, put yourself in the tester’s shoes, then review and see if the test cases make sense.
- Keep the end user in mind at all times. Write the test cases from the end user’s perspective.
- Make sure your software test cases are comprehensive. Double-check them against the software requirements to ensure nothing goes untested.
- Peer-review your test cases. Letting your colleagues review your test cases after writing them is a good practice to make sure that there is no mistakes – especially with important information such as test data.
In Closing
Test cases are essential for thorough software testing. They granulate the software’s functionality and ensure that every button, custom field, or function responds as it should in all the varying scenarios.
A team needs to develop test case templates as these templates guide every tester on what they should be doing during the software development life cycle. The templates also ensure that the reporting of the software functionality is uniform and useful.