What's the purpose of Test Documentation?
Last week I went to a testing meet-up where one of the presenters said that he used documentation to defend himself - which really caught my attention. But it also got me thinking. While Test Documentation may be used to defend yourself, surely that is not its purpose.
Why do you write Test Documentation?
Chances are, something along the lines of, “to communicate information” comes to mind.
But what does “communication” really mean?
I think phrases like “strong communication skills” etc are thrown around and misused. According to Meriam-Webster, the definition of communication is: “It is the art or process of using words, sounds, signs or behaviours to express or exchange information….” Scrolling down the page I saw a further definition: “Information transmitted or conveyed” I proceeded to click on the hyperlink that gave me the definition of convey “to make (something) to known to someone” **_We use Test Documentation to make information of the software known to someone. _****_BUT providing test documentation and making information known to someone are NOT the same thing. _**Which leads me to….
Who is your audience?
When I think I about Test Documentation the most important thing is who will be reading this. My approach towards Test Documentation relies heavily on who will be reading the information. This usually boils down to three categories:
My future self**
This is the easiest audience for me to write test documentation for, because chances are, I don’t need to worry about misinterpretation. I write test documentation for my future self when I am testing a feature which may take more than a day - I need this information so that I can look back at it and see what I have already done and how things went.
Technical people such as developers
This either happens when I’m testing a feature or retesting a bug. To this audience, I make an effort to provide detailed information on the links clicked, usernames, database tables and information you can find with the console open.
Business users such as Project or Product Managers
Providing test documentation for this audience is based on the assumption that they are in charge of deciding whether something is ready to go-live and when that is. Here, I make an effort to say what users of the software can and cannot do at its current state.
Above I state what my focus is for each audience. That’s not to say I wont provide technical information to the Business Users or that I wont tell Technical People what the users currently can and cannot do.
One final note
What you write and what is read may not be the same thing
You may provide results of test cases or a mind-map which shows the current state of the software and in your opinion, it shows things are looking pretty bad. But the reader may think otherwise.
Strictly speaking, this might not be a matter of opinion but a reflection of how well a job you are doing as a tester.
When you write test documentation you should ask yourself, “how can I ensure that the reader understands what I am communicating”.