It's been two weeks since How To Reduce The Cost Of Software Testing
came out in hardback.
It is actually out.
You can go buy it.
You can go to your local physical book store (I'm told a few of those still exist) and ask them to stock
If you live in the continental United States, in Finland, the Netherlands, India, Australia or Germany, and you would like a chapter contributor to come speak to your local user's group (or do a book signing), and you are willing to do a little logistical legwork, well, you can probably get someone to give a talk.
And yet there's something strange going on.
What the book is not
In the fall of 2010, as the actual writing of the book was winding down, about a half-dozen of the contributors got together for a panel discussion at STPCon. It was a grand time, and I'm proud of the stories we told and the ideas we discussed. Toward the end, someone asked about automation, and I mentioned that yes, Karen Johns did have a chapter in the book about reusable test assets and testware, and that's true.
Driving my car cross-country home and back to a consulting engagement over the weekend, I realized something. In the book, we don't really talk about Automation, or Outsourcing, much at all.
I mean, here we have the two most obvious levers for any management to push to save costs, and we barely sort of almost cover them a little -- if you turn your head and squint. Yes, there is a Karen Johns' chapter on testware, and a few people touch on test automation or continuous integration. Jon Bach wrote a chapter on outsourcing, but his chapter is really more on rapid test augmentation, not about outsourcing for cost.
The reason I don't think we talked about those things?
It's 'cuz they don't work, or, at least, they don't work as promised.
Have you ever called a phone number and asked for support, and, within seconds, it became incredibly obvious that the support work had been outsourced to a low-wage country solely in effort to reduce cost?
If this has never happened to you, well, consider yourself lucky. It has certainly happened to me.
Now the promised cost reduction is a decrease in cost-per-transaction, which in this case is a phone call. Instead of paying a dollar, the company calculates that it will pay only twenty-five cents per call.
The only thing is, I didn't make just one call. Instead, I called the first person, who transferred me to a second, who transferred me to a third, and a fourth, who gave me a code to use. I hang up, try the code, it doesn't work, so I have to call back again. That
person transfers me. And again ...
In the end, I don't make one phone call. I make eight. And, at twenty-five cents per transaction, I end up costing the modem supplier two dollars instead of one.
Psychologist and author John Seddon calls this failure demand.
The idea being that when I try to use a service and it isn't fit for use, I create a new kind of demand ("failure demand") that didn't exist before. It didn't exist until the service initially failed.
Seddon conducting a very large, well-documented study of moving staff to low-wage countries in the public sector in the United Kingdom, and came to this conclusion:
"When you outsource purely motivated by cost, cost goes up."
Everyone I know who has tried classic, naive outsourcing to save cost has experienced failure demand.
This also tends to happen with GUI-Driving, Customer-Facing
Automation developed by someone other than the initial programmers. The GUI changes, the scripts report a bunch of "errors", the staff needs to re-run the tests to figure out if they really are errors and repair them.
In other words, the automation can't supply what it is asked to do, and creates a demand for maintenance and support work. In many cases, this demand is greater than the initial demand would be to test the application with modern/thinking/creative methods.
Don't get me wrong; there are lots of reasons that you might outsource, and lots of reasons that you might use tools to automate some tasks testers do. You might, for example, outsource to develop a strategic partner, to build a specific expertise, or because you want to be able to ramp staff up and down relatively quickly. You might automate portions of testing to reduce your test cycles, or to find certain kinds of defects with minimal human interaction, or just to create a sort of executable specification to show your customers the 'happy path' of the business logic.
Again, there are lots of reasons to do outsourcing or automation. It's just that none of those reasons above will directly save you money. And yes ...
Done smartly and effectively, with nuance and skill, by people who know what they are doing, yes, you might save 10%, possibly even 20% -- in the long haul. In the short-term, both of those things are an investment; they will cost you time and money, and lots of it.
And, ultimately, that's a big part of why we didn't include them in the book. I don't want to say "Look, save money, just spend $150,000 over the next six months ... THEN see savings!"
No, I want you to read a book over the weekend, then come into the office on Monday with ideas to save money right now. Ideas that don't need executive buy-in, or to force someone else to change to make you more productive, or that will cost a lot of time or money.
Our goal was to help you be the best tester you can possibly be.
It was tough, it was hard; we learned a lot along the way.
I've been writing this column for going on two years now; blogging for years before that. If these are solutions to the problems you are interested in, please consider the book
. (Want to hear it direct? Consider the keynote
at STPCon in Dallas Oct 24-27)
If you aren't interested in it, or you can't afford it -- or if you are offended that we dared to charge for the work, well, keep it here, there will be more free stuff to come.
No worries, mate.