Scrum是軟體開發的敏捷方法。它以2到4周為一個迭代開發出有價值的商業功能。Scrum團隊有兩個明顯特徵：他們是多面手（例如：他們具備完成工作所必須的所有技能）；他們是自管理的（例如：團隊不斷探索如何把工作做的最好的方法）。通過過去兩年在Scrum團隊中近2年的QA角色的不斷實踐，我認識到Scrum中的QA不僅僅是編寫測試用例和彙報缺陷那麼簡單。

對比傳統瀑布模型的專案中的同步活動，Scrum期望開發活動根據實際需要的順序來執行，例如非同步。這點有悖傳統，讓許多客戶、開發和業務關係人等新手產生疑惑 “如何在程式碼還沒有完成之前進行有效的測試？” 本文重點解釋了QA如何執行敏捷測試以及Scrum團隊中QA角色的重要性。我將通過本文分享在我對Scrum團隊中QA角色及職責的認識。

不僅是編寫測試用例

傳統瀑布模型的專案中，QA介入的時機往往是在程式碼全部完成後的專案收尾階段。這些專案中，QA拿到一份需求文件和已經完成的程式碼，然後開始編寫和執行測試用例以檢查應用程式是否符合需求文件。然而，Scrum中的QA角色不再僅僅是執行測試用例和彙報缺陷。

在Scrum團隊中，QA分析師和其他團隊成員一起參與或擔當大量職責。他們從專案一開始就介入，並且與業務分析者和開發者密切聯絡。在Scrum中，QA不是一個單獨的測試應用程式的團隊。取而代之的是，Scrum團隊是一個業務分析師、開發者、QA一起協同工作的綜合團隊。除了編寫用例，QA還幫助產品負責人（PO）編寫接受用例，相當於承擔產品負責人代理的角色。當產品負責人沒有時間時，QA作為代理保持團隊持續前進。QA和產品負責人通過提出問題和質疑假設進行互動交流，最終澄清業務需求。

參加評估使用者故事（Story）

QA分析師一般很擅長根據使用者需求建立測試用例場景。在識別和捕捉複雜和否定的用例上也很卓越。事實上，在這點上，QA往往比開發做的好，因為開發往往關注使用者故事的好的方面。在版本和週期計劃會議中評估使用者故事時邀請QA參與能讓團隊不再僅僅思考好的方面，有利於產生一個綜合好壞情況的客觀真實的評估。評估是一個很難的事情，讓所有人都參與評估是很好的實踐。

有利於保持視角和目標明確

當團隊執行測試和其他穩定產品的活動時，QA需要掌控計劃、組織或讓整個團隊投入到測試工作中，並且像Scrum Master(SM)那樣保持成員處於積極狀態。很少有開發者喜歡做測試任務。QA需要和Scrum Master一起讓測試對整個測試團隊可見且目標明確。從而保持開發者或其他成員的積極性。有時一些測試場景的構建需要開發或其他團隊成員的幫助，這樣容易創新。力爭讓測試活動有趣，例如用刺激的測試場景、出人意料的測試資料和帶有娛樂意味的競爭。總之，做任何事情，只要有助於團隊樂於加入測試工作即可。

與客戶和開發者緊密合作

QA的主要職責之一是將他們的測試結果反饋給產品負責人或收集他們的反饋。QA和產品負責人緊密合作，幫助他們制定詳細的使用者故事驗收標準。隨著團隊在每個迭代中的深入瞭解，QA也可以幫助產品負責人修改或增強使用者故事以更好地反映真實的需求。

偶爾，QA分析師還充當產品負責人代理。這種情況下，QA和開發者將坐在一起，作為一個團隊一起工作以提高產品質量。QA可以和開發者結對來寫單元測試，討論驗收標準。合作的工作越多，需求也越清楚。一起工作帶來的清晰需求將減少編碼過程中經常遇到的各種問題或疑惑，從而給有效提高開發效率、節約開發和QA的時間。

根據團隊每個人的需求和實際情況，整個團隊將成為一體，都會協助測試。這樣的實踐平衡了團隊和工作完成必須的共同職責，早期測試反饋和持續增長的質量下，它將使專案進展更快。

提供快速反饋

傳統瀑布模型團隊不斷重複的“構建-測試-修復”週期徒增了大量額外工作量，浪費了大量時間。在Scrum中，QA和開發者在整個專案中一起工作，讓活動變得更簡單。在開發過程中，開發者能直接諮詢QA驗收標準或從使用者視角任何功能上的期待行為。這讓測試和缺陷修復更簡單。

自動化迴歸測試

自動化測試常被譽為測試者最好的朋友，因為它可重複執行且執行一致，能得到更好的軟體功能的測試覆蓋率。在2到4週一個迭代的Scrum專案中這點尤為正確。因為QA大體都沒有太多時間去測試應用程式。在2周的迭代中，QA必須完成迭代中所有新功能的功能點測試的同時還要完成對先前實現功能的測試。正因如此，這種職責提高了每個迭代中使用可用的自動化實踐以減少QA壓力的重要性。

當團隊執行持續整合時，自動化測試在快速反饋上大有用途。每釋出一個軟體新版本，可以執行自動化測試並快速提供反饋以反映是否新老功能都正常工作。而沒有自動化測試，就必須手工執行所有的測試，不僅單調，而且容易犯錯。自動化測試能更早的發現缺陷，讓QA有更多時間去探索新功能的一些特殊用例。通過自動化測試，QA可以更快更有效地完成測試工作。

參與釋出準備演示

在每個迭代結束時，團隊需要召開一個迭代審閱會議來向專案責任人和其他有興趣的關係人展示這個迭代完成的使用者故事。迭代審閱會議是團隊中的“良藥”，可以有效激發他們去儘可能完成更多使用者故事。

在2到4周的小迭代中，為了讓使用者故事按時完成，團隊中的每個人都必須沉浸在自己的工作。開發者關注實現使用者故事和修復缺陷，QA關注用例編寫、澄清產品責任人的問題、自動化之前迭代的測試。較短的迭代週期意味著開發沒有多少時間去獲知使用者故事要求的全部功能。這樣，開發一般要詢問QA以更好的理解使用者故事。因為QA知道完整的功能及每個需求和驗收標準。在迭代審閱會議上，讓QA演示專案和解答業務上的問題是很好的實踐。這也讓開發者更專注於處理技術層面的問題。

分析使用者需求

QA是Scrum團隊中產品負責人代理。他們擅長從使用者視角理解業務需求。因為他們經常被問到使用者如何使用專案。QA根據他們的測試經驗給產品負責人提供反饋，幫助他們更好的從使用者視角理解專案。

完善“完成定義”

對於敏捷團隊，清晰的完成定義(DOD)是很重要的。“完成定義”是團隊定義完成標準的簡單列表，是在使用者故事認定為完成必須要完成的事情。完成定義一般包括完成程式碼、執行功能和迴歸測試、獲得產品負責人的認可。一個簡單的完成定義可能包括如下專案：

1. 程式碼完成
2. 單元測試完成
3. 功能和UI測試完成
4. 產品負責人認可

定義“完成定義” 不是QA一個人的責任，QA的責任往往在於監管團隊完成定義和每個完成的使用者故事必須滿足“完成定義”的基線要求。一個高效的敏捷團隊在啟動每個使用者故事前都要審閱“完成定義”從而使團隊每個人都瞭解目標。“完成定義”不是一層不變的，可能會根據Scrum的需要不斷演變。“完成定義”既可以是迭代級的也可以是釋出級的。

用測試策略規範測試

由於Scrum團隊中沒有測試領導甚至測試專家。構建測試計劃或執行測試策略就存在問題。Scrum認為需要準備足夠的文件去支援團隊隨時提出的需求。正因為此，需要準備足夠的高層次測試策略的文件和計劃來指導團隊。因為沒有QA領導在團隊中，QA一般自己來制定測試策略。

測試者和分析者角色融合

測試者和分析者角色融合在敏捷團隊中很常見，業務分析師的角色一般是負責建立和維護迭代和產品的Backlog、從業務角度分析使用者故事、根據產品負責人要求劃分使用者故事優先順序。而QA角色一般負責為每個故事定義或完善驗收標準，確保之前完成的功能沒有老的問題。QA測試每個使用者故事，從終端使用者視角驗證定義的驗收標準是否已經達到，他們也根據業務來分析使用者故事。所以QA和業務分析師的角色責任、必備技能、總體目標有很多重合地方。

一般，在專案開始之時，敏捷團隊從產品負責人那裡拿到使用者故事和提前定義的專案範圍。在敏捷模式下，鼓勵團隊成員提出改善終端使用者體驗的新功能或改變已有功能，也鼓勵團隊一旦發現技術依賴或發現換一種實現將更有效而改變backlog中使用者故事優先順序和順序。無論是定義需求、分析使用者故事、定義和澄清驗收標準、編寫接受性驗證用例或和使用者緊密合作，對於小的團隊，測試者和分析者的角色融為一體有很多優點，但也存在一些缺點，最大的顧慮是沒有測試者或分析者能夠投入過多精力來完全盡責。

結論

除了編寫用例和彙報缺陷，QA在Scrum團隊中承擔更多的職責。他們是團隊的重要組成部分，並且從專案一開始就參與其中。

過去兩年在Scrum團隊當QA分析師讓我有了一個非常棒的體驗，同時也獲得了很多學習機會。我擔當了很多不同的角色和職責，包括QA分析師、產品責任人代理、幫助開發寫單元測試、確保團隊的質量意識和跟蹤問題和軟體缺陷。總之，這些體驗讓我獲得了很多 不錯的技能，同時讓我學習瞭如何做好不同的角色。更重要的是它告訴我如何去問問題而不再是僅僅遵循文件，也教會了我去做任何有助團隊成功的事情。