Scrum是
軟件開(kāi)發(fā)的
敏捷方法。它以2到4周為一個(gè)迭代開(kāi)發(fā)出有價(jià)值的商業(yè)功能。Scrum團(tuán)隊(duì)有兩個(gè)明顯特征：他們是多面手（例如：他們具備完成
工作所必須的所有技能）；他們是自管理的（例如：團(tuán)隊(duì)不斷探索如何把工作做的最好的方法）。通過(guò)過(guò)去兩年在Scrum團(tuán)隊(duì)中近2年的QA角色的不斷實(shí)踐，我認(rèn)識(shí)到Scrum中的QA不僅僅是編寫(xiě)
測(cè)試用例和匯報(bào)缺陷那么簡(jiǎn)單。
對(duì)比傳統(tǒng)瀑布模型的項(xiàng)目中的同步活動(dòng)，Scrum期望開(kāi)發(fā)活動(dòng)根據(jù)實(shí)際需要的順序來(lái)執(zhí)行，例如異步。這點(diǎn)有悖傳統(tǒng)，讓許多客戶、開(kāi)發(fā)和業(yè)務(wù)關(guān)系人等新手產(chǎn)生疑惑 “如何在代碼還沒(méi)有完成之前進(jìn)行有效的測(cè)試？” 本文重點(diǎn)解釋了QA如何執(zhí)行
敏捷測(cè)試以及Scrum團(tuán)隊(duì)中QA角色的重要性。我將通過(guò)本文分享在我對(duì)Scrum團(tuán)隊(duì)中QA角色及職責(zé)的認(rèn)識(shí)。
不僅是編寫(xiě)測(cè)試用例
傳統(tǒng)瀑布模型的項(xiàng)目中，QA介入的時(shí)機(jī)往往是在代碼全部完成后的項(xiàng)目收尾階段。這些項(xiàng)目中，QA拿到一份需求文檔和已經(jīng)完成的代碼，然后開(kāi)始編寫(xiě)和執(zhí)行測(cè)試用例以檢查應(yīng)用程序是否符合需求文檔。然而，Scrum中的QA角色不再僅僅是執(zhí)行測(cè)試用例和匯報(bào)缺陷。
參加評(píng)估用戶故事（Story）在Scrum團(tuán)隊(duì)中，QA分析師和其他團(tuán)隊(duì)成員一起參與或擔(dān)當(dāng)大量職責(zé)。他們從項(xiàng)目一開(kāi)始就介入，并且與業(yè)務(wù)分析者和開(kāi)發(fā)者密切聯(lián)系。在Scrum中，QA不是一個(gè)單獨(dú)的測(cè)試應(yīng)用程序的團(tuán)隊(duì)。取而代之的是，Scrum團(tuán)隊(duì)是一個(gè)業(yè)務(wù)分析師、開(kāi)發(fā)者、QA一起協(xié)同工作的綜合團(tuán)隊(duì)。除了編寫(xiě)用例，QA還幫助產(chǎn)品負(fù)責(zé)人（PO）編寫(xiě)接受用例，相當(dāng)于承擔(dān)產(chǎn)品負(fù)責(zé)人代理的角色。當(dāng)產(chǎn)品負(fù)責(zé)人沒(méi)有時(shí)間時(shí)，QA作為代理保持團(tuán)隊(duì)持續(xù)前進(jìn)。QA和產(chǎn)品負(fù)責(zé)人通過(guò)提出問(wèn)題和質(zhì)疑假設(shè)進(jìn)行互動(dòng)交流，最終澄清業(yè)務(wù)需求。
QA分析師一般很擅長(zhǎng)根據(jù)用戶需求創(chuàng)建測(cè)試用例場(chǎng)景。在識(shí)別和捕捉復(fù)雜和否定的用例上也很卓越。事實(shí)上，在這點(diǎn)上，QA往往比開(kāi)發(fā)做的好，因?yàn)殚_(kāi)發(fā)往往關(guān)注用戶故事的好的方面。在版本和周期計(jì)劃會(huì)議中評(píng)估用戶故事時(shí)邀請(qǐng)QA參與能讓團(tuán)隊(duì)不再僅僅思考好的方面，有利于產(chǎn)生一個(gè)綜合好壞情況的客觀真實(shí)的評(píng)估。評(píng)估是一個(gè)很難的事情，讓所有人都參與評(píng)估是很好的實(shí)踐。
有利于保持視角和目標(biāo)明確
當(dāng)團(tuán)隊(duì)執(zhí)行測(cè)試和其他穩(wěn)定產(chǎn)品的活動(dòng)時(shí)，QA需要掌控計(jì)劃、組織或讓整個(gè)團(tuán)隊(duì)投入到測(cè)試工作中，并且像Scrum Master(SM)那樣保持成員處于積極狀態(tài)。很少有開(kāi)發(fā)者喜歡做測(cè)試任務(wù)。QA需要和Scrum Master一起讓測(cè)試對(duì)整個(gè)測(cè)試團(tuán)隊(duì)可見(jiàn)且目標(biāo)明確。從而保持開(kāi)發(fā)者或其他成員的積極性。有時(shí)一些測(cè)試場(chǎng)景的構(gòu)建需要開(kāi)發(fā)或其他團(tuán)隊(duì)成員的幫助，這樣容易創(chuàng)新。力爭(zhēng)讓測(cè)試活動(dòng)有趣，例如用刺激的測(cè)試場(chǎng)景、出人意料的測(cè)試數(shù)據(jù)和帶有娛樂(lè)意味的競(jìng)爭(zhēng)。總之，做任何事情，只要有助于團(tuán)隊(duì)樂(lè)于加入測(cè)試工作即可。
與客戶和開(kāi)發(fā)者緊密合作
QA的主要職責(zé)之一是將他們的測(cè)試結(jié)果反饋給產(chǎn)品負(fù)責(zé)人或收集他們的反饋。QA和產(chǎn)品負(fù)責(zé)人緊密合作，幫助他們制定詳細(xì)的用戶故事驗(yàn)收標(biāo)準(zhǔn)。隨著團(tuán)隊(duì)在每個(gè)迭代中的深入了解，QA也可以幫助產(chǎn)品負(fù)責(zé)人修改或增強(qiáng)用戶故事以更好地反映真實(shí)的需求。
偶爾，QA分析師還充當(dāng)產(chǎn)品負(fù)責(zé)人代理。這種情況下，QA和開(kāi)發(fā)者將坐在一起，作為一個(gè)團(tuán)隊(duì)一起工作以提高產(chǎn)品質(zhì)量。QA可以和開(kāi)發(fā)者結(jié)對(duì)來(lái)寫(xiě)
單元測(cè)試，討論驗(yàn)收標(biāo)準(zhǔn)。合作的工作越多，需求也越清楚。一起工作帶來(lái)的清晰需求將減少編碼過(guò)程中經(jīng)常遇到的各種問(wèn)題或疑惑，從而給有效提高開(kāi)發(fā)效率、節(jié)約開(kāi)發(fā)和QA的時(shí)間。
根據(jù)團(tuán)隊(duì)每個(gè)人的需求和實(shí)際情況，整個(gè)團(tuán)隊(duì)將成為一體，都會(huì)協(xié)助測(cè)試。這樣的實(shí)踐平衡了團(tuán)隊(duì)和工作完成必須的共同職責(zé)，早期測(cè)試反饋和持續(xù)增長(zhǎng)的質(zhì)量下，它將使項(xiàng)目進(jìn)展更快。
提供快速反饋
傳統(tǒng)瀑布模型團(tuán)隊(duì)不斷重復(fù)的“構(gòu)建-測(cè)試-修復(fù)”周期徒增了大量額外工作量，浪費(fèi)了大量時(shí)間。在Scrum中，QA和開(kāi)發(fā)者在整個(gè)項(xiàng)目中一起工作，讓活動(dòng)變得更簡(jiǎn)單。在開(kāi)發(fā)過(guò)程中，開(kāi)發(fā)者能直接咨詢QA驗(yàn)收標(biāo)準(zhǔn)或從用戶視角任何功能上的期待行為。這讓測(cè)試和缺陷修復(fù)更簡(jiǎn)單。
自動(dòng)化回歸測(cè)試
自動(dòng)化測(cè)試常被譽(yù)為測(cè)試者最好的朋友，因?yàn)樗芍貜?fù)執(zhí)行且執(zhí)行一致，能得到更好的軟件功能的測(cè)試覆蓋率。在2到4周一個(gè)迭代的Scrum項(xiàng)目中這點(diǎn)尤為正確。因?yàn)镼A大體都沒(méi)有太多時(shí)間去測(cè)試應(yīng)用程序。在2周的迭代中，QA必須完成迭代中所有新功能的功能點(diǎn)測(cè)試的同時(shí)還要完成對(duì)先前實(shí)現(xiàn)功能的測(cè)試。正因如此，這種職責(zé)提高了每個(gè)迭代中使用可用的自動(dòng)化實(shí)踐以減少Q(mào)A壓力的重要性。
當(dāng)團(tuán)隊(duì)執(zhí)行持續(xù)集成時(shí)，自動(dòng)化測(cè)試在快速反饋上大有用途。每發(fā)布一個(gè)軟件新版本，可以執(zhí)行自動(dòng)化測(cè)試并快速提供反饋以反映是否新老功能都正常工作。而沒(méi)有自動(dòng)化測(cè)試，就必須手工執(zhí)行所有的測(cè)試，不僅單調(diào)，而且容易犯錯(cuò)。自動(dòng)化測(cè)試能更早的發(fā)現(xiàn)缺陷，讓QA有更多時(shí)間去探索新功能的一些特殊用例。通過(guò)自動(dòng)化測(cè)試，QA可以更快更有效地完成測(cè)試工作。
參與發(fā)布準(zhǔn)備演示
在每個(gè)迭代結(jié)束時(shí)，團(tuán)隊(duì)需要召開(kāi)一個(gè)迭代審閱會(huì)議來(lái)向項(xiàng)目責(zé)任人和其他有興趣的關(guān)系人展示這個(gè)迭代完成的用戶故事。迭代審閱會(huì)議是團(tuán)隊(duì)中的“良藥”，可以有效激發(fā)他們?nèi)ケM可能完成更多用戶故事。
在2到4周的小迭代中，為了讓用戶故事按時(shí)完成，團(tuán)隊(duì)中的每個(gè)人都必須沉浸在自己的工作。開(kāi)發(fā)者關(guān)注實(shí)現(xiàn)用戶故事和修復(fù)缺陷，QA關(guān)注用例編寫(xiě)、澄清產(chǎn)品責(zé)任人的問(wèn)題、自動(dòng)化之前迭代的測(cè)試。較短的迭代周期意味著開(kāi)發(fā)沒(méi)有多少時(shí)間去獲知用戶故事要求的全部功能。這樣，開(kāi)發(fā)一般要詢問(wèn)QA以更好的理解用戶故事。因?yàn)镼A知道完整的功能及每個(gè)需求和驗(yàn)收標(biāo)準(zhǔn)。在迭代審閱會(huì)議上，讓QA演示項(xiàng)目和解答業(yè)務(wù)上的問(wèn)題是很好的實(shí)踐。這也讓開(kāi)發(fā)者更專(zhuān)注于處理技術(shù)層面的問(wèn)題。
分析用戶需求
QA是Scrum團(tuán)隊(duì)中產(chǎn)品負(fù)責(zé)人代理。他們擅長(zhǎng)從用戶視角理解業(yè)務(wù)需求。因?yàn)樗麄兘?jīng)常被問(wèn)到用戶如何使用項(xiàng)目。QA根據(jù)他們的測(cè)試經(jīng)驗(yàn)給產(chǎn)品負(fù)責(zé)人提供反饋，幫助他們更好的從用戶視角理解項(xiàng)目。
完善“完成定義”
對(duì)于敏捷團(tuán)隊(duì)，清晰的完成定義(DOD)是很重要的。“完成定義”是團(tuán)隊(duì)定義完成標(biāo)準(zhǔn)的簡(jiǎn)單列表，是在用戶故事認(rèn)定為完成必須要完成的事情。完成定義一般包括完成代碼、執(zhí)行功能和回歸測(cè)試、獲得產(chǎn)品負(fù)責(zé)人的認(rèn)可。一個(gè)簡(jiǎn)單的完成定義可能包括如下項(xiàng)目：
代碼完成
單元測(cè)試完成
功能和UI測(cè)試完成
產(chǎn)品負(fù)責(zé)人認(rèn)可
定義“完成定義” 不是QA一個(gè)人的責(zé)任，QA的責(zé)任往往在于監(jiān)管團(tuán)隊(duì)完成定義和每個(gè)完成的用戶故事必須滿足“完成定義”的基線要求。一個(gè)高效的敏捷團(tuán)隊(duì)在啟動(dòng)每個(gè)用戶故事前都要審閱“完成定義”從而使團(tuán)隊(duì)每個(gè)人都了解目標(biāo)。“完成定義”不是一層不變的，可能會(huì)根據(jù)Scrum的需要不斷演變。“完成定義”既可以是迭代級(jí)的也可以是發(fā)布級(jí)的。
用測(cè)試策略規(guī)范測(cè)試
由于Scrum團(tuán)隊(duì)中沒(méi)有測(cè)試領(lǐng)導(dǎo)甚至測(cè)試專(zhuān)家。構(gòu)建測(cè)試計(jì)劃或執(zhí)行測(cè)試策略就存在問(wèn)題。Scrum認(rèn)為需要準(zhǔn)備足夠的文檔去支持團(tuán)隊(duì)隨時(shí)提出的需求。正因?yàn)榇耍枰獪?zhǔn)備足夠的高層次測(cè)試策略的文檔和計(jì)劃來(lái)指導(dǎo)團(tuán)隊(duì)。因?yàn)闆](méi)有QA領(lǐng)導(dǎo)在團(tuán)隊(duì)中，QA一般自己來(lái)制定測(cè)試策略。
測(cè)試者和分析者角色融合
測(cè)試者和分析者角色融合在敏捷團(tuán)隊(duì)中很常見(jiàn)，業(yè)務(wù)分析師的角色一般是負(fù)責(zé)創(chuàng)建和維護(hù)迭代和產(chǎn)品的Backlog、從業(yè)務(wù)角度分析用戶故事、根據(jù)產(chǎn)品負(fù)責(zé)人要求劃分用戶故事優(yōu)先級(jí)。而QA角色一般負(fù)責(zé)為每個(gè)故事定義或完善驗(yàn)收標(biāo)準(zhǔn)，確保之前完成的功能沒(méi)有老的問(wèn)題。QA測(cè)試每個(gè)用戶故事，從終端用戶視角驗(yàn)證定義的驗(yàn)收標(biāo)準(zhǔn)是否已經(jīng)達(dá)到，他們也根據(jù)業(yè)務(wù)來(lái)分析用戶故事。所以QA和業(yè)務(wù)分析師的角色責(zé)任、必備技能、總體目標(biāo)有很多重合地方。
一般，在項(xiàng)目開(kāi)始之時(shí)，敏捷團(tuán)隊(duì)從產(chǎn)品負(fù)責(zé)人那里拿到用戶故事和提前定義的項(xiàng)目范圍。在敏捷模式下，鼓勵(lì)團(tuán)隊(duì)成員提出改善終端用戶體驗(yàn)的新功能或改變已有功能，也鼓勵(lì)團(tuán)隊(duì)一旦發(fā)現(xiàn)技術(shù)依賴(lài)或發(fā)現(xiàn)換一種實(shí)現(xiàn)將更有效而改變backlog中用戶故事優(yōu)先級(jí)和順序。無(wú)論是定義需求、分析用戶故事、定義和澄清驗(yàn)收標(biāo)準(zhǔn)、編寫(xiě)接受性驗(yàn)證用例或和用戶緊密合作，對(duì)于小的團(tuán)隊(duì)，測(cè)試者和分析者的角色融為一體有很多優(yōu)點(diǎn)，但也存在一些缺點(diǎn)，最大的顧慮是沒(méi)有測(cè)試者或分析者能夠投入過(guò)多精力來(lái)完全盡責(zé)。
結(jié)論
除了編寫(xiě)用例和匯報(bào)缺陷，QA在Scrum團(tuán)隊(duì)中承擔(dān)更多的職責(zé)。他們是團(tuán)隊(duì)的重要組成部分，并且從項(xiàng)目一開(kāi)始就參與其中。
過(guò)去兩年在Scrum團(tuán)隊(duì)當(dāng)QA分析師讓我有了一個(gè)非常棒的體驗(yàn)，同時(shí)也獲得了很多學(xué)習(xí)機(jī)會(huì)。我擔(dān)當(dāng)了很多不同的角色和職責(zé)，包括QA分析師、產(chǎn)品責(zé)任人代理、幫助開(kāi)發(fā)寫(xiě)單元測(cè)試、確保團(tuán)隊(duì)的質(zhì)量意識(shí)和跟蹤問(wèn)題和軟件缺陷。總之，這些體驗(yàn)讓我獲得了很多 不錯(cuò)的技能，同時(shí)讓我學(xué)習(xí)了如何做好不同的角色。更重要的是它告訴我如何去問(wèn)問(wèn)題而不再是僅僅遵循文檔，也教會(huì)了我去做任何有助團(tuán)隊(duì)成功的事情。