再谈测试左移

为什么要再谈测试前移？

先用敏捷测试宣言开始，就和敏捷宣言一样，短短几句话代表了非常多的含义，能够引发我们很多的思考。

敏捷测试宣言：

• 测试是一个活动 胜于 测试是一个阶段

• 预防缺陷 胜于 发现缺陷

• 做测试者 胜于 做检查者

• 帮助构建最好的系统 胜于 破坏系统

• 团队为质量负责 胜于 测试为质量负责

敏捷测试的基本原则

• 基于风险的测试

• 快速反馈

• 持续测试

• 尽早测试

• 分层测试

• 可信测试

• 代表客户测试

上述原则和宣言，其实都有一个隐含的背后逻辑，就是我们缺陷预防、缺陷尽早发现，是降低质量成本的最好的方式！

各阶段修复缺陷的成本

1、85%的缺陷在开发阶段引入，此时的修复成本是1，在UT测试时修复成本是4、FT测试时修复成本是10、ST测试时修复成本是40，版本发布后修复成本是640

2、而我们软件工程当前的现状是，大部分缺陷通过UT、FT、ST发现，甚至于泄露到工程应用，产生大量的质量成本。

再谈测试前移是源于近期的一次激烈的讨论，这次讨论甚至持续了很多天，每天都讨论到深夜。

话题是关于在团队在冲刺功能开发的时候，测试团队提交故障中有很多易用性故障是否合适的讨论。

测试团队和开发团队站在各自的立场，表达的意见其实都是绝对正确的。

1、测试站在用户的视角，提出的问题理应引起团队的重视和改进。

2、开发要求的是近期处于功能冲刺期，易用性问题不是近期的重点，不希望提交故障。

在这个里面也引申出很多讨论：

1、测试为什么没有在需求、方案评审的时候就提出易用性的问题，而在到测试阶段才作为故障提出？测试是否参与了需求、方案评审？

2、易用性的问题是否应该作为优化提出，汇总后安排专项解决。

3、测试在提交故障的时候应该要将前因后果讲的有理有据。

基于上述讨论的内容我思考了很多，我认为团队在对于测试前移，测试团队的职责定位在思维和理念上是有一些偏差，所以谈一谈我的想法。

当前的测试前移是怎么做的？

传统测试是一个阶段，在这个阶段测试人员执行测试用例，通过提单的方式反馈版本的故障，经过多轮的测试和故障修复，版本能够满足发布条件。

上述模式的主要问题就在于测试介入的时候，版本的质量已经基本确定，通常情况下这个时候会暴露大量的故障，造成很大的修复成本或者影响版本发布。

那我们现在怎么做测试前移呢？我们定义了 测试系统工程师的角色（TSE），前移到需求分析、方案设计环节，对需求、方案存在的问题提出要求并输出验收准则，输出测试设计并且对开发测试范围的要求。这种测试前移的方式很符合我们的正常思维，测试人员要深入到研发活动的各个环节，站在测试的视角提前识别问题并反馈问题，这样能够达到尽早暴露问题或者预防缺陷的效果。

但是每当遇到同事询问一个问题时，我就会很困扰，这个问题就是“测试为什么没有在需求、方案评审的时候就提出易用性的问题，而在到测试阶段才作为故障提出。”

困扰主要有两个方面：

第一、测试真的有能力在需求、方案的时候识别到这些问题吗?

第二、需求、方案的质量由测试来负责是合适的吗？

再谈测试前移

思考再三，其实就想表达一个观点，需求、方案、开发代码 的质量如果都需要测试来负责，其实是存在职责错位的。

为什么这么说，先讲一个例子：一个司机在开车，这个时候副驾驶的乘客不停地在指导说这个车应该这样开，应该那样开。这个时候司机是什么感受？司机能够把车开好吗？

在做需求编写和分析的时候，谁是这个司机？应该是需求经理。 副驾驶是谁？可能很多，有开发代表，也有测试代表。如果是测试要对质量负责的话，他一定是那个话特别多的副驾驶，相信特别招人烦而且可能让需求经理不知道如何做需求。

那讲了这么多应该如何做呢？先应用敏捷测试宣言中最后一句“团队为质量负责 胜于 测试为质量负责”，定义清楚职责，团队中各角色都应承担对应的质量职责。

需求质量的负责人就是需求经理，需求SE

方案质量的负责人就是技术经理，方案SE

版本质量的负责人就是开发团队

所以在出现需求类的问题泄露到测试活动中暴露，我们不应该第一时间问“测试为什么没有在需求、方案评审的时候就提出易用性的问题，而在到测试阶段才作为故障提出。”，而应该考虑我们在需求、方案阶段应该做什么。

那么接下来问题又来了。需求、方案、版本质量都有角色负责，还要测试同学干什么？还要谈什么测试左移？

这个时候我们就要看敏捷测试宣言中的另外四句。

• 测试是一个活动 胜于 测试是一个阶段：测试是一个活动，嵌入在每一个研发活动中。

• 预防缺陷 胜于 发现缺陷：在研发活动中，预防引入缺陷，尽早反馈缺陷是基本理念。

• 做测试者 胜于 做检查者：测试者要有自己的思维，熟悉业务，熟悉架构，站在客户的视角，代表客户测试。

• 帮助构建最好的系统 胜于 破坏系统：站在客户的视角，站在测试的视角，另外也要具备更专业的架构、开发知识，帮助构建更好的系统。

首先测试系统工程师（TSE）要前移到需求分析、方案设计、开发团队的活动中，具体工作需要从预防缺陷、构建更好的系统出发，研讨出各个角色共同认可的方式，而非仅仅是要求TSE参与各类评审并发表意见这么简单粗暴。上述就要求需求经理、技术经理、开发团队等角色更多的与测试系统工程师沟通交流，识别当前需求、方案、开发团队的痛点和不足并且与测试共同一起讨论如何更好的预防缺陷、构建更好的系统，形成有效的落地方式。这个时候就需要再次强调团队对质量负责，更主动的一方应该是需求经理，技术经理和开发团队，需要将测试的能力更好的融入在整个研发活动中。

最后要谈的是测试系统工程师的能力要求，随着敏捷测试，测试前移的推进，对测试的能力确实提出了更高的要求。在整个过程中要能够提炼需求质量/方案质量的评价方式，要掌握软件架构、代码开发、流水线等更多方面的知识能力才能够更好的做到预防缺陷并帮助构建最好的系统。

由于本人是一个资深的测试人，所以上述观点可能有偏颇，如有不同观点希望可以一起研讨。