敏捷团队有专职的QA吗？

刘炜问

敏捷团队有专职的 QA 吗？测试工作整体是怎么安排的？

小波老嬉答

QA 是 Quality Assurance（质量保证）的缩写，我认为回答这两个问题之前，我们要先搞清楚：

敏捷团队中，谁对质量负责？质量是如何保证的？

我的答案是：所有人对所有事负责，质量内建在交付过程中。

所有人对所有事负责

企业导入敏捷，常用的两个框架是 Scrum 和 XP（极限编程），我们来看看它们是如下描述团队结构的。
Scrum 中对团队的描述如下：

Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment;
Scrum recognizes no titles for Development Team members, regardless of the work being performed by the person;
Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.

XP 中的 Whole Team（完整团队）描述如下：

The best teams have no specialists, only general contributors with special skills.

意思是说，团队需要具备端到端交付软件的各种技能，比如需求定义，分析，体验设计，编码，测试，运维等。但并不是那么职责分明，而是整个团队拥有集体所有权，责任共担。
为什么要这么做呢？有明确的分工不是效率更高吗？是的，每个人干自己熟悉的事，个人效率是更高，但团队的产出却不是最大的。
为什么要追求产出最大，而不是效率最高呢？因为敏捷解决的是「不确定性」的问题，而不是「效率问题」。

如果你认同「需求都是待验证的假设」，那么最重要的就是赶紧交付出来，去获取用户的反馈。在有明确分工的团队里，常常会发现一个现象：每个人都在忙，都在做自己擅长的事，但需求却浪费了很多时间在各个环节等待被处理。设计完了等待开发，开发完了等待测试，测试完了等待验收......
这就相当于做了很多不能被交付的半成品，积压在生产线上。如果瓶颈已经在测试环节，很多需求等待被测试，那「开发人员」继续开发更多的功能，对整个团队来说，是在增加瓶颈的压力。如果这时「开发人员」去做测试，就能减轻瓶颈的压力，让更多需求被交付出去。

团队的瓶颈是动态变化的，通过每天的站会，可以让所有人了解团队目前的整体状态，并且主动选择「今天我准备做什么」来给团队贡献最大的价值。如果你划分了每个人的职责，并在迭代一开始就做了具体的任务分工，那往往每个人只会关注自己手里的事情能不能顺利完成，对「别人」的事就缺乏兴趣了。

那团队成员可能会说，别的工作我不会做啊？没关系，我们可以结对啊。通过结对工作，可以快速学会各种技能，开发能做业务分析，也能做测试，测试也能写代码，也能做业务分析，业务分析也能做测试。再结合可视化，站会，Code Review 这些实践，让业务和技术的上下文在整个团队中流动。
最好的团队是每个人有自己的专长，又愿意开放地学习上下游的其他技能，勇于拓展自己的舒适区。这就是 Scrum 价值观中「开放」，XP 价值观中「勇气」的体现。

质量内建在交付过程中

当测试成为软件交付的瓶颈时，传统的做法是增加测试资源，但这难免有点儿亡羊补牢的意思。我们应该系统性地解决问题，让问题不再出现，而不是在问题出现后再去修复。可能的方案有：

• 增加测试资源：加人或加班
• 减少测试工作量：提高上游交付的质量
• 提高测试效率：提升个人能力或使用自动化工具

通过前文说的模糊分工，实现了测试资源的动态扩展。通过引入 BDD，TDD，重构，结对编程，Code Review，持续集成等实践，建立单元测试，集成测试，端到端测试的自动化测试体系，提高上游的交付质量。通过培训和引入新工具，提升效率。

回到题主的问题上

敏捷团队有专职的 QA 吗？测试工作整体是怎么安排的？
答：通常会有一个 QA 专家。TA 会参与计划会议，充分理解需求，编写自动化验收脚本。在 Dev 领取一个需求前，BA，QA 和 Dev 一起对需求和验收条件达成共识。在 Dev 开发完成进入测试阶段前，跟 BA 一起在 Dev 的机器上快速验收，有问题立即处理。在 UAT 环境上做探索测试，性能测试，压力测试等。