Designing a Test Case Format was among
the first tasks given to me when I joined my first job as a Quality Analyst. I
searched the internet and found many ready-made formats. But as I have said in
my previous post that test case format varies from company to company depending
on the type of solution they offer and also on their development process
models, etc. Because of these reasons, I was not able to get a format which suits
my company. So I decided to make a new format. It was a heck of a job but at
last I was able to make a format which suits my company and its development
process.
Anyways, that’s a different story, but
all these stuff inspired me to create an Ideal Test Case Format & upload it
on my blog. The sole reason to do so is that it will/may help the new comers in
the Quality Assurance/Control field if in case they face the same situation as
me.
IDEAL
TEST CASE FORMAT
TC ID :
|
Date :
|
Project Name :
|
Module Name:
|
Author :
|
Tester :
|
Objective :
|
|
Pre-Requisite :
|
|
Steps :
|
|
Input Data :
|
|
Expected Results :
|
|
Actual Results :
|
|
Status :
|
|
Bug ID :
|
|
Remarks :
|
This
format can also be converted & managed in Excel format. Lets discuss the
fields in brief:
TC ID :- The unique test case id
Date :- Date of creating test case
Project
Name :- Name of the project
Module
Name :- Name of the module to be tested
Author :- Name of the person who created the test
case
Tester :-
Name of the person who tested
Objective :- The objective of the test case (for eg.
Verifying & validating the login page)
Pre-Requisite :- The pre-satisfied condition for the test
case to be executed
Steps :- Steps to be taken to execute the test case
Input
Data :- The data input valued for the
test case
Expected
Results :- The expected results
Actual
Results :- The actual results achieved
Status :- Pass/Fail
Bug ID :- Bug Id (Is the test case failed)
Remarks :- Remarks (if any)
Excellent.....
ReplyDeleteThere must be a section for cleanup(){ } parts for cleaning the test environment after the test.
ReplyDelete