Martin Uhlig在德國德累斯頓的Saxonia系統(tǒng)公司擔任測試顧問。自學習商業(yè)信息以來，他一直對敏捷軟件開發(fā)和敏捷方面的當前動向很感興趣。他做過物流，媒體，和產品開發(fā)領域的不同項目。這也包括了他擔任測試員和產品所有者的敏捷項目。
　　情況
　　敏捷環(huán)境中的開發(fā)員和測試員肯定對下列情況很熟悉。一個團隊已經進行了很久的工作，但是他們沒有專業(yè)的測試員。結果，質量要求被忽略了。但是現(xiàn)在——在產品發(fā)布前——一切都會變好，團隊有額外的測試員支持了。今年年初，我被任命為一個測試員流動量高的Scrum團隊的測試員時，我陷入了相似的情況之中。除了開發(fā)員已經建立的單元測試，并沒有自動化測試。但是隨著產品發(fā)布的時間越來越近，團隊必須做出各種關于產品變化的短期決定。我們不得不用快速可靠的方式找到一個測試產品功能及其非功能準則的方法。為了在項目的這個階段開始集成測試和UI測試的自動化，我們需要一個手動解決方案。
　　想法
　　與我們的產品所有者（PO）合作，我們創(chuàng)建了一個概念以組織一個只用于測試，修復和再測試的純粹的質量保證迭代（QA Sprint）。這輪迭代中并沒有安排特寫。我們該如何在這么短的時間內測試整個產品呢？即使有九名測試成員，也不太可能在兩周的迭代內運行測試以達到令人信服且能提供信息的結果。畢竟有必要通過測試覆蓋不同的軟件配置。但是我們很幸運能得到五名同意支持我們測試的測試員和開發(fā)員的特殊幫助。所以我們的人員充足。但是該如何管理所有這些人呢？一開始很明顯：團隊不能簡單地擴充。14個團隊成員（加上Scrum專家）沒有辦法創(chuàng)建一個有效的迭代計劃或每日Scrum，且整個團隊都必須進行重新組織。這并不是一個有效的解決方案，算只對迭代也一樣。這樣，我們不得不另想他法集成額外的測試員。但是哪種辦法行得通呢？答案很簡單——我們需要更多團隊！但是一個新的Srum團隊不會突然出現(xiàn)，尤其對于一輪迭代來說。因此，我們不得不將Scrum團隊和QA團隊分開。Scrum團隊，由以前的團隊組成，應該像平時一樣用佳的Scrum團隊的方法做基本工作。但是為了加強Scrum團隊，我們需要額外的測試員，但是因為上述原因不能讓他們加入Scrum團隊。因此我們不得不創(chuàng)建兩個實質上自己組織但不是SCRUM團隊固定一部分的團隊。這些QA團隊一直重復運行既定的測試集。Scrum團隊的測試員完成并迭代改進了測試集。QA團隊的工作與Scrum團隊的工作被嚴格分開以避免降低Scrum團隊的性能。因此團隊需要一個接口來過濾信息的交流，以避免信息泛濫（尤其是只有實際bug，沒有重復等）。
　　Scrum團隊自身要專心再現(xiàn)并解決bug。我們決定在團隊間使用接口。團隊分開的例外是每日Scrum會議。除了Scrum團隊，每個QA團隊的一個代理人給他們的當前狀態(tài)。改善該計劃，這樣團隊能更好地平衡。Scrum團隊的開發(fā)員之一去了QA團隊和他們一起測試。這樣每個QA團隊有三個成員，包含一個負責測試執(zhí)行的經驗豐富的測試員。此外，Scrum團隊有兩個相對而言較新的成員，他們沒有充分地訓練過，無法快速有效地修復復雜軟件的bug。除了測試集和bug再現(xiàn)，這些同事還要進行探索性測試�？傊�，我們的后計劃是：由兩個QA團隊進行一系列測試。這些測試包括所有的積極的和重要的負面的測試用例。每個團隊都要進行不同的產品配置。QA團隊的測試是由Scrum團隊兩名新開發(fā)的探索性測試支持的。Scrum團隊內的六名開發(fā)員處理bug修復和部署。這樣，兩個團隊建好了，他們支持Scrum團隊，對Scrum團隊的自組織（見圖1）沒有大的負面影響。偏向開發(fā)的開發(fā)員和測試員間的非典型性比率不成問題，因為PO有很多待解決的早存在的問題，足夠讓開發(fā)員在報告第一個bug前忙個不停。

　　圖1. 兩個支持Scrum團隊的QA團隊。兩個團隊間的交流由固定接口和代理（藍色的）負責。

　　實施
　　對于Scrum團隊，QA迭代開始時和其他迭代一樣，只除了一點：迭代計劃比通常要短。迭代計劃中PO只呈現(xiàn)了一些已知問題。迭代中，PO和Scrum團隊的測試員評估了QA團隊發(fā)現(xiàn)的bug并按優(yōu)先順序將它們加入Scrum的迭代儲備中。除了Scrum團隊的迭代計劃，QA團隊還有一個啟動會議。它們接到指令運行來自測試集的積極的和消極的測試用例并記錄bug。整個測試集執(zhí)行完（持續(xù)時間大約是2天）之后，由團隊的印象檢查和改進。后，通過再次測試當前版本的bug修復來完成測試集。在這之后，測試集能夠在QA團隊的下個重復中執(zhí)行了。這樣，兩個QA團隊每次重復總有相同版本但不同配置的產品了。因為QA團隊的每次重復剛裝上新的版本，軟件的安裝和更新機制由PO和Scrum團隊的測試員重復測試。為了感謝和激勵QA團隊，我們使用一些游戲化概念的元素。比如，我們?yōu)殛P鍵的bug設立一些獎項或為發(fā)現(xiàn)了多bug的團隊發(fā)一些小禮物。啟動是QA團隊的官方開始。對于測試集的第一個完整的執(zhí)行，他們需要的正是假定的2天。還有一個額外的好處，每個團隊都有一個預先了解產品的成員。因此其他成員可以在他們的快速學習中受益。