Testers and user documentation

Reading Time: 2 minutes

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.


karlosmid Karlo Smid 


@michaelbolton I met a tester. He doesn’t do testing because he has to write customer documentation all the time. How should I advise him?



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.


michaelbolton Michael Bolton 


@ 
@karlosmid When writing customer documentation, I did plenty of #testing. Often, I found way more bugs than “testers” did.





michaelbolton Michael Bolton 


@ 
@karlosmid So, for your friend: 1) NOTICE that you’re testing. 2) Report problems, give repro procedure, explain /why/ they’re problems.



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:


@michaelboltonMichael Bolton
Published: Shapes of Actions; why #testing is often described by oversimplified modelsbit.ly/usxYU4 #Agile #PMP #PMI #PMOT #PMBOK
 

Read his blog post to further enhance your user documentation writing and questioning skills.



Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather

Notes on Software Testers Speak Up Meeting #1

Reading Time: 2 minutes

Yesterday, we held Software Testers Speak Up Meeting #1. Zeljko Filipin wrote about that event on his blog.
I would like to put some of my notes.
There were 16 people from various companies (200+ employees), and one tester from very small company (Zeljko).
For me It was a great event. How do I know that it was a great event? For that I use my own heuristic:
If discussions on event last for three hours without a break, and people starts topics in a meaningful flow, than that is a great event.
I put some topics on the whiteboard just for start.
We started discussion with question: “Why did you become a tester?”
First issue emerged, testers from big companies have one common problem: they all have to write documentation. I asked two questions: who reads that documentation, and do they mean by documentation word documents?.
Should (and which) documentation must be produced, depends on the company process (not only necessary software development process). But remember, when tester writes Word document, he does not do his job, and that is testing.
Question about requirements specification emerged next. We all agreed that no one have ever got satisfactory requirements specification.
Testing process was next topic, and CMMI come along with that discussion. I briefly explained testing process in my company and how we use mantis as a supporting tool for that process.
How testers cope with the deadlines provoked counter questions: “What is deadline?” and “What should be done by that deadline?” On statement QA is testing I explained that testers are not QA police. Whole organization  should take care about quality. Testers only provide information about product quality.
Testers from big companies all agreed that their software development process does not contain unit testing, TDD, code reviews.

Pizza time had arrived, and I discussed about JMeter. I introduced grinder, by explaining how I am currently using it in order to test the capacity of our new mq broker configuration with Oracle database.

In the end, whiteboard looked like this.

Our plan is to do #2 SpeekUp meeting in two months, this time with some presentations.

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather

Software Testers Speak Up Meeting #1

Reading Time: 1 minute

Pozivamo sve zainteresirane (dakle i software developere) na #1 Software Testers Speak Up Meeting koji će se održati u prostorijama kompanije Ericsson Nikola Tesla, dana 10. studenog 2011 (četvrtak) u 17.30 sati u sobi Hvar.
Cilj druženja je izmjena iskustava, znanja kao i stvaranje zajednice software testera u Hrvatskoj.
Na prvom druženju bi se prije svega međusobno upoznali i popričali o par tema koje bi sudionici odabrali.
Za zagrijavanje, sudionici bi dali svoj odgovor na pitanje: “Što je to testiranje softwarea?”
Neka se čuje glas software testera iz ovog dijela Europe!

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather

Blog that makes software testing interesting and exciting.