The primary goal of a test case is to ensure whether different features within an application are working as expected. It helps validate if software is free of defects and if it is working as per the expectations of the end users.
What is a test case?
The primary ingredients of a test case are a bunch of inputs, few actionable steps, as well as expected and actual results.
What Constitutes a Good Test Case?
An important requirement for a well-written test case is its ubiquitous nature. That different team members can follow the test case without any help is critical to saving future time and efforts. An ability to reuse test cases or test steps can be particularly handy in saving duplication efforts over time.
Writing a good test case thereby necessitates a solid understanding of business requirements and the application under test (AUT). In fact, some sort of regulation within a company can help overcome the ad-hoc approach to testing and ensure test cases written are easily followed.
How to Write a Good Test Case
A test case can be written in multiple ways. Our goal in this article is to give you pointers on common structures you can follow while writing an effective and easy to follow test case.
Use an Easy to Follow Name or a Title
The first step for writing an effective test case is giving it a name or title that is self-explanatory. An easy way to accomplish this is by naming the title as the functional area you are testing. For instance, if the feature or the functionality under test happens to be Logout, the title of the test case could be labelled as “Logout Page”. This makes it easier for other to follow.
Set up a Test Scenario
The test scenario sets up the stage for what we are going to test or the particular behavior that is being validated in the test case. Other constituents of test scenario would include stating any assumptions or dependencies. Ensure an environment on which the test needs to be performed is clearly mentioned as a part of a test scenario.
For example, in the previous test case having “Logout Page” as the title, the test scenario looks something like this:
“Check logout functionality for yahoo.com with Windows 10 operating system”
Assumptions and Preconditions
All assumptions and preconditions that must be bet before a test case is executed could be mentioned separately, rather than as a part of test scenario. For instance, in our logout example the assumption and prerequisites look like:
Prerequisites: The user is logged in and already has a valid yahoo.com email address along with password
Assumption: The user is trying to access yahoo.com on a supported web browser
This prevents false failures and ensures everyone is on the same page before executing the test.
Write Easy to Follow Test Steps
Test steps contain the detailed steps one needs to in order to ensure the feature under test is working as expected. It is important to keep the steps clear and brief, without leaving out essential facts. In case the step is difficult to navigate, having relevant artifacts with screen captures can be helpful.
Pay Attention to Test Data
Testing for every data permutation and combination is challenging and impossible. Hence, it becomes important to select a data set that gives sufficient coverage. This essentially means selecting a data set that specifies not just the positive scenarios, but negative as well. Other key criteria to look for while selecting test data could include choosing:
- Discrete/Unique data value
- Out of Range Values with positive and negative scenarios
- Boundary Conditions focused on minimum and maximum values
- Zero, Blank, or Null parameters
- Invalid data types like a different language
The expected result helps the tester determine if the test case passed or failed depending upon the steps performed previously, under the assumptions listed. If possible, each test step and not just the test end should be linked to an expected result. The expected result for each step needs to mention in detail what alert, page, or screen is to be expected.
The actual results column in the test cases specifies how the application actually behaved while test cases were being executed. If the actual and expected results are the same, you can use “As Expected”.
Does the test case Pass or Fail.
Any other useful information such as screenshots that tester can provide to developers to fix any defects can go here.
|Check login with right data
|Assumptions & Preconditions
|Assumption: The user is trying to access QAComplete on a supported web browser
- Go to qacomplete.com
- Enter User ID
- Enter Password
- Click Sign in
|Userid = [email protected]
Password = Pass
|User should be able to login
Where A Test Management Tool Comes in Handy?
Prioritizing your Tests
In an Agile world, testing different permutations and combinations of tests is not a possibility. This is why it’s critical for teams to prioritize tests for risky areas before releasing a product to the marketplace. With a built-in risk based testing module, a test management tool like QAComplete can help identify areas which you need to focus on to get testing done on time.
Reuse Test Steps
The test steps created in a test management tool can be not just be reused across different test sets, but also across multiple projects. An ability to reuse test steps helps save a lot of time in the longer run as there is no need to write steps from scratch. This helps reduce test maintenance as it is easier to avoid redundancy.
Reducing the Duplication of Data
A test management tool can reduce duplication of data which traditionally occurs when requirements, tests, or defects are managed in a silo. It ensures everyone — from business analysts to developers, testers, and QA managers — has one view of the progress being made.
In the case of regulated industries, such as medical devices, it is often required to document a number of details related to the tests.
- For example:
- When were tests run?
- Who ran the test?
- What requirements did they cover?
A test management tool can come in handy in such a situation since it can automatically keep a log of these details for different tests run at different times