A frequently heard question in our line of business often comes down to this: “how can we sell quality to our customers or sponsors?”. In other words: how can we justify the cost and effort related to making sure our software product simply does what it is supposed to do?
It often comes down to the question for who’s responsible to literally pay for the cost of quality. In our humble opinion, quality should not cost extra. If you integrate it correctly in your software delivery lifecycle, that is. Let me elaborate on that one.
First fact: testing is simply a means to achieve quality. There’s a lot more needed to achieve quality: as from the first idea, through design and development, up to releasing the software. There are many processes and ways of working that help to achieve quality. Based on experience and studies over the past decades, it became clear that the cost of a defect rises significantly per stage in the development lifecycle.
Imagine avoiding this for a change: during a final acceptance phase of a software at a customer’s site, several issues are reported. For each of these issues, the following process is applied:
- Someone at the customer site must take time to report the issue and add as many data as possible
- Someone at the development side must analyze the issue
- Someone must decide when and if the issue will be fixed
- One or more developers must change their focus on what they were doing to understand the analysis and they must adapt code to fix the reported issue
- Someone must adapt documentation to match the new software behavior
- Some initial tests need to run to verify the correctness of the change
- Some extra regression testing needs to be executed to validate that the change did not have an impact on other functionality
- The software update must be deployed to the customer’s testing environment
- The software must be re-tested at the customer’s site
Just imagine that you don’t have to go through this process ever again, that your developers get time to develop new things and your customer immediately gets what he asked for. No need to refer to contracts with penalty clauses, no need to worry about extra cost or impact to the value chain.
Second fact: there’s more to it than the money. The above example is just a simple view on how poor quality directly affects time (and thus budget). What’s equally relevant, but often harder to measure, is the indirect impact: the perception of the customer, the outside world on your organization when you deliver poor quality software. The willingness of the customer to trust your organization and to work with you again in the future. The impact on the value chain?
Let me give you a simple example of something that happened to me recently:
“I was planning a trip near Paris and wanted to book a stay by using the Airbnb app. I remember I had installed it a while ago and was curious to finally use it. I quickly found something interesting and decided to book a 1-night stay. But then I was asked to complete some safety measures and unfortunately, I couldn’t complete the booking. But as an experienced software user, I decided to try it again. And again. But after the fourth try I gave up and booked a hotel using the Booking.com app. And I paid at least double the price, compared to the stay I first found using Airbnb.”
Guess what the odds are of me booking a stay using the Airbnb app ever again? That’s right: zero.
To summarize, there are 3 questions a good software implementer should always ask himself:
- What is the actual cost of poor quality?
- How can we avoid wasting time and resources to fix what went wrong?
- How to achieve first time right?
Brightest can act as a partner in quality for any organization. If you feel you need some advice, do get in touch. And remember: you don’t need a bazooka to kill a fly.