Test case is a step by step process which helps a tester to validate the functionality of an application. This sequence helps in guiding the tester whether a feature/software is bug free and working as per customer requirement.
A test case can be maintained in any test management tool or in simple excel sheet. Let’s check out the basic template for Test Cases using excel sheet.
Date Created | Test case ID/No | Test case Title | Test Cases type | Test category | Priority | Preconditions | Test steps | Expected results | Actual results | Test cycle no | Bug ID.
This column contains a date in which this Test Case was written by the tester.
2.Test case ID/No:
It is a unique number to identify the Test Case from among the number of Test cases. It can be Initial of the Project along with a unique number. For e.g. Project name is Urban ladder and we are writing test case for Req no 1. Then test case ID can be UL_01.
Now if one requirement has multiple Test Cases then we can use in this way:
UL_ Req ID _Unique No i.e. UL_101_01.
There can be two way to have a Test Case Titles. In first way, we can have two separate columns One for Test Case Title and other Description.
As per industry standard and books people prefer to use Test Case Title 1. However, in my team, we have practiced to use Title 2 as a process.
Test case 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 which you’re testing. For example, if you’re testing the login page, include “Login Page” within the title of the test case.
Test Cases Title 2:
Here I have changed a practice little bit. Now instead of writing a high level test scenario, we are writing test scenario in low level.
For e.g. We have the following Requirement:
As a user, I should be able to apply the leave after entering all the fields.
|Test case 1:
|ABC_Leave management_ Leave application_ To verify user is able to enter the values in the all the fields.|
|Test case 2:
|ABC_Leave management_ Leave application_ To verify user is able to click on Apply button.|
|Test case 3:
|ABC_ Leave Management_ Leave application_ to Verify the functionality when user clicks on Apply button.|
Now in above Test Cases format will be: Project Name_ Module name_ Feature_ Functionality
In this way, we can easily identity which Test Case is related to which requirement by checking the title only.
3.Test case type:
This explains the type of Test Cases i.e. Functional, Performance, GUI, Integration or Security.
4.Test case Category:
Test case Category includes two values i.e. Positive and Negative. This defines whether this test case is Positive or negative.
Let me explain you, what could be a positive and negative Test Cases?
Positive Test Cases:
A Test Cases which contains the valid data/ functionality as input is known as Positive test case.
For e.g.: The login field can take only alpha numeric. In this case when we give the input as:
SUR123 then it becomes Positive test case.
Negative Test Cases:
Now we can write negative test case for same feature. For eg: The login field should not take special characters i.e. &$# ($&$ since its invalid for that functionality.
Priority as the name suggests, is about prioritizing a Test Cases as per its importance or urgency to execute. A Test Case can have following priority: High, medium and low.
High defines: A Test Case should be executed at the highest priority, since this functionality is most important to user. And low could be the least priority functionality a user wants.
This explains any Assumptions/Pre-conditions to be used for testing. It should be mentioned point wise. Preconditions are the prerequisite to complete the test case. The preconditions cannot be same for all the test scenario/test case.
For example, the preconditions for the above scenarios will be:
|Preconditions for Test case 1:||1. Leave management tab should be available
2. Leave management form/page should be available with all the fields
|Preconditions for Test case 2:
|1. Apply button should be available in Leave application form.|
|Preconditions for Test case 3.
|1. User should be able to enter the values in all the fields.
2. User should be able to click on Apply button.
Test steps are the way to reach to that functionality. It doesn’t contain verify statements.It always prompts the user to perform the action and have present tense in it. It is important to keep a test step shorter and simple. Don’t leave out any necessary detail in test steps:
For e.g.: To perform login operation the steps could be:
- Navigate to gmail.com
- In the ’email’ field, enter the email of the registered user.
- Click the ‘Next’ button.
- Enter the password of the registered user
- Click ‘Sign In’
The expected result tells the tester what they should experience because of the test steps. We get the expected results from our requirement which describes what a user wants from a feature/ functionality.
Important point to consider: If you have 4 test steps then you should have 4 expected results. That means expected result for each test step.Expected results always contains “should” statement.
This column records the result we get it from system after executing a test step.
This can be written in the form of status which can be pass or fail. This is how the tester determines if the test case is a “pass” or “fail”.
In this sheet, I am adding one additional column which describes the number of test cycles.
When we will run the same test case, let’s say 3 times. So, chances are there the test case is failed once and 2 times its passed. This result should reflect in your test execution.
So, your result column should have Test cycle1|Test cycle2|Testcycle3|Test cycle n
Now after performing all these steps: You will end up with two situations
Situation 1: When your Test Case is Pass.
Situation 2: When your Test Case is fail.
Here we will talk about Situation 2: When your test case is fail then we should have defect ID in front of the test case.
In this way, we can link the Test Cases with our bugs.
Many organization tags bugs with Test Cases. Now here I am tagging Test Cases with bugs while executing those Test Cases.
Here is the sample template
Writing Test Cases for software takes a little practice and knowledge of the software that’s being tested. Well-written Test Cases can make your testing process smoother, and save you time in the long run.
About the author Surbhi
It's been 10 years,I have been employed as a professional Lead Quality Assurance Engineer and Promoted to take additional responsibilities as Test Manager. Participated in various Testing competitions like Testathon, India testing league, Bugathon. Contributed to community by sharing knowledge on Salesforce platform as Speaker in Unicom event. I have tested a number of existing software products to determine if they were working properly, had been configured correctly, and were as good as they could be. Apart from these Professional activities I am very much interested in creative and different stuff. For me Success is Passion + Enthusiasm. If I am interested in something then I will do it until I get success.