大多数人在想到敏捷测试时，先涌上心头的是工具、自动化、何时以及如何测试，还有团队中测试人员的职责。这些都是非常有价值的话题。但是其中哪些是成功必须的因素，哪些是可有可无、有则最好的东西呢？
Craig Knighton 的《我的工作说明不包括这些》一文中讨论了团队应该如何向敏捷转变，他在其中写道：
作为一个团队，我所指的是自组织、跨职能的团队，团队应该认识到：除非自己能克服这些挑战，产出的产品才能得到期望的质量和及时性。除非质量成为所有团队成员的职责，否则就很难打破“编码 - 测试”这样的循环，而这正是问题的根源所在。软件开发中的手工回归测试，完全相当于在生产流水线上的人工检查。在制造业中，人们知道：在自动化检查和早期流程度量方面的投资是关键。然而，一个产品也许要经过改变才能通过自动化方式的测试——这对架构或开发工具的变更要求将会是非常巨大的。在开发者测试上投入精力和时间，能够减轻对于人工检查的依赖，但这意味着开发人员的工作习惯要改变。最后一点，开发人员需要为创建自动化测试套件提供帮助。
他的说法跟社区中的普遍观点很类似。刚刚实施敏捷的团队，可能正打算采取逐步实施的方式，要想取得产品的成功，他们必须着重认识到：成为自组织、跨职能团队是必备条件，不是可有可无；而且还要摆脱“又不是我的屁股上着火”这种心态，这也非常重要。
说到敏捷测试，我们不能不提到刚刚在柏林举办的 Agile Testing Days 会议。Gojko Adzic 对于会议的多个演讲写了一个简要概述。Gojko 提到了 Mary Poppendieck 的一个演讲：
Poppendieck 认为“现在 [软件开发领域] 最大的缺陷是容忍缺陷”。她建议将每个失败之处（即没有发现的缺陷）看作一次学习的机会。找出失败之处的问题根源并消除它 ，从而让类似缺陷在未来消失，这才是前进之道。
来自精益的“停止然后修复”的心态与自组织、跨职能团队直接相关。如果团队没有在一起工作，那团队就不会停下来，但是单独的个人可以停下来（如果你足够幸运）。如果团队真地停止工作，他们就丢掉了在一起学习的机会。学习是软件开发非常重要的环节，在笔者看来，学习才是软件工程的瓶颈。
查看英文原文： Agile Testing Requires Cross-Functional Teams and More
暂无签名
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论