Test Design Specification
"We have to write a TDS, that's pronounced 'tedious'."
If test engineers are going to insist on designs from developers, then we
can be no less strict with ourselves. The TDS should be the first place
a new tester on the project can go for an overview of a test package. If
you have more than one test package, then you need a TDS for each one.
The ANSI/IEEE standard 829-1983 describes every kind of test documentation
that you could ever want to create. Using the whole standard is
almost certainly overkill for anything but a safety-critical application, but
every Quality Engineer should read the 829 standard once in their life.
IEEE publishes collections of their standards. I've found the Software
Engineering (ISBN 1-55937-442-X) collection to be very helpful as a
reference. You probably won't use it very often, but the standards are
handy to have around when you're starting a new project, just to get
some ideas. One copy for the group library is a Good Thing (tm).
A TDS should include:
- a unique title for the document
- overview of what features (aspects of the product) are tested by this suite
- what testing methods will be used
- specific test coverage information. If each test is a discrete item, then
list each test. If the test is more of a system-driver, then describe what
conditions it will detect, and any runtime conditions that might be needed
to do that (command line options, environment settings, etc.)
- pass/fail criteria. I usually phrase this part of the specification like
a proof statement, "Show that when X, then Y and not Z."
Because in testing you generally can only prove incorrectness, it is good
practice to state both positive and negative assertions.
Copyright 1998 Anne Powelllast update 3/8/98