Test case structure
1. What is a test case:
IEEE Standard 610 (1990) defines test case as follows:
“(1) A set of test inputs, execution conditions, and expected results developed for a particular objective,
such as to exercise a particular program path or to verify compliance with a specific requirement.
such as to exercise a particular program path or to verify compliance with a specific requirement.
“(2) (IEEE Std 829-1983) Documentation specifying inputs, predicted results, and a set of execution
conditions for a test item.”
conditions for a test item.”
In Simple terms the test case can be defined as below:
A Test Case is set of preconditions and steps to be followed with input data and expected behavior
to validate functionality of a system.
to validate functionality of a system.
In simple words a test case is brief description of what to test and how to test
2. Objective of writing test cases:
Objectives behind writing and executing the test cases are:
· Find the defects in software products
· Verify that the software meets the end user requirements
· Improve software quality
· Minimize the maintenance and software support costs
· Avoid post deployment risks
· Compliance with quality processes
· Help management to make software delivery decisions
3. Structure of the test case:
The main objective of the test is to find defects in the application or system.
To achieve this test cases should be written well and should have the below details
To achieve this test cases should be written well and should have the below details
1. Test case number
2. Test case name
3. Test case description
4. Pre conditions
5. Test data/Input data
6. Step name
7. Step description/action
8. Expected result
Test case number: A unique number to identify the test case
Test case name: The name of the test case is summary of the test objective
typically written in one line.
typically written in one line.
E.g. For example, if we take the requirement is like below
“Employee creates a document and the manager can either approve it or reject it.”
For the above requirement, possible test cases could be
1. Approve the document by manager
2. Reject the document by manager
Test case description: The test case description is generally short description of the test
objective written in two or three lines.
objective written in two or three lines.
E.g. For the test case, Approve the document by manager, the description could be as below
Document is created by an employee and is sent to manager for approval, manager approves the
document.
document.
Pre conditions: Pre condition is a condition or predicate that must always be true just prior to
the execution of a particular test objective. In other words Pre-Condition is the term itself
indicates the Pre existing set of the condition that should be satisfied to perform a particular task.
the execution of a particular test objective. In other words Pre-Condition is the term itself
indicates the Pre existing set of the condition that should be satisfied to perform a particular task.
E.g. for the above test case example, pre condition is document should be created by employee
and it should be sent for approval
and it should be sent for approval
Test data/Input data: Test Data are data which have been specifically identified for use in tests.
It is the data required to test the test case. Input data is to verify that a given set of input
to a given function/program produces some expected result. Input
can be valid data or invalid data.
It is the data required to test the test case. Input data is to verify that a given set of input
to a given function/program produces some expected result. Input
can be valid data or invalid data.
E.g. In the above test case example, the test data can be employee user ID and password,
manager user ID and password, document details sent for approval, environment details. All this
type of data constitutes part of test data/input data.
manager user ID and password, document details sent for approval, environment details. All this
type of data constitutes part of test data/input data.
Step Name: The sequences of actions are given a number to test the correct behavior/functionalities,
features of an application called step name. It is like Step 1, Step 2 Step 3….etc. It can also be called
as order of execution number.
features of an application called step name. It is like Step 1, Step 2 Step 3….etc. It can also be called
as order of execution number.
Step Description: Simple description of the action performed on the application to get some
expected output from this action.
expected output from this action.
Expected Result: It is the expected output from the system or application for the action
performed on it.
performed on it.
E.g. For the test case in example, below could be the complete test case structure when we put
all together
all together
4.
Test case types:
Test cases are written in a positive perception and also in a negative perception. So Test cases could
be positive test cases or negative test cases.
be positive test cases or negative test cases.
Positive Test case: Testing conducted on the application in a positive approach to determine what
system supposed to do is called positive testing and the test cases written for this purpose are positive test cases.
system supposed to do is called positive testing and the test cases written for this purpose are positive test cases.
E.g. Check Login functionality with valid inputs.
Negative Test case: Testing a software application with a negative perception to check what system not
supposed to do is called negative testing and the test cases written for this purpose are negative test cases.
supposed to do is called negative testing and the test cases written for this purpose are negative test cases.
E.g. Check Login functionality with invalid inputs.
--------------------------------------------------------------------------------------------
Basics of Writing Test Cases:
#1. If test scenarios were all about, “What we are going to test” on the AUT – the test cases are all about
“How we are going to test a requirement”.
“How we are going to test a requirement”.
For example, if the test scenario is “Validate the Admin login functionality” – This would yield in 3 test cases (or conditions) –
Login (successful), Login-unsuccessful when incorrect username is entered, Login-unsuccessful when incorrect password
is entered. Each test case would in turn have steps
to address how we can check a particular test condition is satisfied or not.
Login (successful), Login-unsuccessful when incorrect username is entered, Login-unsuccessful when incorrect password
is entered. Each test case would in turn have steps
to address how we can check a particular test condition is satisfied or not.
#2. The input to create a test case document is FRD, Test scenarios created in the earlier step and any other reference
documents if present.
documents if present.
#3. The test cases documentation is an important deliverable by the QA team and is shared to BA, PM and other teams,
when done for their feedback.
when done for their feedback.
#4. Work is divided among the team members and each member is going to be responsible for creating test cases for a
certain module or a part of a certain module.
certain module or a part of a certain module.
#5. Just like with the test scenarios, before we begin Test case documentation, a common template has to be agreed upon.
Practically anything can be used to create test cases. The 2 most often used choices are MS Excel and MS word.
Practically anything can be used to create test cases. The 2 most often used choices are MS Excel and MS word.
#6. The MS word template looks something like this:
#7. The Excel template could look like the following:
#8. From the above two templates it can be observed that the fields (or the components) that make up for a
test case are the same, the only difference is the way in which they are organized.
test case are the same, the only difference is the way in which they are organized.
So, as long as there is a field for each of the type of information to be included in a test, the format of the
template does not matter. However, my personal favorite happens to be the excel sheet, because it is easy
to expand, collapse, sort, etc. But again, choose any format that works best for you.
template does not matter. However, my personal favorite happens to be the excel sheet, because it is easy
to expand, collapse, sort, etc. But again, choose any format that works best for you.
Fields in Test Cases:
Let us take a moment, to observe the fields that are part of a test case.
Test case Id and Test case description – these are the generic ones.
The other fields can be explained as follows:
a) Precondition - state of the AUT (the state in which the AUT needs to be for us to get started)
b) Input - data entry steps. For these steps it is important to note what kind of input info is required – Test data
c) Validation point/trigger/action – what is causing the validation to happen? (Click of a button or toggle or the
link access. Make sure there is at least one validation point to a test case- otherwise it is all going to be data
entry with nothing to look for. Also to ensure that we have enough modularity, try not to combine too many
validation points into one test case. 1 per test case is optimum.)
d) Output - expected result
e) Post condition - This is additional information that is provided for the benefit of the tester, just to make the test
case more insightful and informative. This includes an explanation about what happens or what can be expected of the
AUT once all the test case steps are done.
b) Input - data entry steps. For these steps it is important to note what kind of input info is required – Test data
c) Validation point/trigger/action – what is causing the validation to happen? (Click of a button or toggle or the
link access. Make sure there is at least one validation point to a test case- otherwise it is all going to be data
entry with nothing to look for. Also to ensure that we have enough modularity, try not to combine too many
validation points into one test case. 1 per test case is optimum.)
d) Output - expected result
e) Post condition - This is additional information that is provided for the benefit of the tester, just to make the test
case more insightful and informative. This includes an explanation about what happens or what can be expected of the
AUT once all the test case steps are done.
See Also => Sample test case template.
---------------------------------------------------------------------------------------------
Source - http://erp-testing.blogspot.com/2012/04/test-case-structure.html
http://www.softwaretestinghelp.com/writing-test-cases-from-srs-software-testing-qa-training-day-4/
Home visits Individual / Group / Online classes in English / Sinhala / Tamil.
Sample Projects/Assignments Exam Papers, Tutorials, Notes and Answers will we provided.
Call +94 777 33 7279 | eMail itclasssl@gmail.com | Skype ITClassSL
Join Facebook Fan page https://www.facebook.com/pages/Itsoftware-Classin-Srilanka/380768322055448
Join Yahoo Group http://groups.yahoo.com/neo/groups/itclasssl/info
