Being a writer makes me a better tester

This weekend, I’ve left the kangaroos and beaches behind for the mountains and red rock of Durango, Colorado.  I’m participating in the Writing-About-Testing peer conference being organized by Chris McMahon. In an effort to keep the organization cost and logistics light & easy, there are only 15 people.  We all write a blog or write presentations for conferences and are software testers.

At the beginning of this year, one of my predictions for 2010 was that software testers would begin to take writing skills more seriously.  I hope that this conference is a means to that end goal.  One of the unspoken skills in testing is our power to communicate.  I can spend all day long finding problems with an application, but what happens if I don’t have the skills to let someone know or clue someone in as to why they need to care?  Testers need good writing skills because:

• We must be able to concisely state what is going wrong in a defect report, especially in the summary line.  I’ve been reading the book, “Don’t Make Me Think” which is about usability testing, but one of the points rang true for writing defects:  humans like to scan.  This makes defect titles especially important.  I’ve actually blogged this point before because I liked what the book How We Test Software At Microsoft had to say about the subject
• We use persuasive writing anytime we’re writing a communication to developers in an effort to convince them of the need to fix something we feel is especially important.  Persuasive writing is a skill unto itself.  My father is an attorney and has made a career out of persuasive writing.
• Writing out tests or explaining how we’ve tested is an especially difficult and necessary task.  If you work in an environment where you are testing something that is under intense scrutiny, then this must be doubly important.  I consider writing tests adjacent to technical writing because we have to explain in very specific terms what we are trying to do, what happens when we do it and why we are trying to do that in the first place.

My writing experience at work involves each of the three points above and more.  If you’d like to see some examples of my writing, you can check out the Atlassian bug reports I’ve written thus far.

Although I keep time constraints in mind, I agonize over the title of every single bug and the repro steps I record probably much more than I should.  When I am describing my tests or writing test objectives, I make every effort to be extremely precise.  My bonus for this effort is that I am always finding new words I can use to describe the features I am testing and the testing that I do.   Am I a nerd if this makes me happy?  I frakking hope so!

Here’s a little known fact about myself:  I competed in a spelling bee for charity when I was in my twenties.  I participated with some co-workers from my job.  I remember that my team took home a ribbon other than first, but I don’t remember exactly what our placement was.  I do remember a conversation that I had with someone else on my team.  We must have spent 20 minutes or so talking about words that we like.  My challenge to every reader of this blog whether you are involved in testing or not:  find a new word and use it to make your own daily writing more descriptive and informative.

If I’m lucky you’ll leave me a comment and tell me about it.  I want to know about your new word, because I’d also like to use it ;)