Martin Uhlig在德國德累斯頓的Saxonia系統公司擔任測試顧問。自學習商業信息以來，他一直對敏捷軟件開發和敏捷方面的當前動向很感興趣。他做過物流，媒體，和產品開發領域的不同項目。這也包括了他擔任測試員和產品所有者的敏捷項目。
情況
敏捷環境中的開發員和測試員肯定對下列情況很熟悉。一個團隊已經進行了很久的工作，但是他們沒有專業的測試員。結果，質量要求被忽略了。但是現在——就在產品發佈前——一切都會變好，團隊有額外的測試員支持了。今年年初，我被任命爲一個測試員流動量高的Scrum團隊的測試員時，我陷入了相似的情況之中。除了開發員已經建立的單元測試，並沒有自動化測試。但是隨着產品發佈的時間越來越近，團隊必須做出各種關於產品變化的短期決定。我們不得不用快速可靠的方式找到一個測試產品功能及其非功能準則的方法。爲了在項目的這個階段開始集成測試和UI測試的自動化，我們需要一個手動解決方案。
想法
與我們的產品所有者（PO）合作，我們創建了一個概念以組織一個只用於測試，修復和再測試的純粹的質量保證迭代（QA Sprint）。這輪迭代中並沒有安排特寫。我們該如何在這麼短的時間內測試整個產品呢？即使有九名測試成員，也不太可能在兩週的迭代內運行測試以達到令人信服且能提供信息的結果。畢竟有必要通過測試覆蓋不同的軟件配置。但是我們很幸運能得到五名同意支持我們測試的測試員和開發員的特殊幫助。所以我們的人員充足。但是該如何管理所有這些人呢？一開始就很明顯：團隊不能簡單地擴充。14個團隊成員（加上Scrum專家）沒有辦法創建一個有效的迭代計劃或每日Scrum，且整個團隊都必須進行重新組織。這並不是一個有效的解決方案，就算只對迭代也一樣。這樣，我們不得不另想他法集成額外的測試員。但是哪種辦法行得通呢？答案很簡單——我們需要更多團隊！但是一個新的Srum團隊不會突然出現，尤其對於一輪迭代來說。因此，我們不得不將Scrum團隊和QA團隊分開。Scrum團隊，由以前的團隊組成，應該像平時一樣用最佳的Scrum團隊的方法做基本工作。但是爲了加強Scrum團隊，我們需要額外的測試員，但是因爲上述原因不能讓他們加入Scrum團隊。因此我們不得不創建兩個實質上自己組織但不是SCRUM團隊固定一部分的團隊。這些QA團隊一直重複運行既定的測試集。Scrum團隊的測試員完成並迭代改進了測試集。QA團隊的工作與Scrum團隊的工作被嚴格分開以避免降低Scrum團隊的性能。因此團隊需要一個接口來過濾信息的交流，以避免信息氾濫（尤其是隻有實際bug，沒有重複等）。
Scrum團隊自身要專心再現並解決bug。我們決定在團隊間使用接口。團隊分開的唯一例外是每日Scrum會議。除了Scrum團隊，每個QA團隊的一個代理人給他們的當前狀態。改善該計劃，這樣團隊就能更好地平衡。Scrum團隊的開發員之一去了QA團隊和他們一起測試。這樣每個QA團隊就有三個成員，包含一個負責測試執行的經驗豐富的測試員。此外，Scrum團隊有兩個相對而言較新的成員，他們沒有充分地訓練過，無法快速有效地修復複雜軟件的bug。除了測試集和bug再現，這些同事還要進行探索性測試。總之，我們的最後計劃是：由兩個QA團隊進行一系列測試。這些測試包括所有的積極的和最重要的負面的測試用例。每個團隊都要進行不同的產品配置。QA團隊的測試是由Scrum團隊兩名新開發的探索性測試支持的。Scrum團隊內的六名開發員處理bug修復和部署。這樣，兩個團隊就建好了，他們支持Scrum團隊，對Scrum團隊的自組織（見圖1）沒有大的負面影響。偏向開發的開發員和測試員間的非典型性比率不成問題，因爲PO有很多待解決的早就存在的問題，足夠讓開發員在報告第一個bug前忙個不停。
圖1. 兩個支持Scrum團隊的QA團隊。兩個團隊間的交流由固定接口和代理（藍色的）負責。
實施
對於Scrum團隊，QA迭代開始時和其他迭代一樣，只除了一點：迭代計劃比通常要短。迭代計劃中PO只呈現了一些已知問題。迭代中，PO和Scrum團隊的測試員評估了QA團隊發現的bug並按優先順序將它們加入Scrum的迭代儲備中。除了Scrum團隊的迭代計劃，QA團隊還有一個啓動會議。它們接到指令運行來自測試集的積極的和消極的測試用例並記錄bug。整個測試集執行完（持續時間大約是2天）之後，由團隊的印象檢查和改進。最後，通過再次測試當前版本的bug修復來完成測試集。在這之後，測試集就能夠在QA團隊的下個重複中執行了。這樣，兩個QA團隊每次重複總有相同版本但不同配置的產品了。因爲QA團隊的每次重複剛裝上最新的版本，軟件的安裝和更新機制就由PO和Scrum團隊的測試員重複測試。爲了感謝和激勵QA團隊，我們使用一些遊戲化概念的元素。比如，我們爲最關鍵的bug設立一些獎項或爲發現了最多bug的團隊發一些小禮物。啓動是QA團隊的官方開始。對於測試集的第一個完整的執行，他們需要的正是假定的2天。還有一個額外的好處，每個團隊都有一個預先了解產品的成員。因此其他成員可以在他們的快速學習中受益。
第一天，Scrum團隊負責已知問題直到QA團隊發佈了第一個bug。此外，兩名探索性測試員能夠在他們的測試中發現一些有趣的可能會轉變爲可再生bug的地方。兩天後，第一個bug和問題修復好了。測試集的下一次迭代中對它們進行了再次測試和其他改進（主要是QA團隊發起的）。每日Scrum中，QA團隊的代理報告了他們團隊的進步並按計劃給QA團隊帶去了重要的信息。每次迭代後，兩個QA團隊的迭代持續時間各不相同。因此我們讓快的團隊重新測試我們已經修復並且在幾次迭代前重新測試過的老bug。因爲團隊找到了一些（明顯修復後重新安裝的）老的錯誤，所以這個想法奏效了。
總結
QA迭代對於項目來說是一大成功。迭代的最後一天，PO 能夠成功進行驗收測試併發布產品。這輪QA迭代的結果是團隊成功地大大改進了產品的質量。Scrum團隊和QA團隊瞭解團隊合作的本質。QA團隊受益於明確的接口，因爲無論他們需要什麼他們都能心平氣和。無需花大量時間尋找正確的聯繫人，QA團隊的任何問題就可以快速有效地得到回答。另一方面，因爲團隊間的這個接口，Scrum團隊的成員大大減輕了他們的工作量。這樣，QA團隊只給他們相關的修訂的信息，他們就可以專注於他們的工作。但是，我們低估了創建好的測試計劃的最初版本以及在我們將bug提交給Scrum團隊前過濾、評估、修改bug所需要的精力。但是我們仍設法解決這個問題，因爲我們可以依靠QA團隊，我們知道：在Scrum 團隊中我們可以推遲重新測試，因爲QA團隊已經做好了。一切按計劃進行的事對我們的PO（思想開明且有QA背景的人）都是一大稱讚。她樂於接受任何建議和意見。在其他項目中，這個概念都必將需要和PO及其他利益相關者多多協商。此外，我們可以受益於向QA團隊中支持我們的有才且積極的同事求助的能力。最後，我可以說：項目中的QA現在正穩步發展，產品也成功在市場上建好了。目前，有大量很好的可以在連續集成中進行的自動化測試。該QA迭代肯定對項目的成功產生了重要影響。
版權聲明：本文出自 SPASVO澤衆軟件測試網：http://www.spasvo.com/news/html/2015109143035.html
原創作品，轉載時請務必以超鏈接形式標明本文原始出處、作者信息和本聲明，否則將追究法律責任。
