- This topic has 2 replies, 3 voices, and was last updated 7 years, 10 months ago by
.
-
Posts
-
This is an interesting post that i recently came across.
Although written in 2015, it gives some idea as to the benefit of software testing for companies that are eager to release software with minimal testing.
The article suggest that a bug can cost up to $1,500 if found in the QA phase.
Whether this is right or not, I’m not sure. What do you think?
Here is the article with some examples of costly bugs.
Some bugs can really prove costly. Another example I heard of was with the point system in Sears. The points were wrongly getting accumulated in a particular scenario. The defect was found within an hour and site was brought down immediately. But in that one hour, transactions worth thousands of dollars (to redeem those points) were already made.
But, I believe that the occurrence of such critical defects in production is pretty low. So, in most cases the figures (though hypothetical) are way too high.
There are plenty of stories of costly bugs that make it to production… see this report (https://huddle.eurostarsoftwaretesting.com/software-bugs-in-2015/) and make it to the papers, bring down large companies and risks lifes. To mitigate these testing have to focus from testing requirements within the scope of the project, and rather have a more overall risk view and watch for . (See https://asym.dk/2017/01/23/where-might-the-black-swans-be-lurking/)
Even with maximum testing this can happen. And companies will “release software with minimal testing” when it benefits the business more than testing would. ..
What a bug costs – when found in production or else where, highly depends on your MTTR (mean time to repair). That the cost increases exactly 10 fold pr environment is a myth. http://thklein.com/en_US/cost-of-defect/
Actually looking into it, using Shift-right / testing in the wild / testing in production along with devops, you can observe and repair very fast. Which reminds me of MTBF (mean time between failures) – so involve your testing based on that too…
and building trust. .. most of all.
- You must be logged in to reply to this topic.