As per IEEE Standard 610 (1990), a test case is defined as follows:
“ 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”.
Test contains the information about what is being tested (a specific requirement), how it will be tested (steps in detail), pre-requisites, data and expected results.
Test Case design happens in the third stage of Software Testing Life Cycle (STLC).
What we are trying to achieve when we run the test case?
The primarily objective of test is to find the defects. Even for simple systems, there exists thousands of tests. Due to time constraints, testers usually use various design techniques in order to expose the maximum number of defects with minimum number of test cases. These techniques will be explained in detail on upcoming blog posts.
More importantly the number of defects and their criticality are two major factors that decides the ship/no- ship decision of a software product.
Now let’s look into the format of a test case document.
The one which commonly used are having below mentioned fields.They are
- Test Case ID
- Test Case Description
- Step description
- Expected Result
- Actual Result
- Test Type
- Requirement ID
- Created By
- Creation date
- Executed By
- Date Of Execution
Test Case ID:
This is the unique id which represent the test.
Test Case Description:
This field will describe the functionality which we are going to test.
In order to execute the test, there are certain conditions which needs to be met.These conditions provided in the pre-condition field for every test.
These are detailed step by step instructions executing as part of a test case run.It simply shows how we are going to test certain functionality (or tell the tester what to do in each step).
The steps should be short and accurate. It acts as a guide for tester while execution.
An efficient test does not exceed more than 15 steps. Test case with more than 15 steps are always difficult to maintain.Having said this, it is also not good to write too many actions in a single step.This will often confuse the people who test.
Also in the case of failed test, it is difficult to identify the root cause if we have executed multiple actions in a single test step.
This field represents the expected result of the test step.
This field represents the actual result of the test step.
Usually this field represents the pass/fail. If the test case has not executed, then the status will be Ready / Not Executed.Sometimes this can be in Blocked status too.
This represents the type of the test (eg: manual, automation etc.)
This is the requirement ID that the test case traces to.
The name of the tester created the test.
The date of creation of test.
The name of the tester executed the test.
Date Of Execution:
The date of execution of the test.
This field records the various comments or additional information if any.