21、软件开发质量保障与同行评审最佳实践

软件开发质量保障与同行评审最佳实践

1. 外包测试的思考

如今，Ben 经常听到关于离岸或近岸 QA 的反对意见，这其实是很常见的情况。实际上，真正的问题并非团队的地理位置，而是人们将质量保障视为他人的工作。

有研究表明，外包第三方测试项目和独立的 QA 团队效果都不佳。最优的解决方案是让编写代码的人同时编写配套的测试框架。这样做有两个重要好处：一是当开发者编写测试时，代码会更易于测试，这也是测试驱动开发（TDD）重要的原因之一；二是开发者负责自动化测试时，会更关心测试并投入更多精力维护和修复。

很多公司将测试外包，只获取一份 bug 报告，这种做法忽视了工程系统的关键部分，会掩盖很多实际问题，错过大量反馈。不过，离岸或近岸开发本身并非不良实践，在时间紧迫、资源有限时，近岸编程团队能发挥重要作用。但当代码编写和测试在不同区域进行时，质量就容易成为他人的责任，测试也会逐渐滞后。

2. QA 团队是否是反模式

Ben 认为后期 QA 流程的问题与延迟和交接带来的摩擦与浪费有关，这一诊断很有道理。好的测试并非软件开发的独立阶段，它需要对软件设计和架构进行深入思考。只有 QA/测试人员和开发者每天协作，才能创建有效的测试套件。同时，清理测试用例，去除不稳定或有问题的测试也很重要。而且，将测试与基础设施即代码相结合，按需提供环境（包括测试环境），能解决配置失控和环境不可重复的问题。

在 Ben 的情况中，拆分 QA 团队是明智之举，但这并不意味着 QA 团队本身就是反模式。例如，有的公司原本让业务系统分析师（BSA）在每个团队内部充当 QA，但 BSA 主要目标是尽快推出产品，不利于关注质量。后来该公司成立了一个为内部和电商网