Someone asked this morning on the MoT site about the relative importance of documentation in testing. “Do we have to spend so much time documenting our tests? It’s so time-consuming: can we do without it?”
If the application you are testing is only ever going to be used once by one person for a completely trivial purpose and never used again, then no documentation is required. In every other instance, some sort of documentation will be needed:
- When users report bugs in production but no-one who worked on the app is still with the company;
- When version 2 needs to be developed but the devs who built version 1 have left the company;
- When users need help or support in the ordinary operation of the app (traditional test scripts are actually very good for helping to create Help files or a wiki);
- When a third party (a client, a regulator, a lawyer, the police, the Government) requires evidence of tests performed or some other tangible guarantee of “quality”;
- When a user blames the app for something bad happening and escalates their complaint to:
- Your CEO, or
- a court of law; or
- When something happens in real life (on a scale of 1 to 10 where 1 is “everybody is laughing at your company” and 10 is “somebody died”) and your company is blamed for it in the media.
These are the times when you will be thankful for your test documentation. I know, I’ve seen all of these (though fortunately, on the last one, my personal involvement was around a 5). Risk analysis will help companies and managers take a reasoned decision on just how much documentation is essential to create and retain. If your risk on the last one is a 10, then be prepared for a lot of printing which you hope no-one will ever have to look at again.