Test case writing is an important part of software testing process and it is important to write test cases effectively in order to make your testing successful. So how to write test cases effectively?
There are lots of different ways to write test cases. This article will give you examples of common structures which you can use and adapt to suit your need.
Test Case Template
A test case is the set of steps that need to be done in order to test a specific function of the software. They are developed for various scenarios so that testers can determine whether the software is working the way it should and producing the expected results.
The test case should include its number, a description, the test data, expected result, actual result and status (whether the test passed or failed).
Here is a simple test case template with an example:
| Test Case No. | Description | Test Data | Expected Result | Actual Result | Status (pass/fail) |
| #1 | Verify response when a valid email address and password is used | (Email address and password details) | Successful login | Successful login | Pass |
Your test could also include any pre-conditions or assumptions that are necessary for the test to be successful, such as the user must already be registered with the software.
A simple template for test cases
This is a fairly common structure that contains a number of important points. The test case has multiple test steps, some of which have expected result and some which do not.
You should have 3-8 test steps in a test case. If you only have a few test steps, you should probably consider making a checklist instead – it’s not worth your while to keep track of a lot of small test cases when a checklist will do the job just as well.
When testers report defects based on the test case, they should indicate which test step failed, in order to make troubleshooting easier.
When you write a test case, you don’t need to specify the expected result for each test step if the result is obvious. In the above example there are unnecessary outcomes of several test steps. For example, ff the browser doesn’t open, the tester won’t be able to proceed to the next step.
If your test case has too many test steps you ought to think about breaking up the test case into a set of smaller ones. If the test case contains a long list of test steps, and an error occurs, the developer will have to backtrack and repeat all the test steps, which he or she might not do by accident, or out of laziness.
Having too many test steps can be a disadvantage for the tester, too. The tester may have to repeat each one of the test steps to ensure that the bug is fixed.
Sometimes the test case template contains a field for pre-conditions. In practice only a few of the test cases need them, so the field is often left empty. An example of a pre-condition is that to change the customer’s address you have to enter a customer first. You can use this field to reference to other test cases, for example by entering a test case ID here.
Test cases are often grouped in test runs. A test run is simply a collection of test cases that testers should perform in a particular order. Rather that inserting pre-conditions into each test case, you could put them in the beginning of a test run instead. An example of pre-condition for a bunch of test cases could be to put the system in a certain state, for example, loading a certain set of customers into the system before testing begins.
Test Case Examples
Here is an example of a software test case:
Title: Login Page – Authenticate user on Hotmail.com
Description:A user should be able to log in athotmail.com.
Precondition:The user must have an email address and password that is previously registered.
Assumption:The browser supportshotmail.com
Test Steps:
- Navigate tohotmail.com
- Enter the email address of the registered user in the ’email’ field.
- Enter the password of the registered user
- Click the ‘Next’ button.
- Click ‘Log in’
Expected Result:The Hotmail inbox of the user should load.
Referencing test data
If you put your test data in a separate file and reference it from the test case, you’ll be able to use a single test case to test many different variations of the data. This is a better solution than explicitly stating test data in the test case.
A test data file can be created in Excel, in Notepad, or included in a database. In the test case above, the “Testaccounts.txt” file might consist of one column for the user name and one for the password. Each line in the test data file represents a unique combination of inputs. The test case will be very efficient because only one test case is needed to test multiple combinations. It also means that the choice of which test data to use is not just left up to the tester’s discretion.
More technical test cases
More technical test cases, such as system level testing, may refer to tests of the database or other system components.
Suggestions for further reading
- Read our article on “How to develop a template for test cases” and which is also on our site – https://reqtest.com/blog/newsletters/how-to-develop-a-template-for-test-cases/
- If you’re still writing test cases in Word, we highly recommend you look into real testing tools instead, such as ReQtest. See www.reqtest.com for more information.
- Now that you’re using ReQtest, read these two articles, one about How to create test cases in ReQtest – https://reqtest.com/blog/howto/how-to-create-test-cases-in-reqtest/ and the other about how to and execute test cases in ReQtest – https://reqtest.com/blog/howto/plan-and-execute-test-cases-in-reqtest/
