
When I started as a tester I learned that test documentation, such as test plans, needed to gain approval from the Director and could be regarded as a project deliverable. I have learned that this is not helpful and that test documentation should support testing and the development.
I remember that, before testing started, we wrote detailed test plans for each project. This documentation included test plans that conformed to IEE standards and all the documentation was written in Word docs. These plans needed the approval of the director but I am not sure that anyone ever read them apart from the testers. We used the plans to test the new project but getting the directors approval for the documentation was really very important. The testers discussed whether test documentation was a project deliverable as these documents had to be produced for every project and needed the approval of the director. I found that as a project progressed I learned more about the project and that this learning was not included in the documentation as the documentation had already been written. As I explored the functionality I frequently found bugs from tests I ran that were not included in the tests I had written in the test plans.
Now I only create documentation if it helps testing and development. I have learned to have test documentation that supports testing as this way I can better support the development of the feature I am testing. I create test documentation such as mind maps, spreadsheets, decision tables, flow charts and state transition diagrams that help me analyse the features being developed. This type of documentation helps me test and can help the developers, designers and product owners too. I also create test strategy documents for a number of reasons which include that writing the strategy enables me to clarify my thoughts and enables me to share ideas. The test plans I create now are to help me test and to help me collaborate with the other members of my team. Documentation is no longer thought of as a project deliverable. The deliverable is a high quality product and the test documentation helps the team to achieve this.
I have changed my mind about documentation.It should not be about gaining the directors approval or being a project deliverable. Documentation should be about supporting testing and development because that way it can help improve quality.