Scrum是一種迭代式與增量式的框架，它體現(xiàn)了軟件開(kāi)發(fā)的一種敏捷式的途徑。在軟件組織中，使用Scrum進(jìn)行軟件應(yīng)用開(kāi)發(fā)與測(cè)試正在變得越來(lái)越流行。

在Scrum團(tuán)隊(duì)中，測(cè)試與開(kāi)發(fā)同樣重要。在每個(gè)Sprint中，測(cè)試人員需要在特定的、極短的時(shí)間內(nèi)對(duì)特性進(jìn)行測(cè)試，以幫助團(tuán)隊(duì)盡早地消除bug。

雖然敏捷測(cè)試比起傳統(tǒng)的測(cè)試方法存在著許多優(yōu)勢(shì)，但它也有不足之處，其中之一就是有時(shí)它會(huì)在每個(gè)Sprint臨結(jié)束時(shí)對(duì)質(zhì)量保證（QA）團(tuán)隊(duì)產(chǎn)生了過(guò)多的壓力，最終可能會(huì)導(dǎo)致Sprint的溢出。

測(cè)試人員所面對(duì)的另一個(gè)問(wèn)題是缺乏全面的文檔。在敏捷項(xiàng)目中有一個(gè)嚴(yán)重的陷阱，就是缺乏對(duì)設(shè)計(jì)與文檔的強(qiáng)調(diào)，因此造成了許多需求的模糊不清。雖然人們說(shuō)過(guò)多的細(xì)節(jié)文檔會(huì)妨礙重要的工作，但我認(rèn)為可以在某個(gè)敏捷項(xiàng)目管理工具中維護(hù)每個(gè)用戶故事的適當(dāng)細(xì)節(jié)、文檔以及每種可能的場(chǎng)景，以此解決這一問(wèn)題。

QA團(tuán)隊(duì)無(wú)法對(duì)幾周之后的工作內(nèi)容進(jìn)行規(guī)劃，在敏捷項(xiàng)目中，測(cè)試人員必須在代碼開(kāi)發(fā)的同一個(gè)迭代內(nèi)進(jìn)行代碼的測(cè)試，并且要求他們?yōu)榇a及整個(gè)應(yīng)用提供快速的反饋。不過(guò)，在大多數(shù)情況下，可運(yùn)行的代碼只在一個(gè)Sprint臨近結(jié)尾時(shí)才能夠提交，此時(shí)由于demo或演示的需要，代碼往往要處于凍結(jié)狀態(tài)。其結(jié)果就是測(cè)試團(tuán)隊(duì)往往缺乏足夠的時(shí)間進(jìn)行驗(yàn)證，因此往往對(duì)某個(gè)特定Sprint的測(cè)試會(huì)推遲到下一個(gè)迭代中，此時(shí)才會(huì)將這些工作丟給測(cè)試團(tuán)隊(duì)。

在Scrum，測(cè)試人員的工作不僅僅是進(jìn)行測(cè)試，并在缺陷跟蹤工具中記錄bug，而是包含了多種不同的任務(wù)，例如測(cè)試管理和分析以及測(cè)試執(zhí)行的職責(zé)。除此之外的職責(zé)還包括客戶處理，以及bug的跟蹤，還有將客戶不斷建議的頻繁變更進(jìn)行集成。

真正的敏捷QA往往還要負(fù)責(zé)非單元測(cè)試工具、測(cè)試環(huán)境搭建以及測(cè)試數(shù)據(jù)的準(zhǔn)備。處于這一角色上的人會(huì)發(fā)現(xiàn)他們需要在互相沖突的選擇中進(jìn)行權(quán)衡。這些選擇與非敏捷項(xiàng)目中的選擇相類似，但由于敏捷項(xiàng)目的時(shí)間短暫，使這些問(wèn)題顯得更為突出。對(duì)于測(cè)試進(jìn)行管理的職責(zé)往往分派給某個(gè)敏捷團(tuán)隊(duì)中的一個(gè)或兩個(gè)成員，而不是由整個(gè)團(tuán)隊(duì)承擔(dān)起這一任務(wù)。

雖然在敏捷項(xiàng)目中進(jìn)行工作會(huì)讓你始終保持警覺(jué)，但分散的職責(zé)以及更好的時(shí)間管理能夠讓你的工作更簡(jiǎn)單，同時(shí)也更高效。

時(shí)間估算是敏捷測(cè)試人員的一大挑戰(zhàn)，要進(jìn)行準(zhǔn)確的測(cè)試估算，需要考慮到多個(gè)重要的因素，例如項(xiàng)目的范圍、所需的測(cè)試類型、測(cè)試任務(wù)以及以往的經(jīng)驗(yàn)。但有時(shí)即使是最精確的估算方式也會(huì)最終顯得時(shí)間不足，這是因?yàn)槊總€(gè)Sprint結(jié)束前的測(cè)試時(shí)間過(guò)于短暫，因此QA無(wú)法進(jìn)行足夠的端到端測(cè)試。如果在先前的開(kāi)發(fā)過(guò)程出現(xiàn)了任何延遲，都有可能影響QA的時(shí)間安排，有時(shí)QA無(wú)法在整個(gè)迭代中完成某個(gè)測(cè)試用例的執(zhí)行，因此他只能選擇快速的完成。在估算過(guò)程中，QA有責(zé)任提醒整個(gè)團(tuán)隊(duì)必須執(zhí)行的測(cè)試任務(wù)，因此讓團(tuán)隊(duì)成員不會(huì)對(duì)任務(wù)過(guò)分承諾。這里的估算應(yīng)當(dāng)包括手工任務(wù)和自動(dòng)化任務(wù)，團(tuán)隊(duì)或許需要對(duì)某個(gè)用戶故事編寫(xiě)或改寫(xiě)自動(dòng)化測(cè)試。

在敏捷測(cè)試中的另一個(gè)障礙是在測(cè)試過(guò)程中缺乏客戶的參與，客戶或許會(huì)認(rèn)為他們只需要在產(chǎn)品完全結(jié)束之后再參與就足夠了。這會(huì)導(dǎo)致驗(yàn)收測(cè)試和驗(yàn)收標(biāo)準(zhǔn)方面的問(wèn)題。我們?cè)谘菔具^(guò)程中很少會(huì)收到下一步應(yīng)該做些什么的反饋。建立一種信任關(guān)系有助于緩解這一風(fēng)險(xiǎn)。

在我之前的一個(gè)項(xiàng)目中，我曾看到客戶建議對(duì)應(yīng)用程序的核心功能進(jìn)行巨大的改動(dòng)。這種改動(dòng)會(huì)影響應(yīng)用程序中的其它特性，并且導(dǎo)致代碼的改動(dòng)，并且使測(cè)試工作量倍增。從客戶那里得到的反饋時(shí)間太晚，會(huì)推遲產(chǎn)品上線的時(shí)間。讓業(yè)務(wù)人員專門(mén)負(fù)責(zé)與客戶進(jìn)行每日溝通，能夠填補(bǔ)在客戶響應(yīng)時(shí)間上的鴻溝。

敏捷的一個(gè)主要優(yōu)勢(shì)是能夠盡早地開(kāi)始測(cè)試。隨著項(xiàng)目逐漸成熟，敏捷測(cè)試也變得越來(lái)越重要。每個(gè)特性在開(kāi)發(fā)完成之后就應(yīng)當(dāng)進(jìn)行完整的測(cè)試，而不是在整個(gè)開(kāi)發(fā)結(jié)束后再開(kāi)始測(cè)試。

在項(xiàng)目的早期完成了幾個(gè)成功的迭代之后，用戶故事與工作量會(huì)開(kāi)始增長(zhǎng)，而項(xiàng)目也需要加入更多的團(tuán)隊(duì)成員。隨著開(kāi)發(fā)人員數(shù)量的增長(zhǎng)，測(cè)試人員的數(shù)量也應(yīng)當(dāng)隨之增長(zhǎng)，以維持一個(gè)恒定的測(cè)試人員/開(kāi)發(fā)人員的比例（通常是一個(gè)測(cè)試對(duì)應(yīng)兩個(gè)開(kāi)發(fā)人員）。

現(xiàn)在，讓我們假設(shè)以上情形在每個(gè)Sprint（大約兩周到四周）中都會(huì)重復(fù)出現(xiàn)。從客戶的角度來(lái)看，在每個(gè)循環(huán)中，敏捷測(cè)試都需要對(duì)一個(gè)或多個(gè)新的軟件模塊進(jìn)行驗(yàn)證。還需要考慮在最終發(fā)布之前如何、以及何時(shí)處理回歸測(cè)試的問(wèn)題。測(cè)試不再是軟件開(kāi)發(fā)的一個(gè)階段，而是與開(kāi)發(fā)混合在一起，持續(xù)的測(cè)試是確保持續(xù)前進(jìn)以及最終成功的咒語(yǔ)，也是唯一的方法。

在每個(gè)Sprint的過(guò)程中，敏捷測(cè)試將對(duì)每個(gè)新的功能進(jìn)行檢驗(yàn)。通常來(lái)說(shuō)，在每個(gè)Sprint的結(jié)束之前，需要保留一小段時(shí)間以進(jìn)行回歸測(cè)試，然后才能進(jìn)入下一個(gè)Sprint。敏捷團(tuán)隊(duì)常常會(huì)實(shí)現(xiàn)一種構(gòu)建驗(yàn)證測(cè)試（BVT）程序，團(tuán)隊(duì)通過(guò)它實(shí)施一個(gè)標(biāo)準(zhǔn)的驗(yàn)證步驟集，它將橫跨整個(gè)應(yīng)用程序，以確保應(yīng)用程序的穩(wěn)定性與功能性。如果可能的話，應(yīng)當(dāng)將這種程序進(jìn)行自動(dòng)化，并集成為持續(xù)集成服務(wù)器的一部分，這將使發(fā)布過(guò)程更加嚴(yán)格。

對(duì)于跨多個(gè)Sprint的項(xiàng)目來(lái)說(shuō)，一種標(biāo)準(zhǔn)的實(shí)踐是在其中設(shè)置一個(gè)代碼強(qiáng)化Sprint，或發(fā)布Sprint，從整合的觀點(diǎn)來(lái)看，能夠確保應(yīng)用程序的整體功能。良好的情況下，假設(shè)在每個(gè)Sprint中都小心翼翼地處理了缺陷的問(wèn)題，那么這個(gè)過(guò)程不應(yīng)該超過(guò)30天或45天?？梢酝ㄟ^(guò)為每個(gè)用戶故事和bug設(shè)定手動(dòng)與自動(dòng)化測(cè)試的目標(biāo)以實(shí)現(xiàn)這一點(diǎn)。QA有責(zé)任將任何尚未實(shí)現(xiàn)自動(dòng)化的用戶故事和bug標(biāo)注為手動(dòng)。這樣，在新的構(gòu)建部署之前，我們就能夠獲得一個(gè)可以手動(dòng)執(zhí)行的回歸測(cè)試的集合。對(duì)于自動(dòng)化來(lái)說(shuō)，我們應(yīng)該維護(hù)一個(gè)良好的自動(dòng)化測(cè)試套件，在開(kāi)發(fā)者每次提交代碼時(shí)作為一個(gè)持續(xù)集成任務(wù)自動(dòng)運(yùn)行。

每個(gè)Sprint中，我們都在添加新的特性，或是發(fā)動(dòng)現(xiàn)有的特性。我們也需要確保之前所創(chuàng)建的功能還在繼續(xù)正常運(yùn)行。一個(gè)自動(dòng)化測(cè)試框架能夠幫助團(tuán)隊(duì)快速地進(jìn)行測(cè)試并找到bug。這不僅是對(duì)于新的開(kāi)發(fā)任務(wù)所產(chǎn)生的回歸缺陷的一種安全保障，同時(shí)也節(jié)省了開(kāi)發(fā)者與測(cè)試人員的寶貴時(shí)間，讓他們專注于自己最擅長(zhǎng)的工作上。

但是，由于每個(gè)Scrum Sprint的時(shí)間限制，同時(shí)編寫(xiě)自動(dòng)化測(cè)試用例以及進(jìn)行手動(dòng)測(cè)試就成為一個(gè)很大的挑戰(zhàn)。為了克服這一挑戰(zhàn)，我們團(tuán)隊(duì)對(duì)于每個(gè)用戶故事完成的定義加入了一個(gè)規(guī)定：如果某個(gè)用戶故事的適當(dāng)路徑（happy path）還沒(méi)有完成自動(dòng)化，那么就不能夠開(kāi)始進(jìn)行測(cè)試。通常來(lái)說(shuō)，讓一個(gè)開(kāi)發(fā)者與一個(gè)QA測(cè)試人員共同合作編寫(xiě)適當(dāng)路徑是一種優(yōu)秀的實(shí)踐。

有些情況下，在一個(gè)Sprint中對(duì)非功能性方面進(jìn)行測(cè)試是不可能的，例如系統(tǒng)的性能。對(duì)于每個(gè)非功能性方面的測(cè)試都應(yīng)當(dāng)創(chuàng)建新的用戶故事，并獨(dú)立估算時(shí)間。此外，這些測(cè)試也應(yīng)當(dāng)實(shí)現(xiàn)自動(dòng)化，并加入到回歸測(cè)試套件中，以確保缺陷修復(fù)后的系統(tǒng)還能夠繼續(xù)正常運(yùn)行。如果整個(gè)系統(tǒng)是持續(xù)集成的，并且使用了自動(dòng)化測(cè)試，那么也許就不必對(duì)其進(jìn)行嚴(yán)格的集成測(cè)試了。

雖然在瀑布式、迭代式與敏捷實(shí)踐中測(cè)試的任務(wù)從原則上來(lái)說(shuō)沒(méi)有什么區(qū)別，但敏捷的心態(tài)與它的測(cè)試實(shí)踐為實(shí)現(xiàn)理想的結(jié)果提供了新的有效方法。敏捷性體現(xiàn)在敏捷實(shí)踐當(dāng)中，而不是體現(xiàn)在支配性的流程中本身。

簡(jiǎn)而言之，一個(gè)優(yōu)秀的敏捷測(cè)試人員應(yīng)當(dāng)具備處理多任務(wù)的能力，并且能夠跟上開(kāi)發(fā)與發(fā)布的節(jié)奏。對(duì)于測(cè)試人員來(lái)說(shuō)，創(chuàng)新性比挑剔來(lái)得更為重要。一個(gè)測(cè)試專家應(yīng)當(dāng)努力進(jìn)行學(xué)習(xí)與創(chuàng)新，并且對(duì)于客戶的期望必須具備全面的理解。最后，一個(gè)敏捷測(cè)試人員必須具備多種技術(shù)，例如手動(dòng)測(cè)試、功能性測(cè)試和性能測(cè)試，并且需要具備領(lǐng)導(dǎo)能力和溝通能力這樣的軟技巧。

本文轉(zhuǎn)載自：InfoQ中文站

作者：Priyanka Hasija，是一位來(lái)自于Thoughtworks的QA咨詢師，她在IT行業(yè)有5年的從業(yè)經(jīng)驗(yàn)。在這段時(shí)間時(shí)，她對(duì)于敏捷的原則已經(jīng)建立了一個(gè)堅(jiān)實(shí)的認(rèn)識(shí)，并且在多個(gè)敏捷項(xiàng)目中成功地實(shí)踐了這些原則。Priyanka在手動(dòng)測(cè)試方面獲得了豐富的經(jīng)驗(yàn)，并且在使用自動(dòng)化測(cè)試工具方面也經(jīng)驗(yàn)頗豐，這些工具包括Cucumber、Web-driver和JMeter等等。她也在內(nèi)部與外部的多個(gè)會(huì)議上進(jìn)行了演講。