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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • 发表于:
  • 原文链接:https://kuaibao.qq.com/s/20181203G13KJD00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。

扫码关注云+社区

领取腾讯云代金券