CSQE: Software Quality Engineering

Software Quality Engineering is the CSQE domain that tests how you plan, assure, control, and improve quality across the software lifecycle. Questions ask you to select engineering controls-requirements verification, reviews, test design, configuration management, measurement, supplier oversight-and justify them with quality principles rather than tool familiarity.

Core rules and concepts

• Quality is conformance to specified and implicit requirements. Assurance emphasizes prevention and process visibility; control emphasizes detection and correction.
• Shift left: defects found in requirements or design are generally cheaper to remove than defects found in test or production.
• Distinguish verification ('Did we build it right?') from validation ('Did we build the right thing?').
• Use standards as frameworks, not checklists: ISO/IEC 25010 for quality characteristics, ISO/IEC/IEEE 12207 for lifecycle processes, IEEE 730 for software quality assurance plans, and ISO/IEC/IEEE 29119 for test processes and documentation.
• Measure both process and product: defect density, defect removal efficiency (DRE), escaped-defect rate, test coverage, review yield, and phase containment.
• Classify cost of quality into prevention, appraisal, internal failure, and external failure; external failures usually carry the highest cost.
• Manage risk: prioritize reviews and tests by likelihood and impact, and record residual risk explicitly.
• Control changes: configuration identification, baselines, change control, and status accounting keep evidence trustworthy.
• Supplier quality: flow down requirements, audit capability, define acceptance criteria, and verify corrective action.

Worked example

A release has 1,000 requirements. Reviews find 60 defects, testing finds 30, and customers report 10. Defects found before release are 90; total defects are 100, so DRE is 90%. Escaped-defect rate is 10/1,000 requirements, or 1%. If review costs 2 hours per defect and production repair costs 20 hours, review saves 18 hours per defect, or 1,080 hours for the 60 review-found defects. Reasoning: DRE measures containment, not total quality; a high DRE can still hide low review yield. Compare against baselines and trend by phase.

Traps

• Treating testing as quality assurance; testing is mainly quality control.
• Reporting coverage alone as quality; coverage shows exercise, not correctness.
• Computing DRE without defining the denominator or phase boundary.
• Assuming a standard certifies product quality; it certifies process conformity or defines characteristics.
• Forgetting configuration management; without baselines, audit and test results are not reproducible.