Test documentation describes the artifacts created before, during, and after testing for the purpose of communicating with stakeholders to solicit feedback, to capture your intended approach to provide guidance for your team, to provide actionable information for business decision makers, and to record your findings for due diligence.

Requirements for test documentation differ markedly between different software development methodologies. For example, contrast the Agile manifesto's preference for "Working software over comprehensive documentation" (which for some Agile teams leads to an executable specifications approach) with a methodology such as Prince II which requires the production of a number of documents. Approaches that are documentation heavy will probably require tools for managing the documentation.

There is an IEEE standard for testing documentation, IEEE 829-2008 - note that as the abstract for the 1998 version notes, "A set of basic software test documents is described. This standard specifies the form and content of individual test documents. It does not specify the required set of test documents."

Further advice on test documentation is available in the following article:

...the thinking tester or test manager should decide what is essential to the building of her real product in each given circumstance. Rather than manufacturing acres of continuous prose in boilerplate documents that almost no one reads anyway, think about the minimum set of artifacts you need to:

Capture your significant thoughts and ideas
Guide (yourself or others) in moving critical work forward
Inform your stakeholders so they have opportunities to provide feedback
Demonstrate due diligence for the record (where this is required)

Fiona Charles, Tester Know Your Product, StickyMinds.com

It's also worth considering: are you primarily interested in documenting what you intend to test, or what you did test?

history | show excerpt | excerpt history