UAT：它也是一種“群體測試”嗎？

標籤：眾包測試   群體測試   

	Viktor Grebenyuk是一名品質保證專家和測試經理，在測試複雜的（主要是金融領域的）系統和應用程式方面有八年以上的經驗。他豐富的經驗讓他可以：比較不同的測試載入器和方法，突出它們的優缺點，並努力找到最適合每個特定案例的正確方法。
	Natalya Serdyuchenko自2004年以來就一直從事軟體開發與測試。她曾與摩托羅拉，索尼愛立信，華為等客戶合作，擔任測試工程師，測試經理和首席分析師。她目前的工作與銀行產業有關。Natalya對改善測試流程，特別是UAT流程有著濃厚的興趣。

?

　　使用者接受測試（UAT）看起來像“群體測試”主要是因為：執行此測試的人不是測試專家。這些人可能是他們自己業務領域的專業人士，但卻對軟體測試原理和技巧還不是很懂。你可能會爭辯UAT的價值及其在SDLC裡的地位，但是一旦你決定去做UAT，你就必須得解決如何讓非測試人員（如：企業使用者）有效負責此事。另外，你或許需要考慮一系列問題：該如何在你的組織裡將UAT和現有測試程式結合起來；建立UAT測試案例的需要及這些測試案例應該看起來像什麼；以及誰負責UAT管理。本文的目的是減少在一個項目上組織和管理UAT時你可能發現的關鍵問題。

　　如何讓非測試人員（企業使用者）有效地進行UAT
　　 首先，如果你想強制非測試人員（我們稱他們為UAT執行者）有效進行UAT，你必須教他們如何做到這一點。你可以使用任何相關的培訓策略（線上培訓，面對面會議等）提供為項目選擇的UAT方法或在你的組織中被獲批准的一般UAT程式的概述，並在UAT中突出他們的職責。一旦有了這些資訊，也有利於共用軟體測試的基本知識，並為他們提供一個在UAT中將被使用的測試載入器的示範。除此之外，或許有必要為他們展示端到端的商務程序的概述。因為事實上一些UAT執行者心中可能並沒有完全掌握端到端的商務程序只是因為他們的日常工作往往局限於被測解決方案（ SUT ）的一個獨立部分的使用。請記住，即使在已經通過了所有培訓課程並學習了你項目開始時給他們提供的所有材料後，UAT中，人們仍然需要持續地諮詢和支援。隨時做好準備，並與UAT執行者保持聯絡，要記得，某些時候你或許需要對一些人重複初始培訓。即使有些企業使用者過去參加過UAT，有經驗了，仍然需要為他們提供至少一個有限的培訓課程，因為UAT過程的某些方面可能會因項目而異。在某些情況下，只分享UAT方法或測試技術並不足以使UAT執行者有效地進行UAT—— 最難的事情是激勵人們。 UAT執行者應明確認識UAT的目的並瞭解他們的責任以及他們正在增加的價值。如你所知，有動力的人才能取得更大的成績，所以，如果你想從你的UAT獲得儘可能多的優勢，你應該儘力讓這些人不僅僅只是遵循正式程式，還要願意參與到UAT中去 。這樣的話，你不僅會獲得好處還能體會到樂趣——下一次與這些有動力的UAT執行者合作就更容易了。在任何情況下（即使你沒有能力為這些人提供任何額外的動力），都請確保你以甚至只讓人們遵循正式步驟就可以獲益的方法去設定過程。
　　 這種情況下幾點建議將協助你，如： 
　　 ?給UAT執行者提供包含他們可能會在UAT中所需要的所有資訊（關於測試環境，獲得被測apps，如何使用測試載入器的手冊，連絡人清單，等等資訊）的詳細說明; 
　　 ?提出一個UAT執行者和UAT團隊其他成員之間的明確溝通計劃; 
　　 ?制定一個清晰易懂的可以在UAT過程中使用的程式以解決UAT執行者的問題; 
　　 ?確保UAT經理和UAT團隊其他成員在解決UAT執行者的問題中的高參與度（他們應該在任何時候都可以感覺到有人可以協助他們）。 
　　 擁有一個有固定測試時間的UAT執行者團隊將是一個真正的優勢（假定50％的時間用來測試，50％的用於線下活動）。建立合理的迴圈，就可以建立一個UAT專家團隊，節省大量培訓時間去做進一步的UATs。

　　如何在你的組織機構中將UAT與現有的測試程式結合起來
　　 將UAT與組織中正在使用的其他測試程式及相關標準（這一點在UAT是項目中使用的唯一一種測試的情況中尤其重要）結合起來很重要。
特別是，你需要確保你生產成為UAT一部分的測試物，文獻和報告與預計生產成為其他測試活動的一部分的是一致的。這也適用於測試管理工具和缺陷跟蹤工具：建議所有測試結果以與被其他類測試管理一樣的方式被擷取和管理。
　　 這將有助於為執行和執行結果計劃的UAT測試案例（如果你有大量的UAT利益相關者，這一點尤其有效）獲得更大的知名度。識別被發現為其他測試活動（如果有的話）一部分的缺陷的副本，並確保所有已識別的缺陷得到妥善處理。

　　你需要生產作為UAT一部分的測試案例嗎？他們應該看起來像什嗎？
從一開始就必須注意，我們強烈建議為UAT編寫測試案例（它們可以被稱為測試案例，測試指令碼，用例，使用者故事，等等）。企業使用者常常盡量避免這樣做，理由是他們已經知道他們將要做什麼及怎麼做，因為它與他們的日常工作類似。捕捉提前為執行而計劃的所有測試案例仍然很重要。
　　 首先，這可以讓你瞭解究竟要驗證什麼，為此要做些什麼，預計會有什麼結果。建立UAT測試案例不僅對在實際開始執行過程前規定驗證範圍很有必要（有時人們在或許真的可以給正被執行的測試增加價值的測試期間開始進行額外檢查，但也可以毀掉整個UAT計劃或為測試的其他部分準備的相關資料），同時也使得UAT的執行在資源和基礎設施的使用計劃（包括人力資源）方面更有效，增加了測試集的堅固性（例如，它有助於在平行多人建立UAT測試案例時避免重複檢查，或協助揭示覆蓋缺口和錯誤假設），並讓你能夠在執行階段更精確地追蹤UAT進度。UAT的性質不同於開發人員或測試專家正在執行的測試類型—— UAT沒有如驗證被測系統是否正常工作這樣的目標。這種類型的測試的主要目標是確保SUT響應客戶的期望，並使企業的目標得以實現。正因為如此，UAT測試指令碼看起來應該是什麼樣的並沒有硬性規定——他們可能被建立為正式的測試案例，使用者故事，甚至審核清單。UAT案例的細節的格式和水平可以根據下幾個因素而有所不同： 
　　 ?你用於開發和執行測試案例的時間。 
　　 ?測試基礎設施的制約。 
　　 ?UAT執行者的經驗（包括他們在企業領域的經驗和軟體測試原理和技術業務方面的經驗）。 
　　 ?UAT團隊成員的可能迴圈（你可以在你項目的UAT過程中使用相同的企業使用者，或有時你需要換用新人）。 
　　 不論UAT測試將被寫入的方式，UAT測試中的與其他測試類型（例如前提，將被執行的一系列步驟，期待的結果或一名參賽者）使用的相同的強制測試案例屬性要被包含在內。定義一個將實施這個測試案例的業務角色非常重要，因為同一個業務情境根據執行者可以有不同的流量（同時請考慮一下客戶體驗——讓某個人扮演客戶以確保過程與最終客戶的角度一致是很有用的）。計劃測試案例的開發時，你可能會把這些因素考慮在內，但你也應該記住，準備的測試案例很明確且它們很可能由企業使用者運行都很重要，這取決於測試哪個業務過程。當你考慮UAT測試案例的覆蓋範圍時，除了對商務程序的特定bit的單獨驗證，你還應該考慮加上一個終端到終端的商務程序驗證。最後，如果你想從UAT測試案例獲得好處，你應該牢記你決定開發他們的理由。對這件事不要採取正式方法，而要以飽滿的熱情（這最後一條建議適用於UAT過程中的任何活動及其他）建立它們。請記住，UAT的執行有時可能會更新原來的業務需求，甚至創造新的需求，因為UAT的執行正成為企業使用者（多數情況下的需求發起人）重新思考他們原先需求的正確性和詳細水平，以及營運目標的完整性的另一原因，因為，在這一點上，他們已經開始使用新的解決方案，甚至第一次詳細地看了新的解決方案。建立UAT測試案例較早地利用了業務需求識別問題，這樣修複它們的成本可能會減少。

　　誰負責UAT管理？
　　 UAT的關鍵成功因素之一是選擇合適的人來管理這項活動。 UAT往往被視為（相對於解決方案而執行的）測試類型之一，所以讓一名測試經理或測試領導管理UAT或許看起來蠻合理的。此人在管理UAT時很可能有類似責任心且必須處理類似問題，如他或她管理系統整合測試（ SIT ）時面對的問題。另一方面，UAT經理將會需要處理一些其他類型的（在某些情況下需要額外的個人技能和/或關於被測系統的商業邏輯知識的）問題。例如，UAT管理和SIT管理之間的重要區別之一是，正在做UAT的人不直接向UAT經理彙報（這是UAT看起來像一種“群體測試”的另一個原因） 。正在做UAT的人仍準備好了他們的生產線管理，這也需要這些人去做他們的主要（即非測試）工作。因此，在某些情況下，UAT經理必須找到UAT執行者線上活動和UAT相關活動之間的適當平衡點。在這種情況下，UAT經理應該有機會獲得升級路徑，因為測試者無法及時實施其UAT的一部分可能會危及整個UAT活動。值得一提的是，避免任何形式的利益衝突，特別是當一些人在項目團隊中擔任多個角色時，也很重要。

　　結論
　　 UAT是解決方案生產前的最後一站，這意味著UAT的組織和管理方式將（在大多數情況下）定義開發了的解決方案的企業使用者期望，這意味著UAT的作用尤其重要。我們希望這篇文章將幫你避免常見的錯誤，在你的項目中提高UAT效率。一件需要銘記的事是，即使你已經建立了一個強大的UAT過程，如果你找到一種方法來激勵人們，你總能從你的群體測試中獲得更多。

　　著作權聲明：本文出自 SPASVO澤眾軟體測試網：http://www.spasvo.com/news/html/2014527145528.html

　　原創作品，轉載時請務必以超連結形式標明本文原始出處、作者資訊和本聲明，否則將追究法律責任。