Hacker News new | ask | show | jobs
by mrgoldenbrown 5378 days ago
I would have liked to see a more realistic discussion of when QA helps the bottom line and when it doesn't. Plenty of software is sold and tolerated by users despite having bugs. If Microsoft waited until the bug count in Windows was 0, they would never ship, and would go out of business. In other words, this blog post is telling us that the correct amount of QA is higher than "no QA", but it is not helping us determine what the right amount of QA is.
2 comments

As a former QA myself, we never insisted on the bug count being 0, instead we focused on the "critical" bug count being 0 and the "major" bug count being as close to 0 as possible before shipping the product. Often it comes down to a negotiation between QA, dev and product but a good company will give QA a great deal of input in when a product is ready to ship.
This strategy backfires when managers want the release out so they fight to lower the severity for every defect that is entered. Then they generate a report showing no high severity defects and release the software. Another common problem is a high number of low severity defects that make the software annoying to use.

I am not claiming that a bug count of zero is possible with most software, but testing quality in at the end is the wrong approach. Nothing affects quality as much as the skill level of the developers.

Agreed. At thing point, any software company with a modicum of experience knows that reaching a 0 bug count is not only impossible, but a waste of money. You get out the new features that you want and make sure it works well, and without causing regressions. Any bugs that inhibit functionality that 80% of the users would use needs to be corrected, as well as any bugs that make us look bad (UI bugs like spelling mistakes, etc).
A more realistic discussion takes into account the fact that a lot of software isn't anything like Windows. You don't get a single shot to release to manufacturing to press images onto media to shove into boxes to put onto store shelves.

So much of our thinking about roles and teams and efforts and project management is still in last century's approach to monolithic one-shot releases.