敏捷驱动QA改变

敏捷理念由来已久，若从敏捷软件开发宣言的发布算起，今年已经是20周年了。在这漫长的岁月里，越来越多的团队在“四个高于”的价值观引领下，以十二项原则为指导，欣然求索而持续演进，在实践中探寻更好的软件开发方法。虽然敏捷自身一直在变化，不同团队对敏捷实践的落地也多有差别，但人们对敏捷核心的理解趋于一致。“追求更短的反馈环” – 便是其中被大家广泛认可的一项核心目标。假如以终为始来看，那么：

• Inception的采用，拉近了项目团队与产品团队/用户的距离，在获得需求有效澄清的同时也对软件设计进行快速反馈和更新。
• Pipeline的采用，加快了软件集成的效率和频率，挂载流水线上的分层自动化测试缩短了代码检测的反馈环，这也是落地快速交付的根本之一。
• 而快速交付的实现，完成了产品/用户-项目团队-外部市场的闭环，小步快走，缩短了市场验证的反馈环。

然而，以“追求更短的反馈环”为目标的敏捷，不仅仅在以上方面改变着敏捷团队的开发流程和技术实施的软件工具，也真切改变着团队人员的角色认知，工作内容和思维方式。在这篇文章里，我们来梳理一下在敏捷驱动下，QA这一角色如何从传统Tester一路走来并不断演化（或许不久的将来会更名为QE）。

角色认知

曾几何时，CMMI还流行，研发中心的人员按职能维度被划分为PM团队，开发团队，BA团队和测试团队等（这可能是角色墙或部门墙形成的一个条件），那时测试团队中质量管控的角色则被称为：

• 手工测试工程师
• 自动化测试工程师
• 专项测试工程师（诸如：安全测试，性能测试，无障碍测试）
• 测试经理

在项目敏捷化转型的过程中，上面各个团队的经理，当然也包括测试经理，或情愿或不情愿地从自己团队中抽出一部分人力资源组建出特性团队。这个团队在敏捷深化的过程中也经历类似塔克曼团队发展模型的历程，下面我们从质量的角度来进行分析。

组建期

这个时期࿰