Reducing the Cost of Testing - Interview with Catherine Powell

The book How to Reduce the Cost of Software Testing is now out - a great effort by a bunch of testers to put a book together and get it published.

Wanting to know more about how and why they did it, I interviewed some of the authors.
First to respond was Catherine Powell

It should be a short book - do less of it and/or hire cheaper testers. Why is there a whole book about it ?

You're right, it is easy. Except for all the ways in which it's really hard. Our original title for the book was "How to Reduce the Cost of Software Testing Without Mindlessly Shooting Yourself In the Foot". (It was too long.)

The point is that there are consequences of our decisions, and the book is about making informed choices that reduce the cost of testing without unacceptable side effects.

To take one of your simple examples: we could reduce the cost of testing by laying off all the testers. This would absolutely drive the costs of testing down. It would also result in buggy, unpredictable software that your customers don't like. Your development costs go up - fewer features per developer hour - because they're working on bugs. Your revenue goes down because people don't really want to buy buggy or hard to use software. Your cost of hosting goes up, because you don't know how the system scales, and you have to just increase everything. In the end, you're worse off than if you'd kept your testers around.

The book is about placing software test - and the costs of testing software - in context of the entire software development lifecycle. It's about taking a facetious answer ("just do less!") and providing manager, executives, and testers with the tools to make those decisions intelligently.

I'm a tester, I find bugs - why do I need to worry about reducing the cost of testing ?

You're a tester. You do a whole lot more than find bugs. You gather information, you understand systems, you figure out how things work and how they don't. And, if you're like most testers, you worry about your job. Heck, most professionals do. This book is about the value that test brings to an organization, and about realizing that value in a cost-effective way. Those are exactly the skills that you as a tester will need to thrive in the future of software development.

Your chapter was about Opportunity Costs - why did you decide to write about that?

So much of what we do in testing is about making tradeoffs. It's about recognizing that we could test forever but that we don't actually have forever; instead there's a release coming up fast. I wanted to write about that decision making process using a tool that is recognizable to the business: opportunity cost. Opportunity cost is what we give up by not doing something. Because we went to the store, we didn't have time to go to the gym; the opportunity cost of going to the store is the benefit we would have gotten from going to the gym (weight loss! better cardio!). Opportunity cost provides us with a way to expose the risks and costs of not doing something, and not doing something is a choice we frequently face in software testing.

How long did it take you to write ?

That's a tough question. The chapter on opportunity costs took a few days. The first draft came together in about a 6 hour period, but it was (like many first drafts) terrible! Fixing it took rather longer.

The appendix on 25 Tips to Reduce Testing Today was faster. Matt Heusser and I worked on that and Immediate Strategies to Reduce Test Cost together - you'll notice the strategies and the tips align - and it was really about the quick hits and small changes that together make a big difference. I don't know if it actually took less time, but it was certainly fun, and a lot of fun to think about what the most immediate thing could possibly be.

Are you happy when you re-read it or would you like to change it ?

I'm still happy with it. There are some tweaks I would make, but I'm still very excited about bringing together business concepts with testing needs and helping those two worlds work better together.

Now that you are a published author, do you have any plans for future books ?

I haven't really decided! At the moment I'm mostly writing for my blog and shorter articles, but there may be a book waiting to emerge.

Will your copy of the book be put in a special place ?

Does the bookshelf count as a special place?

Putting you on the spot - what is your favourite chapter in the book ( and why ) ?

That's a tough one. The chapters are all helpful in very different ways. This is a book to me that you don't read all the way through and put it away. You read different chapters as you go through various situations, whether it's doing budgeting (and reading Michael Larsen's Trading Money for Time), or building up a test team (and reading Anne-Marie Charrett's Cost of Starting Up a Test Team), or trying to move faster (and reading Petteri Lyttinen's You Can't Waste Money on a Defect That Isn't There).

Until this book came out, what was your favourite testing book ?

I'm into the classics, so my favorite is Hetzel's Complete Guide to Software Testing. I pick it up when I need to be reminded of the fundamentals. Parts of it are a bit dated, but most of it is still solid guidance.