Lessons learned in software testing – an experience report

12 April

In the google group Software Testers New Zealand, a discussion thread was posted about testers favourite testing books. One of the main books mentioned in Lessons learned in software testing.

Cynthia, a tester based in Auckland New Zealand wrote this great experience report using the book Lessons learned in software testing (quoted verbatim with permission).

“On 9 April 2010 08:33, Cynthia wrote:
It seems like everyone is recommending Lessons Learned in Software Testing! I do too. I have it on my desk and dip into it quite often.

I thought I would give an example of it being useful to me in a practical way. Yesterday I found a bug, quite late in the development. It was quite an obvious one too, once you’d seen it. But it took me ages to “see” it.
I was kicking myself for not seeing it earlier and thought I’d review how I missed it for so long, so to refresh my mind and give a different focus I glanced through the chapter “Thinking Like a Tester”.

Wow, there it was, Lesson 41 – “When you miss a bug, check whether the miss is surprising or just the natural outcome of your strategy”.

I realised that my strategy had been a bit “off”. The function I was testing was to provide some mathematical and date information to our client’s customers. I’d spent ages making sure the dates and calculations were correct.
But I hadn’t asked the right question – what was the reason our client wanted to give their customers this information? What was the problem they wanted us to solve for them by providing this function?

The bug was that calculation results were being presented in different numerical formats in different places – as 3-decimal places, like 2- decimal places and as integers. They were all correct. But they looked confusing, especially when rounding came into play.

And one of the problems our client wanted us to solve was to reduce the number of phone calls at their Call Centres from confused customers. (This was not documented in their Requirements, but had been discussed informally).

So I finally “saw” that this correct data didn’t solve their problem when it was presented that way.

Now I know that I need to add into my strategy for each new bit of  functionality that I work on – always ask the question “What is the real problem we’re trying to solve here?”

Does anyone else have stories about how their favourite testing books help in real life?

What a fantastic experience report – thank you for sharing Cynthia and thank you to the authors of Lessons learned in software testing – Cem KanerJames Bach and Bret Pettichord.