核心论点

质量与可靠性必须从 requirements 出发：defect 是任何不符合约定要求的结果。因此同一行为在一个项目中可能是 defect，在另一个项目中未必是。

Measuring quality

• Defect count 是基础，但应结合严重度、优先级、暴露概率与业务影响。
• Severity 描述后果有多严重；Priority / urgency 描述多快处理。两者不能混为一谈。
• Severity 1 通常意味着系统不可用且没有可接受 workaround。
• Six Sigma 常以每百万机会 3.4 个缺陷作为高水平参照；Crosby 的 zero defects 更像“第一次就做对”的管理哲学，而非忽略成本与风险的绝对口号。

Prevention over detection

• 测试不会“制造质量”，只会揭露已经存在的质量问题。
• 需求或设计阶段的缺陷往往比编码阶段的缺陷更昂贵；V-model 强调每个开发阶段都有对应验证活动。
• Agile 不是跳过前期思考，而是在每次 iteration 重新检查 problem statement、design 与 user stories。

Whole-system view

技术只是系统的一部分。软件的实际质量还取决于：

• People：用户能力、培训、支持、职责与沟通。
• Process：工作流程、异常处理、升级与恢复。
• Technology：代码、架构、基础设施、数据与集成。

公路事故不能只怪道路；软件事故也不能只怪代码。质量必须分析人、流程和技术如何共同作用。

Criticality

• Safety-critical：失败可能造成人身伤害或死亡。
• Mission-critical：失败会使组织或任务无法完成核心使命。
• Business-critical：失败会造成重大业务、财务或声誉损失。

系统越关键，可接受 defect 水平越接近零，验证、冗余、监控和恢复要求也越高。

Understand the audience

确认 client、target user 与其他 stakeholder 是否是同一群体，并回答：

• 真正的问题是什么？期望功能和成功结果是什么？
• 使用情境、设备、峰值负载与 session 行为是什么？
• 需要哪些 authorization、privacy 与 database protections？
• 更新如何部署、回滚与保持服务连续？

IE Project 质量实践

• 验证 problem statement，而不只是实现已经写下的 feature。
• 写出可测试的 user stories 与 acceptance criteria。
• 用多个设计/原型和 usability testing 比较方案。
• 在需求、设计、编码、集成与部署各阶段安排检查。
• 使用 pair programming / peer review 预防缺陷。
• 持续让真实用户参与，不把 UAT 当成第一次见用户。
• 将 training 与 support 纳入质量方案。

记忆句