Skip to content

Quiz: Quality Assurance and Technical Debt

Test your understanding of technical debt, code quality, testing methodologies, code coverage, and system migration strategies with these review questions.

1. Who coined the term "technical debt" and what financial concept does the metaphor deliberately parallel?

  1. Martin Fowler in 2001, paralleling equity investment where you invest now for future returns
  2. Ward Cunningham in 1992, paralleling financial debt where you borrow against future productivity and pay interest through increased maintenance costs
  3. Kent Beck in 1999, paralleling insurance premiums where you pay ongoing costs to protect against future risks
  4. Robert Martin in 2003, paralleling depreciation where assets lose value over time without maintenance
Show Answer

The correct answer is B. The chapter states that the technical debt metaphor "was coined by Ward Cunningham in 1992 and draws a deliberate parallel to financial debt: you borrow against future productivity to deliver something now, and you pay interest on that loan through increased maintenance costs, slower feature development, and higher defect rates until you repay the principal by fixing the underlying problem."

Concept Tested: Technical Debt

  1. 33% unit, 33% integration, 33% E2E for balanced coverage
  2. 10% unit, 20% integration, 70% E2E to maximize user-facing confidence
  3. 70% unit, 20% integration, 10% E2E
  4. 50% unit, 40% integration, 10% E2E to emphasize component interaction
Show Answer

The correct answer is C. The chapter's testing pyramid diagram specifies a "Recommended ratio: 70% unit, 20% integration, 10% E2E." This distribution reflects the trade-offs at each level: unit tests are fast, cheap, and precise; integration tests are moderate in speed and cost; and E2E tests are slow, expensive, and brittle. The pyramid shape itself illustrates that the foundation should be the widest layer of unit tests.

Concept Tested: Testing Fundamentals

3. What distinguishes "deliberate, prudent" technical debt from "deliberate, reckless" technical debt?

  1. Prudent debt involves more expensive technology choices while reckless debt uses cheaper alternatives
  2. Prudent debt is incurred with conscious trade-offs and a repayment plan, while reckless debt cuts corners without planning to address the consequences
  3. Prudent debt only affects frontend code while reckless debt affects backend systems
  4. Prudent debt is approved by engineering leadership while reckless debt is introduced by individual developers
Show Answer

The correct answer is B. The chapter's technical debt quadrant table contrasts these two types: "Deliberate, Prudent" is described as a "conscious decision to ship quickly with known trade-offs" (example: using a flat file for MVP with plans to migrate later) with low risk because it is planned. "Deliberate, Reckless" is a "conscious decision to cut corners without a repayment plan" (example: skipping tests to ship faster) with high risk. The presence or absence of a repayment strategy is the distinguishing factor.

Concept Tested: Technical Debt

4. Your team's feature delivery has slowed significantly even though headcount has not changed, bug rates are rising, and engineers estimate simple features as taking weeks. What is the most likely underlying cause described in the chapter?

  1. The team is spending too much time writing automated tests
  2. Degrading code quality caused by accumulated technical debt
  3. The product has reached its maximum feature capacity
  4. Engineers are unfamiliar with the testing framework being used
Show Answer

The correct answer is B. The chapter lists these exact symptoms as indicators that code quality may be degrading: "Feature delivery slows down even though team size has not changed," "Bug rates increase, especially regressions," and "Engineers estimate simple-sounding features as taking weeks instead of days." The chapter connects code quality directly to technical debt, explaining that low-quality "spaghetti code" is tangled, poorly documented, and fragile, meaning that changing one part frequently breaks another.

Concept Tested: Code Quality

5. Your company needs to replace a 15-year-old order management system that has many undocumented integrations with other services. Which migration strategy would minimize risk for this scenario?

  1. Big bang migration to complete the replacement quickly and minimize the period of uncertainty
  2. Parallel run where both systems operate simultaneously with output comparison
  3. Strangler fig pattern that gradually replaces legacy components while both systems run
  4. Phased rollout that migrates one user segment at a time to the new system
Show Answer

The correct answer is C. The chapter's migration strategy table rates the strangler fig pattern as "Low-Medium" risk and identifies it as best for "Large, complex systems with many integrations," which matches this scenario. The chapter explains that the strangler fig pattern routes new functionality through the new system while the old system continues handling existing features, and "over time, more and more traffic flows through the new system until the legacy system can be safely decommissioned." A big bang approach would be "Very High" risk for this type of system.

Concept Tested: System Migration

6. What is the primary difference between quality assurance and testing?

  1. Quality assurance is performed by dedicated QA engineers while testing is performed by developers
  2. Quality assurance is the broader discipline focused on preventing defects through processes and standards, while testing is one component focused on finding defects
  3. Quality assurance applies only to production environments while testing applies only to development environments
  4. Quality assurance measures code coverage percentages while testing verifies individual function correctness
Show Answer

The correct answer is B. The chapter explicitly states: "While testing focuses on finding defects, quality assurance focuses on preventing them." It presents the relationship as hierarchical, with Quality Assurance as the "umbrella discipline" that encompasses process standards, code review policies, testing (including manual, automated, and specialized testing), and continuous improvement. Testing is positioned as one component within the larger QA framework.

Concept Tested: Quality Assurance

7. An engineering team reports 90% code coverage but production bugs continue to appear in critical payment workflows. Based on the chapter's guidance, what is the most likely explanation?

  1. The testing framework is miscounting coverage and the actual number is much lower
  2. Code coverage only measures whether code is executed by tests, not whether the tests check meaningful conditions or critical edge cases
  3. Payment workflows cannot be covered by automated tests and require manual testing exclusively
  4. The 90% coverage target is too low and the team should aim for 100% before bugs decrease
Show Answer

The correct answer is B. The chapter warns that "High coverage does not guarantee high quality - it is entirely possible to have 100% code coverage with tests that check trivial conditions and miss critical edge cases." It further states that "a team with 60% coverage focused on the most important and complex code paths may have a more effective test suite than a team with 90% coverage spread uniformly." The chapter advises using coverage as a conversation starter rather than a rigid target, and focusing on coverage of critical paths.

Concept Tested: Code Coverage

8. How should a PM frame the value of code refactoring when communicating with stakeholders who want to see new features?

  1. Explain that refactoring is a technical requirement mandated by engineering best practices
  2. Describe refactoring as routine maintenance that does not require stakeholder visibility
  3. Connect refactoring to business outcomes, such as reducing bug-fix time and enabling faster future feature delivery
  4. Present refactoring as a one-time investment that will never need to be repeated
Show Answer

The correct answer is C. The chapter provides a specific example of how to frame refactoring in business terms: "This refactoring will reduce our average bug-fix time from 3 days to 1 day, letting us ship features 20% faster next quarter." The chapter's tip box states: "Stakeholders often resist refactoring because it produces no visible features. Frame refactoring in business terms... Always connect engineering investments to business outcomes." This approach builds stakeholder support by making the ROI tangible.

Concept Tested: Code Refactoring

9. What percentage of sprint capacity do many high-performing engineering teams allocate to technical debt reduction according to the chapter?

  1. 5%
  2. 10%
  3. 20%
  4. 40%
Show Answer

The correct answer is C. The chapter's tip box on "The 20% Rule" states: "Many high-performing engineering teams allocate approximately 20% of each sprint to technical debt reduction, infrastructure improvements, and developer tooling." The chapter explains that advocating for this investment demonstrates technical maturity, builds trust with engineering, and pays off through sustained velocity, noting that "teams that never address debt gradually slow to a crawl."

Concept Tested: Technical Debt Tracking

10. Which type of performance testing would you recommend to determine whether your system can handle a sudden traffic surge from a viral marketing campaign?

  1. Load testing to verify behavior under expected production-level traffic
  2. Endurance testing to detect memory leaks over extended periods
  3. Stress testing to find the system's absolute breaking point under extreme load
  4. Spike testing to simulate sudden traffic surges like a product launch or viral event
Show Answer

The correct answer is D. The chapter defines spike testing as "simulating sudden traffic surges (product launch, viral event)," which directly matches the scenario of a viral marketing campaign causing a sudden traffic increase. This is distinct from load testing (expected production levels), stress testing (pushing beyond limits to find breaking points), and endurance testing (sustained load over extended periods to detect memory leaks). Spike testing specifically evaluates the system's ability to handle rapid, unexpected increases in demand.

Concept Tested: Performance Testing