Martin Uhlig在德國德累斯頓的Saxonia系統(tǒng)公司擔(dān)任測試顧問。自學(xué)習(xí)商業(yè)信息以來，他一直對敏捷軟件開發(fā)和敏捷方面的當(dāng)前動向很感興趣。他做過物流，媒體，和產(chǎn)品開發(fā)領(lǐng)域的不同項(xiàng)目。這也包括了他擔(dān)任測試員和產(chǎn)品所有者的敏捷項(xiàng)目。
情況
敏捷環(huán)境中的開發(fā)員和測試員肯定對下列情況很熟悉。一個團(tuán)隊(duì)已經(jīng)進(jìn)行了很久的工作，但是他們沒有專業(yè)的測試員。結(jié)果，質(zhì)量要求被忽略了。但是現(xiàn)在——在產(chǎn)品發(fā)布前——一切都會變好，團(tuán)隊(duì)有額外的測試員支持了。今年年初，我被任命為一個測試員流動量高的Scrum團(tuán)隊(duì)的測試員時，我陷入了相似的情況之中。除了開發(fā)員已經(jīng)建立的單元測試，并沒有自動化測試。但是隨著產(chǎn)品發(fā)布的時間越來越近，團(tuán)隊(duì)必須做出各種關(guān)于產(chǎn)品變化的短期決定。我們不得不用快速可靠的方式找到一個測試產(chǎn)品功能及其非功能準(zhǔn)則的方法。為了在項(xiàng)目的這個階段開始集成測試和UI測試的自動化，我們需要一個手動解決方案。
想法
與我們的產(chǎn)品所有者（PO）合作，我們創(chuàng)建了一個概念以組織一個只用于測試，修復(fù)和再測試的純粹的質(zhì)量保證迭代（QA Sprint）。這輪迭代中并沒有安排特寫。我們該如何在這么短的時間內(nèi)測試整個產(chǎn)品呢？即使有九名測試成員，也不太可能在兩周的迭代內(nèi)運(yùn)行測試以達(dá)到令人信服且能提供信息的結(jié)果。畢竟有必要通過測試覆蓋不同的軟件配置。但是我們很幸運(yùn)能得到五名同意支持我們測試的測試員和開發(fā)員的特殊幫助。所以我們的人員充足。但是該如何管理所有這些人呢？一開始很明顯：團(tuán)隊(duì)不能簡單地?cái)U(kuò)充。14個團(tuán)隊(duì)成員（加上Scrum專家）沒有辦法創(chuàng)建一個有效的迭代計(jì)劃或每日Scrum，且整個團(tuán)隊(duì)都必須進(jìn)行重新組織。這并不是一個有效的解決方案，算只對迭代也一樣。這樣，我們不得不另想他法集成額外的測試員。但是哪種辦法行得通呢？答案很簡單——我們需要更多團(tuán)隊(duì)！但是一個新的Srum團(tuán)隊(duì)不會突然出現(xiàn)，尤其對于一輪迭代來說。因此，我們不得不將Scrum團(tuán)隊(duì)和QA團(tuán)隊(duì)分開。Scrum團(tuán)隊(duì)，由以前的團(tuán)隊(duì)組成，應(yīng)該像平時一樣用佳的Scrum團(tuán)隊(duì)的方法做基本工作。但是為了加強(qiáng)Scrum團(tuán)隊(duì)，我們需要額外的測試員，但是因?yàn)樯鲜鲈虿荒茏屗麄兗尤隨crum團(tuán)隊(duì)。因此我們不得不創(chuàng)建兩個實(shí)質(zhì)上自己組織但不是SCRUM團(tuán)隊(duì)固定一部分的團(tuán)隊(duì)。這些QA團(tuán)隊(duì)一直重復(fù)運(yùn)行既定的測試集。Scrum團(tuán)隊(duì)的測試員完成并迭代改進(jìn)了測試集。QA團(tuán)隊(duì)的工作與Scrum團(tuán)隊(duì)的工作被嚴(yán)格分開以避免降低Scrum團(tuán)隊(duì)的性能。因此團(tuán)隊(duì)需要一個接口來過濾信息的交流，以避免信息泛濫（尤其是只有實(shí)際bug，沒有重復(fù)等）。
Scrum團(tuán)隊(duì)自身要專心再現(xiàn)并解決bug。我們決定在團(tuán)隊(duì)間使用接口。團(tuán)隊(duì)分開的例外是每日Scrum會議。除了Scrum團(tuán)隊(duì)，每個QA團(tuán)隊(duì)的一個代理人給他們的當(dāng)前狀態(tài)。改善該計(jì)劃，這樣團(tuán)隊(duì)能更好地平衡。Scrum團(tuán)隊(duì)的開發(fā)員之一去了QA團(tuán)隊(duì)和他們一起測試。這樣每個QA團(tuán)隊(duì)有三個成員，包含一個負(fù)責(zé)測試執(zhí)行的經(jīng)驗(yàn)豐富的測試員。此外，Scrum團(tuán)隊(duì)有兩個相對而言較新的成員，他們沒有充分地訓(xùn)練過，無法快速有效地修復(fù)復(fù)雜軟件的bug。除了測試集和bug再現(xiàn)，這些同事還要進(jìn)行探索性測試。總之，我們的后計(jì)劃是：由兩個QA團(tuán)隊(duì)進(jìn)行一系列測試。這些測試包括所有的積極的和重要的負(fù)面的測試用例。每個團(tuán)隊(duì)都要進(jìn)行不同的產(chǎn)品配置。QA團(tuán)隊(duì)的測試是由Scrum團(tuán)隊(duì)兩名新開發(fā)的探索性測試支持的。Scrum團(tuán)隊(duì)內(nèi)的六名開發(fā)員處理bug修復(fù)和部署。這樣，兩個團(tuán)隊(duì)建好了，他們支持Scrum團(tuán)隊(duì)，對Scrum團(tuán)隊(duì)的自組織（見圖1）沒有大的負(fù)面影響。偏向開發(fā)的開發(fā)員和測試員間的非典型性比率不成問題，因?yàn)镻O有很多待解決的早存在的問題，足夠讓開發(fā)員在報告第一個bug前忙個不停。
圖1. 兩個支持Scrum團(tuán)隊(duì)的QA團(tuán)隊(duì)。兩個團(tuán)隊(duì)間的交流由固定接口和代理（藍(lán)色的）負(fù)責(zé)。
實(shí)施
對于Scrum團(tuán)隊(duì)，QA迭代開始時和其他迭代一樣，只除了一點(diǎn)：迭代計(jì)劃比通常要短。迭代計(jì)劃中PO只呈現(xiàn)了一些已知問題。迭代中，PO和Scrum團(tuán)隊(duì)的測試員評估了QA團(tuán)隊(duì)發(fā)現(xiàn)的bug并按優(yōu)先順序?qū)⑺鼈兗尤隨crum的迭代儲備中。除了Scrum團(tuán)隊(duì)的迭代計(jì)劃，QA團(tuán)隊(duì)還有一個啟動會議。它們接到指令運(yùn)行來自測試集的積極的和消極的測試用例并記錄bug。整個測試集執(zhí)行完（持續(xù)時間大約是2天）之后，由團(tuán)隊(duì)的印象檢查和改進(jìn)。后，通過再次測試當(dāng)前版本的bug修復(fù)來完成測試集。在這之后，測試集能夠在QA團(tuán)隊(duì)的下個重復(fù)中執(zhí)行了。這樣，兩個QA團(tuán)隊(duì)每次重復(fù)總有相同版本但不同配置的產(chǎn)品了。因?yàn)镼A團(tuán)隊(duì)的每次重復(fù)剛裝上新的版本，軟件的安裝和更新機(jī)制由PO和Scrum團(tuán)隊(duì)的測試員重復(fù)測試。為了感謝和激勵QA團(tuán)隊(duì)，我們使用一些游戲化概念的元素。比如，我們?yōu)殛P(guān)鍵的bug設(shè)立一些獎項(xiàng)或?yàn)榘l(fā)現(xiàn)了多bug的團(tuán)隊(duì)發(fā)一些小禮物。啟動是QA團(tuán)隊(duì)的官方開始。對于測試集的第一個完整的執(zhí)行，他們需要的正是假定的2天。還有一個額外的好處，每個團(tuán)隊(duì)都有一個預(yù)先了解產(chǎn)品的成員。因此其他成員可以在他們的快速學(xué)習(xí)中受益。
