Overcoming Illusions on Testing – Part III

This entry (first part http://jarilaakso.blogspot.com/2012/02/illusions-on-testing-part-i-chimera.html and second part http://jarilaakso.blogspot.com/2012/02/reasons-of-illusions-on-testing-part-ii.html) has been on hold for quite a while; mostly because I have been focusing on other things. (I actually changed even the topic because I thought to write about the future later, in the future!) As we are building the Romanian testing community, I have actual work to do and I’m now a father, I didn’t feel motivated enough to keep on writing. The motivation is back and I’m hoping to start adding more posts in the near future. (If you wonder why I didn’t say “I didn’t have enough time”, it’s simply because it’s a lie. Time is a matter if prioritization. We have it, but not for everything.)

I this post, I will be referring to RST quite many times. This is because I like to use examples in my writing and there were fantastic examples in the course. I won’t, however, tell those examples so you don’t lose anything from the experience.

Without further ado, let’s dig in to the topic at hands. So we have seen detailed pre-scripting doesn’t work too well because a) it kills creativity, b) it doesn’t tolerate change too well, and c) people are just not that good in writing detailed instructions. Actually it does work. Just that it doesn’t work for excellent testing, but it works great for invoicing customers and setting up a fake quality assessment done by “even a stranger from the streets”. The latter means the turnover for testers doesn’t matter for the company.

RST has a few exercises around this topic. One was from the tester’s point of view and one from who was trying to write the script for the tester. The exercises are designed to fail with simple answers, which is fantastic from my point of view. So what to do in this case? Firstly, don’t start writing very detailed test scripts for testers. Secondly, to help improve your (data) coverage, you can always ask help from others. Great testers love to help other testers; and in most organizations I have seen, the developers are keen on working with this.

I mentioned in the previous posts that terminology seems challenging for testers. RST has a lot of keywords you should understand. Otherwise it’s hard to follow the discussions. At least James explained all the terms he was using and based on what I have seen for example here http://www.developsense.com/blog/2012/04/all-oracles-are-heuristic/, I am sure Michael is doing the same. The thing with terminology is that you don’t need a word listing for this. What you need to do is to start reading and talking with others and find a common language.

There was an observation earlier that women did better because they had more sense of context in their replies. I understand this easily from a Finnish point of view where we are told that women analyze things while men drink beer, eat sausages and find The Best Way. I could easily see myself fitting in that form still some years ago. How I got out from it? I think it was just a phase actually, but at the end it’s about what kind of people you gather around yourself and what do you do on your free time. I am advocating on reading and writing, but remember that you can get ideas from pretty much anywhere if you keep your eyes/ears open.

Yes, I covered only 3 of the 5 things I mentioned on earlier posts. Why? Because I want you to tell me what you think about them!