从测试看研发管理
老帅
事情源于工作中最近一次对研发流程的优化，原有流程是这样的：
问题出在编码结束阶段，编码结束后，在业务部门进行测试的时候，发现程序不能正常运行，无法开展测试工作。这自然是不合理的，会影响业务部门对研发部门的信任、还会影响业务部门的工作积极性，这都是要不得的，如果得不到重视，会影响企业的长久发展。
当然这个问题很容易解决，只要研发这个环节上增加一道测试流程即可，下面就是优化后的流程，但我们讨论的重点不在这里，先看一下优化后的流程：
我想展开来讨论的是，关于研发自测这个环节为什么我们开始没有加上？这是因为，我们一般认为研发人员对自己开发的模块进行自测，是应该的，用研发术语来讲是默认的，不需要另行强调。程序猿的工作是团队协作中的一环，和环上的所有人一样，都应该对自己所做的工作负责，这样对于环上的其他人才是公平的、有效的，团队的整体效率才能提高。
但研发团队的水平总是良莠不齐的，这也是有原因的，无论从团队组成上、还是成本考虑上，都不可能全是高级程序员，所以抱怨是没有意义的，这根本不是程序猿的错，谁都是从新人做起的。
从以往的经验中和不断发现问题、讨论问题中，我们发现对于流程设计一定要谨慎，不是说有了流程就行了，关键还要看效果！要充分考虑其负面因素。比如说，这个流程节点是研发自测好，还是验收测试好？
研发自测的缺点就在于程序猿的自测水平也是良莠不齐的，很可能有些问题不能被发现，还是到了流程的下一个环节手里，仍然会发生本文开始谈到的问题。
那么基于此，我们思考，至少可以有两种办法来完善这个流程：
1、研发内部验收
2、设置专业测试岗位
我们先来讨论研发内部验收。由专家人物参与的研发内部验收，一定能极大的增强功能研发成熟度，这个自不必说。但这种方法其实是要不得的，为啥？首先，会打击程序猿的积极性，产生不被信任的感觉；另外，也会使程序猿产生惰性和依赖感：”反正有专家呢，我不必负责“；从企业整体角度看，专家是企业的稀缺资源，应该善用，决不能纠缠在太多细节上，无法脱身出来。这么做无异于饮鸩止渴！
我们再来讨论设置专业测试岗位。术业有专攻，专业的测试人员，能提高功能研发成熟度，是毋庸置疑的。但同样的，专业测试人员，也是不希望拿到漏洞百出的程序的。而且在企业的发展阶段中，由于财务和管理成本等因素，也要酌情考虑是否要设置这个岗位。
所以，最终，有些问题，我们是绕不开的，那就是提高程序猿的基本职业素养，而这不是一朝一夕的事，更不是通过求全责备或者埋怨就行的。我们终归需要建设一个良好的研发文化，通过流程和制度建设来一劳永逸的解决我们的问题。让程序猿在其中不断成长，在每一次成长后，都遇到更好的自己，更好的服务于企业。具备成长能力的企业，才是真正有力量的企业。就像大海无惧局部浑浊，在其自我澄清能力面前，终归清澈！