How to write about software testing

Based on the number of requests I’ve had to write articles recently, there seems to be a big demand for testers who can write  well about software testing.  I’ve been asked by a few different companies to write articles on their behalf. Sometimes I’ve been asked to write posts for someones’s blog. I’ve only done that once with Quck Testing Tips which was a lot of fun. But generally, I find it hard enough to be inspired on my blog, let alone writing for some-one elses!

I thought putting down what helps me, might help a few testers out there. Writing well is a great skill for a tester to have. Think of all those persuasive bug reports you will be able to write.  Its also a great way to consolidate and  refine your thinking. (A great read on this topic is chapter is Maria Hammeren’s chapter entitled “writing as a method of reflection”  in the book Dialogue Skill and Tacit Knowledge.)

1) Write from the heart.

Personally, I’m only motivated to write when I have something I feel passionate about. Thats a good thing because you can create a bond with the audience. But it can be unhelpful too if other people are relying on you to write something.

Perhaps passionate is the wrong word, but  writing posts that resonate with you reach out in some way to your audience. Perhaps its the choice of words you use, I’m not sure, but your readers will pick up on your sincerity.

2) Be yourself

That is, don’t try and be the expert unless you have personal knowledge about what you are writing. In practical terms, avoid trying to sound more experienced than you are. Be honest about your experiences.If you do write on a topic (say automation) in a authorititive manner, you had better be able to back it up with fact and substance.

An excellent example of someone who does this  well is Michael Bolton. I believe in what he writes because he cites references and backs up his statement with examples and facts.

Nuff said.

3) Give yourself Permission

I have James Bach to thank for pointing this one out in a tweet*. Its so true.
Give yourself permission to write your thoughts. They do count and they are of value. Trust me on this one. A great example of some-one who does this is Lanette Creamer. I admire they way she is so forthright with her ideas.

*tweet info with nod to Michael Bolton for supplying it

[quote style=”boxed”]As a teacher this is key: Permission givers http://bit.ly/9qnyOt (thanks @jerryweinberg, for the link, and the permission)[/quote]

4) Proof Read

I tend to write posts 2 or 3 times before I let them loose on the world. Seriously. This is how I work.

a) Write down sentiment anyhow, anyway. Don’t worry about what it looks like
b) At this point I  feel free to explore, sometimes I stray from my originally intended topic to the point where I have a compeltely new article.
c) Read the post (try reading it aloud), and rewrite it, move paragraphs around to get a better flow. Cut out paragraphs that prevent a nice flow through the post
d) Take a break, do something different
e) Come back re-read the post, edit it. check for spelling then send it

A trap you can fall into though is over proofing. If you feel really strongly about something, and you leave it to the next day, you may chicken out and decide not the send it. Sometimes posting in the heat of the moment is a good idea. (Hey I never said writing was clear cut!)

5) Give credit

If you get an idea based on a book you read, share that. If something inspires you, share the link.

6) Be Original

No-one wants to hear trite stuff that parrotts what others say. Believe me. Make your content your own. If you are talking about a hot topic, try and put your own personal spin on it. What are your thoughts on it? Don’t parrott a thought leader, their stuff is far better than yours anyhow.

7) Be Precise

Often its a struggle to come up with a precise word that reflects exactly what you want to say. But please, don’t be lazy about it. The english language is diverse and there’s bound to be a word that aptly describes what you want. Use a thesaurus if you have to, or do what I do and wait until the right word comes to you. Your readers will appreciate it.

8 ) Why do you write?

Here is Bernard-Henry Levy on his view on writing. Great stuff. In particular what drives him to write is interesting:

[quote style=”boxed”]I am not writing to be loved. There is as much pleasure to being hated as being loved. I write in order to convince. In order to win. In order to change, even just a little, the world. I recently launched an appeal on Twitter supporting those attacking the official websites of the Tunisian regime. An intellectual calling for hacking doesn’t happen very frequently, and there is a stir. I am happy that it succeeded. I care about being heard.[/quote]

Whats your driver? Is it your ego, is it SEO ratings or is it something else? I started writing to get ratings for my website, but now I write for the pure joy of writing, because I get a kick out of crafting a beautiful piece of work.

9) Practise

The only way you are going to get any good at writing is by practicing.  How are you going to practice, well thats up to you, but writing a blog is a good start. Don’t aim for perfection, just get out there and write something. I will never forget my first blog post. It was the equivalent of hello world! (I wish I still had it, I would link it here)

Well, thats it. Nearly

There is one more thing.

If you are serious about writing skype me on charretts. I offer free coaching and I’m willing to include writing in that scope, as long as its to do with testing.

[By the way, when I’m talking about writing, its mostly in the context  of articles, blogs etc.]


 

Discovering Big Trak

Recently, I’ve been reading up on how we approach and report on solving problems. One book recommended to me was Exploring Science by David Klahr.

There’s lots in this book.  Khlar performs experiments in his “Discovery Lab” where participants are observed solving and reporting problems.  He uses a robotic toy called Big Trak. Its a self propelled, self contained toy that can be programmed to move around the floor.

Khlar programs a function (its a repeat function) on the toy. He then asks the participants to figure out the function and report how the program operates.

Its been an interesting read and some of the dialogue that happens during hypothesis and testing fits in nicely with the IM Coaching I’m giving. Its one of the reasons James Bach suggested I read the book.

This experiments were performed in the late eighties, so I was quite suprised to see Big Trak’s been sold in my local bookstore.

I immediately grabbed a couple and brought them home.

I handed one out to one of my kids to see if he could figure out how it worked. Here’s the video.

I’m going to incorporate these new robotic toys into my Exploratory Workshop, if I can just work out how to switch off that really annoying beep sound.

Mind mapping your testing strategy

I recently was asked to do a talk on software testing for a group of iPhone developers.  I decided to speak to them at a practical level and talk about how I approach software testing, as I wanted them to understand that there are different ways you can perform software testing other than resorting to heavily documented process and formal test scripts.

As part of my preparation I decided to use FreeMind to create a mind map of some of my testing strategies. Like many in the testing community I find I rely heavily on mnemonics to remember heuristics and oracles. I like Parimala Shankaraiah’s post on the Power of Mnemonics and decided to create something similar but in a mind map form.

Most of the information is not new and has been around the testing community for a while. As I started brain dumping the information, I got really excited about the map. I knew that not only was it helpful for the talk, but for me personally, it provided a great tool to remind me of different approaches I can take to testing. I’ve inserted due credit, but if I’ve left anyone out or got it wrong, please let me know and I can update it.

In fact I’m so thrilled with the results, I’m going to share it. So here it is.

Bug Tracking Tools Explained

Like it or not, all software has bugs.You may not know about them but they are there..lurking in the darkness, ready trip up one of your innocent user who has just gone and purchased your software.

That’s why you employ a software tester. A software tester’s job is to find as many of the bugs and report them to you and the rest of the team before they can do untold damage to you and  your software’s reputation.

You can report bugs in as many ways as there are to communicate. You can write the bugs up in an email, on a piece of paper, in a spreadsheet (see my previous post on spreadsheets). You can even directly speak to the relevant person and directly show them the bug.

Or you can use a bug tracking tool.

So why do you need to track a software bug and whats so great about a bug tracking tool?

Software Bug Workflow

Well, just as a normal bug goes through several stages in its life such as egg, nymph, larvae and finally adult, so to does a software bug go through its own lifecycle or workflow. Redmine the opensource software I use as my online bug tracking tool,  uses the word workflow so I’ll use that term in this post.

Typically a simple bug workflow goes as follows:

Bug WorkFlow

Bug WorkFlow

Where:

new is when a tester creates a bug report

open is when a developer  accepts the bug report as valid

fixed is when a developer indicates that the bug is fixed

tested is when a tester indicates the bug has been tested

closed is when a tester accepts the bug has been fixed and the report is now closed

This is a very simple workflow. Alternatives to the workflow can happen when for example,  bugs are rejected by the developer  or a bug fails test and the tester places the bug back to open state. In fact, it can get quite complicated if you let it.

Most bug tracking tools will let you modify or create your own stages and workflows, but if your new to the concept of a bug tracking tool, its better to select a simple existing workflow and use that for a while to get used to what works for you. Redmine, lets you chose a preexisting work-flow.

A bug tracking tool then allows a tester to create a bug report and monitor its progress as it goes through its workflow

So whats the big fuss? Why not just use a spreadsheet or email?

I’ve personally benefited a lot from bug tracking tools. Here are some ways they’ve helped me.

Benefits of a bug tracking tool

1) Its easy to keep track of one bug, but keeping track of many bugs is hard work. A tool helps you easily find out what bugs are still open, fixed, closed. Bug tracking tools normally allow you to sort and filter your bugs and create reports on the bugs.

2) You can track other stuff about bugs, such as how important they are and who is fixing them. This can help you prioritise which bugs are important and require urgent fixing.

3) You can start seeing clusters of bugs which indicates there may be underlying issues in parts of the code

4) Lots of people can see the status of the bugs, not just the tester and the developer. The overall bug status can be quickly reviewed by many avoiding nasty surprise syndrome (NSS) at the end of development/testing.

5) Sometimes not all bugs are fixed in the current release but will be fixed and tested in a future release. This means long after software release the bugs still need to kept open and tracked. A bug tracking tool ensures that these bugs are not overlooked in the future.

6) A bug tracking tool can centralise information. Often a bug tracking tool can be used to track new features as well as issues and can act as a document repository. Redmine offers many additional features such as document repository and wiki.

7) A bug tracking tool can improve productivity by increasing bug awareness and responsiveness. It is also handy when a project is scattered geographically and works across different time zones.

As I’ve mentioned in previous posts, there are many open source options bug tracking tools out there, so if budget is an issue there is no need to spend a lot of money on an top end commercial tool.

And of course, a tool is only as good as the developer and tester using it and will fail miserably if no one is willing to use it, so perhaps if your thinking of adding such a tool to your testing toolbox, speak to the rest of your team first to find out what they are looking for in a tool.

In search of the ultimate bug tracking tool

As many of you know, I’ve been on the hunt for a bug tracking tool for a while now and I’m glad to say the hunt is over.

I needed this bug tracking tool to meet some key criteria.

1) It had to be easy to install. Startups don’t always have a reputation of up front planning and I wanted a tool I could recomend that was quick and easy to install.

2) It had to be open source. I didn’t want to pay for a bug tracking tool unless I had too. My clients feel the same way.

3) I wanted to embed the bug tracking tool into my website Testing Times and then provide it as a service for my clients who don’t have or want a bug tracking tool.

4) It had to be easy to use and secure. I wanted each client to have access to only their project.

TRAC got the heads up for being opensource, but was too hard to install in comparison to YouTrack, which beat it hands down. YouTrack only provided a temporary license though and I had trouble getting my hosting company to support Apache Tomcat. The effort to install something I may have to pay for later, made me feel it was pointless to pursue.

Tails was interesting and looked great, and if I had to pay for a tool, their pricing structure suited my needs. There is no messy install as it’s a hosted service but that meant that I wouldn’t be able to embed it onto my site.

Practitest had similar issues for me, and also the pay per month/user pricing structure didn’t suit my needs.

I was at a bit of a loss until BHARATH suggested Redmine.

Redmine is an opensource tracking tool that’s easy to install, easy to configure and secure.  It ticked all the boxes and it’s now sitting on my website. You can take a look at it at  http://bugs.testingtimes.ie if you like.

I have created a public project called Testing Times for those who want to investigate a bit further.

The real test of course will be my clients, their reaction and how much they use it.

So a hearty thanks to Bharath and a sigh of contentment from me.