How to create good test case template

Testcasetemplatefor those who are using or would like to implement the Use Case modeling technique.
"Effective system testing requires a concrete and testable system-level specification. A system specified with use-cases provides much of the information necessary for system testing: ... the collection of use-cases is the complete functionality of the system." [Ivar Jacobson ]

The purpose of this lesson is to show a creation process of a test case template. Often, we create it in the wrong way, because we use the wrong field types, and this, in turn, increases the execution and maintenance process time.

Inthis lesson I will review what works in testing and what doesn’t. I will then take the working pieces and fit them together into one template.

I presume that you have already read an article or a book about using the "Use Case" modeling technique.
If you haven’t you can find articles by searching the Web, you can read "Writing Effective Use Cases", a book by Alistair Cockburn, or you can see my recommendations in the end of this lesson.

Pay attention to the extended Use Cases that can be the source for the TC’s.
Extended Use Cases includes:

Business life cycle Use Case
Supplementary specification with non-functional requirements that has:
Table with all external operational variables
Relative frequency of each operation
Performance requirements
Useful for testing UML diagrams
If you would like to read a book about creating TC – my suggestion would be to read "Introducing Software Testing: A Practical Guide to Getting Started" by Louise Tamres, 2002. In this book you will find a descrīption with examples of creating test cases from use cases.


The information below was taken from accepted and identified sources and can be used for better understanding of my descrīption. This information is necessary because some terms have various meanings in software testing, and I will therefore provide them to avoid misunderstanding.

The golden rules of software testing defined by Glenford J. Myers, [The Art of Software Testing, 1979]

Testing: run program with intent to find an error

Test case (TC) A set of test inputs, executions, and expected results developed for a particular objective.


Test Procedure. A document, providing detailed instructions for the [manual] execution of one or more test cases. [BS7925-1] Often called - a manual test scrīpt.

Test suite. A collection of test scrīpts or test cases that is used for validating bug fixes (or finding new bugs) within a logical or physical area of a product. [H. Q. Nguyen, 2001]

The test case descrīption can be either documented manually or store in the test repository of an automated testing tool suite. If the test cases are documented automatically, the format and content will be limited to what the input forms and test repository can accept. [D.J. Mosley 2000]

In our case we assume that test cases must be documented manually.

Use Case (UC) A descrīption of a set of sequences of actions, including variants, that a system performs that yields an observable result of value to an actor. [UML guide by G. Booch, 2001]
O8d+Sc+c:d~257506In order to select the fields that we will use in our template, let us first identify all possible field choices for the TC:
Project name and test suite ID and name51Testing
Use Case Name (name is usually an action like: Create the)
Version date and version number of the test cases
Version Author and contact information
Approval and distribution list
Revision history with reasons for update
Other sources and prerequisite information
Environment prerequisites (installation and network)
Test pre-conditions (data created before testing)

TC name
TC number (ID)
Use Case scenario (main success scenario, flow, path, and branching action)
Type of Testing (i.e. functional, load, etc.)
Objectives
Initial conditions or preconditions
Valid or invalid conditions
Input data (ID, type, and values)
Test steps
Expected result
Clean up or post conditions
Comments
---------------------------------------------------
Actual results (passed/fail)
Date
Tester
Type of machine
Type of OS etc.
Build release
Label name
Date of release

1. Select all fields that will be used in the Test Log document. From my experience, MS Excel is the best for a Test Log. The following fields are usually used in a test log document, but these fields sometimes mistakenly appear in the test case template.

Actual results (passed/fail)
Date
Tester
Type of machine
Type of OS
Build release
Label name
Date of release

2. Now select all fields that belong to the test suite and do not depend on small details. We will assume that for each use case, we will create a number of test cases in a separate test suite document. This information can be provided in the beginning of the test suite document:

Project name and test suite ID and name
Use Case Name (name is usually an action like: Create a…)
Version date and version number of the test cases
Version Author and contact information
Approval and distribution list
Revision history with reasons for update
Environment prerequisites (installation and network)
06Test pre-conditions (data created before testing)
Other sources and prerequisites information
Clean up or post conditions

3. Choose all the necessary fields for the TC template from the remaining list:
TC name
TC number (ID)
Use Case scenario (main success scenario, flow etc.)
Type of Testing.
Objectives
Initial conditions or preconditions
Valid or invalid conditions (use the word Verify for valid conditions and Attempt to for TC with invalid data. This will help simplify verification and maintenance)
Input data
Test steps
Expected result
Comments

Let us choose only the necessary fields and combine some information like TC number, type of test, and project name in one field of template.
Remember: Adding additional fields to the template increases the amount of work to create and maintain the test suite. The project cost raises as well. Keep in mind that the same rules apply to the test suite and a test log document.
Test suite name; TC name; TC number (ID); type of testing;
Use Case scenario (main success scenario, flow etc.)

Objectives
Initial conditions or preconditions
Valid or invalid conditions (when it is possible, begin your descrīption with the word Verify for valid conditions and input data and Attempt to for invalid. This will help you to simplify verification and maintenance of TC’s.)
Input data (ID, type, and values)Test steps
Expected result


If you plan to use automation testing tools in the future, please review the following steps:
Perform. setup
Perform. thetest
Verify the results
Logthe results
Handle unpredictable situations
Decide to stop or continue the test case
Perform. cleanup


I can’t resist to remind you Cem Kaner’s good practices of designing TC’s before showing the samples of templates. (More detailed descrīption of creating a good TC may be the topic of a separate book.)
An excellent test case satisfies the following criteria:

• Reasonable probability of catching an error

• Exercises an area of interest

• Does interesting things

• Doesn’t do unnecessary

• Neither too simple nor too complex