敏捷软件测试

如果你在传统瀑布模式下做了几年测试，突然被拉进一个每天开站会、两周发一版的敏捷团队，最直接的冲击往往不是工具不会用，而是不知道自己的工作该怎么摆。需求随时在变，用例写不完就得测，开发催着你提缺陷，产品又希望你"再确认一下"。这门《敏捷软件测试》体系课，针对的就是这个具体场景。

它解决的是"角色错位"问题

这门课不是教你怎么用某个测试工具，而是先回答一个更前置的问题：在敏捷团队里，测试人员到底该干什么。

课程从敏捷测试十条原则讲起，这部分内容看似偏理念，但实际解决的是协作中的判断标准——什么时候该坚持质量红线，什么时候该接受"足够好就发布"。对刚从传统模式转过来的人，这种判断力比多会一个自动化框架更缺。

另外一大块内容是敏捷团队的组织挑战和测试人员的标准。比如测试和开发怎么结对、缺陷该在哪个环节拦截、跨职能团队里测试如何避免被边缘化。这些都是实际工作中会碰到的组织问题，不是理论。

学完能独立做什么

• 能在一个迭代周期内规划自己的测试活动，不再依赖一份提前写死几个月的测试计划；
• 能参与需求澄清和验收标准讨论，而不是等开发提测了才开始介入；
• 能根据项目情况选择自动化测试的切入点和覆盖范围，知道哪些该自动化、哪些不值得；
• 能说清楚自己在敏捷团队中的职责边界，和程序员、产品经理的协作方式有章可循。

换句话说，学完不会立刻变成自动化测试专家，但能让你在敏捷项目里站住位置，知道每天该产出什么。

资料适合什么基础的人

课程定位是"初次接触敏捷项目的测试人员"和"希望提升敏捷测试技能的测试工程师"。这意味着两件事：

第一，你最好已经有基本的软件测试经验，至少写过测试用例、提过缺陷、经历过完整的测试周期。完全没有测试基础的人直接看，会在协作和策略部分缺乏代入感。

第二，课程不假设你有自动化测试经验。自动化测试方法的部分讲的是策略和取舍，不是教你写某个框架的代码，所以不用因为不会编程而跳过。

需要说明的是，这门课的课件涉及企培版权，不提供下载。也就是说，学习主要靠在线观看和做笔记，习惯囤资料的人要调整一下预期。

怎么用这份资料更有效

建议按"原则—组织—策略—迭代"的顺序看，不要跳着只看自动化部分。敏捷测试的难点从来不是技术工具，而是节奏和协作方式的改变。如果你正在或即将进入敏捷团队，可以边看边对照自己团队的站会、迭代评审和回顾会议，把课程里的原则落到实际流程里。

如果暂时没有敏捷项目经验，重点看测试人员在不同迭代阶段的工作那部分，把它当成一张进入敏捷团队前的地图。等真正上手时，再回头对照自动化测试和协作经验的内容，效果会更好。