5 Questions With Iain McCowatt

Iain McCowatt was kind enough to spare the time to answer my questions and explain his views on automation, zombiesm and why he gets called Liam...

1) What's your testing background and why is testing your passion?

My background is hard to pin down in that it's been quite varied. Once I even tested in order to reverse engineer a product rather than to assess its quality. That was fun! Now, apart from a couple of years with a software vendor, I’ve tended to test in Enterprise IT.

Most recently I’ve been working with large banks. I’m something of a serial obsessive; I love to get heavily into something, to learn it inside and out…and then move on to something new. Until I fell into testing, I thought that was a personality defect, now I see it as a blessing. Testing, at its heart, is all about learning and discovery. It never fails to provide something new to learn, something new to obsess about. 

2) You did a great series of posts on "idiot scripts" - does this mean you were once a zombie tester? Why is it that people associate testing with scripts and do you think that will ever change?

A zombie? Not likely. In many ways I was fortunate in in my development as a tester. For most of my early years I had a mandate to test and free reign over how to do so. It was only in recent years, on moving to the management of outsourced testing services, that I encountered something different: a belief that one can manage testing like a sausage factory, with measurable, repeatable processes and drones turning the handle of the machine. That’s not how I see testing, and you know what? It doesn’t work. 

And yes, I see signs of hope. Increasingly I’ve been meeting clients who have simply had enough of the broken promises, who want real testing, who value passion, creativity and intelligence. Change is coming.

3) You've also done a number of interesting posts on automation - do you find that there is also "idiot automation" and that people aren't thinking about their approach to it?

That’s a nice way of putting it. There are three major idiocies that really bug me when it comes to automation. 

First is why we automate. Lots or organization behave as if test automation is a universal good, an end in itself. So they end up managing automation as if it is somehow separate from testing. I’ve met teams of automation engineers who never talk with the testers they should be serving, testers who are discouraged from contributing to the automation conversation. That’s nonsense: automation serves no purpose whatsoever unless it helps testers to solve testing problems.

Next are the unnecessary constraints that we often put on what we automate and how we do so. There seems to be a tendency for people to over-generalize solutions. They’ll solve a problem in one situation, and then assume that the answer will be useful in another situation: even if the problem is completely different. So we end up with dumb-ass assertions that “all automation must be justified by R.O.I.”, “tests must be fully automated”, or “automated tests must be idempotent”. These all come at a cost: blindness to the real opportunities to automate, and weak, compromised, automation. When people solve the wrong damned problem it shouldn’t come as any surprise that they fail.

Then there is the complete misunderstanding as to the costs of automation. This isn’t just about tangible financial costs, but what you lose by automating. Tools may be able to do certain tasks better than people can, but their focus is narrow. By attempting to remove the intelligence, intuition and even unpredictability of people from the testing equation you choose to ignore all manner of potential problems. Don’t get me wrong: I’m in no way anti-automation, in fact much of my work involves figuring out ways to use tools to help testers, but I believe that we need to get better at understanding exactly what tools do, and don’t do, for us.

OK, rant over. No doubt I’ll blog some more on this subject in the future.
Next?

4) It can be confusing for a newbie to testing - the scripts vs exploratory arguments, do you need to know how to code, QA vs QC vs Tester etc - what advice would you give to a newbie?

In a word: learn. Learn how to learn. Learn to love learning. Be ready, willing and able to learn whatever you need to learn in order to best serve your project as a tester. When I say learn, I don’t mean class-learning or book-learning, I mean learning by doing: taking ideas about testing and making them your own, changing, breaking and remaking them until they’re in your bones. And when you think you’ve learned enough, be ready to throw it away and try out a different way of thinking about the problem you’re working on.

5) What books are you reading at the moment and why are you reading them?

At the moment I'm reading What Computers Can't Do (Dreyfus). That's informing some of my current work in test automation. I'm also interested in the role of intuition in testing, which has led me to Working Minds (Klein, Crandall, Hoffman) which is a great reference for a set of techniques that can help you to figure out the heuristics that experts use to solve problems.

Bonus Question) How many people miss out the other 'i' in your name and does it annoy you?

Ha! That's the Scottish Gaelic spelling, the Cyclops variety is an English derivation. Once upon a time miss-spellings bothered me, but I'm used to it now. It's amusing how three-vowels-in-a-row can throw people into a dyslexic spin. 

I've had just about everything: Iam, Lain, Liam...