Test documentation can be a daunting task if you have just joined a new company or you have been promoted to a new position.

You obviously want to make a difference and ensure that your supervisors know what an excellent job you are doing.

Why? Because they ARE ALWAYS WATCHING…!

In the beginning (2-4 weeks), you will be given benefit of doubt to get your head around the work. But then you have to start showing what you will bring to the position.

Documentation and process will form a major part of your work.

Don’t get stumped by all the jargon and terminology people in software testing use. You are free to make up your own jargon, if you want.

At the end of the day what matters is your processes work to reduce the impact of software defects and the way you approached the testing is better than what it was before you were hired.

So ensuring that your supervisors know what an excellent job you are doing is vital to job security.

James Bach (One of the foremost software test experts in the world) stated in one of his youtube video lectures titled “Buccaneer-Tester- Winning Your Reputation”  that the company his brother John Bach worked for, shipped the entire test team to India without ever informing John. Obviously the decision was made high up in the management hierarchy who have no idea why software test experts are required. They are only concerned with the budget bottomline. The fact that John Bach managed to turn these Indian software testers into this super testers didn’t get noticed. For the upper management, this vindicated their decision to ship the test team to India because….IT WORKS! Not because there was someone to ensure that it worked!

So one of James Bach’s assertion was how to make yourself visible to the administration so that you become essential to the company strategy.

I think documentation and reporting skills plays an important part in making yourself visible to the upper management, that you are making a difference to the company.

So what sort of documentation should you keep? In the videos that I have watched (quite a few), I didn’t get a clear answer. So I went and compiled my own list, based on my own experience:

1. Prepare a document that clearly specifies how the entire test cycle is carried out. Exactly how many weeks each phase of testing involves, how many testers will participate in the testing, how many many test cases will be run per week, how many test environments will be used, what sort of automated tests will be run in each phase and how the projected progress will be tracked. Some people call it Test Plan. Call it anything you want. But this gives an upper level view of the test process. Every Test Manager should prepare this document.

2. Prepare a document which specifies the test environments and what dependencies they must have. For web applications, you simply need cross browser document. But for windows applications, you will need to prepare detailed environment specification so that dependencies are properly installed. For example, your software installation install SQL CE. So to test this, you must prepare a test environment (VM-virtual machine) which doesn’t have SQL CE pre-installed. Otherwise you cannot verify whether your installer installs the pre-requisite or not.

3. Prepare a document with a checklist for each feature of the product. I am assuming that you have prepared test suites to test each and every feature in the software. So this checklist will help you identify if a particular scenario has been addressed or not in your cache of test cases. Remember that there may be a large number of scenarios for certain applications. It is your responsibility as a Test Manager to prepare test cases for those scenarios. Having a checklist that lists down all possible scenarios for a certain feature definitely helps. Use user story, feature spec from developers, your own black box testing and exploratory testing to identify the scenarios.

4. Prepare a document that sets up a process for identifying when the behaviour of an existing feature changes. This prevents a misunderstanding between the developer and the test team. It also safeguards against blame from developers that a feature change has not been tested properly. The clearly defined process informs the test team as soon as the behaviour of an existing feature changes. Test team then go and make necessary changes to the test case steps as well as update related documentation. This helps in identifying why the test case was changed and what this new change involves.

5. Prepare a document that lists down what percentage of the product testing is automated. I have been asked on numerous time to quantify how much of the testing is automated. Having such document helps you answer those questions in a professional manner. Again this boils down to your visibility to the upper management, which will help with your job security.