Qualitätssicherung bei Software ist alles andere als ein gelöstes Problem
Or, in English:
Quality Assurance in software is anything but a solved problem
Well, he’s right. The problem isn’t of course that we don’t have tools and processes to deal with QA. The problem he refers to is that those tools and processes rarely encompass all software any given business relies on.
Heartbleed was “just” the most dramatic example of recent times. It’s a business critical software package used by at least 66% of websites, supported by donations of around USD $2,000 anually. Something had to give. In the words of Steve Marquess: “So the mystery is not that a few overworked volunteers missed this bug; the mystery is why it hasn’t happened more often.”
Trends in Understanding QA
Here at spriteCloud, however, we noticed a trend that we consider encouraging in this context.
When we were a younger business, of course we had to work hard to prove our worth to our clients. Nobody wants to risk large contracts on the unproven skills of an unknown company. We all get that. At times, it was hellishly frustrating, but we persevered.
What’s more interesting is that when we started out, we had a lot more convincing to do on the value of QA in general than we do today. We may be able to pride ourselves on contributing to the fact that our returning clients incorporate QA routinely into their development processes. Perhaps.
But what we see as a trend is that new clients increasingly understand the value of QA before we come in contact with them. The need to convince them of QA itself is all but gone, and it’s much more about how we deliver it.
Our sample set isn’t small, but it’s biased. We recognize that. Perhaps that bias, though, provides the most insight into the motivation for the above trend.
If you examine our client list, you’ll see that all of them have something in common that is not, perhaps, immediately apparent. The commonality is that for our clients, software is not a product, but a tool to advertise and sell products.
There’s money talking here. Money demands reliability of the sales tools, and reliability requires some form of verification that requirements were met. It’s simple, really.
The Future and Cloud Services
It’s arguable that all software needs to be reliable, but strangely enough that’s not really true. When you take a starkly cynical look at the old model of shrink-wrapped software, vendors were basically selling software packages on trust and hype. Once the money was paid and the package shipped, it hardly mattered whether it was working.
Now clearly that’s not a healthy stance to take when trying to build a lasting relationship with customers. Yet some software vendors still operate in a comparable fashion.
It’s likely that this will change, too, due to the rise of cloud services. Cloud services rarely are sold as one-off copies, but paid continually for a much lower subscription fee. It takes months or years to get the same returns on such a lower subscription than on a single sold copy of shrink-wrapped software.
As such, maintaining a high level of customer satisfaction is imperative — and a much more obvious business requirement. As this shift from shrink-wrapped software towards cloud services continues, it’s likely that software quality assurance will continue to gain recognition as a necessary requirement for meeting business needs.
Free and Open Source Software (FOSS)
Going back to the beginning of this post, it’s still somewhat unclear how these trends will impact on FOSS. The heartbleed bug was enough of a wakeup call that industry giants are pooling resources to fund OpenSSL and other mission critical software. Whether this donation-driven model yields more involvement of QA methods in FOSS is not certain, however.
As our experience shows, QA tends to be required when bugs hurt financially. That is, there’s a direct link between the money invested and the losses prevented, and because of this direct connection, financial controllers can ensure that QA process yields high returns.
The donation mentality though is to write off the amount spent, and hope for indirect returns, somewhere down the line. That means it is not so much down to the financier to demand rigorous QA, as it is down to the development team to include it for their own benefit.
One hopes that this will happen.