Reading: Charting the Course by Rob Sabourin — Chapter 2: "Some Philosophy"

While reading Chapter 2, one fundamental question really stopped me: "How do we actually know we're ready or finished in software development?"

Is it when requirements are ready for design? When design is ready for development? When code goes to QA, when testing finishes, or when the product finally goes public?

In practice, we usually try to quantify readiness using metrics like code coverage, static analysis, and predefined quality gates. But tools can only take us so far. Ultimately, the entire team needs a shared understanding of what "done" truly looks like before shipping.

Here are my main takeaways and reflections from the chapter.

Redefining Quality with Juran

Joseph Juran, a Quality Control Expert in quality management, simply defines quality as features that provide customer satisfaction. He breaks this down into the Juran Quality Trilogy:

• Quality Planning: Designing for customer needs.
• Quality Control: Ensuring standard operations meet the target.
• Quality Improvement: Continually driving down defects.

Link: https://link.amazon/B0ebmUBmi

The Reality of Bugs & Regression

No matter how pristine the code is, how thorough the unit tests are, or how detailed the code reviews are done, regression bugs are inevitable after a change. That’s a reality coined by Watts Humphrey that every developer has to accept.

To catch these issues without testing infinite variations, Genichi Taguchi (author of the Total Quality Handbook) emphasizes using smart sampling techniques for combination testing.

A few principles that stand out:

• Address them early: There’s no such thing as a "good" or "bad" bug—the sooner you fix it, the cheaper it is to solve.
• Priority vs. Severity: Severity is technical impact, but priority is a business decision. It changes based on timing, product goals, and stakeholder priorities. What was low priority last month might become critical today.
• Always report, even minor issues: As my mentor used to say: Even if it’s a trivial bug, report it. Deciding whether to fix it or live with a workaround is a product decision.

Link: https://link.amazon/B00WNa0Am

The Bug Priority Matrix

Much like the decision matrix from The 7 Habits of Highly Effective People, bugs are typically categorized into four quadrants:

• Q1: High Priority / High Severity (Drop everything and fix)
• Q2: High Priority / Low Severity (Minor issue, but business-critical)
• Q3: Low Priority / High Severity (Major technical issue, but edge case or low impact)
• Q4: Low Priority / Low Severity (Nice to fix eventually)

Link: https://link.amazon/B0dk2jHHu

Reframing the Purpose of Testing

Computer scientist Edsger W. Dijkstra famously wrote in Notes on Structured Programming:

"Testing can show the presence of bugs, but never their absence."

When Non-testers often ask, "How long will it take to test this feature?" under the assumption that testing continues until the software is 100% bug-free. In reality, people aren't paying for perfection—they're asking how much targeted effort we need to invest across different levels to manage risk.

Two Practical Testing Strategies:

1. Timeboxing Exploratory Testing: Give testers a fixed window of time to execute a specific test charter. If deeper testing is needed, assign a new charter. This keeps exploration structured and prioritized without spiraling into endless testing loops.
   
   
2. Bug Confirmation & Re-testing: Always verify fixed bugs specifically to ensure the issue is resolved and that the fix didn't silently inject new regression bugs.