我们接着来聊一聊测试工程师的工作除去工作本身我们会通常与人打交道因为一个项目迭代的完成是很多部门很多人一起来完成的这个时候会出现一些有意思的碰撞。我来浅聊一下我的看法我的思维模式一般都是当下、后续、长期所以我的回答也会按照这个格式来1、产品需求文档过于简陋堪比毛坯房目前怎么解决评估可测性这个需求虽然比较毛坯还是需要看下能否正常支撑测试工作的展开如果需求毛坯到我都不知道这个需求想干啥我测试用例都写不了那说明这个prd不具备可测性。梳理问题清单并组织二次确认把需求问题列出来拉相关产品开发测试聊一下这几个地方有歧义、有问题最好拉个会议把问题逐个确认并同步确保大家都对需求理解一致形成书面确认并留痕这个时候需求疑问基本都确认了一定一定要求产品更新需求文档给出变更记录和链接这是你后续沟通的依据调整测试计划和做好风险评估需求补充或者变更了需要看些这次调整是否影响原有的测试计划安排如果对于工期估时有影响那需要同步一下如果有其他风险也要说出来后续怎么处理建议需求文档规范化建议产品leader对于需求文档建立一些基本的文档模板规范包括图文格式、场景覆盖、影响范围等做好产品需求内审一般需求写完了公审之前产品内部会有一个内审这是一个优化的方向。这个也需要你看看怎么和产品方沟通这个事情长期怎么优化可以灵活想一些优化方案就比如说沉淀一下产品知识库使用ai方案什么的这个探讨空间比较大。测试可能更加关注当前怎么做或者后续怎么优化处理2、开发提测质量不佳当下冒烟测试并评估可测性可以通过冒烟测试评估当前整体质量是否影响正常进测如果不太影响的话可以适当灵活调整下测试方案与策略质量卡点与打回如果真的太差了核心功能用不了主要流程走不通明确给出问题表现与打回原因同步所有相关人员必要时要求重新开发、重新提测同步风险并留痕如果确定打回重新提测那原定工期必然会受到影响此时需要向项目管理说明现状情况和排期风险后续推动开发自测开发是需要有自测这个环节的无论是单元测试或者是集成测试都需要给出自测结论和说明并且公开化建立提测准入机制有的时候开发的自测和测试的自测可能理解不一样测试可以在测试用例编写完成之后从全量用例中抽取一部分比较精炼的用例作为开发自测用例并且需要制定通过标准通过率、自测报告、静态扫描结果如果可以开发的自测结果需要公开化长期自由发挥一下比如测试可以介入技术评审、代码审查或者给开发特别标注重要场景处理等等3、提单一个问题开发说不是问题给我打回了当下明确问题根据现有的prd、单据、问题表现判断这到底是缺陷还是产品设计问题又或者说是交互问题分类处理如果是缺陷问题那没什么说的prd需求预期、复现路径、问题表现、沟通记录全都记录在工单里面并且评估问题的优先级和严重程度标注预期修复时间如果是产品设计漏洞或者体验问题工单流转到产品方同样给出实际结果、询问预期结果看下当前表现是否修改修改方案是什么并且要补充到prd后续规范记录与留痕我一直觉得bug单不是一个简单的记录而是代表着每一个bug的生命周期可以看到bug的产生、经过、和结果。回到这个问题上面开发无故拒绝修复这是不好的如果拒绝修复的bug在打回给测试时一定要给出拒绝原因并标注说明这个bug涉及到的相关人员一定要通知到位。建立bug判定标准bug的创建需要标注这个bug的类型程序bug是bug需求bug也是bug开发和产品都可以是bug的解决方。长期这个场景更多体现的是沟通交流的场景其实在这个方面上可以建立一下部门协作的信任4、测试时间不够/测试工作量太多但是项目马上必须上线当前紧急盘点评估与测试范围分级看下目前还有多少工作量、多少时间剩余工作量主要是P0、1、2、3中的哪些占比大概多少。测试方案调整看下哪些回归场景可以用脚本代替、或者代码批量校验、或者日志监控代替合理分配时间。资源申请与加班协商能否借用当前其他测试人力又或者能否借用开发、产品人力来协助测试又或者说能否借用产品验收的时间另外也评估下当前工作通过加班是否能完成。产品需求方案调整给出当前有质量风险的功能模块的测试情况看下协商部分产品功能能否砍掉或者调整为其他简易方案。如果以上都行不通直接向项目经理、各个leader给出结论无法承诺高质量上线项目风险很大。如果项目经理说就要上就问题就有问题没事作为一个测试工程师我还有招来接着说量化风险并通知到位你要告诉所有人上线风险是必然存在的列出没有覆盖的功能点、未执行的测试用例、未修复的缺陷清单、可能对业务造成的影响。看下上级领导在知情的情况下怎么决策处理。项目经理说有问题那咋了我一定要上好继续推动可控的上线方案比如采用灰度发布、分批上线、功能开关、兜底方案避免全量开放引发灾难。制定线上事故补救预案提前准备好紧急回滚方案、热修复方案、数据修复脚本、监控告警机制确保出问题之后第一时间能快速响应解决。后续复盘根因与流程改进出现这种情况线上事故肯定少不了。一定要明白为什么出现了这个事情是开发提测质量不佳、产品需求变更频繁、测试方案错误、又或者说是排期估时不合理哪里不合理我们就优化改进。长期的话我觉得还是规范流程比较重要
