相比于上一篇文章的技术推进，这一篇文章以管理推进的角度出发，应该会有更多的讨论和争议吧，毕竟涉及到管理落地时，比技术落地更要复杂，远比一项技术取得成果更为困难。

上一篇文章提到，写这些文章的初衷，是因为看到目前太多的公司在测试上投入很大精力，很多测试同行在自己公司中十分努力的推行测试体系，但收效甚微。转而想到了，如果我们仅仅考虑技术，从测试管理角度，我们只做了其中一个部分，技术是提高生产力的，而管理是发挥每个人的长处，且让信息在组织中保持通畅、一致的。那么我们就基于这个思路聊一聊如何进行测试管理。

首先，我们考虑公司文化，项目流程及质量现状。什么意思呢？具体的问题，比如公司当前上线的质量是好还是不好，公司当前的项目模型是瀑布还是敏捷，再比如公司大致一个项目版本的周期是多长。我们仔细思考这 3 个问题，其实是从结果，模型及周期给了我们初步的答案，后续，我们就该从这几个问题中着手进行解答并且推进了。

推进时，测试 Leader 一定知道，当前所有的活动都是为了质量提升负责，也就是说，对于自主研发型公司而言，上线结果不好，就是有问题。所以，本着以终为始的思路，首先建立不同环节的准入准出，就成为了第一要务，当然，要结合现状。

朋友小 A 的公司，领导是研发出身，认为研发做得好，质量就上去了，测试人员能力过得去就行，所以大力提倡研发人员对于质量的考核，但仅仅在考核上做文章，而相应的流畅标准，如何检查并未有效到位，结果自然不言而喻。

而朋友小 B 的公司，领导是市场出身，不懂研发，但就要求对于客户有好的结果，所以对于上线质量要求很严格，认为出了事就是测试有问题，也有些过于偏激，毕竟其实质量是团队的事情。所以，测试体系的出发点，应该从准入准出入手，下方以一个例子来说明。

公司流程：研发完成后提交测试 → 测试首先在测试环境进行验证 → 通过后可进入预发布环境 → 通过后可以进入生产环境，

这里提到的关键词是通过。研发达到什么程度可以提交测试？是做完就可以，还是说自测完成就可以，那怎样认为研发完成自测并且就绪？保证了哪一级用例的覆盖？通过率达到多少？同理，测试环境通过率达到多少可以进入下一个环节，bug 级别高于哪个等级就不能通过。预发布环境通过率达到多少可以进入下一个环节，bug 级别高于哪个等级就不能通过，几天之内无重要 bug 出现才可发布。

有的朋友可能会说最后一点有些难度，毕竟实施下来的公司不多，但是仍然有大部分公司再实施并且收效很好。这其实代表了当前版本是否已经足够稳定并且团队是否有很足的信心。

这里，我们如果按照此思路，则已经初步建立了第一个层面的测试流程，下来，就是让技术和管理结合的更紧密。
1，文档规范
内部：包括但不限于测试方案或者测试大纲，测试用例，测试报告，Bug 级别规范，Bug 提交规范等等
外部：设计相关文档（PRD 及原型），研发相关文档等等
2，时间要求
内部：测试方案完成时间，测试用例提供时间，测试人员投入时间，测试计划完成时间
外部：需求确定时间，提测时间，服务器就绪时间，交付时间
3，不同层级的测试
如：单元测试 100%，接口测试 100%，UI 测试 30%
4，不同程度的标准
如：研发修改代码后，执行相应的单元测试、接口测试应该全部通过才可合并代码
如：每天晚上定时部署后，结果应该高于哪个指标之上
如：日构建，每天提交的版本一定是无阻塞性问题的
如：Bug 日清，规定 4 点前测试提出的中级及以上问题必须解决
5，对于考核的影响
如：自测后，提交测试时，阻塞 bug 需要低于多少，Bug 数量需要低于多少，BugReopen 率应该低于对少
如：上线后的质量应该达到什么程度，若有问题相应速度应该达到什么标准。
6，对于和研发团队的沟通
之前一个同事说，有些话如果能让他们自己说出来，他们会更认同，起码也得让他们认同了，我们再推。这个非常认同，但是很难。大部分做事有 2 种，一个是自下而上的，当然这个同事的观点也是这样。另外一个就是自上而下，不同的时候用不同的技巧解决不同的问题
自上而下的推进，是我们要让测试体系和公司整体的体系结合起来，是要从全局的角度提出对于质量的要求，对于过程的控制，是要本着一切以用户为核心的考虑并且解决问题。自下而上的推进，则是以点带面，以人为本，从小大到，从 1 到 2 的做法。比如有些改进我们会先在 1 个业务线或者 1 个项目试点，待这个改进产生了明显的效果，通过对比看出来和其他未改进项目的差异，则可顺理成章的扩大化的推进改进点，这就是典型的自下而上的做法。

所以，当我们做到以上这些时，当我们有了规范、有了标准、有了流程、有了目标，已经是一个比较完备的测试体系了。接下来，我们需要持续改进，让流程、体系、效率变得更佳。比较多的有 2 种思路。一种是以结果分析触发，比如测试针对每一个版本给出测试分析的数据，客户反馈问题的多少、是降低了还是升高了，各级别的反馈数量具体多少，项目过程是否缩短了。再比如：以过程分析触发，同样时间内，团队完成的工作量是否增加了（比如敏捷团队中的 point），每一个版本发现的 Bug 数量是否有明显的下降趋势，哪一个模块的 Bug 数量最多，哪一种类型的 Bug 数量最多，Test Cycle 是否健康，项目是否持续报出较多风险，整体 Delay 情况如何。一句话，数据是不会骗人的，通过数据来找答案是最好的方式。但是这里需要注意的是，基于数据的分析，要保证数据对比的同纬度，这样才不会做到被数字欺骗。

最后，我们再从项目管理三要素上来做一个相对简单点的总结。

质量、范围、成本是大家一直认可的项目管理三要素，被众多教材引用，被无数学者探讨，但是这 3 个标准是否还适用于今天这个快速变化的世界。记得之前看一本书叫知行合一，从斌老师编写的。里面提到的观点让我非常认同，受益良多。讲的是对于衡量项目是否成功的标准来看，我们重新定义项目三要素，没错，是质量、价值和约束。

质量讲的是我们交付的东西，对于用户或者客户来说，是否达到了承诺的标准
价值讲的是项目是否达到了应该达到的价值。这里的价值是从组织或者客户，而不是从项目角度来看的
约束，指的是项目是否在给定的条件内完成？他可能是时间，也可能是成本。而约束并不是目标，而是前提

所以，最终我们来看测试管理是否好了，是否当前算是合格的，我们要看
1，我们是否给客户交付了高质量的产品
2，我们是否代表了用户的视角、提高了用户的满意度及项目的商业价值
3，我们是否能不断提高效率，不断提高质量，让我们更快更好
如果以上这几点我们的答案都是 OK 的，那么我相信你的体系一定会健康的。