"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 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.

Prerequisites. A preexisting set of conditions and data that should be met to execute a particular step mentioned in the test procedure.

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.

• 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:

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

• Perform setup
• Perform the test
• Verify the results
• Log the results
• Handle unpredictable situations
• Decide to stop or continue the test case
• Perform cleanup

• 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"]

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:

If you are not using Use case modeling technique you can rename Use Case flow field into " Requirement under the Test".

Guidance for creating text in a template.

I'm giving the best advice I have. You have to decide what is suitable for your needs and modify template accordingly.

1. Introducing Software Testing: A Practical Guide to Getting Started Louise Tamres, 2002
2. The Art of Software Testing by Glenford J. Myers 1979
3. Black Box Software Testing -Professional seminar by Cem Kaner 2002
4. Client Server Software Testing on the Desktop and the Web by Daniel J. Mosley, 2000
5. Just Enough Software Test Automation. by Daniel J. Mosley, Bruce A. Posey, 2002
6. 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

Recommended Reading on Use Cases

1. Booch, G., I. Jacobson and J. Rumbaugh, The Unified Modeling Language User Guide., Addison-Wesley, 1999, pp. 219-241.
2. Structuring use cases with goals, by Cockburn, Alistair, Journal of Object-Oriented Programming, 1997.
3. Basic Use Case Template", by Cockburn, Alistair, 1998.
4. "Functional Requirements and Use Cases", by Malan, R. and D. Bredemeyer, 1999.
5. Use Case Action Guide", by Malan, R. and D. Bredemeyer, 2000.
6. UML Specification.

   Alex Samurin has many years of an international experience in system Research & Development, Information Technology, Quality Assurance and testing across various industries. This includes experience with FMS, JIT, decision support and E-commerce systems. He currently performs QA and testing activities on the high security e-business J2EE application in Toronto, Canada.

   He can be reached through his web site http://extremesoftwaretesting.com/

    

    

    

   ---

   ---

   
   
   Extreme Software Testing Main Page
   © 2006 geocities.com/xtremetesting/ and © eXtremeSoftwareTesting.com