Test Case Template

Test Outline: This document is written before writing test cases.This is a planning document in which the flows or scenarios are written at a high level. These flows or scenarios are later expanded to test cases, in which they are written in detail.Also the biggest advantage of writing this document, before going to test cases is the 'traceability matrix', where you ensure that the project/feature is sufficiently or thoroughly covered by the individual test cases.

Download the template
Find below the links to download the template in either word format or web page single archive file.

testoutline_template.doc
testoutline_template.mht

Explanation of different sections in the template

Change History: Under this section, you specify, who changed what in the document and when, along with the version of the document which contain the changes.

Review and Approval History: This captures who reviewed the document and whether they Approved the test outline or not. If approved, the reviewer will specify the review comments(if any) to be incorporated in the test outline.There is a review template at the end of the testcase_template.doc, which can be used to specify the comments for test outline also.If the test outline document is 'Not Approved', then either the scenarios mentioned are not sufficient or the scenarios are in a very bad shape(not in a state to be reviewed) etc.

Document References: Any additional documents that will help better understand the test outline document like design documents or Requirements document etc.

Projects Covered in Test Outline: Projects can be features of the product or modules which are covered in the test outline document.

Traceability Matrix: This Matrix is filled after finishing writing all scenarios in the outline.This is to ensure that all requiremnts or features are sufficiently covered by the test cases and none are missing.So you map the requirement or feature and subfeature to the test case that will be covering it. The following IDs uniquely identify the requirements or feature and subfeature.You can add your own IDs based on the need
REQ_ID = Requirement ID from the SRS document
DD_ID = Detailed Design ID from the Detailed Design document

Setup Requirements: Any setup that has to be done in the application being tested, prior to executing this test case, should be mentioned here.For example, if the test case needs certain login IDs with certain settings to begin, which are not created as part of the test case, then such things need to mentioned in this section.

Test Objectives: Specify at a very high level, what the test case is intended to achieve or verify.

Test Case Limitations: Does the test case achieve the above mentioned test objective completely or are there any exceptions?These exceptions need to be specified in this section.For example, test case has to verify 'something' on type A, type B and type X, but because of some reason it could NOT verify that 'something' on type X, then its a limitation.

Test Case Dependencies / Assumptions: Prior to executing this test case, any other test case needs to be run? All those dependencies need to mentioned here.

Process Flow: In this section, we specify at a high level what the flow of the test case is.Suppose there are multiple users in the test case, then a process flow can look like
user1: does something
user2: does something else
user1: does again something
user2: says good bye

Test Outline Table column - 'User': Who has to perform the action. Suppose in a application, there are two roles 'Buyer' and 'Supplier', then user can be those role names.

Test Outline Table column - 'Action': Under Action you specify the following
Flow Name - A high level name given to action performed by the user.Suppose Buyer has to create certain purchase orders in the applications, then the flow name can be 'Create Purchase Orders'
Description - The following things should be mentioned here at a high level
Description of what actions should be performed
What is the type or characteristics of data to be used.
What should be verified or checked after performing the action.

Effort Estimates: In this section you specify the effort needed to write each test case and the effort needed to execute them.