在過去的幾年中，一種創建軟件的新方法席卷了軟件開發和測試領域:敏捷。
事實上,根據VersionOne的敏捷狀態報告截至2018年，97%的組織以某種形式實踐敏捷。然而，受訪者報告說，這種采用在他們的組織中並不總是普遍存在，這意味著在采用和成熟方麵還有很長的路要走。
那麼敏捷到底是什麼，為什麼它能如此迅速地流行起來?讓我們來探索敏捷方法到底需要什麼，以及如何在您的組織中更詳細地引入它。具體來說，我們將介紹:
- 測試如何適應敏捷方法?
- 敏捷團隊中有哪些不同的測試方法?
- 敏捷運動的下一步是什麼?
準備好了嗎?我們走吧!(或下載我們的敏捷測試電子書用於離線訪問。)
關於敏捷方法論
敏捷方法已經席卷了軟件開發世界，並迅速鞏固了其作為“黃金標準”的地位。敏捷方法都是基於以下四個核心原則開始的敏捷宣言．這些方法植根於適應性規劃、早期交付和持續改進，所有這些都著眼於能夠快速、輕鬆地響應變化。因此，毫不奇怪，88%的受訪者在VersionOne的2017年敏捷狀態報告中將“適應變化的能力”列為采用敏捷的第一大好處。
然而，隨著越來越多的開發團隊采用敏捷哲學，測試人員已經努力跟上步伐。這是因為敏捷的廣泛采用導致團隊更頻繁地發布版本和完全無文檔的軟件。這種頻率迫使測試人員在保持質量標準的同時，改變何時進行測試，如何與開發人員和BAs合作，甚至進行什麼測試。
敏捷團隊中的測試意味著什麼?
敏捷原則都是關於協作性、靈活性和適應性。它建立在這樣一個前提上:世界現在經常變化，這意味著軟件團隊不再有幾年的時間把新產品推向市場。在此期間，競爭對手提供的產品或客戶期望可能會發生變化，團隊可能會變得無關緊要。敏捷通過適應團隊成功的需要，幫助團隊更多地協作，從而最大限度地降低了這種風險。它通過鼓勵團隊定期展示他們的工作並收集反饋來實現這一點，以便他們能夠快速適應變化。
快速啟動您的敏捷協作:閱讀我們的文章，“開發人員和測試人員之間對齊的秘密”。
在測試方麵，敏捷開發的快速步伐導致了測試人員的幾個必要條件:
- 基於風險確定需求的優先級，因為不可能測試所有內容
- 自動化測試以提高效率
- 增加探索性測試的使用，以加快從代碼交付到測試完成的時間，並強調創建可工作的代碼的必要性
- 適應不同衝刺階段的變化
第四個必要條件——適應性——尤其重要，因為它要求測試人員擁有更廣泛的、跨功能的測試技能，這代表了在瀑布式環境中通常需要的狹窄測試技能的背離。與瀑布式環境不同，遵循敏捷方法的測試人員需要與開發人員保持密切聯係，以便在整個軟件開發生命周期中協作進行測試。在瀑布式方法中，測試人員通常會根據大量的需求文檔進行測試。該文檔不會頻繁更改，因此測試人員能夠相對獨立於開發人員而存在。然而，大多數敏捷方法都不重視文檔，新特性的需求可能隻在需求跟蹤係統的一張票據中，而沒有列出所有的邊緣情況。這些場景中的測試人員需要與開發和業務團隊高度溝通，因為他們幾周前編寫的測試可能很快就會過時。為了成功，測試人員需要靈活並能夠適應移動的目標。
總的來說，敏捷宣言中有四個核心原則對測試人員來說是很重要的:
- 個人和交互勝於過程和工具
- 工作軟件優於全麵的文檔
- 對變化做出反應，而不是遵循計劃
- 協助客戶進行合同談判
所有這一切的底線是每個人——測試人員、開發人員和其他人員——必須進化以接受敏捷的工作風格。
敏捷不是萬能的
每個組織都是獨特的，麵臨不同的內部因素(即組織規模和利益相關者)和外部因素(即客戶和法規)。為了幫助滿足不同組織的不同需求，在使用其中一種敏捷方法時，可以使用各種敏捷方法和幾種不同類型的測試。哪種組合適合你的團隊取決於你的內部和外部因素、需求和目標。讓我們來看看一些最流行的敏捷方法和測試方法，包括:
- 敏捷方法
- Scrum
- 看板
- 測試方法
- 行為驅動開發(BDD)
- 驗收測試驅動開發(ATDD)
- 探索性測試
- 基於會話的測試
2敏捷方法類型
1) Scrum
是什麼?最流行的軟件測試方法之一(由58%Scrum采用一種高度迭代的方法，專注於在每個sprint之前定義關鍵特性和目標。它旨在降低風險，同時快速提供價值。
Scrum從需求或用戶故事開始，描述功能應該如何執行和測試．然後，團隊通過一係列衝刺來快速提供小的價值爆發。為了幫助團隊以這種靈活的方式工作，避免轉移優先級，Scrum要求從一開始就回答問題。
它與《瀑布》有何不同?盡管Waterfall在發布產品之前包含了多個測試和錯誤修複周期，但Scrum更具協作性和迭代性。最大的區別之一是，Waterfall在早期需要大量的文檔。這個文檔使得隨著過程的進行而更改特性變得更加困難，這在某些環境中可能是消極的(例如消費級軟件)，而在其他環境中可能是積極的(例如團隊試圖發射火箭的環境，因為沒有人希望危險的需求頻繁變化)。也就是說，您可能認為Scrum就像許多“迷你瀑布”，因為需求在每個sprint開始時都被很好地定義，並且不應該在其中發生變化。不同之處在於，下一個sprint的詳細需求並沒有提前幾個月設定。
更深入地說，Scrum要求測試人員、開發人員和BAs之間更定期地合作，通常以每日站立會議和衝刺回顧的形式進行，以確保適當的溝通和一致。此外，還有一個Scrum Master，他通過移除團隊中的障礙來確保項目最有效地進行，從而幫助保持項目的正常進行。Scrum Master可以是團隊中的任何人，比如開發人員或測試人員。
領養意味著什麼?Scrum為來自瀑布環境的團隊提供了最簡單的過渡之一，因為它是基於時間的衝刺，並且仍然可以提前計劃發布。也就是說，它確實需要更快的迭代和更強的協作。
是給誰的?由於Scrum的快速迭代，它最適合那些客戶和涉眾希望通過定期在展示會議上看到工作產品而積極參與的團隊。這種合作允許團隊為即將到來的展示做出更改。采用Scrum方法時應該參與的關鍵團隊成員包括:
- 產品負責人
- Scrum Master
- 開發人員
- 自動化工程師
- 測試人員
- 利益相關者
什麼是最佳實踐?除了強大的溝通、協作和適應性，Scrum方法論下的測試人員的其他最佳實踐還包括:
- 根據來自銷售代表或客戶的溝通(通常以用戶故事的形式)確定接受標準(注意:這種直接聯係應該有助於減少誤解)
- 使用驗收標準來開發代碼，並確保團隊批準該代碼
- 在將代碼部署到生產環境之前，先在類似沙箱的環境和類似生產環境中測試代碼
2)看板
是什麼?看板是一種非常簡單的基於敏捷的方法製造(它是由豐田公司開發的，用來幫助提高工廠的生產率)．在其核心，看板可以被認為是一個大的、有優先級的待辦事項列表。與Scrum一樣，看板中的需求是根據流程中的當前階段(待完成、開發中、測試中、完成)來跟蹤的。
與Scrum不同，看板不是基於時間的。相反，它完全基於優先級。當開發人員準備好進行下一個任務時，他/她將其從待辦事項列表中刪除。由於計劃會議較少，這種方法意味著團隊需要非常緊密地聯係在一起。在這種環境中，如果開發人員的工作速度比測試人員快得多，瓶頸就會突然出現。在這種情況下，團隊中的任何人都應該介入並在不同領域提供幫助。當然，滿足這種需求需要很大的靈活性和適應性。
它與《瀑布》有何不同?看板仍然有像瀑布一樣的需求，但是需求可能會發生變化，因為直到開發人員從backlog的頂部選擇每個需求時，測試團隊才開始考慮測試它。相比之下，《Waterfall》是基於時間的，在計劃中有很多開銷。在某些情況下，在瀑布環境中進行繁重的計劃是很好的，比如在構建昂貴的東西時，但這並不總是必要的。使用看板，發布仍然是有計劃的，但團隊通常不會在特定日期前向任何人承諾特性，除非所討論的項目接近待辦事項列表的頂部。
領養意味著什麼?看板為正確的團隊提供了簡單的過渡。為了順利過渡到看板，業務分析師、開發人員、測試人員和利益相關者應該坐在一起，定期溝通。當過渡到看板時，重要的是要記住，這種方法提供了將代碼投入生產的最快方法，但代碼可能會有一些技術債務。這是因為在不知道下一步是什麼情況下進行開發，並不一定會產生最可重用的代碼。
是給誰的?看板最適合小團隊，或者不為公眾生產特性和/或不承諾特定發布日期的團隊。此外，對於任何主要專注於維護工作的產品或團隊來說，這是首選的方法，因為錯誤並不總是直接的，通常需要研究才能解決，這使得時間管理具有挑戰性。不能最小化問題計劃量的團隊可能會更好地遵循Scrum或瀑布方法。
應該參與看板環境的關鍵團隊成員包括:
- 產品負責人
- 項目經理
- 開發人員
- 自動化工程師
- 測試人員
什麼是最佳實踐?除了保持可見性和協作的優先級，測試人員遵循看板方法的最佳實踐還包括:
- 在業務所有者、開發人員和測試人員之間保持非常開放的溝通渠道
- 確保團隊能夠靈活地承擔核心職責之外的其他角色，以幫助清除瓶頸
- 讓每個人都成為產品的所有者，這樣他們就會完全投入到結果中
4敏捷測試方法
1)行為驅動開發(BDD)
是什麼?許多人都聽說過或使用過測試驅動開發(TDD)。例如，開發人員使用TDD編寫單元測試，使其在代碼編寫之前失敗。BDD基於與TDD相同的原則，但它不是單元測試，而是在業務級別調用更高級別的測試。BDD不像TDD那樣從麵向技術的單元測試開始，而是從基於最終用戶行為的初始需求開始，並調用“人類可讀”的測試，甚至可以取代一些需求文檔。這個需求基於產品應該表現出的行為，為工程師在開發測試時創建了一個無懈可擊的指南。
欲了解更多信息，請閱讀我們的文章:“為什麼BDD是DevOps測試的秘密武器。”
具體來說，BDD從使用Gherkin Given/When/Then語法的功能規範開始。然後，該規範指導開發人員、測試人員和產品負責人跨功能進行轉換。正如他們所做的，他們使用自動化測試函數來確定完整性，精煉代碼，直到它通過測試，很像TDD方法，隻是在團隊級別。為了確保測試通過(通常需要多次嚐試)，開發人員應該隻重構代碼，而不添加任何新功能。
總而言之,BDD需要一個“智能”自動化策略這推動了高水平的效率。這種策略將BDD與其他敏捷方法區別開來。
它與標準的瀑布測試有何不同?BDD與標準的瀑布式測試截然不同，因為前者要求測試用例在早期根據需求編寫，並要求在開發周期結束時執行這些測試。然而，在敏捷環境中使用BDD，測試不是基於需求和測試與功能的開發一起進行．
此外，在瀑布方法中，測試人員是編寫測試用例的人。另一方麵，BDD方法適合於編寫測試的業務所有者。這種切換減少了業務分析人員、開發人員和測試人員之間的溝通(或錯誤溝通)。
領養意味著什麼?改為BDD方法當團隊習慣於傳統的測試風格時，這可能具有挑戰性。它需要BA或測試人員預先編寫測試，並由開發人員用代碼編寫與之匹配的測試規範。這是團隊內部的一種新型協調方式，但它非常積極，因為團隊作為一個單元一起工作，包括業務用戶。
是給誰的?BDD方法非常適合開發以功能為中心的軟件的團隊和/或將用戶體驗放在第一位的團隊。應該參與BDD環境的主要團隊成員包括:
- 產品負責人/業務分析師
- 項目經理
- 開發人員
- 自動化工程師/測試人員
什麼是最佳實踐?遵循BDD方法的測試人員的最佳實踐包括:
- 簡化文檔，以保持整個流程精簡
- 采用“三個朋友”模式，產品負責人、開發人員和測試人員組成一個有凝聚力的團隊
- 使用像Cucumber這樣的測試框架來定義標準
- 以盡可能容易重用的方式構建自動化測試
- 讓業務分析師學習Gherkin語法並直接編寫測試用例
2)驗收測試驅動開發
是什麼?ATDD類似於BDD，因為它要求首先創建測試，並要求編寫代碼以通過這些測試。然而，在TDD中，測試通常是麵向技術的單元測試，在ATDD中，測試通常是麵向客戶的驗收測試．
ATDD背後的理念是，用戶對產品的感知與功能一樣重要，因此這種感知應該推動產品性能，以幫助增加采用。為了實現這個想法，ATDD從客戶那裏收集輸入，使用這些輸入來開發驗收標準，將這些標準轉換為手動或自動驗收測試，然後根據這些測試開發代碼。像TDD和BDD一樣，ATDD是一種測試優先的方法，而不是需求驅動的過程。
此外，像TDD和BDD方法一樣，ATDD通過消除開發人員解釋產品將如何使用的需要，幫助消除潛在的誤解領域。ATDD比TDD和BDD更進一步，因為它直接指向源頭(即客戶)，以了解產品將如何使用。理想情況下，這種直接連接應該有助於減少在新版本中重新設計功能的需要。
它與標準的瀑布測試有何不同?ATDD不同於標準的瀑布測試，因為它是一種測試優先的方法。標準瀑布測試要求基於需求預先編寫測試用例，而ATDD不是需求驅動的測試過程。
領養意味著什麼?因為ATDD代表了與傳統方法的背離，從一種方法轉換到另一種方法對團隊來說並不容易。為了處於采用ATDD方法的最佳位置，團隊需要獲得涉眾的支持，這有時可能具有挑戰性。
是給誰的?由於ATDD強調用戶感知，它最適合那些專注於用戶體驗、以高采用率為目標並希望在未來版本中盡量減少功能更改數量的團隊。應參與ATDD環境的主要團隊成員包括:
- 客戶/客戶支持
- 開發人員
- 產品負責人/業務分析師
- 自動化工程師/測試人員
- 項目經理
什麼是最佳實踐?遵循ATDD敏捷方法的測試人員的最佳實踐包括:
- 與客戶密切互動，例如通過焦點小組，以確定期望
- 依靠麵向客戶的團隊成員，如銷售代表、客戶服務代理和客戶經理，了解客戶的期望
- 根據客戶期望製定驗收標準
- 優先考慮兩個問題:
- 如果係統做了X，客戶會使用它嗎?
- 我們如何驗證係統是否做了X?
3)探索性測試
是什麼?下一個是探索性測試，實際上是一種功能測試但在敏捷環境中很重要。探索性測試讓測試人員擁有代碼的所有權，以一種有組織的、混亂的方式進行測試。在這種情況下，測試人員沒有遵循測試步驟，而是以標準或聰明的方式使用軟件來嚐試破壞它。測試人員將像往常一樣記錄缺陷，但是並不總是提供應用程序被測試的內容和方式的詳細文檔。
探索性測試沒有腳本。相反，它是關於基於每個獨特的軟件開發最好的測試。由於它的非腳本方法，探索性測試經常模擬用戶在現實生活中如何與軟件交互。
總的來說，探索性測試遵循四個關鍵原則:
- 並行測試計劃，測試設計和測試執行
- 具體而靈活
- 對潛在的機會進行調查
- 知識共享
它與標準的瀑布測試有何不同?探索性測試實際上可以在瀑布環境和敏捷環境中完成，但是敏捷環境中測試人員和開發人員之間的緊密集成有助於緩解在瀑布環境中運行探索性測試時可能出現的任何瓶頸。
此外，為了在瀑布環境中運行探索性測試，測試結果的文檔是必須的，並且該文檔應該易於追溯到需求。當然，這種類型的文檔在任何環境中都是有用的。
領養意味著什麼?采用探索性測試相對容易，因為它可以快速啟動(和擴展)，易於學習，並為整個團隊帶來好處。也就是說，重要的是要記住，它不應該是唯一的測試形式(相反，它應該告訴接下來會發生什麼類型的測試)。此外，即使它是無腳本的，探索性測試也不應該是非結構化的(測試人員仍然需要設置一個目標，記錄您的活動並采取特定用戶角色的心態)。
是給誰的?探索性測試可以幫助減少花費在測試上的時間，發現更多的缺陷並提高代碼覆蓋率。因此，探索性測試最適合這樣的團隊:有時間限製的團隊，需要幫助確定要運行的最佳測試類型的團隊(特別是在沒有來自開發人員的規範的情況下)，以及希望確保他們在之前的測試中沒有遺漏任何內容的團隊。應該參與探索性測試的主要團隊成員包括:
- 測試人員(盡管團隊中的每個人都應該以某種方式參與)
什麼是最佳實踐?測試人員使用探索性測試的最佳實踐包括:
- 使用思維導圖或電子表格來組織應用程序中的功能
- 專注於特定領域或特定場景
- 跟蹤測試的內容以幫助重現任何錯誤
- 在工具中記錄結果比如qTest Explorer所以要對測試的內容負責
4)基於會話的測試
是什麼?最後，讓我們回顧一下基於會話的測試。基於會話的測試基於探索性測試，提供了更多的結構。因為探索性測試是完全沒有腳本的，它使得問責變得困難，並且在很大程度上依賴於相關測試人員的技能和經驗。基於會話的測試旨在通過為探索性測試帶來更多的結構來緩解這些缺點，同時又不損害探索性測試所提供的好處，例如更好地模擬用戶體驗的能力和測試的創造性。
基於會話的測試提供了這種結構，方法是在有時間限製的、不間斷的會話中進行測試，根據章程進行測試，並要求測試人員報告在每個會話中進行的測試。此外，基於會話的測試應該以測試人員和經理之間的“彙報”涵蓋了五個證明點:發生了什麼(PAst)，取得了什麼成績(R結果)，是什麼阻礙了(O障礙)，還需要做什麼(OUtlook)以及測試人員對此有何感受(F捕鰻)。
它與標準的瀑布測試有何不同?與探索性測試一樣，基於會話的測試可以在敏捷環境和瀑布環境中運行，但它更有利於測試人員和開發人員之間的緊密協作，這通常在敏捷環境中可以找到。
領養意味著什麼?與探索性測試非常相似，采用基於會話的測試相對容易，因為它易於快速獲取和啟動。對於已經習慣了探索性測試的測試人員來說，最大的障礙是接受基於會話的測試調用的附加結構。同樣，像探索性測試一樣，運行基於會話的測試的團隊應該記住，它不是最終的一站，而是一種幫助確定接下來進行的最佳測試類型的方法。
是給誰的?基於會話的測試可以幫助減少測試時間，同時增加缺陷發現和代碼覆蓋率，使其成為麵臨時間限製並需要更多指導來確定要運行哪種測試類型的團隊的理想選擇。對於發現探索性測試的好處，但需要在整個過程中改進問責製的團隊來說，它也是理想的。應該參與基於會話的測試的主要團隊成員包括:
- 測試人員
- 經理
什麼是最佳實踐?測試人員使用基於會話的測試的最佳實踐包括:
- 概述任務，以便測試人員清楚他們正在測試的軟件
- 開發一個明確的章程，指出任務、要測試的軟件領域、哪些測試人員將運行會話、會話將在何時發生以及持續多長時間、設計和執行的測試、發現的錯誤和總體注釋(如探索性測試)。像qTest Explorer這樣的文檔工具在這裏可以提供幫助）
- 不受任何幹擾地運行測試會話
- 在會議報告中清楚地記錄會議期間的活動和注意事項
- 在測試人員和經理之間進行彙報，以回顧會議的發現，並討論測試的下一步步驟
如何將測試與敏捷交付過程結合起來
一旦您確定了哪種測試方法適合您的組織，您還沒有完全完成。您仍然需要將測試與交付結合起來。為了實現這一目標，我們建議采取三管齊下的方法:
1)盡早參與開發過程
測試人員越早參與越好。理想情況下，測試人員應該從第一天開始就在現場。這是因為讓測試人員在每一步都有一席之地提供對需求和目標的更高層次的洞察，鼓勵協作，並幫助深入了解進行頻繁(如果不是連續的)測試的需要。
2)經常測試，但要深思熟慮
隨著越來越多的團隊采用敏捷方法，效率就是一切。這種對速度的需求使得團隊也接受了DevOps和持續集成，以保持事情的進展，而這需要更頻繁地測試。但是在以效率和頻率為中心的調整中，測試人員需要保持深思熟慮，以免產生更多的開銷，並運行不必要的測試，從而實際上減緩了過程。
3)以測試創建為基礎
記住，在當今敏捷、DevOps驅動的世界中，測試人員需要快速地創建測試。具體來說，測試人員可以減少從需求收集到測試創建的時間越多越好。在這方麵，從一開始就在所有對話中占有一席之地應該會有所幫助。
下一步是什麼敏捷測試?
盡管敏捷已經在軟件開發生命周期中取得了重大進展，但還有很長的路要走，尤其是在測試團隊中。
展望未來，更廣泛的采用和更成熟的敏捷方法將要求測試人員超越測試創建和執行，也開始關注代碼交付和集成。與此同時，測試人員將需要磨練他們的自動化技能，更多地參與整個軟件開發過程，並繼續與開發人員建立協作關係。最終，這些變化還將要求測試人員成為開發和產品使用方麵的專家，以便提供更全麵的測試策略，並承擔起“質量冠軍”的角色。
在未來，對於在敏捷環境中工作的測試人員來說，三個關鍵原則將變得特別重要:
1)溝通
敏捷需要測試人員和開發人員之間的緊密合作，這種合作使得溝通成為測試人員的首要任務。此外，在一個質量成為每個人責任的世界裏，測試人員將成為“質量冠軍”，充當內部專家，這將使他們清楚地溝通測試需求和推理的能力受到關注。
2)技能多樣性
在敏捷環境中，任何事情都可能瞬間發生變化，這就要求測試人員具有很強的適應性。這種適應性的一部分是擁有多樣化的技能集，以便測試人員可以根據需要改變過程。例如，功能測試人員需要擴展他們的技能，而不是手動腳本執行。這種多樣化的技能集是必須的，因為不同的sprint需要在短時間內執行不同類型的測試。
3)商業思維
最後，敏捷采用了一種非常以客戶為中心的方法，以確保客戶盡可能快、盡可能早地獲得盡可能多的價值。測試人員在傳遞這種價值方麵扮演著重要的角色，但這要求他們具備業務思維，以便他們能夠理解客戶的期望、願望和關注點，並相應地製定他們的測試策略。
為什麼領先公司采用qTest來擁抱敏捷
超過300家領先的公司已經選擇改進他們的軟件測試過程，並使用qTest擁抱敏捷。以下是其中幾位領導者對他們為什麼選擇使用qTest的解釋:
“我們能夠在短短幾周內迅速減輕從惠普質量中心到Tricentis qTest的所有測試用例，並讓團隊組建並運行。實施過程非常好。”
-Radka Iordanova, Office Depot, Inc.電子商務總監
“我們已經看到測試人員錯誤的大幅減少，現在我們有了關於缺陷的曆史記錄。我們可以看到問題出在哪裏。American Equity和Tricentis之間的合作關係非常好。”
-Dennis Young, QA助理副總裁，American Equity
“我們評估了很多其他的測試平台，發現Tricentis qTest是迄今為止最好的，也是最直觀的……自第一次實施qTest以來，我們的效率至少提高了50%。”
——傑西·雷諾薩(Zappos高級質量工程師
特別感謝Ali Huffstetler為這個博客繪製圖片。