Quality is important. There’s no denying it. But how important is it, really?
I’ve bought a pair of New Balance sneakers last year and they were bad. They were bad enough for me to return them to the store on the next day.
To set things straight – I don’t usually return stuff even if it’s bad. Something has to really rub me in the wrong way for me to consider wasting effort on an unnecessary trip to the store.
And you know what? I’ve bought a new pair of New balance sneakers this summer. And they were good. I absolutely love them.
What’s the bottom line of my sneakers shopping experience? The quality of your product doesn’t make or break your presence on the market.
Sure, some may say that the same won’t work with software. They will say that there are countless alternatives on the market and users will be switching to them as soon as the first crash lights their screen with an error message.
To counter that point – I haven’t seen a shortage of sneakers. But I have seen a lot of people using uncomfortable, glitch and buggy software on a daily basis. These people aren’t switching because they are used to their apps.
Then there’s marketing that has much more to do with your app’s sales than it’s quality. Get a couple of YouTubers to sing you praise in the review and start pouring champagne into that bathtub. It’s just how our world works nowadays.
And yet, in a modern software development project, QA takes up to 50% of the time. Yes, testing usually takes as long as the development itself.
Why?
The real price of a bug
The answer to this question – just like to many other questions in our world – is money. Plain and simple. It’s cheaper to fix bugs before they hit the final version of the product than it would be to maintain and patch the entire system in the long run.
Or, alternatively, you may not even make it to the fixing stage after the release.
One does not have to walk far for examples.
Amazon web Services went down for 4 hours in 2016. Needless to say, the crash affected countless websites from all over the globe. Did the company lose any customers and is it now in demise? Nope,. But that single failure that could have been prevented by properly timed QA has cost the company a lot of money.
How much? Who knows, but to put things into perspective – when Amazon’s site went down for as little as 20 minutes it had cost the company $3.75 million.
Or we can take a look at Apple. Not today’s Apple but the 2012 version when we thought that it can do no wrong… Until they’ve released Apple maps to counter Google’s product.
Remember the train wreck that was Apple maps at launch? Entire cities were erased from existence. No, not in public riots, just from the map app, but still.
I don’t think that anybody knows the approximate estimate of the company’s financial losses, but the damage to the brand was done as it has revealed its corporate teeth to the mass market.
Test early, test often
Both of the companies from our example haven’t lost their brand or their clients to software bugs, but they have lost money. A lot of money. More than you are willing to waste down the drain, I guess.
So what is the solution?
Early and often tests, of course. You can save a lot of budget in the long run if you do so as, according to a research by IBM, the cost of fixing a bug after the product release is 4 to 5 times higher. Not only that, but it is also 100 times higher than the cost identified in the maintenance phase.
To put things into perspective, if it costs $100 to fix a bug during the requirements stage, the price will jump to $1000-$1,500 during QA and to $10,000 in production.
So which one are you willing to pay? A hundred bucks today or 10K tomorrow?
QA best practices
How can you prevent overspending on a project due to poor execution of Quality Assurance?
You can follow these simple tips throughout the entire development lifecycle:
- Introduce the concept of Quality to your team. Ensure that every developer working on a project knows the standards you are aiming at and does his or her best to meet them. In a world where 90% of all software defects come from human error or carelessness, this step is of top priority.
- Plan your sprints with QA in mind. Cover 100%^ of the code with tests, both manual and automated, after every iteration is ready and before it hits production.
- The “test early, test often” and the continuous delivery methodology are your best friends for life.
- Use the tools and testing frameworks to your advantage. The market offers countless solutions for QA engineers nowadays and some of them can truly make or break the testing process.
- Only automate if it is worth it. The developers should cover the code with tests on their side, but an additional investment in automated testing only makes sense on enterprise-scale or security-oriented projects.
- Specify the reporting procedure. What good is a found bug is the developer can’t find or reproduce it to fix the issue?
- Track and manage your team in real time. Incorporate software that tracks the workflow, the amount of open and closed issues as well as their priority. This will allow to better plan the next sprint.
Now we know the true value of QA. Or do we? Contact us if you still have any questions left and we will do our best to help you!
