测试角色在项目各阶段的项目管理tips

一、前言

二、现状及思考

三、详谈测试介入各阶段的项目管理tips

四、暴露风险最终与协作方共同确定运作策略

五、总结

资料获取方法

一、前言

项目管理是一个繁杂的过程，每个阶段需要涉及到不同人员、资源的协调配合。每个角色都有自己的定位和任务，为了紧密配合项目经理或无分配项目经理运行项目的场景下确保项目成员共同达成项目目标，不同的角色掌握相应的项目管理意识就尤为重要。

那么，测试角色作为项目交付的质量把控者，具备相应的项目管理意识在项目的高质量、高效率交付目标上有着重要作用，如前置识别质量风险、进度风险等。

本文旨在梳理、谈论测试角色在项目各阶段如何评估测试范围及风险、前置暴露问题以及推进测试进度等项目管理事项，高效协作及交付测试角色产物，最终与项目各方共同推进达到高质量、高效率交付的目标。

二、现状及思考

在现有敏捷迭代快速交付模式下，针对某一需求/项目会拆分至各个团队，各个团队节奏及交付目标不完全一致，且无项目经理角色跟踪推进的情况下，存在后置与协作团队沟通确认事项，如：未拉齐依赖方排期、前期未识别出改动系统、需求/设计变更未及时同步相关方、无设计方案沟通导致提测内容不满足提测标准，等均可影响交付节奏。那么作为测试角色的我们可以做哪些事情？

核心主旨：高效沟通协作，提前思考后续阶段较容易影响进度、质量问题及风险点，暴露问题，前置沟通、评估及推进相关事宜；避免问题后置暴露在测试阶段；下一章节就让我们来详谈各个阶段测试角色可提前关注事项，与各方高效协作共同推进解决的相关tips。

三、详谈测试介入各阶段的项目管理tips

3.1 需求评审阶段

软件测试的第一步就是需求评审，只有对软件需求做了准确、完整的评审后，才能对接下来各种测试工作的开展做好基础，如需求评审理解偏差，后期很多测试任务都将会受到影响。

需求评审完成需了解哪些信息：

优先级——识别项目/需求重点程度，优先级，以及期望上线时间情况（定位后续跟进力度）
需求背景——该需求基于什么业务背景改造（便于需求理解不偏差及后续测试阶段重点关注的核心目标）
改动范围——评审改动范围基于现有系统是否有冲突、是否明确合理，是否影响其他系统，也可关注下体验问题（避免后续开发测试阶段流程不通返工）
识别改动/交互系统——明确该需求是否涉及其他系统改动，识别改动系统/是否需配合联调系统（识别改动系统前置协调拉齐相关系统周期，避免后续阶段临时协调资源情况）
测试节点——软件需要进行哪些方面的测试，如功能测试、联调测试、回归测试、性能测试、稳定性测试、兼容性测试、安全测试等
测试环境——明确交互系统是否支持测试环境联调（可前置协调/前置确定联调方案，避免后置沟通确定环境占用测试周期）
测试数据——根据改动范围思考测试数据来源，识别是否可内部闭环造数，是否可使用测试小工具
测试方式——可前置思考使用功能测试、自动化测试
测试人员——识别测试干系人、明确主测试方（如重点项目/需求需要主测试情况）

3.2 设计评审阶段

设计评审为评价设计满足质量要求的能力，识别问题及提出解决办法。设计过程中越早增加质量保证活动对最终设计效果的影响就越明显。目前较大项目/逻辑较复杂需求/研发优化，均需研发输出设计评审文档并邀请测试参与涉及评审。

设计评审时需要check的内容：

设计思路满足需求——结合需求背景及内容优先关注设计思路是否与需求评审阶段理解的有偏差
设计内容是否存在遗漏——评估是否存在遗漏功能
关注实现方式——实时、异步等处理方式对后续测试排期、方式及测试难度有参考价值
评估改动设计影响——基于原有系统改动除本次需求修改内容是否影响原有功能，是需明确影响范围，研发侧输出影响范围
明确阶段范围——根据需求是否存在拆解阶段交付，是需明确各阶段交付内容
交互方/依赖方实现方式——关注交互方/依赖方实现方式
UAT/灰度/上线方案——根据上线特性，前置沟通UAT/灰度/上线方案

3.3 排期阶段

排期阶段是项目管理中重要的一环，时常在此阶段会暴露一些风险，排期容易出现两个问题，一是排期不合理，二是后续不能按照排期稳步推进，好的排期就要尽量避免这两个问题，那么测试阶段合理的排期就需尽可能多的参考该节点及之前节点项目各方提供的有效信息，全局评估、拆分任务交付，最终提供较合理排期。

输出测试排期需要考虑的维度：

参考项目重点程度、优先级——是否优先级与已排期需求冲突，需参考优先级调整资源及排期
结合需求、设计参考及核对研发工时及排期、阶段交付内容——研发提供拆解后的任务排期是否合理（前置功能是否提前交付，依赖的任务是否有序等），测试依据研发排期时间提供可并行/串行等较合理的测试排期
关注研发是否有联调排期——需保障提测质量，时间紧任务重情况下是否压缩研发联调排期，可能影响提测质量及测试交付时间
测试联调排期——测试输出联调周期需拉齐对接系统排期（可协同产品沟通拉齐），避免临时协调联调时间导致延期
APP排期——需确认实现方式为：原生/flutter
明确方案是否存在变更——可再次明确需求/设计方案是否存在变更未同步情况
明确主测试方——如涉及多方系统，排期阶段可明确主产品、主研发、主测试方

3.4 测试用例编写、评审阶段

测试用例的编写必须依据需求文档，结合设计方案，确认所有以疑问点，覆盖所有功能需求点，跟进需求情况输出冒烟测试用例、功能测试用例、联调测试用例，思考业务实操场景，模拟用户场景串联流程保障测试内容的高覆盖。并在用例评审节点邀请产研参与评审，有序进行用例评审，确认疑问共同完善测试点并会后输出评审会议纪要。

测试用例编写、评审阶段需要注意的事项：

确认需求文档版本及标准——明确最新PRD版本（存在产研线下沟通后未同步测试情况，尽量避免），如有原型需明确原型及PRD内容描述不一致情况下如何开展测试工作
思考细节逻辑合理性及歧义描述——思考细节逻辑描述是否合理，PRD描述存在歧义点需标注明确
包含充分的异常测试用例——丰富异常用例，避免异常情况下功能异常
识别用户体验问题——提示信息是否明确、页面功能是否易用
业务范围和系统设计维度补全用例——跟进需求及设计细化测试维度丰富测试用例
测试数据、账号、配置等——识别测试数据、账号及配置是否需协同方配合，是否可使用工具等提升效率，如需全流程连通在该阶段记录
测试用例评审——与产研侧确认测试范围、沟通疑问，评审用例设计的清晰度与合理性，优先级排定是否合理，是否覆盖了需求上所有测试点，用例是否具有很好的可执行性，用例的冗余处理机制，是否设计了充足的异常测试用例，是否从用户的角度出发来设计用户使用场景和使用流程的测试用例，是否简洁、复用性强。
联调用例评审——输出交互场景与交互方评审，如为主测试，评审前串联整个项目/需求的流程场景用例，组织评审、明确测试数据、账号、配置等信息
用例评审会议纪要——记录待确认点及已确认点

3.5 编码阶段

编码阶段作为研发角色活动，通过编码过程来实现产品需求，此阶段的异常等需相关方知悉；

研发阶段需同步的信息：

需求/方案变更——是否存在需求/方案变更，是否及时同步至产品、测试侧
是否有提测延期风险——存在延期风险会压缩后续测试周期，需前置识别并抛出

3.6 代码评审阶段

代码评审是研发全流程的工程实践之一，通过代码评审可以更好的保障产品质量和代码质量；可根据改动大小与研发侧沟通进行线上/线下等评审方式参与。

代码评审阶段需检验的标准：

慢sql、空指针等——可有意识评审慢sql、空指针等问题
业务逻辑——测试人员需关注是否有明显的逻辑错误，改动是否遵循业务逻辑
补全回归用例——跟进改动范围可识别需改动影响原有功能部分，特别注意需确保主流程是否影响，补充回归用例
文档——提供新接口/修改接口是否有相应的接口文档更新维护
需求冲突识别——关注改动范围，识别其他需求是否也存在改动该段代码问题，避免需求冲突
提高个人代码评审能力——学习研发针对代码评审的意见/建议以及好的代码实现逻辑，便于问题更早的发现（以及代码编写规范、可读性、可维护性等）

3.7 冒烟测试阶段

冒烟测试是指在对一个新版本进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测性，尽早发现较阻塞进度问题，提前识别。

冒烟测试阶段重点关注的维度：

基本功能验证——优先验证基本功能是否可用，便于后续逻辑等较复杂功能开展
主流程验证——优先识别主流程问题，避免流程阻塞，阻碍测试进度，提前暴露流程问题及风险（方式依据项目/需求情况有效采取手工/自动化方式进行）

3.8 功能测试阶段（内部测试阶段）

功能测试阶段开始了大规模的测试工作，在此期间仔细详尽的测试，

功能测试阶段核心把控的思想：

明确变更同步——针对测试阶段任何变更需同步至相关方，避免一方不知情
识别需求冲突——共同测试需求，测试分支、需求相互影响
测试数据高效使用——分析测试数据是否可验证多用例，高效使用测试数据验证尽可能多用例提升效率
测试问题务必抛出——测试阶段发现的问题即使较小也需要抛出来提供给相关确认方确认，如无需更改则记录相关结论
探索性测试——探索性测试，可在测试阶段发现前期未识别到的影响功能等
测试进度报告、风险抛出——针对时间较长/较大需求、项目发送测试进度报告，暴露风险（识别是否有影响进度、质量等风险问题，抛出问题，记录待确认问题及已沟通确认问题

3.9 联调测试阶段（包含研发联调、测试联调）

联调测试为了保障该需求/项目的所有改动场景下发的数据在全链路系统下正常流转闭环，覆盖用户真实实操场景来确保项目/需求的交付质量。

联调测试阶段注重：

研发联调环节——再次核对涉及系统交互需求/项目，研发联调工作是否覆盖主流程测试点
联调场景验证——与全链路系统进行联调测试验证，覆盖用户真实实操场景
补全联调场景——在联调阶段，可能存在场景覆盖不全情况，可有选择性了解上下游系统逻辑，可覆盖补全联调场景，且针对接口及消息尽量全的确保数据传输场景

3.10 稳定性测试（适用于APP）

为保障APP端用户体验，APP稳定性测试不可或缺，上线前针对上线版本进行稳定性测试已加入到APP测试流程中，日常针对APP稳定性随机测试也持续监控。

稳定性测试需监控：

崩溃率——监控阿凡达平台统计，分析APP线上崩溃原因，丰富稳定性测试脚本
CPU实时监控——记录稳定性测试期间对应版本的CPU占用数据，平均值、最大值
内存实时监控——记录稳定性测试期间对应版本内存占用数据，平均值、最大值
网络实时监控——记录稳定性测试期间对应版本流量占用数据，平均值、最大值

3.11 UAT阶段

UAT阶段主要为业务验收阶段，用户角色验收产研测交付内容，为确保UAT顺利进行，较大项目/需求测试人员有针对性进行主流程拉通测试可提前发现配置、环境因素所产生的问题，此环节可加快UAT进度确保项目更高效交付（该阶段可根据项目诉求调整）。

UAT阶段应保障：

拉通主流程——根据项目/需求大小确定是否需拉通UAT，避免UAT因配置/环境等原因产生流程阻塞
跟进/复盘UAT问题——针对较大项目/需求跟进及复盘UAT中产生的问题，规避重复问题产生事项

3.12 上线前master回归测试阶段

上线前master回归未确保长时间需求不上线分支及版本冲突等因素，上线当前进行master回归操作可有效确保发布内容运行稳定，保障质量。

master回归阶段需check：

master回归测试——回归上线功能主流程以及原有流程主流程，规避测试分支与上线分支代码冲突等问题

四、暴露风险最终与协作方共同确定运作策略

在项目各环节已前置思考可能带来的风险，提前规避、提前暴露，但并不能完全保障，那么在暴露风险后，可参考风险程度分析与分类定位，与项目各方高效协作，共同商榷解除风险的可行性方案以及后续运行策略。

4.1 风险程度分析

极小：没有危害或微小危害 20%
轻度：轻度危害 40%
中度：中等 60%
重度：较大危害 80%
极大：重度危害 100%

4.2 风险识别分类/分解结构

技术类：明确是否为需求/技术层面引起的风险
组织类：明确是否为项目依赖关系、资源等原因引起的风险
外部：明确外部影响具体原因

4.3 与协作方共同商榷风险推进方案

测试人员可根据测试角度定位风险优先级，优先解决风险程度较高问题，且优先级较高风险需同步至上级知悉，必要时可采取升级等方式处理；

如为技术类风险——与项目经理、产品、研发共同评估技术层面解除方案；
如为组织类风险——与项目经理、产品、研发共同协同调整计划/申请资源等方式处理；
如为外部风险——测试人员需提供具体问题，协同项目经理、产品沟通具体原因，采取相对应的应对措施；

4.4 举例说明

4.4.1 举例一

背景：管理工作台项目（优先级top1，交付时间紧，开发工作量大）
产生问题：因测试周期时间紧，为避免延期提测，测试在研发阶段明确提测时间时，发现提测存在延期风险

风险程度分析及分类：组织类-重度风险
（识别阶段：研发阶段，识别及反馈角色：测试人员，类型：进度类）
与协作方商榷推进方案（解决过程及方案）：
因项目优先级较高，测试人员将此风险反馈至主产品及产品负责人处，因各方前期了解的信息存在差异化/关注点不一致等，线下拉齐会议沟通，根据交付优先级拆解交付内容，迭代提测进行测试，最终拉齐前、后端研发、测试交付目标一致，并调配资源进行各项任务交付，风险解除。

小结：依据风险程度，可内部解除的快速推进落地，需耗时较长/协调资源等需及时反馈至上级沟通，确保风险尽快解除落地。