Test Cases Template

Release Information

Project:
Internal Release Number: 1.0.0
Release Audience:
General availability release
Customer-specific release: CUSTOMER(S)
Developer release (Internal usage only)
Early access release (Controlled external access)
Attached Worksheets:
Related Documents:
Links to Relevant Standards
Links to Other Documents

Introduction

Why is a Test Case needed?

A Test Case tells us "how" testing is done in contrast to a Test Plan which tells us "why" and "when" to test.

A Test Case is needed to provide a documented, repeatable, stepwise process that always tests a specific software component the same way. If a software defect is discovered during Test Case execution, then the Test Case can be used to receate the problem for the developer. When a developer corrects a defect discovered by Test Case execution, the same Test Case can be repeated to confirm the correction.

The test cases should be written in enough detail that they could be given to a new team member who would be able to quickly start to carry out the tests and find defects.

================================================================================

FTPOS-01.0: Module X - Happy Path (positive)

Use Cases Covered: Design Architecture Design - Architecture
Actor:
  • ...
Testing Goal:
  • Validate ...
Success Criteria:
  • ...
Test Environment Setup:
  1. ...
Test Tools:
  • ...
Test Data: ...
Test startup procedure:
  1. ...e
Test closedown procedure:
  1. ...
Testreset procedure for rerun:
  1. ...
Step # Step Action Expected Results Actual Results
Start ... ... ...
001 ... ... ...

================================================================================

FTNEG-01.0: Module X - Happy Path (illegal xyz format defense)

Use Cases Covered: Design Architecture Design - Architecture
Actor:
  • ...
Testing Goal:
  • Validate ...
Success Criteria:
  • ...
Test Environment Setup:
  1. ...
  2. ...
Test Tools:
  • ...
Test Data: ...
Test startup procedure:
  1. ...
Test closedown procedure:
  1. ...
Testreset procedure for rerun:
  1. ...
Step # Step Action Expected Results Actual Results
Start ... ... ...
001 ... ... ...

Suggested test step action verbs

Each step can be written very tersely using the following keywords:

login [as ROLE-OR-USER]
Log into the system with a given user or a user of the given type. Usually only stated explicitly when the test case depends on the permissions of a particular role or involves a workflow between different users.
visit LOCATION
Visit a page or screen. For web applications, LOCATION may be a hyperlink. The location should be a well-known starting point (e.g., the Login screen), drilling down to specific pages should be part of the test.
enter FIELD-NAME [as VALUE] [in SCREEN-LOCATION]
Fill in a named form field. VALUE can be a literal value or the name of a variable defined in the "Test Data" section. The FIELD-NAME itself can be a variable name when the UI field for that value is clear from context, e.g., "enter password".
enter FIELDS
Fill in all fields in a form when their values are clear from context or when their specific values are not important in this test case.
click "LINK-LABEL" [in SCREEN-LOCATION]
Follow a labeled link or press a button. The screen location can be a predefined panel name or English phrase. Predefined panel names are based on GUI class names, master template names, or titles of boxes on the page.
click BUTTON-NAME [in SCREEN-LOCATION]
Press a named button. This step should always be followed by a "see" step to check the results.
see SCREEN-OR-PAGE
The tester should see the named GUI screen or web page. The general correctness of the page should be testable based on the feature description.
verify CONDITION
The tester should see that the condition has been satisfied. This type of step usually follows a "see" step at the end of the test case.
verify CONTENT [is VALUE]
The tester should see the named content on the current page, the correct values should be clear from the test data, or given explicitly. This type of step usually follows a "see" step at the end of the test case.
Company Proprietary
Copyright © 2003-2004 Jason Robbins. All rights reserved. License terms. Retain this copyright statement whenever this file is used as a template.
Copyright © 2005 Jerry Everett, Ken Everett, and Ray McLeod. All rights reserved. License terms. Retain this copyright statement whenever this file is used as a template.