{"id":310,"date":"2011-04-13T10:03:33","date_gmt":"2011-04-13T08:03:33","guid":{"rendered":"http:\/\/blog.asym.dk\/?p=310"},"modified":"2011-04-13T10:03:33","modified_gmt":"2011-04-13T08:03:33","slug":"the-problem-with-test-documentation","status":"publish","type":"post","link":"https:\/\/www.asym.dk\/index.php\/2011\/04\/13\/the-problem-with-test-documentation\/","title":{"rendered":"The problem with test documentation"},"content":{"rendered":"

The agile manifesto<\/a> explicitly values \u201dworking software over comprehensive documentation.\u201d In test, this means that actual testing is valued over test documentation. I would have put it this way: Focus is on the quality of the product<\/em>, not on the quality of the documentation <\/em>of the product.
\nWe can probably all agree that it’s more fun to test and explore <\/em>software than writing documentation. But it would be too <\/em>radical, if we skipped writing documentation at all!
\nI think, however, that we testers should be more critical about the documentation we actually do produce, and that we should look for ways to improve <\/em>the documentation we’re making.
\nThe problem with documentation is not that too much time is spent writing it instead of actually testing the product. The problem is that the quality of the documentation is often just not good enough.
\nMost organizations have standards for test documentation and require their testers to write specific types of documents based on mandatory templates.
\nTemplates are generally a good thing, but they can be problematic if you limit your writing process to \u201dfilling in the gaps.\u201d A good document contains useful information to the reader, so the most important step in the writing process is finding out what information is actually needed.
\nNot all sections of a template can be equally useful in all contexts (or useful at all), and very often you need to document things which there has not been left space for in the template.
\nBut, finding out what to document is not trivial. Basically, it requires that you know the context of the project you are working on. Determining context can be difficult if you are new on a project, but asking questions can give you answers which will help you define <\/em>the context.
\nHere are some questions, which I find useful:<\/p>\n