Pro-testing Against Bad Software Quality

Tea-time with Testers

New software testing ezine

The fourth issue of a new software testing ezine called "Tea-time with Testers" was released earlier this week. It is an interesting ezine - especially in that only a total of four issues have been published so far but it has just about the strongest possible support from the top of the testing world. Earlier issues have articles from the likes of Jerry Weinberg, James Bach, Markus Gärtner and so many other great testers from around the world that it is just incredible. In my opinion, that is quite an achievement for such a fresh endeavor. Plus, I feel truly honored to have been asked to participate.

My article is about test cases in agile. I chose that topic because of one particularly active LinkedIn discussion that went on for almost a year. I had considered blogging about my thoughts on the discussion but when Lalitkumar Bhamare (one of the two founders and editors of the ezine) asked me if I would be interested to write an article in the May issue of Tea-time with Testers I happily accepted and decided to share my thoughts in the article instead.

Here is a link to the fourth issue of "Tea-time with Testers". My article starts on page 32.

Self-criticism

I am very critical about what I write in situations like this. It is my first publication in a serious testing ezine, after all. Still, almost immediately after submitting the article to Lalitkumar, I noticed a need for improvements. Specifically in my description of the way I prefer writing test cases. My (poor) excuse is that I finished the article at around 4am the night before it had to be submitted so I was no longer thinking straight at that point. Of course, to be fair towards myself, it was the best I could come up with in such a short time.

Anyway, in addition to what I wrote in the article I would like to add the following:

I call the method iterative because I am basically doing the exact same thing the developers do but with test cases. I only write down ideas for those tests that I feel will be needed during that iteration. I only elaborate on the test cases that absolutely need more information and, like I mentioned earlier, I only write just enough to make the tests useful. I do not wish to hinder any tester's intuition or will to explore by setting up unnecessary rules and limitations. Later on, I will refactor the test cases based on current needs if and when requirements change.

This not only saves me time and effort but it also makes it easier for me to maintain the test cases. Plus, should a new tester join the project later on, it is easier for me to rapidly convey the essence of the test ideas to that person without bogging down his/her learning of the system with minor details that have no relevance to the person yet at that point. Add continous, transparent communication on top of that, which helps prevent misunderstandings, and I am left wondering why did I not realize things could be done this way already years earlier.

By the way, my favorite tea is camomile. I lllove it!