creation process of a test case template.

The purpose of this tutorial 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 tutorial 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 and tutorials 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, [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 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. [H. Q. Nguyen, 2001]
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. [D.J. Mosley 2000]
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. [UML guide by G. Booch, 2001]

In order to select the fields that we will use in our template, let us first identify all possible field choices for the TC:
1. Project name and test suite ID and name
2. Use Case Name (name is usually an action like: Create the)
3. Version date and version number of the test cases
4. Version Author and contact information
5. Approval and distribution list
6. Revision history with reasons for update
7. Other sources and prerequisite information
8. Environment prerequisites (installation and network)
9. Test pre-conditions (data created before testing)
***************************************
10. TC name
11. TC number (ID)
12. Use Case scenario (main success scenario, flow, path, and branching action)
13. Type of Software Testing (i.e. functional, load, etc.)
14. Objectives
15. Initial conditions or preconditions
16. Valid or invalid conditions
17. Input data (ID, type, and values)
18. Test steps
19. Expected result
20. Clean up or post conditions
21. Comments
****************************************
22. Actual results (passed/fail)
23. Date
24. Tester
25. Type of machine
26. Type of OS etc.
27. Build release
28. Label name
29. 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.
o Actual results (passed/fail)
o Date
o Tester
o Type of machine
o Type of OS
o Build release
o Label name
o 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:
o Project name and test suite ID and name
o Use Case Name (name is usually an action like: Create a…)
o Version date and version number of the test cases
o Version Author and contact information
o Approval and distribution list
o Revision history with reasons for update
o Environment prerequisites (installation and network)
o Test pre-conditions (data created before testing)
o Other sources and prerequisites information
o Clean up or post conditions
3. Choose all the necessary fields for the TC template from the remaining list:
1. TC name
2. TC number (ID)
3. Use Case scenario (main success scenario, flow etc.)
4. Type of Testing.
5. Objectives
6. Initial conditions or preconditions
7. 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)
8. Input data
9. Test steps
10. Expected result
11. 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.
1. Test suite name; TC name; TC number (ID); type of testing;
2. Use Case scenario (main success scenario, flow etc.)
3. Objectives
4. Initial conditions or preconditions
5. 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.)
6. Input data (ID, type, and values)
7. Test steps
8. Expected result
If you plan to use automation testing tools in the future, please review the following steps:
o Perform setup
o Perform the test
o Verify the results
o Log the results
o Handle unpredictable situations
o Decide to stop or continue the test case
o Perform cleanup
[D.J. Mosley 2000/2002]
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
[Cem Kaner " Black Box Software Testing -Professional seminar " 2002 section 8 "Test case design"]
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.
[Cem Kaner "Black Box Software Testing -Professional seminar " 2002 section 23 "scripting"]
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:
XXX. XXX.- XXX
Name of the project (abbreviation) Type of testing Unique number.
If you are not using Use case modeling technique you can rename Use Case flow field into " Requirement under the Test".
Blank template:
TC # UC flow
Objectives


Preconditions Input (maybe for different conditions) Expected Results



Guidance for creating text in a template.

TC# Proj.Fun.-010 UC flow 2.2.2 main success scenario (Basic, alternative, exception flow name or function under test)
Objectives Try to use:
-Verify that (for TC with valid data)
-Attempt to (for TC with invalid data)
Preconditions Input Expected Results
-The system displays…
-User has successfully…
-The system allows…
-The user has been authenticated… (For different conditions where applicable)
-The user selects…
-The user enters… -Expected result may be copy-paste from Use Case but it depends on how the Use Case is written.
I'm giving the best advice I have. You have to decide what is suitable for your needs and modify template accordingly.