简易研发管理流程

近来被派到XX公司学习，我很奇怪，一个快被淘汰，干什么都不让人满意的人，还会被拍出来学习。有觉得浪费公共资源的羞愧感。

昨日按计划原定是想找测试部门的负责人，学习了解XX公司测试流程、如何提升测试质量、如何对测试人员进行考核等问题。经协调，与一个叫*姐的人对接。

*姐在了解的我的来意后，问道：“你知道我的职位是什么吗？”我说：“我的要求是和测试团队的负责人进行交流学习，所以我认为您是测试团队的负责人”，*姐说：“你都不知道我的职位是什么，你就来找我？”场面一度非常尴尬。然后*姐问我，你现在遇到了什么问题。我说，我带领着一直研发团队，研发的效率和质量如何提升是我直接面临的问题。我们的产品迭代过程中，测试周期很长，经常和开发周期相当，而且上线后经常会发生一些质量问题，追究下来测试和我说没测试到，也没办法全测试到，研发说写代码本来也就无法保证100%不出问题，无人承担责任。如何解决这个问题，如何对测试过程进行管理，如何考核？

*姐轻蔑的笑了笑，开始了他犀利但深刻的方法论：

产品的质量把控，不在于测试。测试是整个产研周期的最后一个环节，它对产品的理解是最低的，对产品理解最深的是产品经理，然后是研发，最后才是测试。所以要解决研发效率和质量是一个环环相扣的体系，要从最开始说起，也就从产品经理开始。

*姐询问我们是否有需求评审环节，研发测试是否参与，并在了解岗位配置情况后，*姐再次轻蔑的笑了笑，你们的产品经理太好当了。也许你们的产品经理在产品和逻辑思维上确实很出色，但是在项目管理，落地执行的环节上出了问题。由研发来拆解需求功能点，是错误的。这是你工作糊涂，领导搞不清你到底在做什么，对效率不满意的关节点。需求拆解成功能点，必须由产品经理来执行。当一个需求拆解成功能点后，大致的开发周期其实就已经出来了。

需求拆解成功能点，一般分为三级：

[if !supportLists]1. [endif]一级是功能模块，例如你做APP,需要有用户注册、消息推送模块，这个是一级需求。

[if !supportLists]2. [endif]用户注册需要有用户信息填写、短信验证等功能，这是二级功能。

[if !supportLists]3. [endif]短信验证有具体的验证逻辑，例如手机号验证、重复提交等，这是三级功能点。

一般来说，在XX公司，二级功能，执行时间一般是1-2天，你们要弱一些，但不能超过3-5天。

所以，通过需求文档的功能拆解有四个好处：

[if !supportLists]1. [endif]方案清晰，评估准确，评审起来很舒服，不会遗漏功能。

[if !supportLists]2. [endif]在你大致清楚一个功能点的开发周期后，研发也没有太多扯皮的余地。当然你要相信你的研发团队，具体情况还是要具体评估的。1-2天或3-5天只是一个大致的标准。

[if !supportLists]3. [endif]便于测试编写测试用例，测试覆盖面会很清晰很全面。

[if !supportLists]4. [endif]需求拆解颗粒度越细，约便于你统计研发质量。但是和执行效率要找到一个平衡点。所以推荐最多不不超过三级，二级对于你们来说也可以。

基于产品需求文档对功能点的拆解，我们可以通过一个公式，构建一个概念，来评估研发质量，这个概念叫缺陷密度：

缺陷密度=∑（测试提交缺陷*缺陷权重）/需求总数

缺陷密度越大，研发质量就越低。所以通过这个指标来了解你的研发团队开发质量情况，对比不同团队的执行情况。但是*姐再三强调，缺陷密度是一个浮动很大的范围，你可以作为了解研发团队质量的一个感性认识，但不合适做为KPI进行考核，因为这里有一个漏洞，需求总数越大，缺陷密度也就越低。但我反过来想，研发为了降低缺陷密度，在固定的时间里，完成了更多的需求，也达到了驱动研发提高开发效率的目的。

然后*姐问，你们研发做单元测试吗？我说，我要求研发做冒烟测试。*姐再次轻蔑的笑一下，你是不是不懂？你们总共做几轮测试？我被问懵了，我说，测到bug,就改，改完接着测，还有问题接着改，直到测试通过。*姐说，你们太不专业了!

测试不应该是一个功能一个功能的提测，而应该是一轮一轮的集中测试，并且最多不应该操作三轮：

[if !supportLists]1. [endif]首轮测试发现问题，提交研发修改。这里是要指出的是，测试出的问题，不用等所有功能测试完。发现问题就提交研发修改，但研发修改完成后，必须是提交的所有问题修改完后，在提交新一轮的测试。

[if !supportLists]2. [endif]研发全部修改完成后提交测试进行第二轮回归测试，这个时候可能还有一些小问题，提交研发最终调整。

[if !supportLists]3. [endif]最后一轮，研发调整完成后，提交测试再做最终测试。这个时候应该没有太大问题了。如果还有问题，视情况就要对研发进行处理了。

通过三轮测试，有三个好处：

[if !supportLists]1. [endif]约束了研发的态度。我们现在经常出现一个问题，研发做完，也不管做得怎么样，他们奉行一个理论：开发出Bug是正常的，测试就是负责找Bug的，找到我再改就是了。于是就出现我做你测，测完我再改，改完你再测，无数次重复。测试疲于应付，研发没有管控。

[if !supportLists]2. [endif]提高了测试效率。轮测制度，其实给测试空出了很多时间，这些时间首先是研发自己做单元测试，以免超出轮测次数，提升了研发的责任心。其次测试空出来的时间还可以做很多其他事情。*姐说，你以为测试就是做测试吗？测试要做用例设计、需求评审、自动化代码编写、然后才是测试执行。

[if !supportLists]3. [endif]提高了测试质量。因为是轮测，测试就有了明确的测试范围，不会被几个细节给干扰，碎片化的测试会导致测试系统性不够，对测试质量会有很大的影响。

谈到这，*姐说，最后才是你的问题，当线上产品出了问题，你要追责，“你的测试说我没测试到，我也不可能什么问题都测试到。研发说，我的代码也不可能100%不出BUG，于是不知道该谁来承担责任。只能自己顶着头挨骂“，这个时候，你就很好处理了，你问测试两个问题：

[if !supportLists]1. [endif]你的测试用例覆盖了没？

[if !supportLists]2. [endif]产品的需求写到了没？

测试根据产品的需求编写测试用例，如果产品写了这个功能，定义清楚，那么就是测试用例没有覆盖到，是测试负责。如果产品需求连这个功能点都没有定义，那就是产品的锅。很好界定。

*姐说，你不是学计算机的吧，我说我是计算机科学专业的，*姐说那你这么连这个都不知道。你哪个学校的？

*姐说，我有个问题想问你，今天你是遇到了我，你掌握了这套流程，要是今天你没遇到我呢？你还要花多少时间来掌握？这些东西不是我原创的，它就在网上！

侮辱性不高，但伤害性极大！

*姐说，聊下来，我们两的岗位很像，你要学两个方向，第一软件工程能力，工程能力很重要。第二是质量管理。我说哦。

当*姐听到我在准备考项目经理的时候，*姐说，很好，可以去考，对你会有帮助，但是你们不要招项目经理，对于自研产品的互联网团队来说，产品经理其实就涵盖了项目经理的职责。

然后我说，我问问关于CI/CD的情况你会说吗？郭姐轻蔑的大笑起来，不客气的说，你们现在就是个小作坊，基本流程机制都没整明白，硬套CI/CD，不会对你们的效率有任何帮助，反而是个拖累。我再说一遍，今天你是遇到了我，你掌握了这套流程，要是今天你没遇到我呢？你还要花多少时间来掌握呢？这些东西不是我原创的，它就在网上！你懂吧？

我说我懂，我之前就是到处扑火，疲于奔命，我知道我要跳出来，才能彻底解决问题，可是我一直跳不出来，认知层面太低。*姐轻蔑的笑了。

*姐最后说，你还是很有领悟能力的，一般人，听我说这些，根本领悟不了，你刚才总结的很到位，我说，因为这一切就是我每天都在面临的问题，所以你一说我就特别有感触。

*姐说，再见。就不送了！