前言关于Scrum迭代开发模型我们用的开发模式我们团队用的是Scrum敏捷迭代开发模型。简单说就是每轮版本固定周期我们一般是2周规划好本次迭代要做的需求需求拆成用户故事排进迭代 backlog待办池开发按故事点估时、领任务、按计划推进每日站会同步进度、暴露风险、对齐预期迭代结束交付可上线的产品增量Scrum里最重要的三件事1. 承诺团队承诺本次迭代要完成哪些需求每个成员承诺自己负责的任务按时交付承诺不是嘴上说说是对团队的责任——说好了做哪些就要做到2. 透明进度透明做到哪了、卡在哪了所有人都知道风险透明有问题提前爆不等最后才说数据透明bug数、完成率、通过率全量可查3. 检视与适应每轮迭代结束要复盘做得好不好哪里能改进下一轮迭代针对问题调整不重复踩同一个坑Scrum团队里测试的角色传统理解测试就是“最后一道把关”但在Scrum里测试不是最后一环等着接活的人——测试是质量信息的提供者。每轮迭代测试结束我要给团队一个清晰结论这个版本质量怎么样、能不能上、有什么风险。这个结论是团队决策上线与否的重要依据所以我说的每句话、每个数据都要经得起追问。我们的工作方式边开发边测试我们不是等开发全部做完才提测而是开发做完一个需求我就测一个需求不囤积。这样有几个好处bug早发现早修不堆积到后期开发对刚写完的代码还有印象修bug成本低不会出现最后一周测不完的情况每日站会我能同步真实的测试进度对应的节奏是迭代第一周周四用例评审开发完成后立即开始测该需求迭代后半段整体回归、收尾报告理解了Scrum的运作方式和我们的工作节奏就能理解我这套测试执行方法为什么这么设计承诺对应我“圈定版本范围、摸清开发进度”——先搞清楚团队承诺了什么我才能承诺我测什么透明对应我“中途爆风险、群里发摘要、对人”——让所有信息流动起来不藏不掖检视与适应对应我“每轮结束复盘、生产bug沉淀”——这轮不好下轮改闭环边开发边测试对应我“开发做完就测、不等提测”——保证节奏不积压下面就是我自己每轮迭代照着做的完整流程。不是什么高大上的理论就是在这个框架下一步一步把事情做踏实。第一章 迭代开始——圈定范围摸清家底1.1 先搞清楚这个迭代到底做什么禅道里拉一下本次迭代关联的需求列表自己过一遍每个需求知道大概什么功能、涉及哪个模块一段话总结出来这个迭代主要做了什么写进报告里用1.2 摸清每个开发的开发进度具体怎么摸不是等开发主动告诉你而是主动去问、去盯提测前1-2天找每个开发确认你负责的模块做完没有有没有延期风险有没有需求变更导致返工有没有依赖别人的接口还没好在禅道里看任务状态已完成/进行中/未开始区分三件事记清楚计划做的迭代 backlog 里规划的实际做完的开发真的提交了的没做完延期的说了要做但没做完的为什么做这一步方便后续排测试计划——开发做完一个我就测一个领导问“谁还没做完”能立刻答上来知道自己要测的范围到底有多大对应Scrum的承诺原则——团队承诺了什么实际交付了什么我心里要有数1.3 迭代开始前自己建一个版本记录文档记录以下信息版本号 / 迭代名称提测日期 / 预期上线日期本次涉及的需求列表禅道需求ID涉及模块模块对应开发责任人谁写的代码找谁测试环境地址 / 账号 / 测试数据准备情况第二章 用例编写与评审迭代第一周周四2.1 用例编写什么时候写迭代开始后基于本次迭代的需求文档/用户故事编写测试用例开发边写代码我边写用例两边并行用例要写什么每条用例覆盖一个明确场景正常流程 异常流程 边界值 权限/状态组合用例包含前置条件、操作步骤、预期结果关联禅道里的需求ID保证可追溯用例数量控制不贪多覆盖全就行核心功能写细一点边缘功能写主干场景时间紧的时候先保证主流程和核心异常场景2.2 用例评审固定时间迭代第一周周四评审的目的让产品、开发、测试三方对齐认知确认我理解的需求是对的确认我覆盖的场景没有遗漏提前发现需求理解偏差不等测完才发现“咱们理解不一样”评审前自己先过一遍每条用例我自己能讲清楚“为什么这么写”对照需求文档确保覆盖了所有验收标准标注出自己拿不准的场景评审时重点问评审时怎么做按模块逐条过用例产品确认需求理解是否正确开发确认实现逻辑是否符合预期有争议当场讨论清楚不把疑问留到测试执行阶段评审过程中发现的遗漏当场补评审后的动作更新用例根据评审意见修改/补充禅道里维护好最终版本评审结论同步到群里所有团队成员同步格式用例评审已完成本次迭代共X条用例覆盖X个需求评审意见已修改用例已更新到测试用例文档/禅道。2.3 为什么用例评审这么重要不评审自己理解错了需求测了也白测不评审开发按自己的理解写代码测试按自己的理解写用例两边对不上不评审漏了场景没人发现等测完了才说“这个怎么没测”评审不是走过场是测试质量的第一道防线第三章 测试执行——边开发边测试开发完一个测一个3.1 工作节奏不等全部提测开发做完一个需求我就测一个。具体操作每日站会关注开发进度谁的任务状态变成“已完成/待测试”主动问一句“这个可以测了吗”开发说可以了马上开始测这个需求测完出bug提禅道对应开发开发修好了马上回归验证验证通过这个需求就算测完了为什么要这样bug早发现早修开发对刚写完的代码还有印象修得快不会出现最后一周bug成堆、测不完的情况迭代后半段时间留给整体回归而不是还在测新功能每日站会我能说出准确的测试进度3.2 每天做的事早上站会前看禅道bug列表有哪些修好了待回归优先回归已修复的bug关掉确认修复的没修好的问开发今天能不能好准备好站会要同步的内容站会上同步昨天测了什么模块、出了几个bug今天计划测什么有没有阻塞/风险需要同步白天按用例执行测试新bug提禅道开发做完了新需求马上开始测遇到阻塞立刻处理不能等下班前估算一下整体进度大概测了百分之多少明天要测什么模块心里有数3.3 风险提前说什么算“风险”进度风险按当前速度可能赶不上上线时间bug风险出了严重/致命bug功能整个走不通环境问题测试环境挂了、数据没了、连不上了开发延期该完成的没完成导致我积压了测试任务需求变更临时改了需求用例要重写评审要重开怎么同步不等收尾才说中途就在群里同步格式同步一个风险XXX模块目前发现XX问题/进度滞后XX天/环境XXX异常影响会导致XXX没法测已找XXX开发确认预计XXX时间恢复有进展再同步目的就一个让所有人知道当前真实情况别到最后一天才说“测不完”。透明不是等别人问是主动同步。3.4 不照搬需求文档需求文档/用户故事是“计划要做成什么样”实际开发做出来的可能不一样有偏差、有遗漏、有变更测试过程中实时更新自己心里那本账实际做完的到底是哪些报告里只写实际测了的不写计划要做但实际没做的第四章 禅道bug管理——提bug、追修复、做闭环4.1 提bug的规范一条合格的bug记录包含标题[模块名] 一句话描述问题严重程度致命/严重/一般/建议自己先打个标优先级紧急/高/中/低复现步骤别人照着能做出来1. 2. 3. 一步步写清楚实际结果现在是什么样预期结果应该是什么样截图/录屏有就贴一图胜千言所属模块选对模块方便统计和分配指派给对应的开发责任人关联需求关联禅道里的需求/故事ID方便追溯提bug的潜规则bug描述清楚开发不用来回问“怎么复现”节省大家时间复现步骤写详细不是为了开发是为了以后自己回来再看也能想起来4.2 bug跟进流程每天看禅道今天新提了多少bug开发已解决多少待验证多少已关闭多少跟进节奏状态我的动作开发已解决当天回归验证确认修复就关闭没修好就激活备注原因开发延期未修群里对应模块责任人问修复计划遗留bug记录在待办清单里持续跟踪不遗忘分模块划责任人禅道里每个bug都有模块字段每个模块绑定对应开发责任人模块bug、模块责任人、具体整改跟进对应开发人员责任到人不模糊4.3 待办闭环谁修什么bug → 修好我回归修好了就关闭遗留bug记录跟踪不丢不忘每轮结束清理一遍禅道bug状态确保没有悬空的第五章 迭代结束出报告——数据化、风险说透、对人5.1 报告结构固定模板每轮套用第一部分迭代范围一段话总结这个迭代主要做了什么涉及哪些需求列需求ID/模块名和完整需求描述计划做的 vs 实际做完的 vs 没做完延期的三列对比第二部分测试结果全部数据化指标数据本次测试用例总数XX条总共测出bug数XX个致命bugX个严重bugX个一般bugX个建议/优化类X个用例通过率XX%第三部分迭代bug风险根据模块列出所有bug的风险等级其中包含必须马上修复的bug列出来说明为什么可以后续迭代优化的列出来说明为什么可以放我自己的专业测试意见这个版本能不能上有什么顾虑建议怎么决策第四部分回归情况本次回归了哪些老模块列出来哪些模块没回归、原因是什么没回归的模块存在什么潜在风险要如实写第五部分待办闭环待修复bug清单谁修什么、计划什么时候修好修复后由我回归验证遗留bug持续跟踪计划5.2 群里发报告固定人操作方式完整报告上传附件群里发重点摘要不贴全文规则固定项目leader、管家master、产品经理pm版本范围、整体进度、测试结果、版本风险、整体结论开发a、开发b模块bug、模块责任人、具体整改跟进摘要范例项目leader、管家master、产品经理pm 本次迭代测试报告已出摘要如下【范围】本次迭代主要覆盖XX、XX模块计划需求X个实际完成X个X个延期【结果】用例X条发现bug X个致命X严重X一般X通过率X%【风险】X个bug建议上线前修复已列清单X个可后续迭代【结论】我的建议是XXX开发a 开发b 模块bug已分责任人待修复清单见报告附件请今天确认修复计划完整报告见附件第六章 上线当天——冒烟验证快速响应6.1 上线后立刻做的事上线后半小时内走一遍核心流程冒烟核心流程怎么定登录 → 核心功能入口 → 新增/编辑/提交 → 数据落库确认主流程能通再深入看关键模块6.2 同步线上情况没问题时线上冒烟已过核心流程登录→XX→XX验证通过无异常。有问题时线上冒烟发现XXX异常现象是XXX影响范围XXX已通知开发XXX紧急处理有新进展同步。6.3 线上问题处理流程确认现象、影响范围、影响用户同步给开发紧急修复修复后验证同步修复结果第七章 生产bug管理7.1 所有线上bug全部记录不管大小、不管是不是自己的漏测、不管是不是环境问题全部记录在一个地方我单独建了一个“线上bug沉淀表”记录字段发现日期本次迭代版本号bug所属模块bug现象描述影响范围根因开发原因/测试漏测/需求问题/环境问题发现渠道用户反馈/监控告警/自己发现反思总结举一反三设计该场景测试用例7.2 每条生产bug必须自己复盘总结复盘的思考路径这个bug是怎么出去的我的测试为什么没拦截到是这个场景我没考虑到还是考虑到了但没写用例还是写了用例但执行漏了这个场景属于哪一类遗漏边界值/异常场景/数据状态/并发/权限/接口超时/配置项/历史数据兼容……我的测试用例里有没有覆盖这个场景如果有为什么没测到如果没有马上补上输出物补的用例更新到测试用例文档/禅道用例库补的场景加到后续迭代回归清单同类场景排查检查其他模块有没有类似盲区7.3 生产bug必须沉淀每条线上bug都是自己的“踩坑记录”每轮迭代结束翻一遍同类坑不踩两次就是进步沉淀多了自然知道哪些场景容易漏下次优先覆盖第八章 自动化工作空闲时间做8.1 做什么不要贪多不吹要做全量挑一个最常回归的模块把核心用例转成自动化做就做完整一个模块不半途而废8.2 做完主动展示跑通了发群里给开发看、给leader、给测试组长看问一句有没有优化建议接收专业意见持续优化8.3 稳步成长不画大饼不说“我要把全部用例自动化”只做实事一个模块一个模块来每轮迭代复盘时记录自动化新增进度第九章 每轮迭代结束必须复盘9.1 复盘问题清单本次测试哪里不足哪些场景考虑不全踩了什么坑自动化新增进度生产漏测问题整改优化9.2 复盘产出下轮迭代要改进的点写下来下轮迭代开始前看一遍用例库更新回归测试清单更新第十章 自己的避雷针不找借口、不说自己只会手工测试不吹牛、不瞎承诺大目标客观说事不甩锅不止堆数据必须有自己的判断所有问题走完完整流程发现→同步→跟进→复盘→闭环写在最后❗❗❗向上管理很重要它不是谄媚也不是讨好而是完整展示自己的工作量与能力目的是让领导看见✅我靠谱✅我用心✅我在进步✅我有思考✅我有价值✅不是只会点点点测试的小白对应到Scrum承诺的事我做到透明同步所有信息每轮检视与适应改进自己。每轮对着过一遍保证不漏事、不被动、心里有数。一句话总结把整套事情闭环做好让领导看到你的进步。 这套东西不高级就是踏实做。❌ 很多新人误以为向上管理就是拍马屁。⬆️向上管理的本质你埋头干活但领导不会时时刻刻盯着你的全部工作。向上管理就是把你实实在在做过的事、遇到的困难、取得的进步有效传递出去争取资源、规避风险不是虚的客套。