On Software Testers Speak Up Meeting #1 I met a colleague tester that is responsible in his organization for writing user technical documentation. At that time, I was strongly against idea that testers should do that activity, because testers are responsible for testing the system. So my advice to the fellow tester was to convince his project manager that testers should stop writing project documentation.
But his response was that testers in his organization are the most qualified for writing user documentation, and user documentation is one of the most important artifacts of the agreement with the customer.
They had a situation when customer database administrator dropped production database, instead of applying a database patch (stupid mistake according to every database administrator that knows its craft). User documentation that explicitly stated how database patching should be done, played significant role when customer wanted to blame testers organization.
Because of that information I had been thinking for several weeks after testers speak up meeting. For testers organization, customer documentation is integral part of their product, not just the system itself!
So I decided to ask for help. Twitter was my tool of choice.
I know about Michael Bolton and his testing magic for a long time. I met him at the STP2010 in Las Vegas where I attended his Rapid Software Testing course. Great thing about him is that he is doing free consultancy. Here is his answer.
And immediately all become clear. I had an emotion about testers writing user documentation. That emotion got me thinking about fellow tester problem. I asked for help, and advice was immediately clear: "As a tester, your are glue in your organization". That means ask a lot questions about every line that you put in user documentation. When you write user documentation, interact with others, ask questions about documentation stuff that bothers you. Don't be just a dummy that writes it down.
Today, there was also one important Michael tweet that connects with his advices about writing user documentation:
Labels: karlo, learn testing
