I love documenting things – quite possibly a little too much if I’m honest. I’m not though, a fan of bureaucracy, of having to fill out endless forms and reams of unnecessary documentation. Now I know that sounds more than a bit contradictory, let me explain.
There are two positives that I like about documentation. First is that it allows me to pass information onto someone else, or multiple someones at the same time. It forces me to be clear, with no ‘um’s or ‘err’s and allows me the time to think through what I’m saying before having to say it. I usually find that just the process of writing down how I’m going to test an application or change, helps me to understand it better.
Second is that for documents as deliverables, once read they can be approved. An approval (should) indicate that the recipient has read and understood what you have written and that they either accept or agree with what you’ve said.
Earlier in my career I was introduced to these documents as something to ‘cover my back’, an insurance policy against things going wrong. If and when a bug escaped testing I could theoretically point to my Test Plan, or my reviewed Test Scripts and say that as everyone had read and approved what I was going to do, and no-one had pointed out the omission at the time, then I couldn’t be held at fault by those same people for the omission.
Nowadays I have more confidence in my work. Through experience I miss less (although there will always be bugs that slip through the net – no software application can ever be certified as completely bug free). Now I find that my documentation serves a slightly different purpose.
Technically it still works as an insurance policy, but I’m less worried about having to use it as such. Now I use my Test Plan and Scripts to ensure that other members of the team have interpreted the requirements and specifications of the application, in the same way that I have. The documentation is a test in itself, but a test that allows me to prevent some defects before they arise. This not only saves time and money but actually reduces bureaucracy as these defects which are not raised, no longer have to be tracked, resolved, retested and reported on.
As with everything else, documentation and approvals have to be treated in context. I find that for small changes requiring a day or two of testing, that a single A4 sheet can capture all the information needed, with detailed scripts attached as an Excel sheet if necessary. Larger projects have a Test Plan that is formally approved before Scripts are written (which are then usually approved verbally as part of a short meeting with the developer).
As for who needs to give that approval, I follow the same guidelines as with processes in my earlier post. At the minimum you need an approval from the developer providing their deliverable (the code) to you, and one from the user, to whom you are eventually delivering a tested application to. That list might be expanded or slightly altered depending on the context, but it’s where I start.