How to write a good test case

From Apache OpenOffice Wiki
< QA‎ | Testcase
Revision as of 00:35, 27 July 2012 by Adailton (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

A test case in software engineering is a set of conditions or variables under which a tester will determine whether an application or software system is working correctly or not. The mechanism for determining whether a software program or system has passed or failed such a test is known as a test oracle. In some settings, an oracle could be a requirement or use case, while in others it could be a heuristic. It may take many test cases to determine that a software program or system is considered sufficiently scrutinized to be released. Test cases are often referred to as test scripts, particularly when written. Written test cases are usually collected into test suites.


What is test case?

IEEE Standard 610 (1990) defines test case as follows:

"(1) A set of test inputs, execution conditions, and expected results developed for a particular objective, such as to exercise a particular program path or to verify compliance with a specific requirement.

"(2) (IEEE Std 829-1983) Documentation specifying inputs, predicted results, and a set of execution conditions for a test item."


According to Ron Patton (2001, p. 65),

"Test cases are the specific inputs that you'll try and the procedures that you'll follow when you test the software."

Boris Beizer (1995, p. 3) defines a test as "A sequence of one or more subtests executed as a sequence because the outcome and/or final state of one subtest is the input and/or initial state of the next. The word 'test' is used to include subtests, tests proper, and test suites. Good Test Cases Copyright © Cem Kaner 2003. All rights reserved. Page 2


Bob Binder (1999, p. 47) defines test case:

"A test case specifies the pretest state of the IUT and its environment, the test inputs or conditions, and the expected result. The expected result specifies what the IUT should produce from the test inputs. This specification includes messages generated by the IUT, exceptions, returned values, and resultant state of the IUT and its environment. Test cases may also specify initial and resulting conditions for other objects that constitute the IUT and its environment."


In practice, many things are referred to as test cases even though they are far from being fully documented.

Brian Marick uses a related term to describe the lightly documented test case, the test idea:

"A test idea is a brief statement of something that should be tested. For example, if you're testing a square root function, one idea for a test would be 'test a number less than zero'. The idea is to check if the code handles an error case."


Test case element

A test case template can be found QA/Testcase/Template

Elements in test cases that are intended for publication within a conformance test suite. Defining and providing element has proved helpful in a variety of areas during the test development process. It also helps those who run the tests to verify the conformance of their implementations. For example, metadata can be used to:

  1. track tests during the development and review process
  2. filter tests according to a variety of criteria (for example, whether or not they are applicable for a particular profile or optional feature)
  3. identify the area of the specification that is tested by the tests
  4. aid in the construction of a test harness to automatically execute tests


  • Identifier

Test case title: The name by which the test case is formally known.

  • Description

Purpose: A brief explanation of the reason the test case was developed.

Description: A representation in words of the nature and characteristics of the test case.

Test objects: An unambiguous feature or module is being test

Preconditions: Conditions that must be met before this test is executed.

SpecRef: Identification of the portion of the specification tested by this test case.

SeeAlso: A list of references to relevant materials. It can help to clarify the intent or usefulness of the test case.


  • Feature

Product: Which product is being test.

Function Area: What feature/function/model is being test.


  • Info

Execution method: Will this case be executed manually or automatically

Requirement: What feature developing activity request this test

Focus: Generally, if test failed what user's activity will be impacted

Platform: The test will be executed in which operation system

Release: The test is able to be executed from which software version.


  • Revision

Version: An identifier that allows one to distinguish between different revisions of test case.

Status: One of an enumerated list of values that can be used to track the state of a test at a given time.

Date: Update test case in which date.

Contributor: The individual or organization that contributed this test case.

Comments: A brief explanation of what part of test case has been update.


  • Steps

Steps: Steps to carry out the test, and data that are needed for the test execution.

Expected Results: The results that a conformity implementation is expected to produce when this test case is executed.


With all above input clearly, your test case will be well organized and easy to read. With an easy understand test case everyone can execute test efficiently and smoothly. With an efficient test case test quality will be improved indeed.


A sample test case for your reference QA/Testcase/Sample

Personal tools