What
Test design specification and test case specification are prescribed in IEEE829:1998 Standard for Software Test Documentation. IEEE829 is an attempt to date collate together all the various test documentation and standardise them.

Test Design Specification is written to show which test cases are to be included in the test case suite..

The Test Case Specification is at the individual case level. The document details how a particular case will test a requirement. Note a requirement may be tested by more than one test case. Conversely a test case may cover more than one requirement.

Of course the need for such documentation is not universally accepted. For instance, companies implementing the Rational Unified Process (RUP) might decide that, this level of ceremony is not necessary in their development cycle. If they do decide it is necessary, it might grow as development passes through the phases, inception or construction. However if they are following the Rational prescriptions they are likely to be using Unified Modelling Language UML

More information on IEEE829:1998 is available. A copy of the overall test plan for this site is also viewable.

Why?
Two reasons. Firstly for the documentatary process. Thus anyone can see what is to be tested and how. After the event it can be used for auditing purposes. This might be the case in safety critical software or that requires regulatory approval. An example is medical monitoring software.

Secondly, for the focus it brings to the test process. Many test phases miss this stage out, or do not follow through thoroughly on the documentation.However they run the risk of missing important test cases or not testing requirements.

A negative aspect is that it takes a large amount of time. Additionally the amount of documentation can seem onerous and overboard. Thus in many test programmes, people just start writing tests without forethought.

Who?
In an ideal world the test case specification documents would be drawn up by a team of test analysts. A senior analyst would draw up the Test Design Specification. These would then be seamlessly passed on to a team of test engineers and test technicians to actually execute the test suite.

"In an ideal world". How we laugh!. In the real world, the roles of test analyst and test engineer are just rolled into one. An individual tester will often decide which tests to run, against which requirements (if the organisation maps tests back to requirements. He or she will then proceed to execute the tests themselves.

Where?
Usually within the development team and at their offices. However if the organisation is using the RUP or an agile methodology they migh draw these up (if they do at all) in conjunction with the customer or other stakeholders, at their own site.

When?
In a traditional waterfall cycle the specifications would be drawn up as the development was taking place. Ready for the test phase at the end of the development cycle. Now that the waterfall is out of fashion, this is seen as a high risk strategy.

The worst case scenario (quite common) is that the documents are drawn up, using an expensive process. They are then left to gather dust. As the project continues, changes are made to the requirements, but the test spec's are ignored.

How?
The Test Design spec should have in the document, which features to be tested and success/fail criteria. Criteria for determining input values for tests are laid out. The input values themselves are not detailed.

For a test specification, the following are needed:-
 input values and existing data.
 the predicted outcome and any change in the state of the software.
 any special procedures.

The documents need to be up to date, so that they mirror the requirements. Thus everyone can be see what is to be tested and how, at any given time.

For further information, check out some of the books below. Also numerous websites have info on IEEE829 and other standards. Coley Consulting has some informative pages.