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

　　然后，待到迭代结束，既然测试的标准是以可交付或潜在可交付来制定的，那也就意味着只要这些测试通过了，我们就可以满怀信心地将它交付出去了。但这些测试也只是给了我们自己信心而已，它与传统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”译为“接收”岂不是产生了更大的价值?

　　所幸最后，“接收”的译法得到了大家的理解和认可，但大家也都觉得，这段故事不应该被埋没在书本纸张的墨水之下，也应该让更多的人看到这本书，看到这些译者字斟句酌的认真态度。正是出于这样的考虑，大家决定，用这篇翻译后记来记录我们在翻译过程中的纠结和争论，以及最终选定“接收”译法的考虑。

原文转自：linkedin.com