本文共 4283 字，大约阅读时间需要 14 分钟。
作者：徐毅
我在参与审校《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，则由交由团队来完成。
然后，待到迭代结束，既然测试的标准是以可交付或潜在可交付来制定的，那也就意味着只要这些测试通过了，我们就可以满怀信心地将它交付出去了。但这些测试也只是给了我们自己信心而已，它与传统UAT代表的客户或用户验收通过的含义相距甚远。
再退一步说，其实真正能够做到研发团队交出来的就是一个可交付或潜在可交付的东西，更多的时候都还需要交给某个专门做更高级别或更接近尾声的测试的部门，例如系统测试、性能测试、全联网测试等等。这也意味着在研发团队完成开发和测试之后，还有一些其他类型或阶段的测试工作需要继续，半成品的系统还没有达到可以交付的水平，当然也远没有到可以去执行UAT的状态或时间点。然而，我们仍然选择用AT来指代研发团队开发过程中完成的所有测试，是用来判断团队产物可不可以进入下一个环节的标准。
再来看，UAT所服务的主体是用户或客户，从某个角度来看，团队和客户是处在两个甲乙双方的关系，“验收”这个词也体现了甲方验收乙方交付物的概念。然而，在敏捷中，AT意味着团队完成了开发测试过程之后，向某个角色或某些角色声明工作已完成的标准。而且AT所服务的主体通常都是产品负责人或是内部干系人，也都归属于乙方的范畴，且不说敏捷方法强调开发人员和业务人员的紧密合作，敏捷宣言同样也明确地提到了“客户合作 高于 合同谈判”，为AT这个术语所选择的中文词汇当然也要提现这种合作的态度和倾向才行。
而且，正如《敏捷软件测试》提到的测试象限图所描述的那样，并不是从传统到敏捷之后，UAT就被AT所取代，而是呈现出一种并存的态势。
如果我们认为在敏捷下仍然存在UAT，而且也翻译为“用户验收测试”的话。那么我们应该把敏捷的AT翻译成什么呢？不管是从敏捷测试理念还是从翻译的角度来看，我们又怎么可能接受在开发过程中有 “验收测试”、而后再执行“用户验收测试”呢？从两个概念在敏捷方法下所发挥的作用来看，AT是支撑团队、支撑开发过程的，而UAT则是支撑用户或客户、出现在开发过程之后的。
从前面一些测试领域专家的意见来看，UAT可以被看作是从AT中挑选出来的一组具有特定意图和目的的测试子集；而且UAT侧重于验收，具有已通过检验、可以付款的意味，而AT则侧重于引导团队与干系人之间的沟通，指引开发过程沿着正确的方向前进。
作为一名敏捷圈内少有的测试出身的敏捷教练，“Acceptance Test”这个词到底什么意思，我也跟众多敏捷测试领域的大师级人物交流过，在国内测试圈内也已经跟很多同行争执过这个术语的翻译，我无法接受在我所审校（或翻译）的书籍中将它翻译成“验收”，所以也跟本书的译者、编辑和其他审校者们争得面红耳赤。我认为实际情况是人们普遍会把传统的UAT简称为“验收测试”，如果我们在翻译敏捷相关作品时，也将敏捷中的“Acceptance Test”翻译或称呼为“验收测试”，从受众的角度来看，几乎不太可能会意识到这跟他们一直所理解的“验收测试”（也即传统的UAT）是不同的概念，在敏捷中的用法也不同。从传播知识的角度，这是我不可接受的结果。
另一方面，老实说，或许“接收”的译法在测试圈内也不一定有共识，但我自认为对敏捷测试的理解还是很到位的，我们不能够因为“觉得跟传统UAT差不多”就沿用了旧的词汇，敏捷测试跟传统测试本就是非常不同的两种主张，要想激发普罗大众形成这样的意识，就更不能够用“旧瓶装新酒”的方式了。如果这本书出版之后，“接收”的译法能够激发读者们去思考、怀疑、挑战它，那也是一件非常值得庆幸的事。即使，更多读者和从业者一起群策群力找到了比“接收”更好的译法，从改变测试世界、引导正确认识敏捷测试理念的角度来看，我们决定在本书中将“Acceptance Test”译为“接收”岂不是产生了更大的价值？
所幸最后，“接收”的译法得到了大家的理解和认可，但大家也都觉得，这段故事不应该被埋没在书本纸张的墨水之下，也应该让更多的人看到这本书，看到这些译者字斟句酌的认真态度。正是出于这样的考虑，大家决定，用这篇翻译后记来记录我们在翻译过程中的纠结和争论，以及最终选定“接收”译法的考虑。
亲爱的读者朋友，如果你对“Acceptance Test”这个词该怎么翻译也有想法，不管是怀疑、挑战、支持、建议或是任何思绪，我诚挚地邀请你与我联系，我非常愿意交流这个话题！
徐毅，敏捷顾问、敏捷测试专家
,
参考资料：
关于《Scrum精髓》和购买地址
转载地址：http://hljli.baihongyu.com/