测试研发管理

低劣的研发质量改进是如何降低研发效率的

质量改进，期望通过过程的改进让事情变得更简单不容易做错，而不是更复杂。但往往，质量从业人员应避免用经验和局部立场去考虑问题，导致越改越低效，还无法有效的问题。...

前段时间，微信一篇文章陈春花教授的文章《管理要为经营服务》，其中提到一个观点： “管理始终为经营服务，但要搞懂两点：第一，管理要做什么，由经营决定，不是由管理决定；第二，管理水平不能超过经营水平。如果一家企业的管理水平超过了经营水平，这家企业一定会走向亏损”，第一点好理解，但第二点，我是不太理解的。特别在百度搜索了一下：管理，是指管理主体组织并利用其各个要素（人、财、物、信息和时空），借助管理手段，完成该组织目标的过程。按此解释，管理水平可以理解为，利用各要素，完成组织目标的过程质量。因此，德鲁克谈管理的目标，提升效率、降低成本，实际可理解为管理过程的质量衡量的标准。如果按此方向理解，管理水平高难道不好吗？

但实际上，在大家感受中确实充满痛苦的印象。比如：就一个几十人的小公司，还把华为的IPD流程全套引入然后僵化执行，配置一堆额外的职能人员。又或，没流程以前很方便都可以走完的事，结果现在搞了个流程，一堆人审批，几百块钱的事，还要董事长审批。还有，一个几个人1个月就完成的项目，以后也不会维护了，还要写一堆文档，开一堆评审会。总之，在很多人感受中，流程、管理其实就是把简单事情搞复杂。其实，

管理的目的有两个：提高效率和降低成本。

经营的目的有两个：完成生产要素的流动，实现增值。

上述案例，其实是打着“提高管理水平”的旗号，干的确实“降低效率”的事情，与管理背道而驰。

研发质量管理中，经常会接触到研发流程改进，本来目的是希望是让事情变得简单，做事的人不容易出错，预防缺陷的发生。但人们通常习惯性地去判断某些行为的对与错，所以导致管理行为无法产生有效的结果。

这里以一个各研发企业都会遇到的场景，谈谈我的思考。

无论哪个企业都会有bug处理流程，一般过程如下：

研发提交测试代码-> 测试进行测试->登记Bug -> 原因分析 -> 修改方案 -> 影响性分析 -> 修改 -> 测试 -> 测试组再测试。

这里经常会出现几个问题点：

1.研发提交的代码质量太差，测试发现很多简单错误，于是测试部认为提测前研发应先自测，保证提交给测试的产品保证基本的质量。

此处通常的改进方案：开发提测前提供自测列表，保证自己提交功能自测都通过了，然后再提交给测试。

2、测试回归，多轮还是无法通过测试。主要是bug没有完全修改完全或引起新的bug的引起。

此处改进方案：1、为什么会没改全或者引起新的BUG呢？因为，修改没有做好影响分析，因此修改代码时，修改方案或影响分析，应对修改方案进行评审并且代码也要进行复审，然后再提交测试。2、倒逼，只给测x轮的机会，如果x轮不过要特批或重新排队。

就上述的2个问题点解决方案进一步分析：

第一个问题的解决方案，会有一些副作用。比如，本来增加一轮可以发布了，但由于此机制导致不能发布，需要增加：领导审批、计划重排。最后无法正常发布，延期，产品经营受损。另外，倒逼的前提是，假定研发的质量差，研发的过程能力，本来研发应该进行设计能力、编码过程的改善从源头提升交付质量。但实际情况很可能是，为了X轮可以过，研发会增加自测的时间。因此，看起来好像测试部门的测试时间缩短、轮数减少，但其实整个流程周期、人力投入并没缩短。经常也会出现，研发自测通过，测试不通过的情况，于是又会引发测试、研发相互指责。全局看并没有本质的提升与优化，反而把事情搞复杂、效率低了。

第二个问题点改进方案，可能根本解决不了问题，为什么呢？我们回顾一下：之所以多轮测试->因为回归不过或者新引入的Bug->原因的确是开发组的测试不充分导致的本身交付物的质量不高->而测试不充分的原因，有时间压力的成分，但是另外一个重要的原因是影响性分析不足之外。而影响性分析不足的原因是人的能力不足——但几乎高手也不可能分析的很全面。这才是没有达到效果的主要原因。第二个原因是测试覆盖不全，测试在进行回归时，往往也不是所有用例都测，而是挑选可能影响的用例进行测试。

因此，上述的解决方案凭经验看视乎是很合理的，但实际上降低了效率，其实也没有完全解决问题。

因此，根本的改进方案应该是：

1、每次改动后开发把所有测试用例都跑一遍，自然可以避免提交给测试后不会引入新的bug。

2、开发测一遍，测试再测一遍，结果又不一致，其实是降低效率，浪费工时的。因此，最好的方法是建立标准一致的“测试自动化”环境，开发、测试采用一致的自动化测试结果，开发测完，研发不用再测了或者只需要增加自动化无法完全覆盖，任需人工确认的部分即可。

因此，改进方向是提升测试自动化水平与效率。而不是去延长流程环节。

测试代码自动化，还可以有效的消除等待的浪费。使得，测试与开发进行异步配合工作模式。

比如：在正常的流程中，回归测试时，开发修改代码，修改完后提交测试测试执行测试。此时，测试需要等待开发完成代码修复才能开始bug的回归工作。如果测试能实现用例自动化，完全可以与开发并行工作，开发改代码时，测试将需要执行的用例自动化，然后自动化后的用例就不用再执行了。如此，开发与测试，不是一个串行的工作而是并行的模式。整个流程的效率会大大的提升。

通过流程图对比可以发现，自动化程度越高，流程运行周期越短。而且，二次bug的问题也能根本避免。通过引入新的技术与工具，实现流程运作的又快、又好。

从此案例，也可以看到，作为研发质量改进人员，不能只盯着人与工作关系以及简单依据质量管理体系的原则，简单依据经验去思考问题。需要广泛的学习新的工程技术与新的工具实践案例，才能真正实施有效的过程改进，确保质量、进度、成本均做到了最优。

否则，所谓的过程改进，往往确实会让事情更复杂，效率更低而且还解决不了问题。其实，不仅仅在BUG处理流程，再其他环节也存在类似问题，比如在需求分析。后面文章再做论述。