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