You can ship higher quality software without affecting your overall delivery timeline. And, by shipping higher quality software, you’ll lower your maintenance costs, create happier customers, and spend less time putting out fires and more time improving your product. So if quality pays such great dividends, why is the world so full of buggy software?

Quality isn’t an inherently exciting topic. The benefits are difficult to quantify. It requires upfront investment and perpetual discipline. And it isn’t even particularly fun. As a result, the quality bar for software is incredibly low with over half of software systems being released with defects that affect usage. ¹ This isn’t encouraging, but there is some good news.

Investing in quality can lower your development costs by reducing time spent reworking code—regardless of whether that rework is caused by changing design requirements or just debugging. ² In the best case, you shorten your overall timeline and deliver higher quality software. In the worst case scenario, you save time in development and shift that saved time to your effort on quality assurance. In that case you only end up with a better product for the same amount of effort.

It’s hard to believe, I know. So lets talk real results. A study by the NIST found that over a third of costs associated with software defects could be eliminated by the addition of better testing processes and tools to help find and address defects earlier in the software development process. ³ Similarly, a study of more than 45 projects by NASA found that the increased quality assurance efforts reliably decreased the number of defects without increasing the overall development cost. ⁴ And they were building software for rockets and space shuttles. There’s no question. Quality is worth the investment.

…over a third of costs associated with software defects could be eliminated by the addition of better testing processes and tools to help find and address defects earlier in the software development process.

The key is that the earlier you find a problem, the cheaper it is to fix. 1 Finding and fixing minor bugs after shipping is about twice as expensive as finding them before shipping, and, in the most extreme cases, the costs of finding and fixing a severe problem after shipping can be up to 100 times more expensive than if it was caught during the design or requirements gathering. ⁵ Of course, not every problem will result in such significant increases, but time and again, studies have shown that quality is effectively free in software development. The only real dilemma is whether you want to save money preventing issues or waste money fixing them. ⁶

The key is that quality can’t be considered an afterthought or a nice-to-have, but rather an inherent requirement and an ongoing part of development. The costs to implement good quality assurance controls aren’t zero, but with the right processes, it’s unquestionably more effective to ship high quality software than low-quality software. There’s no reason to not include formal quality assurance in your process.

Who is this course for?

Testing is an art, and there are people who make long successful careers dedicating themselves to testing. In our experience, though, there’s a whole other world of small teams that haven’t been exposed to the concepts and benefits of formal quality assurance and issue tracking. We want to change that by making quality assurance more approachable so that more teams can get started. Our hope is that after taking the first steps, that work will become a springboard for you to learn more and take your tools and processes even further. 2

If you’re on a small team or have never worked in an environment with a formal quality assurance process, then you’re in the right place. If you’re a QA pro, you might gain some insight, but you’re likely way beyond the material we’ll cover here. Anyone can ship higher quality software, but while the overall benefits are effectively free, quality isn’t automatic. You’ll have to set aside time to set up the tools and processes, but once you’re up and running, you’ll spend less time putting out fires and more time improving your product.

So what’s next? We’ll run through a quick overview of the tools and processes available to improve software quality and paint the picture of how they can all work together. And don’t worry, we’ve made sure that these lessons are both product and technology agnostic so that you can apply them with the tools that work best for your team and technology stack.

Sound good? Let's get started by looking over the ecosystem of quality assurance tools and processes to see how everything fits together. (There's also a table of contents at the end of each page if you want to skip around.)

1. Forrest Shull, et. al., “What We Have Learned About Fighting Defects” (2002), 9. ↩
2. Steve McConnell, Code Complete, Second Edition (Microsoft Press, 2009), 474. ↩
3. NIST, “Software Errors Cost U.S. Economy $59.5 Billion Annually” (2002). ↩
4. David N. Card, “A Software Technology Evaluation Program” (1987), 2. ↩
5. Shull, et. al., “What We Have Learned About Fighting Defects”, 3. ↩
6. McConnell, Code Complete, Second Edition, 477. ↩