QA Plan > Test Suite > Test Case Format

Process impact: This reference page documents the format of test cases and gives tips on writing test cases. You can copy and paste the sample test case into your test cases file. This file itself should not be edited to hold specific test cases.

This test case format is suitable for manual system test cases.

Each test case should be written in enough detail that it could be given to a new team member who would be able to quickly start to carry out the test and find defects.
TODO: Copy and paste this test case template as many times as needed in your test cases document. Give each test case a unique id.
One-Column Test Case Format

unique-test-case-id: Test Case Title

Purpose: 1-3 SENTENCES
Preconditions: PRECONDITION
Test Data:
VARIABLE = {VALUE1, VALUE2, VALUE3, ...}
VARIABLE = { x | DEFINING-CONDITION }
VARIABLE = { DESCRIPTION OR LINK-TO-VALUE-SOURCE }
Steps:
  1. visit STARTING-POINT
  2. STEP
  3. STEP
  4. STEP
  5. verify EXPECTED-RESULT
Notes and Questions:
  • NOTE
  • QUESTION

Two-Column Test Case Format

unique-test-case-id: Test Case Title

Purpose: 1-3 SENTENCES
Preconditions: PRECONDITION
Test Data:
VARIABLE = {VALUE1, VALUE2, VALUE3, ...}
VARIABLE = { x | DEFINING-CONDITION }
VARIABLE = { DESCRIPTION OR LINK-TO-VALUE-SOURCE }
Steps:
Test Input Expected Output
visit STARTING-POINT EXPECTED-SCREEN-CONTENT
STEP EXPECTED-FEEDBACK
STEP EXPECTED-FEEDBACK
STEP EXPECTED-RESULT
Notes and Questions:
  • NOTE
  • QUESTION

Test Battery Format

TOPIC-NAME Test Battery

Test ID Summary Expected Results Comments
UNIQUE-TEST-ID-1 PURPOSE, PRECONDITIONS, STEPS, AND TEST DATA. SPECIFIC-EXPECTED-OUTPUT NOTES and QUESTIONS.
UNIQUE-TEST-ID-2 PURPOSE, PRECONDITIONS, STEPS, AND TEST DATA. SPECIFIC-EXPECTED-OUTPUT NOTES and QUESTIONS.
UNIQUE-TEST-ID-3 PURPOSE, PRECONDITIONS, STEPS, AND TEST DATA. SPECIFIC-EXPECTED-OUTPUT NOTES and QUESTIONS.
UNIQUE-TEST-ID-4 PURPOSE, PRECONDITIONS, STEPS, AND TEST DATA. SPECIFIC-EXPECTED-OUTPUT NOTES and QUESTIONS.
General comments: COMMON CHARACTERISTICS OF ALL TESTS IN BATTERY. QUESTIONS and NOTES.

Test Case Attribute Values

Purpose One to three sentences that briefly explain the purpose of this test case. This should have enough detail that another team member could understand it without reading the detailed steps. If this becomes too long, break the test case up or put more information into the feature descriptions.
Preconditions Test case preconditions are conditions that are assumed to be true before the start of the test case. Using preconditions helps keep the test cases maintainable because common initial steps need not be repeated in several test cases.
Test Data List of variables and their possible values used in the test case. You may list specific values or describe value ranges. The test case should be performed once for each combination of values. The possible values of each variable are written in set notation.
Steps

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. This is usually only specified 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 into specific pages should be part of the steps of the test.
enter FIELD-NAME [as VALUE] [in SCREEN-LOCATION]
Fill in a named form field. VALUE can be a literal value, the name of a variable defined in the "Test Data" section, or a descriptive phrase. The FIELD-NAME itself can be omitted when the UI field for the given 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-OR-BUTTON" [in SCREEN-LOCATION]
Follow a labeled link or press a button. The screen location can be a predefined panel name or English phrase. This step should usually 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 specified 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.
perform TEST-CASE-NAME
This is like a subroutine call. The tester should perform all the steps of the named test case and then continue on to the next step of this test case.

Every test case must include a verify step at the end so that the expected output is very clear. A test case can have multiple verify steps in the middle or at the end. Having multiple verify steps can be useful if you want a smaller number of long tests rather than a large number of short tests.

Notes and Questions Any notes that help explain the test case or relate it to the development process, and any questions that arise while writing the test case.

Further Information

For more information on advice, see:

Company Proprietary
Copyright © 2003-2004 Method Labs. All rights reserved. License terms. Retain this copyright statement whenever this file is used as a template.