第1个回答 2022-06-05
最近在思考我到底算不算是测试主管，测试主管都要做些什么，我觉得自己有点四不像，所以蛮记录一下自己的想法。
测试主管，在我们公司叫 质量保障工程师，很好理解，你就是来保障你所负责项目的质量。
所以基于项目维度：
1、制定版本计划，测试计划，测试策略
（1）版本计划，在需求评审完成后，各角色就应该输出对应的测试计划，并初步拟定一个合理的版本交付时间，如果交付时间已经有明确的限制，则从最后一个环节进行反推，每个角色的交付时间点，比如，QA是最后一个环节，则QA评估如果要按时交付，对应QA需要的测试周期，反推出开发需要在什么时间点提测，开发也以此类推他的前置（例如：UI）要什么时间节点给他交付物，最后定一个各角色都认可的计划，进行实施。
（2）测试计划，通常一个团队都不止负责一个产品或一个版本或一个事务，此时需要主管对项目事务进行分配，分配到每个组员身上，制定团队内的测试计划，每个组员都能清晰获取到自己的任务，并明确事务内容和完成时间。我现在是使用Excel，制定一个测试计划表，最左列是组员姓名，首行是日期，每一天每个人做什么都写清楚，能安排到未来多少天就提前安排，这样大家自主获取自己每日的任务即可，我也可以查阅是否有任务漏排，以及事后也好追溯对应版本的时间周期，对于重要事务优先排入计划，非重要事务顺延或插空安排，相对不容易忙乱。
（3）测试策略，这里的测试策略包含产品测试策略和需求/版本测试策略。
产品测试策略，就是基于产品所处的阶段，产品的目标进行分析，并制定出产品要做哪些纬度的测试，每个纬度的测试标准，以及产品的质量要求。产品的测试策略需要与项目内相关角色同步，比如：项目负责人，开发经理等，大家达成一致后方可执行。（为什么要跟项目其他角色同步并达成一致？因为后续在执行过程中会涉及到他们的一些数据和事务，避免大家意见不统一或标准不一致而导致项目质量和进度受到影响）
需求/版本测试策略，就是根据版本的内容和需求制定对应的测试方案，比如，开发今天做了一个服务端底层优化，那么对于这个需求，QA需要了解其设计方案，改动范围，从而评估影响范围，并制定合理的验证测试方案（如：涉及哪些接口，接口要测试，对应前端业务是否也要进行验证等，以及是否涉及到性能影响，是否要做性能测试等）；再比如，开发今天做了一个XXX功能的版本，QA需要基于功能大小进行测试评估，这个版本预估需要安排几轮测试，每一轮的测试方案是什么，是否涉及到专项测试等。需求/版本测试策略主管可以培养组内能力好的同学进行制定，主管进行评审。
2、事务优先级评估
只要团队所有人不是都在做同一件事，那势必就会有优先级。有些主管负责多个项目，每个项目可能都有它的重要程度，以及每个项目的事务又都有优先顺序，此时就需要主管进行优先级评估，保障重要紧急事务能够如期完成。
事务优先级在主管安排测试计划的时候就会体现，优先级高的事务先排，优先级低的放后，如果有临时插单的优先级高的事务，则主管对当下的事务进行调整，尽量满足各个事务的时间要求。所有我团队内的事务均有我进行分配，如果开发有临时提测，全部走我这个口，不直接对接测试同学，以便于我能把控各个事务的进度和时间合理性，也让测试同学不会被插单事务弄得混乱，组员同学只要根据我的安排依次完成对应事务即可。
也有遇到过两个项目都说自己的事务很紧急要优先安排的情况，此时只能拉两个项目负责人一起沟通，大家把自己的事务重要性进行说明，最后达成一致意见，到底谁更优先，如果真的都很重要，那QA主管是否考虑要对外借调人员来支援测试，以满足项目的需求。
3、推动重难点问题解决
项目测试过程中，总会遇到一些重点或者困难的问题，往往这些问题并非是一个职能可解决的，一般都是涉及到多个职能部门配合进行，此时就需要测试主管具备良好的沟通协调能力，能够跨团队跨部门进行协调推动。
我对于项目重难点问题的解决步骤一般如下：
（1）首先对问题进行分析根本原因
（2）制定对应的解决方案，从各角色出发，输出书面文档
（3）将文档同步至相关涉及职能负责人确认，并进行方案沟通，最后达成一致意见：是否可行
（4）若可行，则对应实施，让各职能负责人给出方案处理时间，并跟进
（5）若不可行，则评估不可行的原因是否可有其他方案替换，若仍无法执行，则先放弃对应角色方案，优先执行其他角色方案
（6）确保最后的解决方案在可以解决问题或者一定程度上降低问题所带来的风险
4、重难点技术攻关
这一点是我的短板，因为自身技术欠缺，所以在重难点技术攻关上，我需要测试开发同学的配合，大致配合方式如下：
（1）提出当下需要攻关的重难点问题
（2）主管与测试开发同学讨论可能可进行的方向
（3）测试开发同学进行调研，出调研报告
（4）主管与测试开发同学评估调研结果可行性（包含：性价比、价值等），聊方案细节，并达成一致
（5）主管与测试开发同学进行事务规划，排计划，估人日
（6）测试开发实施，主管验收
如果主管自身技术很牛逼，则可以自己投入进行方案制定和调研，最后让测试开发同学实施实现即可，这样的方式比较快捷，也不容易被测试开发同学“忽悠”，如果自身技术不够硬，那就只能让测试开发同学把方案说到你能明白，并且他能对你提出的大部分问题给出合理的回答。
5、项目风险评估
风险评估贯穿整个产品生命周期，从需求评审开始一直到发布上线，测试主管需要在每个环节对项目进行风险评估，当意识到有可能影响项目进度和质量的风险，需及时预警，并能够提出规避或优化建议。
基于对产品设计架构和程序实现架构的了解，通过分析产品遗留问题，找出产品质量风险较高的模块或功能，给予项目改进建议，弥补漏洞。
风险评估需要基于很多因素，包括产品用户量，版本目标，问题影响范围等等，根据对用户和产品的理解，提供各模块或功能质量标准的判断建议，在产品发布前协助项目负责人在质量和进度之间作出权衡。
6、项目全维度质量过程改进
通过质量过程发现质量问题，能够主动与产品相关部门进行沟通，协调项目或部门间的资源，推动解决问题，取得实际成效。
因为一个人发现问题的量是有限的，所以要做质量过程改进，最好是能够汇总大家所遇到或感知到的问题，然后进行优先级排序，再根据优先级各个击破。
目前我的方式是，每个月会收集一次团队内同学所遇到或发现的问题清单（包含：流程、部门间配合、质量风险等），收集完清单后进行性问题描述的精炼，接着进行问题归类，然后制定优先级，根据优先级排期进行解决（大致如下图片）
这些问题可以分配给团队的同学一起进行，可以指导他们做几个，主要流程和思维方式正确，剩下的就是看能力了，所以主管可以先让下面同学试试看，毕竟每个人想到的方案可能都不同，说不定会有让你眼前一亮的产出，主管做好评审以及过程中的指导还有落地实施的一些辅助工作。
测试主管，有一个“管”字，自然少不了管理的事务。
所以基于团队维度：
1、团队建设
（1）根据项目业务情况，以及测试策略，确定你的团队需要什么样的人，各多少人，然后进行配备，团队的梯度最好能保持比较正常的梯度，不要出现断档的情况。
（2）团队内的成员需要相互备份，也就是说有B岗或C岗，这样有利于团队完整和稳固，当有人离职或请假，他的B岗可以完成他的事务，不至于因同学情况导致事情被耽误而出现较大的影响，或同学不敢请假的情况。
（3）团队升级，随着测试的深入和质量的提升或业务调整，势必需要具备一些新的技能，那么在团队内部，需要引导比较好的学习氛围，大家愿意主动进行学习和分享，带动团队能力和技术的提升。（在一些特殊情况下，也可以进行强制学习，提升团队技能）
（4）在团队内尽量扁平化，不要有太多层级，避免一层管一层，导致职级高的同学反而在做打杂，擦屁股的事情，各司其职最理想，每个职级承担不同能力的事务，如果要把事务下放，需要有审核机制，不能完全放手，避免出现不必要的疏漏。
2、组员绩效制定
根据不同职级和岗位，制定合理的绩效考核，可以是KPI也可以是OKR，或者两者结合。
甚至绩效可以私人定制，目的是为了能够激励团队同学努力往上，日常事务能够跟绩效对得上，不要出现辛辛苦苦干活，最后绩效上的数据却无法体现价值的情况，所以绩效可以针对每个人的事务或者目标进行制定，但建议同职级同岗位的考核项尽量保持一致，不然无法横向对比产出和价值。
3、团队流程规范制定
无规矩，不成方圆，所以一个团队一定需要一些流程规范的束缚，并且需要有效执行
最基本的几个，BUG提交规范，测试反馈流程和规范，测试流程
当有了流程和规范，就是如何更好得执行，可以在绩效中增加相关的流程执行扣分项，当出现流程或规范未执行，绩效中相应进行扣分