少走弯路，测试团队管理是怎么做的？

海上孤帆

区别于测试团队的其他测试工程师，测试负责人（测试主管、测试经理…）不仅要承担日常的测试工作，也要管理测试团队。测试负责人最终是要保障生产环境的产品质量的。以下几点是很重要的：

1. 区分事情的重要性、优先级，抓核心的、重要的事情，解决核心问题，切忌凡事恨不得事必躬亲。例如一个产品需求既有主干流程，也有细枝末节。作为测试负责人，在测试用例设计之前，就要分析出核心的测试需求，测试团队的其他小伙伴在测试需求的基础上去扩展更多细枝末节、分支用例；此外，测试负责人也要去验收这个产品需求的核心功能、核心流程，保障核心功能、核心流程不会出现问题。

2. 所谓管理，“管”就是分配资源，“理”就是明确激励机制、追责机制，让组织中的每个人自己动起来，让组织流动起来。测试负责人最该做的，不是追在别人屁股后面做监工，每天逐个人逐条事项的监督，而是要明确目标，建立机制，并让这个机制运转起来，最终在项目组形成一种良性的循环机制。例如搭建能够提升测试团队共享协作质量和效率的平台、制定测试团队的工作规范。就像给测试团队编写一个函数，测试团队的小伙伴给定输入，就能产生预期输入。具体如测试流程规范、测试用例设计的规范、测试用例管理（meterSphere、在线流程图、思维导图等）、测试环境维护和治理规范、产品发布规范（上线checkList是必不可少的）、API自动化的脚本编写和管理规范等。一个小技巧，可以把优秀的测试用例范本，作为测试用例的规范示例。

3. 根据每个公司、每个团队的实际情况，不断优化测试流程（测试流程可参考博文 软件测试流程）。适用于一切项目的完美流程是不存在的，在实际工作中，我们还要根据每个公司、每个项目的实际情况针对性地优化测试流程（不断优化测试流程也是中高级测试人员的素质之一），比如有的公司需求设计的问题比较多（需求功能遗漏、需求设计逻辑Bug、需求对用户的意义不大），那需求评审环节、测试需求分析环节就要多花时间去提出需求设计上的问题，提醒产品同学补充遗漏的功能、改进有逻辑缺陷的功能、砍掉对用户意义不大的不必要的需求等；再如，软件常见问题反复出现，那就需要整理一份软件常见缺陷的checkList（其实就是用例设计中的错误推断法），作为每次迭代，用例设计完后的查漏补缺；再如，测试环境没有问题，生产环境时不时出现问题，那么就需要增加预生产环境的测试，以及加大生产测试的比重；接着如，生产测试也无法保障产品在生产环境的质量，那么也很有必要增加生产环境的质量监控。优化测试流程，总的原则就是哪里薄弱优化哪里，哪里问题多优化哪里（步步高点读机，哪里不会点哪里）。注：流程中要把握几个关键环节的交付物和时间节点，让流程固化下来，不流于形式，有的环节要提供模板文件，这是流程的重要价值之一。

4. 测试团队培养和激励、授权。产品质量不能只靠测试，更不能只靠单个的“测试牛人”，测试团队的质量上去了，产品质量也会相应提升。要提升测试团队的质量，培养测试团队就非常重要。秉着“科学的学习”信念，我推荐的一个测试团队培养方法是基于最优秀的教材（例如“极客时间”、“小D课堂”等优质学习资料），测试团队去学习并组内分享，并且更重要的是，应用在日常工作时间中。通过日常工作，去真正理解、真正掌握所学所知。人员激励也非常关键，我暂时理解到的激励方式是带小伙伴学习、成长以及鼓励他们。关注他们的成长、及时给到反馈。此外，部门团建也是有重要意义的，和小伙伴一起玩耍（爬山、吃饭等），既能拓宽自己的眼界（每个上进的小伙伴都会有让你眼前一亮的思想、信念、观点的），也能增进彼此的信任，更高效保质地完成工作。

5. 项目开发中的风险点分析（时间节奏的把握）以及项目上线后的风险分析。例如对项目上线的风险点分析，主要分析影响面大的基础数据，结合业务和程序处理逻辑可能出现的差错。比如服务端发版过程的新老数据转换、有版本概念的新老数据过渡以及其他影响面大的功能点可能带来的风险。

6. 生产质量保障。上线前，测试过程中的风险把控（测试流程的各环节的风险把控）；上线过程中的风险把控（checkList)、灰度发布和生产回归测试（别人接触不到，我们能接触到）；上线后，（1）线上监控，预警平台（硬件级）、ELK系统（代码级）、业务数据平台（业务级），（2）线上问题跟进和处理，评估问题的严重程序，应急处理。热更或回滚。

7. 大QA意识（QUALITY ASSURANCE/质量保障），只要是不利于项目质量、影响大的问题，都可以提出来，比如项目团队的流程问题、系统日志监控等。就算QA提不出解决方案，也要先把问题提出来，问题提出来了，团队里才会有意识去解决。提问题和解决问题是两回事，怎么解决问题不是一时半会的事情，但反映问题是可以很快完成的。