In our earlier post, we made discussion on “When test cases should be written? Information objectives, & Tests Intended to expose defects”. Now we shall discuss about “Test Specification and Test Case Template”.
OVERVIEW
A test design specification defines the approach for testing, test techniques to be used, test case design methods to be used, test environment, etc. Test specifications are documented in the test plan. The test case specifications should be developed from the test plan and are the second phase of the test development life cycle. The test specification should explain “how” to implement the test cases described in the test plan.
A test suite is a framework that provides for a way of grouping test cases. A test suite may consist of test cases to test a specific functionality. For an example a test case for testing a specific user interface (or web page) can be grouped/ formed together to form a test suite. Each test suite and its test cases should be uniquely identifiable. A test case contains a description of the test that needs to be conducted on a system. A test case is reusable and may be included (when desired) in one or more test suites.
PURPOSE OF THE TEST CASE DOCUMENT
The Test Case document documents the functional requirements of the test case. The intended audience is the project manager, project team and testing team. Some portions of this document may on occasion be shared with the client/user and other stakeholder whose input or approval into the testing process is needed.
TEST SPECIFICATION ITEMS
Each test specification should contain the following items:
Description: Describe the test case and the individuals involved in the testing. Include diagrams depicting the interaction between individuals and the different elements being tested.
Preconditions: Describe the preconditions for the test case. A precondition is the state of the system that must exist before a test case can be performed.
Post Conditions: A post condition is a list of possible states the system can be in immediately after a test case has finished.
Test Case Identifier: A unique name or number.
Purpose: What features are being tested?
Reference Reference to specifications and design documents have to be provided.
Input: It consists of input data and/ or actions. Input data may include data items to be entered online or data records in a file or database to set up or data items to be input from the interface of some other software systems. Input actions include keyboard or mouse actions for navigation and control necessary for online interaction.
Output: Output consists of output data and/ or outcome. It consists of messages, reports, etc, that would be output on completion of the test case. It describes reaching a specific state, for instance successful completion of a transaction.
Environment List specific hardware, software, and network configuration that needs to be setup for the test.
Procedure: It describes the steps for the test setup, test starting, test executions, results logging, and test stopping, etc.
Constraints/Restrictions: Any constraints on performing the test cases.
Dependencies: What tests have to be executed before this on and what if the program fails them?
Feature- Pass/Fail: A method or criteria that describes under what circumstances a feature can be considered as “Passed” or “Failed”
SAMPLE TEST CASE TEMPLATE
Test Case Template: Here is a sample Test Case template.
| TestCase id | TestCase Name | TestCase Description | Test Steps | TestCase Status | Test Status (P/F) | Test Prority | Defect Severity | ||
| Step(s) | Expected | Actual | |||||||
Conclusion: Depending on complexity of the software system and the level of testing, some or all of the items stated above might be included in a test case template for recording test case design.
In our future post we’ll discuss “Types of Test Cases: Formal and Informal Requirement Based Test Cases”.
