一句话结论

软件质量不能只靠上线前“数 bug”；应同时衡量用户可见的外部质量与代码内部的结构质量，并把预防、测试和反馈嵌入整个交付流程。

内容脉络

1. 质量代价：录音以 2022 年美国 poor software quality 约 US$2.4 trillion 的估算开场，强调 cybercrime 与 legacy technical debt 会把早期的“快捷修补”放大为长期成本。
2. 外部质量视角：录音用 ISO/IEC 9126 解释功能性、可靠性、可用性、效率、可维护性、可移植性等用户或运行环境可观察的属性。
3. 内部结构视角：ISO 5055 聚焦源代码和架构中的 Reliability、Performance Efficiency、Security、Maintainability 弱点，可借助静态分析形成自动化度量。
4. 比 defect count 更深入：仅统计 bug 是滞后指标；cyclomatic complexity、结构弱点密度、technical debt 等指标能更早暴露“内部腐烂”。
5. Shift left：在需求、设计和编码早期就定义可测试的验收条件；TDD 先写测试再写实现，使质量影响设计，而非成为末端检查。
6. 自动化与人工互补：自动化适合重复的 regression checks，人工应投入 exploratory testing、未知边界和高风险场景。
7. 跨角色协作与 flow：开发、QA 与利益相关者从开始就共同工作，减少交接、阻塞与返工；Agile 仪式本身不等于顺畅交付。

关键概念

• External quality：系统在真实使用环境中的行为和体验。
• Structural quality：源代码与架构是否包含会损害可靠性、性能、安全和可维护性的危险弱点。
• Leading indicator：在事故前预警的指标，例如复杂度、静态分析严重缺陷、未覆盖的高风险需求。
• Lagging indicator：事故后才出现的结果，例如生产 defect、downtime、投诉和收入损失。
• Flow：从想法到可靠产品的价值流动能力，而不是单纯“做了多少任务”。

IE Project 应用

• 为 1 个关键用户结果写出“结果—指标—目标值—数据来源—频率—负责人”。
• 选择 1 个 leading indicator 与 1 个 lagging indicator，解释两者为何互补。
• 找出最复杂或最危险的模块，并定义静态分析或代码审查 gate。
• 把 1 条验收标准转成自动化 regression test。
• 说明人工 exploratory testing 要覆盖的异常路径。

反思问题

当 AI 能在数秒内生成大量代码时，团队应降低对 defect 的容忍度，还是重新定义“可接受 defect”？哪些自动化 gate 必须先于生成速度扩张？

关联资料

• The $2t cost of poor software quality
• CISQ Software Quality Standards / ISO 5055
• Moodle Week 6