为什么不直接让开发兼任测试？

大家好，我是陈哥。

不知道大家看没看过这个问题：

既然测试也要求写代码，那干脆让开发兼任测试不就好了吗？

这句话听上去像是测试人员被要求写代码的气话，但我之前在《做软件测试需要懂代码吗？》一文中讨论过为什么现在各个公司都开始要求测试写代码，大家感兴趣的话可以去看看。

借着这个问题，我想和大家继续聊聊：为什么不直接让开发兼任测试？

说句实在话，对于大部分企业来说，这想法太理想化，真落地准出乱子。

开发和测试的核心价值和工作逻辑压根不是一回事，硬把俩角色捏一块儿，最终亏的是产品质量。

一、思维惯性是道绕不过的坎

开发和测试最大的区别，不是会不会写代码，而是思维方式的根本对立。

开发是建设性思维，拿到需求就琢磨怎么实现，怎么把逻辑搭得通顺，怎么让代码跑得高效。

我们禅道团队有一套自己的产品研发流程，我们会要求开发在迭代时进行自测。

但在这种思维下，开发在自测时会不自觉地按照自己的实现路径去测试，很难跳出既定框架。

测试不一样，他们是破坏性思维，核心目标就是找出软件的漏洞。

我本身是测试出身，我当年做测试的时候，拿到一个功能一般先想的不是怎么用，而是怎么用才能把它搞崩。

就像一个登录按钮，开发自测的话一般确定账号密码正确能登、错误登不上就觉得完事了，但测试可能会测连续点五十次按钮会不会卡顿，测用空字符、超长字符串当账号会怎么样，测在弱网环境下登录失败会不会提示错乱。

二、测试的核心价值不止于写代码

现在很多人觉得测试要求写代码，就和开发没区别了。

这话只说对了一半，写代码只是测试的工具，不是测试的全部。

测试的核心能力是场景设计和质量把控，这些能力和开发的技术实现能力完全是两码事。

就拿自动化测试来说，开发写自动化脚本可能比测试快，但测试写的脚本更有针对性。开发写脚本会聚焦于功能实现逻辑，而测试写脚本会覆盖边界场景、异常流程。

我们团队之前做性能测试，一个开发写的脚本只测了正常并发下的响应时间，而测试补充了峰值并发、突发流量、长时间运行后的性能衰减等场景，最后发现的内存泄漏问题，正是在长时间运行的场景下才出现的。如果只靠开发的脚本，这个问题到上线都发现不了。

测试还要懂业务、懂用户。再说回禅道产品研发流程，正是基于这点，我们在计划会阶段会要求测试人员去做需求的测试实例化。

我们让测试人员立足于用户操作场景，以“在什么情况下、做了什么操作、产生什么结果”的形式澄清需求，从而转化为测试用例，最终通过测试验证需求。

如果大家对这个流程感兴趣，备注【流程3.0】扫码领取资料

这种对用户的理解，不是会写代码就能具备的，是测试长期站在用户角度思考积累的能力。

而且测试要对整个产品的质量负责，这种全局观开发没有。

开发通常只关注自己负责的模块，而测试要打通整个业务流程。

举个网购下单流程的例子，这涉及商品库存、购物车、支付、物流四个模块，每个模块的开发只测自己的部分，但测试要从选商品、加购物车、下单、付款到查物流整个流程走一遍，还要测其中某个模块出问题时，其他模块会不会受影响。

三、独立测试是团队协作的压舱石

有人说让开发兼测试能提高效率，其实恰恰相反，会严重影响团队效率。

开发的核心任务是写代码，让他们兼测试，必然会分散精力。

更重要的是，独立测试能形成有效的监督机制。这就像我们在学生时代检查不出来自己做错的题目，写代码也是一样。这种监督不是挑刺，是对产品负责。

众所周知，Facebook程序员的水平高于业界平均水平，他们有足够的能力同时做好开发和测试工作。

再这，Facebook在功能发布之前，会先发布到内部环境中，几千内部员工先测试。这看着是没有专职测试，但本质上是把测试的能力拆分到了不同角色里。

开发和测试不是替代关系，是协作关系。

开发负责把功能做出来，测试负责把好质量关，两者目标一致，都是为了做出好产品。

现在测试要求写代码，不是为了变成开发，而是为了更好地履行测试职责；开发参与单元测试，也不是为了替代测试，而是为了提高自己的代码质量。

真要是把两个角色合二为一，看似省了人力，实则丢了质量，最终只会捡了芝麻丢了西瓜。

如何划分开发和测试之间的职责，这就是另外一个我们值得探讨的课题。

如果大家对此感兴趣，可以备注【流程3.0】领取禅道产品研发流程规范，看看禅道的开发和测试都在干什么。