The Unconventional Wisdom series features a new post each month from Robin on some real truths in software testing. He dispels some truth that you otherwise might not realise with his regular blog posts. In the latest instalment, Robin examines the business case for automated testing. Explore more posts in the Unconventional Wisdom series here.
——————————————————————————————————————-
Many in the testing community have difficulty establishing business cases to support investing in automated testing. Before taking a big step, especially one involving large investment, many organisations commonly require preparation of a business case showing the proposed approach’s financial value. I agree with the conventional wisdom that business cases are valuable, yet too often business cases as carried out become conventional “we’s dumb.”
Automating testing incurs a number of recognisable expenses, including acquiring one or more automated test tools and perhaps additional equipment, changing procedures, training, and possibly adding staff with relevant skills. Showing believable quantified financial benefits is harder.
Perhaps the only thing the development community is less comfortable with than testing is business cases. Ironically, some of those organisations that ordinarily would not even consider “throwing good money after bad” to (disfavoured) testing may be looking to invest in test automation because they see it as a way to get rid of current testing.
Business Case
The term “business case” actually usually refers to a whole process or procedure which culminates in preparation of a document called a “business case” that in turn becomes the basis for deciding whether to take some action typically involving an investment considered significant.
Wikipedia says, “A business case captures the reasoning for initiating a project or task.”
Usually it describes the background of the project, the expected business benefits, the options considered and reasons for rejecting or accepting each option, the expected costs and benefits of the project, and the expected risks. A financial analysis is included comparing the costs and benefits of the respective options, including “no change” or “business as usual” (BAU). Ordinarily, to be picked, an option must show financial advantage over doing nothing and over other alternatives. Return on Investment (ROI) generally is used to depict such advantage quantitatively.
Commonly-Recognised Issues
I find people overwhelmingly feel the biggest obstacles to useful business cases are financially quantifying benefits and performing calculations that support making the desired decision. Like an iceberg, though, ten times as many business case pitfalls commonly occur below the surface than are recognised above.
I describe these 21+ pitfalls and ways to avoid them in my “Building Right, Reliable, and Responsible REAL ROI™ Business Cases” seminar and related forthcoming book. Several of those unrecognised pitfalls are discussed below.
Unrecognised Pitfalls
Much of the attention to business cases focuses on and is largely limited to arithmetic calculations, which are unfamiliar to many people. In fact, though perhaps new to you, factors such as the time value of money and the calculations themselves are fairly simple and straightforward. The more critical and less recognised challenge is getting appropriate figures to include in the calculations.
Several pitfalls relate to this. For instance, there is a tendency to consider only cost savings from no longer spending amounts currently being spent. Meaningful financial analysis also must—but often does not–take into account cost avoidance, revenue enhancement, and revenue protection.
It’s also common for analyses to look only at the short term, perhaps just for the period of development/implementation; but the story also must reflect ongoing operations, support, and maintenance. Similarly, focus on technical aspects often leaves out sometimes more weighty non-technical factors, such as staffing, training, production, sales, market share and growth, reputation, competition, and customer behaviours.
Automating testing is touted for enabling faster implementation, whose main benefits are non-technical. However, speed to market must be weighed against too-seldom-considered risks that automated test tools may not catch certain forms of poor quality that may especially resonate with customers.
Such factors may be included in “intangibles,” which conventional we’s dumb mistakenly believes cannot be quantified financially. Instead, they are merely listed and then balanced against calculations applied only to tangibles. Not surprisingly, when the tangibles don’t support a desired outcome, practically every analysis imputes added value to the intangibles so that amazingly the preferred result prevails anyhow.
Frequently business cases are called “cost justifications.” Realise that justification means finding reasons to support a predetermined decision, which in fact is probably a tip off to what’s really happening. Many business cases are just sales pitches for a chosen approach and ignore or give little attention to alternatives.
The no change scenario is perhaps omitted most often, probably because the organisation has no meaningful measures of the current state, especially of value. Thus, business cases for proposed test automation typically contrast the tool’s costs to those for manual testing; but neither’s REAL value is measured with regard to testing’s purposes. That is, there could be but probably is no business case for testing itself.
Sometimes the powers that be simply skip the charades and declare ROI isn’t relevant for decisions where the proponents “know best.” What I call REAL ROI™ results from avoiding these and the other common ROI pitfalls. It’s needed to provide the basis for making reliable decisions, such as for test automation.
Contact me at [email protected] to discuss, learn more, and get help.
“It isn’t what we don’t know that gives us trouble, it’s what we know that ain’t so.”
– Will Rogers
This is the Unconventional Wisdom blog. Much of conventional wisdom is valid and usefully time-saving. However, too much instead is mistaken and misleadingly blindly accepted as truth, what I call “conventional we’s dumb”. Each month, I’ll share some alternative possibly unconventional ideas and perspectives I hope you’ll find wise and helpful.
