I was recently interviewed for a cool article on test automation by Elisa Gabbert. It was posted this week on SearchSoftwareQuality.com. My favorite quote:

Kelly was less cautious. "As for bleeding-edge tools, I think it's all fair game," he said. "I often find that I'm writing automated tests from scratch in Ruby or Java, but for the bulk of the automation work there are many great tools available (both commercially and open source)."

I just like being classified as "less cautious." It makes me smile. I know that I'm about as conservative as they come when it comes to tool selection, so it's ironic that I'm the loose cannon.

I will say, I was surprised when I read Scarpino's comment that unit test tools might not be ready for prime time. I don't think I could disagree more. I think the tools are great and when I find developers who aren't doing developer testing - they loose points with me. That is of course provided they work in a language and project context where it's easy to do that testing.

I like the article. Glad I was asked to be involved.

A while ago I answered the following question on SearchSoftwareQuality.com’s Ask The Software Quality Expert: Questions & Answers.

I am a test engineer working on Windows applications. I do manual testing. In the agile world, when things keep on changing every now and then, it's difficult to get well-defined requirement specifications from developers, which disturbs test case writing, traceability, and test execution. What would be the right strategy to make sure we are delivering quality product?

Here is a clip from my answer:

One of the organizing principles for the book Testing Computer Software was how to test without well-defined requirements specifications that always change. Similarly, Lessons Learned in Software Testing has many tips and tricks for dealing with just that problem. If you're not familiar with those two books, I highly recommend them. Aside from those deeper views on the topic, I might share the following.

I've never worked anywhere where the requirements were well defined and/or locked down. I don't really know what it would look like if I did. Some of the project teams I worked with thought they had well-defined requirements, but once development and testing started, that often turned out not to be the case. My perspective has never been to operate under the assumption that I would get requirements that I could trust as the sole oracle for my testing.

You can find the full posting here.