According to software testing expert Scott Barber, executives often see the testing side of software development as #EpicFail. Testing isn't just a failure in these executive's eyes, it's reached epic proportions. To explain #EpicFail for the uninitiated, at the recent STP conference in San Diego, Barber explained with a story about his sons showing off on the backyard trampoline. If one tries to do a flip and doesn't stick the landing, that's a fail. If he tries to do a flip and crash lands with a broken leg, that's #EpicFail.
So why do executives see testing as #EpicFail? Barber says it all comes down to accounting. "When you look at the accounting spreadsheet," Barber says, "testing is a cost center, not a profit center." He says it's in the same bucket as coffee. Although "no one in their right mind" would cut either out of the technology budget, they still both cost money and don't make product. The executives' focus, according to Barber, is not so much on making the best software possible as the most profitable software possible; so, if they could, some executives would only spend budget on things that directly contribute to making and selling the product. It's easy for executives to write testing off as being "all overhead."
Barber also likens software testers to auto mechanics and dentists because they all fix stuff. "When you've got your tester hat on, you hate the phrase nobody wants to pay for testing," he says. So to explain more clearly, he asks testers to think about taking their car to the shop for repairs. "You don't want to give the mechanic money," Barber says. "What you want is to get your car fixed. But you're willing to fork over the money to get it fixed, or you wouldn't have brought it in in the first place."
The mechanic says he'll run some tests, which will cost money, and then after those tests he'll tell you how much it'll cost to fix it. "Nobody wants to pay that!" It's the same with the dentist -- you go in for the cleaning, and you know they're going to tell you when to come back in and fork over a lot more money to fix stuff.
This is the way executives look at software testing, according to Barber. "They don't care about testing; they care about what sort of value you bring to the product." So refrain from talking to executives about the need for testing, Barber advises, and instead frame the conversation in terms of what the QA process will do for the product and for the bottom line. So the important question is how to tie software quality with increased revenue.
Of course, better quality software sells better -- until you reach a point of minimizing returns. "We, as testers, on the whole, want quality that's far above the bar that maximizes revenue," says Barber. It might cost much more to fix some things than it will save the company. There may be a defect that will only affect a small portion of the customer base.
The executive might be weighing the idea that a fraction of a percent of customers will call and complain against the threat of having to delay a release date, which means moving all sorts of things around. Speaking as the executive, Barber asks the question, "How many millions of dollars is it going to cost me to give you the opportunity to fix it, versus how much will it cost me to ship the product this way?"
Barber says it's important for the business to strike a balance between the testers' desire to make the absolute best possible quality software ever and the executives' desire to make sure the company turns a profit and the shareholders stay happy. "As we [testers] interface with those business execs, we've got to understand what their driver is," says Barber. If it's too expensive to test software and get it to market, the business might be better off selling a physical product like lawn chairs, he says, "because the shareholders will go for it as long as it makes the stock price go up." Barber clarifies that he is not defending this position, he's only explaining it.
When he's called in as a consultant, Barber says, executives think they're asking him to train their testers on how to test. In reality, however, Barber thinks what they really want is for someone to explain to the testing team how to go about testing in a way that will improve the bottom line. "It's not 'teach my testers how test'," he says. "It's 'teach my testers how to help my business.'"