在過去幾年中，一種創建軟件的新方式已經風靡軟件開發和測試世界：敏捷。

事實上，根據VersionOne的敏捷狀態報告，截至2018年，97％的組織以某種形式實踐敏捷。 然而，受訪者表示，這種採用在其組織中並不總是很普遍，這意味著在採用和成熟方面還有很長的路要走。

那麼究竟什麼是敏捷的，為什麼它如此迅速地變得如此受歡迎？ 讓我們更詳細地探索敏捷方法所涉及的內容以及如何在組織中引入它。 具體來說，我們將涵蓋：

• 測試如何適應敏捷方法？
• 在敏捷團隊上測試的不同方法有哪些？
• 敏捷運動的下一步是什麼？

關於敏捷方法論

敏捷方法已經風靡軟件開發世界並迅速鞏固其作為“黃金標準”的地位。敏捷方法論都是基於敏捷宣言中概述的四個核心原則開始的。這些方法植根於適應性規劃，早期交付和持續改進，所有這些都著眼於能夠快速，輕鬆地響應變化。因此，在VersionOne的2017年敏捷狀態報告中，88％的受訪者認為“適應變化的能力”是擁抱敏捷的頭號優勢，這一點也就不足為奇了。

然而，隨著越來越多的開發團隊採用敏捷理念，測試人員一直在努力跟上步伐。這是因為敏捷的廣泛採用促使團隊更頻繁地發佈版本和完全無證的軟件。這種頻率迫使測試人員在進行測試時，他們如何與開發人員和BA一起工作，甚至他們進行的測試，同時保持質量標準。

對敏捷團隊進行測試意味著什麼？

敏捷原則都是關於協作，靈活和適應性的。它建立在現在世界變化的前提下，這意味著軟件團隊不再需要多年才能將新產品推向市場。在那段時間內，競爭對手的產品或客戶期望可能會發生變化，而團隊的風險則無關緊要。敏捷通過適應團隊成功所需的內容，幫助團隊更多地協作，從而最大限度地降低風險。它通過鼓勵團隊定期展示他們的工作並收集反饋以便他們能夠快速適應變化來實現這一目標。

快速啟動您的敏捷協作：閱讀我們的文章“開發人員和測試人員之間保持一致的祕密”。

縮小測試範圍，敏捷開發的快節奏為測試人員帶來了幾個必要條件：

1. 根據風險確定需求的優先級，因為無法測試所有內容
2. 自動化測試以提高效率
3. 增加探索性測試的使用，以加快從代碼交付到測試完成的時間，並強調創建有效代碼的必要性
4. 適應從衝刺到衝刺的變化

第四個必要條件 - 適應性 - 特別重要，因為它要求測試人員具有更廣泛的跨功能測試技能，這代表了與瀑布環境中經常需要的較窄測試技能的背離。此外，與瀑布環境不同，遵循敏捷方法的測試人員需要與開發人員保持密切聯繫，以便在整個軟件開發生命週期中協作進行測試。在瀑布式方法中，通常會有一個大型的需求文檔供測試人員測試。該文檔不會經常更改，因此測試人員可以相當獨立於開發人員而存在。但是，大多數敏捷方法對文檔都很清楚，新功能的要求可能只在需求跟蹤系統中的票證中，而沒有列出所有邊緣情況。這些場景中的測試人員需要與開發和業務團隊進行高度溝通，因為幾周前他們編寫的測試可能很快就會過時。為了取得成功，測試人員需要靈活並能夠適應移動目標。

為了取得成功，測試人員需要靈活並能夠適應移動目標。

一般而言，敏捷宣言有四個核心原則，對於測試人員來說很重要：

1. 個人和流程與工具之間的互動
2. 通過綜合文檔工作軟件
3. 響應遵循計劃的變更
4. 通過合同談判與客戶合作

所有這一切的底線是，每個人 - 測試人員，開發人員和其他人 - 必須發展才能擁抱敏捷的工作方式。

敏捷不是放之四海而皆準的

每個組織都是獨一無二的，面臨著不同的內部因素（即組織規模和利益相關者）和外部因素（即客戶和法規）。 為了幫助滿足不同組織的不同需求，您可以在其中一種敏捷方法中使用各種敏捷方法和幾種不同類型的測試。 哪種組合適合您的團隊取決於您的內部和外部因素，需求和目標。 讓我們來看看一些最流行的敏捷方法和測試方法，包括：

敏捷方法論

• Scrum
• 看板

測試方法

• 行為驅動開發（BDD）
• 驗收測試驅動開發（ATDD）
• 探索性測試
• 基於會話的測試

2敏捷方法論類型

1）Scrum

它是什麼？作為最受歡迎的軟件測試方法之一（58％的組織已根據VersionOne採用了敏捷方法），Scrum採用高度迭代的方法，專注於在每個sprint之前定義關鍵特性和目標。它旨在降低風險，同時快速提供價值。

Scrum從一個需求或用戶故事開始，概述了功能應該如何執行和測試。然後，該團隊通過一系列衝刺循環，以快速提供小規模的價值爆發。為了幫助團隊以這種靈活的方式工作並避免改變優先級，Scrum要求從一開始就回答問題。

它和瀑布有什麼不同？瀑布包括在發佈產品之前的幾個測試和錯誤修復週期，而Scrum更具協作性和迭代性。其中一個最大的區別是瀑布早期需要大量文檔。這個文檔使得在過程繼續進行時更改功能變得更加困難，這在某些環境（例如消費級軟件）中可能是負面的，而在其他環境中則是積極的（例如團隊試圖發射火箭的那些）沒有人想要經常危險移動的要求）。也就是說，您可能會認為Scrum就像許多“迷你瀑布”一樣，因為每個衝刺開始時需求都很明確，不應該在其中移動。不同之處在於，下一個衝刺的詳細要求不是提前幾個月設定的。

潛水更深入，Scrum要求測試人員，開發人員和BA之間進行更多定期協作，通常採用每日站立和衝刺回顧的形式，以確保正確的溝通和協調。此外，還有一位Scrum Master通過刪除團隊中的阻截者來確保他們最有效，從而幫助項目完成任務。 Scrum Master可以是團隊中的任何人，例如開發人員或測試人員。

採用有什麼意義？ Scrum為來自瀑布環境的團隊提供了最簡單的轉換之一，因為它基於時間的衝刺和發佈仍然可以提前計劃。也就是說，它確實需要更快的迭代和更強的協作。

它是誰的？由於其快速迭代，Scrum最適合那些客戶和利益相關者希望通過在展示會議上定期查看工作產品而積極參與的團隊。此協作允許團隊對即將到來的陳列櫃進行更改。在採用Scrum方法時應該參與的主要團隊成員包括：

• 產品擁有者
• Scrum Master
• 開發商
• 自動化工程師
• 測試者
• 利益相關者

什麼是最佳做法？除了強大的溝通，協作和適應性之外，遵循Scrum方法的測試人員的其他最佳實踐還包括：

• 根據銷售代表或客戶的通信（通常以用戶故事的形式）確定驗收標準（注意：此直接連接應有助於減少誤傳）
• 使用驗收標準開發代碼並確保團隊批准該代碼
• 在將其部署到生產環境之前，在類似沙箱的環境以及類似生產的環境中測試代碼

2）看板

它是什麼？看板是一種非常簡單的基於敏捷的方法，植根於製造業（它由豐田公司開發，旨在幫助提高工廠的生產率）。在它的核心，看板可以被認為是一個大的，優先的待辦事項列表。與Scrum一樣，看板中的需求由其當前階段（待辦，開發，測試，完成）跟蹤。

與Scrum不同，看板不是基於時間的。相反，它完全基於優先權。當開發人員準備好完成下一個任務時，他/她將其從待辦事項列表中拉出來。由於計劃會議較少，這種方法意味著團隊需要非常接近。在這種類型的環境中，如果開發人員的工作速度比測試人員快得多，那麼就會出現瓶頸。在這些情況下，團隊中的任何人都應該跳進並幫助不同的領域。當然，滿足這種需求需要很大的靈活性和適應性。

它和瀑布有什麼不同？看板仍然有像瀑布這樣的要求，但是由於測試團隊沒有開始考慮測試每個要求，直到開發人員從積壓的頂部選擇它，因此需求可能會發生變化。相比之下，瀑布是基於時間的，在計劃中有很多開銷。在某些情況下，在瀑布環境中進行繁重的規劃是很好的，例如在建造昂貴的東西時，但並不總是必要的。使用看板，版本仍然有計劃，但團隊通常不會在某些日期向任何人提供功能，除非相關項目位於待辦事項的頂部。

採用有什麼意義？看板為正確的團隊提供簡單的過渡。為了順利過渡到看板，業務分析師，開發人員，測試人員和利益相關者應該坐在一起並定期溝通。轉換到看板時，重要的是要記住這種方法提供了將代碼投入生產的最快方法，但代碼可能會有一些技術債務。這是因為開發時並不總是知道接下來的內容並不一定能夠生成最可重用的代碼。

它是誰的？看板最適合不為公眾製作功能和/或承諾發佈某些日期的小型團隊或團隊。此外，它是主要專注於維護工作的任何產品或團隊的首選方法選擇，因為錯誤並不總是直截了當，往往需要研究解決，這使得時間管理具有挑戰性。根據Scrum或Waterfall方法，不能最小化問題規劃量的團隊可能會更好。

應參與看板環境的主要團隊成員包括：

• 產品擁有者
• 專案經理
• 開發商
• 自動化工程師
• 測試者

什麼是最佳做法？除了保持可見性和優先協作之外，遵循看板方法的測試人員的最佳實踐還包括：

• 在業務所有者，開發人員和測試人員之間保持非常開放的溝通渠道
• 確保團隊可以靈活地承擔其核心職責之外的其他角色，以幫助消除瓶頸
• 讓每個人都成為產品的所有者，以便他們完全關注結果

4敏捷測試方法

1）行為驅動開發（BDD）

它是什麼？很多人都聽說過或使用過測試驅動開發（TDD）。例如，開發人員在編寫代碼之前使用TDD編寫單元測試失敗。 BDD基於與TDD相同的原則，但它不是單元測試，而是要求在業務級別進行更高級別的測試。 BDD不是像TDD那樣從面向技術的單元測試開始，而是從基於最終用戶行為的初始需求開始，並且需要“人類可讀”的測試，甚至可以替換一些需求文檔。此要求基於產品應展示的行為，為工程師在開發測試時使用創建氣密指南。

有關更多信息，請閱讀我們的文章：“為什麼BDD是DevOps中的測試祕訣。”

具體來說，BDD使用Gherkin Given / When / Then語法從功能規範開始。然後，該規範指導跨功能的開發人員，測試人員和產品所有者。正如他們所做的那樣，他們使用自動化測試功能來確定完整性，改進代碼直到通過測試，就像TDD方法一樣，除了團隊級別。為了確保測試通過（並且通常需要多次嘗試），開發人員應該只重構代碼，而不是添加任何新功能。

總而言之，BDD需要一種“智能”自動化策略，以提高效率。該策略將BDD與其他敏捷方法區分開來。

它與標準瀑布測試有何不同？ BDD與標準的瀑布測試極為不同，因為前者要求在需求的早期編寫測試用例，並要求在開發週期結束時執行這些測試。但是，在敏捷環境中使用BDD，測試不是基於需求，測試是在功能開發的情況下進行的。

此外，在Waterfall方法中，測試人員是編寫測試用例的人。另一方面，BDD方法適用於編寫測試的企業主。此開關可減少業務分析人員，開發人員和測試人員之間的通信（或溝通錯誤）。

採用有什麼意義？當團隊習慣於傳統的測試方式時，更改為BDD方法可能具有挑戰性。它需要BA或測試人員預先編寫測試，並且開發人員要在代碼中編寫測試規範以進行匹配。這是團隊內部的一種新型協調方式，但非常積極的是團隊合作為一個單元，包括業務用戶。

它是誰的？ BDD方法非常適合從事以功能為中心的軟件和/或將用戶體驗放在首位的團隊的團隊。應參與BDD環境的主要團隊成員包括：

• 產品負責人/業務分析師
• 專案經理
• 開發商
• 自動化工程師/測試員

什麼是最佳做法？遵循BDD方法的測試人員的最佳實踐包括：

• 簡化文檔以保持整個流程的精益
• 採用“三友”模式，產品所有者，開發人員和測試人員組成一個有凝聚力的團隊
• 使用像Cucumber這樣的測試框架來定義標準
• 以儘可能容易重用的方式構建自動化測試
• 讓業務分析師學習Gherkin語法並直接編寫測試用例

2）驗收測試驅動開發（ATDD）

它是什麼？ 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）探索性測試

它是什麼？接下來我們進行探索性測試，這實際上是一種功能測試，但在敏捷環境中非常重要。探索性測試使測試人員對代碼擁有所有權，以有組織，混亂的方式對其進行測試。在這種情況下，測試人員不會遵循測試步驟，而是以標準或巧妙的方式使用軟件來嘗試打破它。測試人員將像往常一樣記錄缺陷，但並不總是提供有關應用程序測試內容和方式的詳細文檔。

探索性測試不是腳本化的。相反，它是基於每個獨特的軟件開發最佳測試。由於其無腳本方法，探索性測試通常模仿用戶在現實生活中如何與軟件交互。

總體而言，探索性測試遵循以下四個關鍵原則：

1. 並行測試計劃，測試設計和測試執行
2. 具體而靈活
3. 協調調查潛在的機會
4. 知識共享

它與標準瀑布測試有何不同？探索性測試實際上可以在Waterfall和Agile環境中完成，但是敏捷環境中測試人員和開發人員之間的緊密集成有助於緩解在瀑布環境中運行探索性測試時可能出現的任何瓶頸。

此外，為了在Waterfall環境中運行探索性測試，必須提供有關測試結果的文檔，並且該文檔應該易於追溯到需求。當然，這種類型的文檔在任何環境中都是有用的。

採用有什麼意義？擁抱探索性測試相對容易，因為它可以快速啟動（和擴展），簡單易學併為整個團隊帶來好處。也就是說，重要的是要記住，它不應該是唯一的測試形式（相反，它應該告知接下來會發生什麼類型的測試）。此外，即使它沒有腳本，探索性測試也不應該是非結構化的（測試人員仍然需要設置目標，記錄您的活動並採取特定用戶角色的思維模式）。

它是誰的？探索性測試有助於減少測試時間，發現更多缺陷並提高代碼覆蓋率。因此，探索性測試最適合受時間限制的團隊，需要幫助確定要運行的最佳測試類型的團隊（特別是在沒有開發人員規範的情況下）以及希望確保他們沒有的團隊以前的測試都不會錯過任何東西。應參與探索性測試的主要團隊成員包括：

• 測試人員（雖然團隊中的每個人都應該以某種方式參與）

什麼是最佳做法？使用探索性測試的測試人員的最佳實踐包括：

1. 使用Mindmap或電子表格等組織應用程序中的功能
2. 專注於某些領域或某些場景
3. 跟蹤經過測試的內容，以幫助重現任何錯誤
4. 在qTest Explorer之類的工具中記錄結果，因此對測試的內容有一定的責任感

4）基於會話的測試

它是什麼？最後，讓我們回顧一下基於會話的測試。基於會話的測試建立在探索性測試的基礎上，提供更多結構因為探索性測試完全沒有腳本，所以它使問責制變得困難，並且在很大程度上依賴於所涉及的測試人員的技能和經驗。基於會話的測試旨在通過​​為探索性測試帶來更多結構來緩解這些缺點，而不會剝奪探索性測試提供的好處，例如更好地模仿用戶體驗和通過測試獲得創造性的能力。

基於會話的測試通過在時間限制的，不間斷的會話期間進行測試，針對章程進行測試並要求測試人員報告每個會話期間發生的測試來提供此結構。此外，基於會話的測試應該通過測試人員和管理人員之間的“彙報”進行限制，其中包括五個PROOF點：發生了什麼（過去），取得了什麼（結果），阻礙了什麼（障礙） ），還有什麼需要做的（Outlook）以及測試人員對此的感受（感受）。

它與標準瀑布測試有何不同？與探索性測試相同，基於會話的測試可以在Agile和Waterfall環境中運行，但它更有利於敏捷環境中常見的測試人員和開發人員之間的緊密協作。

採用有什麼意義？與探索性測試非常相似，採用基於會話的測試證明相對容易，因為它易於快速啟動和啟動。對於已經習慣於探索性測試的測試人員來說，最大的障礙是採用基於會話的測試調用的附加結構。與探索性測試一樣，運行基於會話的測試的團隊應該記住它不是最後一站，而是一種幫助確定下一步要進行的最佳測試類型的方法。

它是誰的？基於會話的測試有助於縮短測試時間，同時增加缺陷發現和代碼覆蓋率，使其成為面臨時間限制並需要更多指導以確定要運行的測試類型的團隊的理想選擇。對於在探索性測試中獲益但需要在整個過程中改進問責制的團隊而言，它也是理想的選擇。應參與基於會話的測試的主要團隊成員包括：

• 測試者
• 經理

什麼是最佳做法？使用基於會話的測試的測試人員的最佳實踐包括：

• 概述任務，以便測試人員清楚他們正在測試的軟件
• 開發一個明確的章程，指明任務，要測試的軟件區域，運行會話的測試人員，會話將在何時進行，以及設計和執行的測試，發現的錯誤和整體說明（與探索性測試一樣，像qTest Explorer這樣的文檔工具可以在這裡提供幫助）
• 在沒有任何中斷的情況下運行測試會話
• 在會議報告中明確記錄會議期間的活動和說明
• 在測試人員和經理之間進行彙報，以審查會議的結果並討論下一步的測試步驟

如何使測試與敏捷交付流程保持一致

一旦確定哪種測試方法適合您的組織，您就還沒有完成。您仍需要將測試與交付一致。為實現這一目標，我們建議採用三管齊下的方法：

1）儘早參與開發過程

測試人員越早參與，越好。理想情況下，測試人員應該從第一天起就在場。這是因為讓測試人員在桌面上的每一步都能提供更高水平的需求和目標洞察力，鼓勵合作並幫助確定頻繁（如果不是連續）測試的必要性。

2）經常測試，但是很周到

隨著越來越多的團隊採用敏捷方法，效率就是一切。這種對速度的需求促使團隊採用DevOps和持續集成以保持移動，這需要更頻繁地進行測試。但是在效率和頻率集中的重組中，測試人員需要保持周到，以免產生更多開銷並運行不必要的測試，這實際上會減慢過程。

3）通過測試創建來運行

牢記在當今敏捷，DevOps驅動的世界中對速度的需求，測試人員需要在創建測試時立即投入運行。具體來說，越多的測試人員可以減少從需求收集到測試創建的時間越多越好。從一開始就在所有談話中坐下來應該有助於這方面。

敏捷測試的下一步是什麼？

雖然敏捷已經在軟件開發生命週期中取得了重大進展，但仍有很長的路要走，特別是在測試團隊中。

展望未來，更廣泛的採用和更加成熟的敏捷方法將要求測試人員超越測試創建和執行，並開始專注於代碼交付和集成。與此同時，測試人員需要磨練自己的自動化技能，更多地參與整個軟件開發過程，並繼續與開發人員建立協作關係。最終，這些變化還將要求測試人員成為開發和產品使用方面的專家，以便提供更全面的測試策略並承擔“質量冠軍”的角色。

將來，對於在敏捷環境中工作的測試人員來說，三個關鍵原則將變得尤為重要：

1）溝通

敏捷需要測試人員和開發人員之間的緊密協作，而這種協作使通信成為測試人員的首要任務。此外，在質量成為每個人的責任的世界中，測試人員將成為內部專家的“質量冠軍”，這將使他們能夠在聚光燈下清晰地傳達測試需求和推理。

2）技能多樣性

在敏捷環境中，一切都可以改變，這需要測試人員適應。這種適應性的一部分是擁有多樣化的技能組合，以便測試人員可以根據需要改變方向。例如，功能測試人員需要將他們的技能擴展到手動腳本執行之外。這種多樣化的技能組合是必須的，因為不同的衝刺需要在短時間內執行不同類型的測試。

3）商業心態

最後，Agile採用以客戶為中心的方法，以確保客戶儘可能快地儘早獲得儘可能多的價值。測試人員在提供這一價值方面發揮著重要作用，但它需要他們採取商業思維方式，以便他們能夠理解客戶的期望，願望和關注，並相應地制定他們的測試策略。

為什麼領先的公司正在通過敏捷測試實現敏捷

超過300家領先的公司選擇改進他們的軟件測試流程，並通過採用敏捷。以下是其中一些領導者為什麼選擇使用qTest而說的原因：

“我們能夠快速將所有測試案例從惠普質量中心緩解到qTest，並在短短几周內啟動並運行團隊。實施過程非常好“

-Radka Iordanova，Office Depot，Inc。電子商務總監

“當你轉向敏捷時，僅僅改變你的開發方法還不夠，你必須升級你的軟件工具...... QASymphony正是我們所尋找的。”

-Alex Bantz，Salesforce Marketing Cloud質量工程總監

“我們已經看到了測試者錯誤的大幅減少，現在我們已經有了缺陷的歷史。我們可以看到問題所在。 American Equity和QASymphony之間的合作非常精彩。“

-Dennis Young，美國股票QA助理副總裁

“我們評估了很多其他測試平臺，發現qTest是最好的，而且到目前為止最直觀......自首次實施qTest以來，我們的效率提高了至少50％。”

-Jesse Reynosa，Zappos高級質量工程師

特別感謝Ali Huffstetler為這個博客繪製圖像。

原文： https://www.qasymphony.com/blog/agile-methodology-guide-agile-testing/ ，

http://pub.intelligentx.net/