Test case structure
Introduction
A well-written test case should allow "any tester/person" to understand and execute the test.
When writing test cases, it’s important to put yourself in the user’s shoes and to include all the necessary details. Putting forth the extra effort to write good test cases upfront will save you time and effort further down the road. Well written test cases can mean the difference between a well-tested application and a poorly tested application, After all Quality is built into software from the ground up.
Writing test cases – especially high volumes of them at once – can be a time consuming task. Azure DevOps Test Management makes it easy to write high quality test cases and keep them organized. Here, we’ve outlined some tips on how to write test cases, along with a sample of a test case.
How to write test cases for software:
Use a Strong Title
A good test case starts with a strong title. As a best practice, it’s good to name the test case along the same lines as the module that you are testing. For example, if you’re testing the login page, include “Login Page” in the title of the test case. In some cases, if the tool you’re using doesn’t already do this, it might makes sense to include a unique identifier in the title of the test case as well, so the identifier can be referenced instead of a long title
Include a Strong Description
The description should tell the tester what they’re going to test. Sometimes this section might also include other pertinent information such as the test environment, test data, and preconditions/assumptions. A description should be easy to read and immediately communicate the high-level goal of the test.
Keep the Test Steps Clear and Concise
Test cases should be simple. Keep in mind, the person who wrote the test case might not be the same person who executes the the test itself. The test steps should include the necessary data and information on how to execute the test. This is perhaps the most important part of a test case. Keep this section clear and concise, but don’t leave out any necessary details. Write the test case so that anyone can go in and perform the test.
Include the Expected result
The expected result tells the tester what they should experience as a result of the test steps. This is how the tester determines if the test case is a “pass” or “fail”.
Make it Reusable
A good test case is reusable and provides long-term value to the software testing team. When writing a test case, keep this in mind. You can save time down the road by re-using the test case instead of re-writing it.
Here is an example of a test case:
Title: Login Page – Authenticate Successfully on gmail.com
Description: A registered user should be able to successfully login at gmail.com.
Precondition: the user must already be registered with an email address and password.
Assumption: a supported browser is being used.
Test Steps | Expected Result
- Navigate to gmail.com | User is presented with the Gmail landing page
- Enter the email address of the registered user. | valid email required. e.g"user@gmail.com"
- Click the ‘Next’ button. | Please enter Password is displayed
- Enter the password of the registered user | Password entered successfully
- Click ‘Sign In’ | User successfully logged in