测试在项目流程中的那些事儿

youdao

ydtech

youdao

ydtech

youdao

ydtech

1. 发版频率在排名第二，2021全年发版71次，相当于每周都有一个版本在进行迭代，快速迭代的节奏， 对人效和团队协同效率要求高。

2. 整个2021年，研发人均 bug 数100+，bug 较多，提测质量不高。为了不拉长项目周期， 保障较短的 bugfix 时间非常关键，同时要考虑如何提高提测质量。

针对上述挑战的内容，我们可以看到提测质量上，我们存在不足之处。我们之前做过提高冒烟用例比例、冒烟交叉执行、时间预估增加冒烟时间等尝试，最后发现收获的效果有限。主要原因如下：

• 多方合作、项目有固定 deadline：由于项目特殊性，部分需求是多方合作的模式且有固定的deadline，就需要项目尽快上线，在对项目效率有极高要求的情况下，我们允许带一些层级深的bug上线，针对上线情况做 hot fix。

  
  

• 项目节奏紧张，需快速迭代更新：现有研发团队是串行的节奏，能持续高效迭代，为保证项目节奏的稳定性，避免出现因一个项目周期拉的过长导致节奏紊乱，我们接受分步提测的形式，就有可能出现冒烟功能不完整的情况，导致提测质量不如预期。

基于以上原因，我们可以看到在质量与效率之间需要做一定的选择时，需要向项目效率倾斜，所以我们既然无法更好地改变提测质量，那就去改变我们能改变的。

youdao

ydtech

QA 可以做什么让整个迭代周期变短，在bug很多的情况下还能快速迭代且线上问题较少呢？先来看下我们的项目流程：

从整个项目流程上看，可能与很多团队如出一辙。

在流程上，QA作为下游的一个部分，可以看到QA参与输出的内容其实有很多，这些部分就是我们可以尝试去改变提升的点。

那么我们从这些输出内容看下，面对上述挑战，QA 都做了哪些改变以及还有哪些困境。

项目排期计划模板：

【when】项目排期一般是需求评审完后，根据需求拆分需求模块和开发模块。

排期计划中，QA 的工作：熟悉需求，拆分需求模块，制定测试计划

QA 同学加入进模块拆解，能更好的了解需求，拆分的开发模块也能更快的知道当有bug时，bug是属于哪个端的，提给哪位对应的开发。

根据各模块的提测时间和大致开发周期，QA同学也能制定对应的测试计划。

【what】-- QA具体需要做什么

1.协助开发拆分功能模块，确保模块都有对应的开发负责人

2.确认项目deadline、开发总预计时间和提测时间。

项目测试计划模板：

【when】测试计划一般在项目排期给出后1天内提供，后续根据排期动态调整。

测试计划中，QA的工作：根据需求预估时间和人力，明确测试环境与策略，制定合理的测试计划，预估风险

【what】-- QA具体需要做什么

1. 拆分功能模块，模块明确好对应的测试。（包含用例编写安排、一、二轮测试安排和兼容测试安排）。

2. 预估好项目的总体测试时间和各轮次的测试时间。

3. 一轮接近尾声时，与开发明确好上预发时间；二轮接近尾声时，与开发明确好上online环境的时间。

4. 如有数据配置项，二轮测试开始前与产品明确好配置所需内容和完成时间节点.

以上1、2两点尽早提供，其余可在对应时间点给出。当然，如遇到需求变更、人力变更等需要及时提出和调整。

【how】-- 具体怎么做

根据开发排期，动态制定和调整合理测试的计划。

如下图拆分的测试计划，后台配置（星火）与用户端提测时间不一致，结合两个提测时间点，我们利用用户端提测前的时间，先执行后台配置的用例，这样即使是分步提测，我们也能确保每次提测时测试资源能跟上。

· 按照模块、用例量与难度划分，制定每人每天用例执行目标

一轮测试模块划分根据用例编写与熟悉度划分

· 实行交叉测试，避免因不熟悉导致遗漏或效率降低

二轮进测试进行交叉，利用TC平台的任务指派，也可以清楚看到组员的任务数量与完成情况。

如下图，测试计划的拆解与人员分配，细致划分到每人每日的工作目标，且各模块的分配会进行交叉，一轮测试人员发现用例不完善或测试不方便的地方也提供了文档以便二轮人员尽快上手测试。

[小结]：

我们可以看到，调整测试计划的4种方式，主要目的都是通过这些办法去更高效地去完成测试任务，保障项目如期上线；更完善、全面地去发现bug，提升项目质量。

【小结】：

1.定制化的流程，让流程更加统一规范和智能化。

2.关键信息的及时同步，能减少每日站会、信息同步会等重复会议，节约了时间。
各团队之前的协作更加顺畅，那团队协同效率和人效也就自然而然能进一步提高。

2. QA 高效提bug、研发快速修bug秘诀：

2021Q1 效率工具的需求收集提效讨论中，提bug流程的优化建议一一实现了，每个人提bug 的速度大幅提升，主要汇总如下：

• bug区分问题类型 —— 使bug分类更精准，能更好地分析数据，push对应人员

• bug状态展示优化 —— 各状态一目了然，更快找到需要处理的bug

• bug描述预置版本、步骤、设备等信息 —— 减少重复内容输入，提bug效率更高

• jira移动版接入使用 —— 附件内容更方便上传，bug描述更准确，减少因无法复现、描述不清等原因带来的重复沟通成本
  

【小结】：

1. 即使是预置的一些提bug信息和界面优化，也让测试更“优雅”地工作，提bug和验bug也更有劲儿了。

2. T+1修复周期的约定与消息推送，给了研发一个心理预期，正如我们根据项目情况调整测试策略一般，研发也根据我们给的预期调整了工作模式，从而使研发fix bug周期保障到最短，高效且有质量地修复了bug。

工作流程的调整与满满预期的加持，让整个团队的工作效率极大提高。

1. 测试日报

【when】一般项目提测后，需要每日下班前发送日报

【what】-- QA具体需要做什么

汇总其他QA的进度，根据项目情况发送日报or周报。
日报中风险项一环节可根据项目情况修改，同步计划、提醒事项等都可以写入。
push开发fix bug：p1 修复周期不超过T+1天，bug数量较多时，可根据测试情况适当催开发修改（比如一轮测试接近尾声，还有很多服务端前端bug，就需要催一下了）

【how】-- 具体怎么做

在galaxy平台工具上，实现了日报自动生成工具，每日可自动生成日报内容，方便大家看进度，且日报中还有当前bug状态和链接，研发也能更快找到自己的bug。
日报一键生成效果如下：

日报的自动生成，节省了测试每日汇总进度的时间，更是直接大幅减少了关键信息的沟通同步成本，是人效和团队协同效率提升的又一次加成buff。

2. 质量报告（测试报告）

【when】项目上线后，对项目进行总结梳理

【how】-- 具体怎么做
结合 jira 的使用流程，可一键生成测试报告并同步质量平台。

生成的测试报告示例：

【when】项目上线后的一周内，小型项目如有必要可合并组织

【why】复盘的目的：针对项目中不足之处，共同讨论对策，争取下次做得更好

【what】-- QA具体需要做什么

1. 数据文档准备：形式其实不做限制，需要的数据、文档等准备好即可，也可以与开发轮流组织。

2. 会议上形成的todo list需要进行跟进处理

【how】-- 具体怎么做

复盘例子：

复盘提效 jira 看板：如下图  

（ps：催 bug 或者发日报的时候也可以使用，比较清晰）

【小结】：定期做项目复盘，让团队意识到我们当前存在的问题，推进项目流程一次比一次做得更好。

【不足】：
当然，在复盘过程中，各团队虽然达成一些共识共同改进，也遇到了一系列问题。

问题一：项目节奏已经很紧张的情况下，大家可能都在赶项目进度，没有余力去做复盘总结工作，追求效率从而忽视了质量。

问题二：复盘形成的todolist也没时间去跟进，导致复盘的总结内容最后不了了之，复盘失去意义。

问题三：一些复盘改进点，往往由于各种特殊原因而不能按规定执行 。

基于以上原因，复盘收获的效果是比较有限的，也是我们今后需要探讨与改进的一个命题。

youdao

ydtech

项目流程中，我们关注各个阶段需要做什么事的同时也会做项目管理与把控，关注项目风险，守住 deadline。

风险可以分为两类：质量风险和进度风险

举个例子：

用例编写的时间不够，影响测试时间和上线时间，我们称之为进度风险；而用例编写时，编写用例人员不熟该功能，用例覆盖不足，我们可以称之为质量风险。

这里我们主要关注的是项目进度，所以着重关注进度风险一项。进度风险，就是在项目进度中出现的风险从而影响了整个项目的时间点。

在测试计中，我们设计了风险一栏放于第一位，目的就是让QA在项目流程中，及时从测试角度去观测和记录风险。

比如：

面对风险出现时，需要 case by case 讨论。在进度风险出现时，首要原则就是及时暴露风险、寻找方法去尽可能降低风险。

项目组很多项目因与其他部门配合，有固定deadline并且允许有部分已知问题带上线，那么我们一般从测试开发角度去商议的解决办法如下：

以上方案如果还不能守住 deadline，就要考虑项目延期。