Why is it so important to consider your software test documentation requirements? Well for starters we all spend a significant amount of time writing software test documents. So getting the content and pitch wrong means wasting a significant amount of time and effort. Here are 7 questions that will help you get the pitch and content right for your software test documentation.
1. Should I document what to test or how to test it? Step by step how to test it documentation can be useful where you hand tests over to 3rd parties. If your test team know what they are doing, try saving some effort and just outline what needs to be tested.
2. Is the product design changing? The level of detail in your test documents should increase as the design gets closer to completion. When the product you are testing is still changing then detailed test documents will probably need changing later too.
3. Will you deliver your documents to a third party? If you deliver your documentation to a customer then you should consider any standards they demand. If your documentation is only needed internally then think about meeting a lower level of requirements in order to achieve your objectives.
4. Who is going to read your test documentation? If you find yourself writing test documentation that no one seems to read then you should question why you write it. Where you are handing your test documentation to other testers to read then pitch your test documentation with that audience in mind.
5. Will your documentation facilitate delegation? Where you use test plans to coordinate and drive the test project you will obviously need to write with a level of detail. Where you are writing and running test cases for yourself then consider saving some effort and just outline the testing.
6. How much maintenance are you prepared to invest in? The more detailed your test documentation the more time you need to reserve for maintenance. Where your product design is changing rapidly you should consider putting time aside later to update your documents.
7. How will you track document changes? Where you provide your documentation to a third party, or a customer, you should consider a strict version control regime. At a minimum your test documents should be identifiable with unique ids, versions and titles.