《Scrum精髓》审校后记：关于Acceptance Test的翻译引发的思考

　　《Scrum精髓》审校后记：关于Acceptance Test

　　我在参与审校《Scrum精髓》的过程中，审译者队伍对于“Acceptance Test”这一词汇应该如何翻译有着不同的意见和理解，经过大量的交流和讨论，非常感谢审议者队伍对于“接收测试”译法的理解和支持!此文正是为了记录选择“接收测试”译法的原因而成，可见于《Scrum精髓》书中的后记一章。

　　不知道读者看到“接收测试”、“接收测试驱动开发”这样的词汇会不会觉得好奇，接收是什么意思?是不是就是验收测试?跟UAT也即用户验收测试又有什么区别呢?其实不瞒读者朋友们说，就算是在译者、审校和编辑内部，关于“Acceptance Test”应该怎么翻译，也是有不同意见的。最终大家确定下来，采取“接收”的译法，并附加注释和这篇翻译后记，之所以会这样做，当然是因为这个词很重要。简单来说，敏捷的AT跟传统的UAT根本就是形似神不似，其内涵和具体用法有着极大的区别。Gojko Adzic在他的《Bridging the Communication Gap》书中就明确地表达了自己的观点——“它们根本就处在软件项目的两个相对端”。而Janet Gregory和Lisa Cripin在《敏捷软件测试》书中也认为“‘Acceptance Test’这个词特别迷糊人，因为它让一些人认为它就是’UAT’。在敏捷的语境下，它通常被用于指代面向业务的测试，但该术语同时也包括第4象限的面向技术的测试，例如客户对系统性能或安全的要求。”

　　首先我们要来看一下这些词汇本身的含义和历史，以及是如何诞生的。

　　传统的UAT概念已存在多年，并无很多争议，它是在软件项目中客户签收交付物并认可其已完成的阶段所执行的一类测试，关注重点在于该解决方案能够解决用户的问题，而非系统本身有无故障、是否满足了需求文档中的要求。

　　然而，在敏捷方法中经常提到的Acceptance Test则有很大不同。首先，它并不是在最后阶段才执行，而是在开发过程中执行，侧重于验证所开发的功能或故事满足了要求。它并不是一种或一类测试，而更像是一个逻辑概念，像一个框，代表多种不同类型的测试。

　　Acceptance Test这个词汇的起源，跟FIT这个工具很有关系，最初就是被用来描述一个故事在功能层面的测试，以便与单元测试区分开来。这在很多文献中都可以看到，而且至今也还有很多敏捷实践者仍把Acceptance Test当作是Story Test(故事测试)的同义词，不过Janet和Lisa则认为AT这个词同样可以被用于描述验证远高于故事层级的行为，而不仅仅只是适用于故事。Gojko则认为这个词本身并不好，他自己更偏好于“可执行规格说明书”的说法，因为这描述了它的本质，它本来是就是用于开发的规格说明书，只是用了一种可以被直接执行以检查代码的形式而已。

　　说了这么多，其实也是想证明，从词汇诞生的历史来看，敏捷的AT和传统的UAT确实就是不一样的。但探究多个概念的含义到底有何区别，不能够只是关注单词本身，还需要考虑词汇所代表实践在特定场景下的实际运用方式等各个方面的因素。

　　在敏捷开发中，如果说存在着一个完美的情况，那就是开发团队经过一个短迭代的开发之后，可以拿出一个可交付或者潜在可交付的产品增量，那这也就意味着团队需要完成可交付或潜在可交付标准里的所有测试，代码级别的测试就是单元测试，而更高级别的各种测试则被用“Acceptance Test”一个词所代替。

　　之所以这样做，也是因为在敏捷开发中，进入到高级别测试环节的时候，我们所拿到的或者所面对的并非是一个“完整的”系统，而是“部分”、“少量”特性，甚至只是故事(有人认为故事包含多个特性，也有人认为是一个特性被分成了多个测试，总之不是所有人都认为故事和特性是等价的)，如果我们要按照传统的方式把所有的测试阶段、测试层级、测试类型都进行逐一地规划，那么测试管理的成本就太高了。顺应敏捷开发的特点，一切都从一个细小而明确的需求出发，那么团队采取的方式就是在计划时明确地定义需求的边界和验证的标准。如果需求是实现一个新特性，那么测试就大多是功能型的测试;如果需求是要改进系统的响应速度，那么测试主要就是性能测试;如果需求是增加对某款新型浏览器的支持，那么测试很可能就涵盖了功能测试以及兼容性测试等一些类型。然而，不管是何种类型的测试，它们都是用来判断某个具体需求或故事是否已经完成的标准，并称之为“Acceptance Test”。以此方式，也可以简化团队在计划时的工作，团队只需要问“那这个特性要做到什么样子才算完成呢?”至于这些要求如何细化为具体的Acceptance Test，则由交由团队来完成。

原文转自：linkedin.com