Test Cases
Test Cases
A test case documents a test, intended to prove a requirement.
The relationship is not always one-to-one, sometime many test case are required to prove one
requirement. Sometimes the same test case must be extrapolated over many screens or many
workflows to completely verify a requirement. There should be at least one test case per
requirement however.
Some methodologies (like RUP) specify there should be two test cases per requirement a
positive test case and a negative test case. A positive test case is intended to prove that the
function-under-test behaves as required with correct input and a negative test is intended to to
prove that the function-under-test does not provoke an error with incorrect input (or responds
gracefully to that error).
This is where the debate about what to script, and what not to, really heats up. If you were to script
separately for every possible negative case, you would be scripting till the cows come home.
Consider a 'date-of-birth' field in a software application. It should only accept 'correctly formatted'
dates. But what is a correct format? It is probably possible to generalise this from the requirements
and come up with a single test case which specifies all the acceptable date formats.
But what about the negative case? Can you possible extrapolate all the possible inputs and specify
how the system should react? Possibly, but it would take you forever. To generalise it you could
simply say that the system should produce and error with 'unacceptable input'
I tend to favour the approach that a positive test case implies a negative case.
If your positive case also documents how the software is expected to handle exceptions then it
covers both the positive cases and the negative cases. If your testers are well trained and educated
then they will attempt all the possible input values in an attempt to provoke an exception.
In reality the number of cases depends on the latitude you allow your testers.
Storing Test Cases
There are a variety of ways to store test cases.
The simplest way is in a word-processing document of a spreadsheet.
One of the common form is a TSM or Test Script Matrix (also known as a Traceability matrix). In a
TSM each line item represents a test case with the various elements of each case (see below)
stored in the columns. These can be good for a small test effort since it is relatively easy to track
scripting and execution in a spreadsheet but in larger projects they prove difficult to manage. The
extent to which they actually aid traceability is also questionable since they don't enforce change
control and aren't very good at one-to-many mappings.
In more complex software development efforts a database or specialist test case management tool
can be used. This has the benefit of enforcing a standard format and validation rules on the
contents of the test case. It can also be used to record execution on multiple test runs, produce
reports and even assist with traceability by linking back to requirements in a separate database. It
can also enforce change control and track the history of changes and execution.
26
