我和敏捷团队的五个约定

我——作为一名测试人员——有一个与众不同的习惯：每当要加入一个新项目的时候，我总会找到项目中的同伴，真诚而亲切地说：“为了更好地合作，我有5个约定，希望大家能尽量遵守”。
约定1. 业务分析师们，我们其实是同一个角色的两种面孔，请叫上我们参加客户需求会议

我们的团队需要让客户频繁的得到可用的软件，客户的不断反馈会给软件的未来做出最正确的方向指引。

如果我们交付的软件有很多质量的问题，存在大量的缺陷，客户会被这些缺陷的奇怪行为干扰，没有办法把注意力放在软件本身的价值是否符合他们的真正需求上，不能给出最有价值的反馈。所以，我们只有频繁的做测试，在每次交付之前都把质量问题找出来告诉我们的团队，问题才能及时的得到改正。

而我坚信“prevention is better than cure”（预防胜于治疗），我会要把工作的重点放在预防缺陷上，这样可以节省Dev们很多修复缺陷的时间与精力。

为了达到这个目的，我需要跟你一起参加客户需求会议，尽早的了解客户需求与使用软件的惯常行为。那么在你完成需求的验收条件的定义的时候，我也基本完成了测试用例的准备。

我们可以赶在开发人员们写代码之前就告诉他们我要测什么，让他们减少因为过于乐观而漏掉的一些重要的有破坏性的情况，减少缺陷的发生。这是我测试的一项重要任务。

如果你们在大部分需求都整理好了再交给我们，我会浪费掉等待的时间。更重要的是，开发好的软件里面已经有很多本来可以不存在的缺陷在里面了，开发人员们可能需要加班加点来保证在项目最终交付时间之前把它们改好。这样很容易产生新的缺陷的。

所以，请让我尽早了解需求，请不要让我到项目后期才能开始测试。

约定2. 开发人员们，虽然你们是编写自动化测试的专家，但请听听我们意见

我知道，对于你们，自动化测试不过是利用junit, rspec, selenium，watir，uiautomation等等写出的“另一段程序”而已。而对于80%的QA来说，编写自动化测试并不是一件简单的事情。

不过我仍然相信，有测试人员介入的自动化测试更有价值。

你们用单元测试，集成测试来保证代码的质量。然而你们的这些日常测试离代码更近，离最终用户还点远。很多测试都不是在测软件功能。

你们可以把功能测试写的又快又多，而我们可以指出什么功能测试最有必要加到自动化测试中。

你们平时大部分精力都在编码上，没有太多时间去查都有什么缺陷。而我们可以指出什么地方缺陷可能会出现的比较频繁，建议在这些脆弱的地方加自动化测试。

所以请听听我们的意见，我们可以给你们提供这些信息。

约定3. 项目经理们，请不要要求我们测试软件的所有路径

软件测试是一个永无止尽的任务。基本上没有什么软件简单到我们能够尝试完它的每一个可能的路径的。就连一个看似简单的微软计算器都有无穷尽的路径，无止尽的输入，更何况比这个更复杂的商用软件。

如果你们担心没有尝试过全部的路径不可靠，疑惑我们怎么敢说这个软件质量是好的还是坏，都有什么风险。请你们先注意，我们是跟业务分析师一样，都了解软件的价值的。价值可以帮我们做出判断，什么时候可以停止测试并对客户说我们的软件已经满足您的要求了，请放心使用。

因为我们了解价值，我们可以肯定的说哪些软件的使用方式是至关重要的，哪些是不太可能出现的。我们会在全面测试了软件以后，把主要精力放在价值高的功能点上。合理的利用项目有限的时间。

因为我们了解价值，我们可以正确的把发现的问题分类。我们可以帮助dev们把精力放在重要的缺陷上，避免把时间放在对于客户微不足道却不得不花费大量精力才能修正的问题上。

所以，请不要要求我们无止尽的测试一个软件。我们了解价值，请相信我们的判断。

约定4. 迭代经理们，如果对于交付风险有任何疑问，请来询问我

BA和Dev们都是关注一个软件在什么情况是可以良好的工作。而我们除了验证这些情况以外，大量的时候都用在寻找什么样的情况软件不能正常的运行。所以除了针对定义好的软件行为进行测试，我们还会做很多探索性测试。我们通常可以通过这样的测试发现一些没有定义的、不曾预期的行为。这些行为往往将会构成软件交付的风险。

我们会告诉你们现在都发生了什么问题，分别分布在哪里。

我们会告诉你们，在什么情况下软件可能会有异常行为，是不是会牵连到其他的部分，是否可以绕过去。

我们会告诉你们，哪些部分功能比较不稳定，需要更多的留意。

约定5. 测试人员们，那些敏捷实践对于我们也是有用的。

结对不是dev们的专利。我不希望总见到你们独自坐在自己的位置上冥思苦想。走出去，跟其他队友多多交流！

多跟测试队友交流，pair看看设计的测试用例是不是够全面，独自一个人想到的未必足够好。他们会给你诚恳的意见的。对他们，也请一样认真对待。

如果你发现开发人员们做出的架构决定使测试工作变得更困难。那么请大声地告诉他们，design for testability（提高你们设计的可测性）。

如果你发现业务分析师写的需求无法验证，定义的客户行为不够具体，一个用户故事中包含太多了功能点，等等，那么也请大声地告诉他，INVEST（独立，可协商，价值，可估算，短小，可测）。

也请你们多跟开发人员结对写自动化测试，既可以帮助你们学习怎样更好的编写自动化测试，也能帮助开发人员们结对更多的了解用户行为。

这就是我的五个约定，它们是我在团队中顺利展开工作的基础。

作者：覃其慧，ThoughtWorks敏捷咨询师。她参与了大量的敏捷软件开发的实践和敏捷咨询。目前主要关注以价值为驱动的敏捷测试。

 

 

感言：在自己公司感慨颇深啊,最近写一个台湾总公司的程序！不告诉我们业务上的意义，照着连需求文档都算不上的文档写，发现问题还要无尽的等待回复，奇怪的方式操作着传说中的informix。需求改了，出错了还说我们的浪费他们时间，靠。

 

最近被气爆了