公司某部门对“上意“的思考

某部门2018年的时候，接收到一项来自上层的指令：提高测试用例自动化率，到2020年要达到95%。他们回头一看，截止2017年年底的时候，他们才堪堪实现了10%。所以在理想的情况下，他们必须如下图来实现目标。

为了实现这个目标，自动化手动测试用例的任务，就被分配到各个测试团队里。最初的完成情况不算差，但是几个月以后，团队内部的抱怨甚嚣尘上，同时自动化的完成情况开始下滑如下。

为此，负责人专门找到团队的Scrum Master了解情况，发现事情是这样的：

由于自动化任务的完成率低，团队成员开发意愿低，任务完成率赶不上计划的进度；为了赶上计划，经理们必须安排更多自动化任务，团队的工作负担增加，由于实际的生产力并没有提升，进一步减少任务的完成率。

如下图所示，这是一个增强环路，情况在持续变坏。

由于首先被听到的声音说：自动化测试用例的任务重，难以完成，所以团队里的人都不愿意做。负责人首先关注到的变量是自动化任务的“完成率”。要提高它，就需要提供更多的人力，为此更多的开发人员也被要求开始做这项任务，希望以此改善任务的完成情况。如下图所示，但是由于开发人员本身也是有开发工作的，反而进一步降低了任务的完成情况。

这个方案还没有持续多久，商业需求部门就开始提出反对意见了。因为工作负担的增加，特别是开发人员被安排了这项任务之后，新功能的开发成本开始上升，商业需求部门非常不满意，提出要求削减工作量；他们并不认为自动化测试用例有什么商业上的价值。如下图所示，这就使得方案变得不可行了。

为此，负责人再次找团队一起讨论他们面临的现状，这时他听到了新的声音：那些被自动化的测试用例，基本上不会再被重复执行了。

特别是他后来了解到，功能测试用例只有不足16%才会被选入到回归测试当中反复被执行。团队普遍认为自动化的测试用例的收益不高。他们现在开发的产品在2020年即将结束生命周期。如下图所示，进度差异越大，自动化的测试用例越多，由于会被重复执行的测试用例不是等比例上升的，测试用例的执行率反而下降的，进一步提高团队的抱怨程度。

到此，就有了一个问题：上层提出来的95%自动化测试用例的要求，对于某部门来说是不合理的。之所以要自动化，是为了能够重复执行，那些注定不需要重复执行的用例进行自动化，是缺乏足够理由的。

因此，他们现在正在沟通这个指标问题，试图说服制定者们。如果最后成功了，那么问题就解决了，如果只是部分的成功，至少问题得到一定程度的缓解。

这里我们能看到心智模式如下：

1. 质量部门觉得自动化测试用例是一个非常好的实践，他们认为软件开发部门都差不多，应该有一个统一的高标准的追求；

2. 商业需求部门更关心功能和它的成本，不在乎是否自动化测试，只是要求时间和成本不变坏

3. 研发管理人员为了完成KPI考核，努力的提高团队的工作量，尝试使用压力解决问题

4. 开发团队感受着痛苦，努力地完成任务，然后是抱怨