《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