敏捷团队有专职的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 环境上做探索测试,性能测试,压力测试等。