I’ve recently written about the question of AI’s role in quality assurance —just one of the many questions I often hear from business leaders looking to cut back on their QA spending. To be certain, there’s nothing inherently wrong with looking to save money; that’s a big part of any executive’s job. But questions like these—”How much should I spend on quality?”—often uncover some larger issues that must be addressed surrounding the value of quality to any business that relies on software. Or, in other words, any business looking to compete in today’s market.
Case in point, another common question I hear: “Why do I need to spend so much on quality when I’m using vanilla cloud software?”
This question has a lot to unpack. As with the other avoidance questions that raise issues of how businesses value their software, this question implies that cloud-based software is somehow simpler than software that’s custom built and hosted on-premises. In reality, there’s no such thing as simple when it comes to the software that drives your business—and there’s really no such thing as “vanilla” in enterprise IT, either.
What Does “Vanilla” Even Mean?
When people buy cloud products, they often refer to this software as “vanilla,” which is meant to suggest that it’s plain. Original. Nothing special or different from the same product everybody else has already bought from this provider. For example, someone might buy some cloud-based HR software that comes with a litany of different settings that can be adjusted to make the software behave how a particular business needs it. But by the time all those settings are customized and that software is hooked up to all the legacy systems the organization is still using, does that software really behave just like any other out-of-the-box instance of it?
The short answer is no, especially when it comes to QA. Quality is about way more than whether or not a menu drops down like it’s supposed to. It’s about how we take a single business process that has multiple data dependencies that lead to multiple user scenarios and make it work each time.
So in the case of the HR software, it makes no difference if we put it on a server in an office somewhere or put it in the cloud. The data dependency and the complexity don’t change. For the system to work the way it needs to in either scenario, the person making hires needs to access data. The moment we related this HR software to the important and critical business process of hiring, that’s where we introduce risk. And that risk is unique to every business. That risk is what drives the need for QA, not the software itself, or who you purchased it from, or where you’ve decided to store it.
The Bigger Problem: A Disconnect of Expectations
I believe the bigger problem here has to do with the expectations many executives have of their software, and how those expectations translate to discussions of value.
Consumers today are standing up to say they want more quality from every company they do business with. We love Whole Foods and are willing to spend more money on products that are produced locally, safely, humanely, and with some craft. We want quality clothes. Discover is basing their adverts entirely on the fact that they have real people on the phone when you call them. But for some reason, when it comes to technology on a corporate scale, the market seems to always question why we need quality testing in the first place.
Ultimately, businesses think they shouldn’t spend money on testing because they’re already spending good money on engineers and developers, right? And whether they realize it or not, many businesses that utilize big applications like Salesforce Marketing Cloud or Oracle aren’t just using vanilla, out-of-the-box solutions. They want things tweaked. Customized. Configured. And even though they may not be making core code changes, they are still making all these changes to make the software really work as a solution for things other than what was intended. Yet they see these applications working so smoothly, they believe everything must be architecturally sound. But that expectation has now yielded the expectation that they shouldn’t have to spend much money at all on testing because software should just work.
Risk Doesn’t Go Away, And Neither Should QA
For that reason, every client believes they’re the same as somebody else. The way businesses often procure software is to ask providers for a reference to another customer with a similar use case. Those other organizations being used as a reference may have gotten started the same way as your company, but they’ve had such a success with testing along the way that they may have forgotten how much of an investment they’ve made along the way. That translates to problems for companies like mine who are selling quality assurance services; our success tends to be the enemy of our ability to point to our value.
And then after the first year, with all the recommendations and changes to make things better from their QA partner, some businesses expect to spend less money on quality the second year. But your development hasn’t decreased, and neither has your risk—even if you’ve moved to the cloud. So why should your spend? At the end of the day, you’re still producing something your business is relying on, something that really isn’t vanilla at all. For that reason, you have the same need to apply quality with the same vigor as you deploy new implementations. Full stop.