test case

home

Articles

Blog

Books

Tools

Links

FAQ Page

test case

What
"A set of inputs, execution preconditions, and expected outcomes developed for a particular objective, such as to exercise a particular program path or to verify compliance with a specific requirement. After [IEEE,do178b]"
BS 7925-1.British Computer Society Specialist Interest Group in Software Testing (BCS SIGIST)

A group of test cases, covering all the requirements of a component or system is a Test Case Suite.

Why?
The test case is a small building block in the test process. So small, it is easy to forget how fundamental and important it is. The concept of "Test Case" exists to provide an element of structure in the testing process.

The central aims of testing software are firstly, to give confidence that the system's behaviour is as we expect, both functionally and non-functionally.

Secondly to generate useful information about the system or component. The information generated can then be used as a basis for making technical and business decisions.

These two aims, have an inherent amount of trust. Thus, in terms of confidence, we need to make sure that all areas, that might give us cause to lose confidence have been exercised. Following on from this the risk of failure has been mitigated.

Who?
As the "test case" is such an integral part of testing, everyone should be involved at some stage with a case. This could be a unit tester, working on a change of a single line code. The Test manager querying if all the requirements have been covered by test cases. The test analyst drawing up the test design specification.. Developers, responding to a fault raised as a result of a test being run, needs to know what the test involved. Even customers undertaking acceptance testing need to have test cases.

Where?
Everywhere that testing takes place.

When?
Through the whole software development cycle.

How?
The way we create test cases depend greatly on the organisations maturity and attitude towards testing. The important words, in my opinion are process and ceremony. Process is the mechanism through which we arrive at a test case. The concept of Ceremony I have taken from Phillipe Krutchten, Per Kroll. In their book on the Rational Unified Process RUP, they use ceremony to show the reverence with which the development process is undertaken. Thus an organisation that does all its testing on the fly without any documentation has low ceremony. A military communications project where every i and t has to be reviewed by a committee is high ceremony. Kroll and Krutchen recommend this is set on a project by project basis.

An organisation with low ceremony or without a structured process are likely to have the following characteristics in their test cases:- low traceability to requirements, vague documentation, unclear expectatiions of inputs and outputs. Test cases are difficult to replicate, due to the vagueness and use of data.

The opposite is true of the highly structured testing organisation. A typical example is at the higher levels of the CMM and is developing mission or safety critical software. Examples include the military or medical software. The testing programmes need to be available for audit by regulatory authorities or the customer.

Highly developed documentation for a particular test case will include:

*;the initial state of the software under test
*; the input
*; and the predicted outcome.

Additional information may be required:- special steps that are required and data to be existing already.

Most organisations are in between these two extremes. Some documentation, with a degree of ceremony. It is up to the organisation to decide on the appropriate approach for a particular project.