How to create good test case template
Test case template for 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."
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.
In this 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 description 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 description. 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,
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 execution of one or more test cases. Often called - a manual test script.
Test suite. A collection of test scripts or test cases that is used for validating bug fixes (or finding new bugs) within a logical or physical area of a product.
The test case description 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.
In our case we assume that test cases must be documented manually.
Use Case (UC) A description of a set of sequences of actions, including variants, that a system performs that yields an observable result of value to an actor.
In 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 name
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)
Test 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 description 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 the test
Verify the results
Log the 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 description 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 things
• Neither too simple nor too complex
• Not redundant with other tests
• Makes failures obvious
• Allows isolation and identification of errors
Scripting:
An Industry Worst Practice
COMPLETE SCRIPTING is favored by people who believe that repeatability is everything and who believe that with repeatable scripts, we can delegate to cheap labor.
The following are samples of templates with the fields that we previously chose.
For each unique test case number, I chose the following format:
XXX.XXX.-XXX
The description is
It is table of 3 columns
XXX.
Name of the project (abbreviation)
XXX.-
Type of testing
XXX
Unique number.
If you are not using Use case modeling technique you can rename Use Case flow field into " Requirement under the Test".
Bibliography:
Introducing Software Testing: A Practical Guide to Getting Started Louise Tamres, 2002
The Art of Software Testing by Glenford J. Myers 1979
Black Box Software Testing -Professional seminar by Cem Kaner 2002
Client Server Software Testing on the Desktop and the Web by Daniel J. Mosley, 2000
Just Enough Software Test Automation. by Daniel J. Mosley, Bruce A. Posey, 2002
The following articles from StickyMinds.com
Challenge of Test Case Maintenance By Sreeram Kishore Chavali
Developing test cases from use cases By Ross Collard
Step By Step Test Design By Kathleen A. Iberle
How to Write Better Test Cases by Dianne L. Runnels
UML training
http://www.intelinfo.com/newly_researched_free_training/UML.html
Recommended Reading on Use Cases
Booch, G., I. Jacobson and J. Rumbaugh, The Unified Modeling Language User Guide. Addison-Wesley, 1999, pp. 219-241.
"Structuring Use Cases with Goals", by Cockburn, Alistair, Journal of Object-Oriented Programming, 1997. http://members.aol.com/acockburn/papers/usecases.htm
"Basic Use Case Template", by Cockburn, Alistair, 1998. http://members.aol.com/acockburn/papers/uctempla.htm
"Functional Requirements and Use Cases", by Malan, R. and D. Bredemeyer, (functreq.pdf) 1999.
"Use Case Action Guide", by Malan, R. and D. Bredemeyer, 2000.
UML Specification. http://www.rational.com/media/uml/resources/media/ad970803_UML11_Summary.p
页:
[1]
