《Scrum精髓》審校后記：關于Acceptance Test的翻譯引發的思考

　　《Scrum精髓》審校后記：關于Acceptance Test

　　我在參與審?！禨crum精髓》的過程中，審譯者隊伍對于“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