敏捷团队的质量保障赋能

“没有专职的测试人员？

代码提交就直接发布到生产环境？

而且，一天还可以发布多次？”

对于很多团队来说，这是完全不可能的事情！他们都是怎么做到的？

01 两个案例

相信很多人都对前面这些问题很好奇，在解开谜团之前，我们先来看两个案例。

案例1

随着互联网业务的发展，某行业核心系统为了面对互联网的挑战，需要对系统进行改造。可是，真想改起来却寸步难行……

该系统已经有十多年的历史，业务规则复杂，业务逻辑代码全部都在数据库脚本层；缺乏有效的业务文档，需求分析文档是以系统页面流转和操作步骤为主的形式，开发和测试人员对业务没有清晰的概念，只是知道系统有哪些操作，某个操作对应的真实业务并不清楚。

面对几百万行代码的改造，没有业务上下文的支撑，其难度可想而知。

案例2

某团队开发半年的一个网站在上线前一个多月发现根本没法正常运行，被迫延期半年后才上线……

原来，该网站是基于一个第三方平台开发，由于业务的特殊性需要支持2TB的数据量。但是，该第三方平台并没有验证过可以支持这么大的数据量，在上线前一个多月UAT环境准备就绪，系统在UAT运行的时候完全垮掉。

在进退两难的情况下，团队也只有硬着头皮往前走，一边优化自己开发的程序的性能，一边还要协助第三方平台进行升级……团队所经历的种种心酸也是不言而喻。

02 传统质量保障之痛

案例分析

前面两个案例的痛我们都能感觉到，那么问题到底出在哪里？

案例1：寸步难行的遗留系统

• 缺乏业务上下文：没有有效的业务价值传递方式，团队的沟通都是基于系统行为进行，开发和测试了解到的都是页面流转方式和具体的操作，难以识别业务高风险问题；
• 缺乏系统的设计，代码没有分层，不能体现业务，也很难编写有效的自动化测试来保障质量。

案例2：延期半年才成功上线的网站

• 分析、开发、测试都没有考虑真实业务需求，缺乏性能风险意识，只关注了功能需求；
• 第三方系统没有验证，对第三方系统并没有有效的风险评估；
• 测试环境准备不够及时，上线前一个多月才准备好的UAT环境也是导致更晚发现性能问题的原因之一。

从质量保障到质量保障赋能

在传统的质量保障模式下，前面案例所发生的事情并不少见。随着业务和技术的不断发展，对传统系统的质量之痛，相信大家都是深有体会。

一方面，靠独立的测试团队把关质量，靠滞后的测试阶段来测试、发现系统的问题，导致大量时间的浪费和成本的升高。

另一方面，不同角色的人员相互独立、甚至有着高高的部门壁垒，是一种相对对立而不是合作的关系。普遍认为测试是最终要对质量把关和负责的，其他角色各自做好自己阶段范围内的工作就好，形成了一种“各人自扫门前雪”的局面，而没人能将业务需求到产品整个串起来，确保是否开发了正确的系统。

这样的质量保障方式已经不