敏捷软件测试

如果你是从瀑布流项目里走出来的测试人员，第一次进敏捷团队，大概率会经历一段懵的时期：需求不再是厚厚一份文档，而是一张卡片加几张嘴；测试用例还没写完，开发那边已经合并了三个提交；站会上别人说得飞快，你插不上话；迭代结束前三天，测试环境忽然变成全组最抢手的资源。

这些不是能力问题，是工作方式换了。敏捷测试不是把原来的测试流程压缩到两周里跑一遍，它改的是测试什么时候介入、介入到什么程度、和谁一起对质量负责。这篇导读帮你判断：自己缺的到底是哪一块。

先确认你是不是真的需要补这门课

下面几种情况，对上一条就不用犹豫：

• 知道敏捷宣言里有「可工作的软件高于详尽的文档」，但落到自己每天做的事上，不知道具体该怎么操作。
• 团队里没有独立的测试阶段，你不确定测试该在迭代的哪一天开始动手。
• 和开发坐在一起，但合作只停留在提缺陷单，没有别的协作方式。
• 自动化测试写了一些，但不确定哪些该自动化、哪些手测更划算，回归越攒越重。
• 迭代评审时被问「这个迭代的质量怎么样」，除了缺陷数答不出别的。

反过来，如果你已经在敏捷团队里做了两三年，能说清楚自己团队的质量门禁是怎么设计的、自动化分层怎么分的，这门课对你偏基础，可以跳过。

课程要解决的四个具体缺口

缺角色认知：敏捷里测试到底归谁管

传统项目里，测试是一个岗位、一个阶段。敏捷团队里，「测试」变成一种贯穿全程的活动，谁来干、干到什么程度，是团队自己协商出来的。课程会讲到敏捷测试人员的原则，这些原则不是口号，是用来在站会、计划会、回顾会上表态的依据——比如什么时候该说「这个需求验收标准还不清楚，现在估点不准」。

缺协作方式：和程序员紧挨着坐，然后呢

物理上坐一起不代表协作就发生了。课程涉及测试人员和开发的具体配合：需求澄清阶段怎么一起把验收标准写出来，编码阶段怎么用结对或者即时沟通把缺陷挡在提交之前，而不是等提测后再靠缺陷单来回。这部分对刚从传统模式转过来的测试人员最有直接价值。

缺策略和自动化判断：不是所有东西都值得自动化

敏捷迭代周期短，回归压力大，自动化几乎是刚需。但课程要处理的是更前面的问题：哪些测试适合自动化、自动化测试在迭代节奏里怎么维护、与手工探索性测试怎么分工。如果你现在的自动化脚本跑一次要半小时还经常误报，这里能找到调整方向。

缺节奏感：迭代里测试到底在哪个时间点做什么

这是最容易踩坑的地方。课程会梳理一个迭代从计划、开发、测试到评审回顾的推进过程，对应的测试活动分别是什么。看完你至少能回答：迭代第一天测试该干什么，开发还在写代码时测试是不是就闲着，迭代最后一天除了跑回归还该做什么。

学完之后，你应该能回答这些问题

• 迭代计划会上，测试人员需要提前准备什么，才能对估点和验收标准提出有效意见？
• 需求写成了用户故事，验收标准该由谁写、写到什么颗粒度算够用？
• 团队没有独立测试阶段，你是怎么保证质量不被迭代节奏挤掉的？
• 哪些测试放进自动化、哪些留给手工，判断依据是什么？
• 回顾会上，你用什么数据说明这个迭代的质量状况，而不是只说「缺陷有点多」？

如果这些问题你现在答不利索，边学边在课上找答案，比单纯看概念有用得多。

看之前的两点提醒

一，这门课偏角色、策略和流程，不是自动化工具的操作手册。想学具体某个测试框架怎么写脚本，这里不解决，但能帮你想清楚该拿这个框架去自动化什么。

二，课件涉及企业培训版权，不提供下载。建议看的时候自己动手记：把课程里提到的每个活动对应到自己团队的迭代日历上，标出哪些环节你现在是缺的。笔记比课件更有用。

敏捷测试的难点从来不是知识，是你所在的团队愿不愿意改协作方式。课程能给你的是判断依据和话术，剩下的要靠你在下一次迭代里真的去试。