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

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]
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. ***************************************

  11. TC name
  12. TC number (ID)
  13. Use Case scenario (main success scenario, flow, path, and branching action)
  14. Type of Software Testing (i.e. functional, load, etc.)
  15. Objectives
  16. Initial conditions or preconditions
  17. Valid or invalid conditions
  18. Input data (ID, type, and values)
  19. Test steps
  20. Expected result
  21. Clean up or post conditions
  22. Comments
  23. ****************************************

  24. Actual results (passed/fail)
  25. Date
  26. Tester
  27. Type of machine
  28. Type of OS etc.
  29. Build release
  30. Label name
  31. 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.

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:



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:

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

Bibliography:

  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

    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://extremetestingsphere.com

     
     
     




    Software Testing Main Page
    © 2006 http://www.geocities.com/xtremetesting/