敏捷研发模式下QA应该如何工作？敏捷测试实践

大家好，我是持续讲干货的sean文哥。求职面试相关文章输出暂告一段落，可以关注我去历史文章里回看。

这是一篇老文章。

随着公司为了应对不确定性，开始引入敏捷研发模式，开始敏捷转型，各角色的工作方式和流程都在发生变化。什么是敏捷测试？和传统测试有什么区别？我们测试有哪些实践来支撑敏捷研发流程？

敏捷没有最佳实践，也没有终点，下面将结合公司近3年敏捷实践介绍测试工作在scrum里的具体一些实践和改进

01

传统测试VS敏捷测试

从各阶段介入时间和工作方式发生变化

02

敏捷测试宣言

为端到端虚拟团队在质量交付上指明方向

• 全程的测试活动介入 胜于 孤立的测试阶段

• 预防缺陷 胜于 发现缺陷

• 持续性的精准自动化测试 胜于 回归式的全量自动化测试

• 帮助构建最好的系统 胜于 破坏系统

• 团队为质量负责 胜于 测试为质量负责

• 团队为产品负责 胜于 产品为产品负责

03

敏捷测试流程

以两周一个迭代为例各阶段工作流程和规范

04

日常敏捷测试实践

具体落地的实践，供参考

每天工作闭环

• 每天测试进展，包含问题、延期、技术任务进展

• 任务拆分表，测试进展、cc通过、cc及时结果及时反馈

暴露风险

• 有阻塞一小时，及时随时升级

• 站立会、测试进展、敏捷日报 体现

需求评审

• 需求6阶段讨论，3阶段宣贯，提高需求评审效率

• 提前了解需求，带着问题去评审

• 参考 需求评审表 发问

• 做好笔记

任务拆解会(重要)---从转测内容的粒度上有标准

• 将大需求拆分为可演示、可测试、可验收的粒度，一般不超过3天的开发工时

冲刺会

• 关注任务拆分表，任务项是否可测、提测时间是否合理

• 关注你自己对应的开发是谁

技术方案

• 参考开发技术方案评审表

• 做好笔记

测试估时和排期

• 对每个任务项估时要有思考，测试要有侧重点

• 自己统筹整个迭代的测试任务，避免三阶段测试任务扎堆

• 80%测试任务 6阶段完成

测试用例

• 结合开发改动点先制定测试方案

• 用例严格按照模板来编写

• 迭代第一天 用例评审

• 多个测试参与评审

• 引导开发按照测试用例来完成业务编码，尽量一次做对

高效会议

• 提前周知、安排好时间

• 会议前有思考、有准备

• 高度投入，不做其他与会议无关的事情

写在最后，

敏捷实践受不同公司文化、组织架构、人员认知、技术栈影响，磨合出的测试实践各有不同，以上是部分实践，不全，抛砖引玉，供大家参考。

你觉得呢？有任何想法欢迎在评论区讨论或留言。

另外，研发质量效能、职级晋升、职业规划等将会持续输出干货。

关于我，二十年QA、测试、敏捷研发、研发质量效能相关经历；历任百度、易宝、艺龙、直客通、蔚来等QA负责人、测试总监及研发质量效能负责人；在求职面试、职业规划、职级晋升、职场生存潜规则、敏捷研发、质量效能领域专业知识和落地实践有相当丰富经验。

如果觉得对你有帮助，也可以联系我进一步交流