敏捷測試策略
在敏捷環境中，我們在短期衝刺或迭代中工作，每個sprint只關注一些需求或用戶故事，因此文檔在數量和內容方面可能不會那麼廣泛。
之前我們得出的結論是，由於時間限制，我們可能不需要在每個sprint的敏捷項目中都有一個廣泛的測試計劃，但我們確實需要一個高級敏捷測試策略作爲敏捷團隊的指導。
敏捷測試策略文檔的目的是列出團隊可以遵循的最佳實踐和某種形式的結構。請記住，敏捷並不意味着非結構化。
在這裏，我們來看一個敏捷測試策略樣本以及文檔中包含的內容。
有關：
測試策略通常有一個任務陳述，可能與更廣泛的業務目標和目標相關。
典型的使命宣言可能是：
通過提供快速反饋 和 缺陷預防而不是缺陷檢測，不斷提供滿足客戶需求的工作軟件 。
支持者：
- 在我們首次定義其驗收標準/測試之前，不會爲故事編寫代碼
- 在所有驗收測試通過之前，故事可能不被認爲是完整的
在敏捷測試策略文檔中，我還會提醒每個人關於質量保證
-
質量保證是一系列活動，旨在確保產品以系統，可靠的方式滿足客戶要求。
-
在SCRUM（敏捷）QA是每個人的責任，而不僅僅是測試人員。質量保證是我們爲確保新產品開發過程中的正確質量而開展的所有活動。
測試級別
敏捷測試象限
單元測試
爲什麼：確保代碼正確開發
世衛組織： 開發人員/技術架構師
內容： 所有新代碼+遺留代碼的重新分解以及Javascript單元測試
時間： 一旦編寫新代碼
地點：本地Dev + CI（構建的一部分）
如何： Automated，Junit，TestNG，PHPUnit
API /服務測試
原因： 確保組件之間的通信正常
世衛組織： 開發人員/技術架構師
什麼： 新的Web服務，組件，控制器等
時間： 一旦新API開發並準備就緒
地點： 本地Dev + CI（構建的一部分）
如何： 自動化，肥皂用戶界面，休息客戶端
驗收測試
爲什麼： 確保滿足客戶的期望
世衛組織： 開發人員/ SDET /手冊質量保證
內容： 驗證故事的驗收測試，功能驗證
時間： 功能準備就緒並進行單元測試時
地點： CI /測試環境
如何： 自動化（黃瓜）
系統測試/迴歸測試/ UAT
爲什麼： 確保整個系統在集成時工作
世衛組織： SDET /手冊質量保證/業務分析員/產品負責人
內容： 場景測試，用戶流程和典型用戶旅程，性能和安全測試
時間： 驗收測試完成後
地點： 臨時環境
如何： 自動（Webdriver）探索性測試
產品積壓
軟件開發失敗的最常見原因是由於團隊中不同成員的要求不明確和要求的不同解釋。
用戶故事應簡潔，簡潔，明確。作爲一個很好的指導方針，最好按照INVEST模型編寫用戶故事。
一個好的用戶故事應該是：
我獨立（所有其他人）
N egotiable（不是特定的特定合同）
V aluable（或垂直）
E stimable（很好的近似）
S mall（以便適合迭代）
T estable（原則上，即使還沒有測試）
應使用以下格式編寫用戶故事
As a [role]
I want [feature]
So that [benefit]
重要的是不要忘記“福利”部分，因爲每個人都應該通過開發故事來了解他們所添加的價值。
驗收標準
每個用戶故事都必須包含驗收標準。這可能是鼓勵與團隊中不同成員溝通的最重要因素。
接受標準應該在創建用戶故事的同時編寫，並且應該嵌入到故事的主體中。所有驗收標準都應該是可測試的。
每個驗收標準應該有許多驗收測試，以Gherkin格式編寫，例如
Scenario 1: Title
Given [context]
And [some more context]...
When [event]
Then [outcome]
And [another outcome]...
故事研討會/ Sprint計劃
在每個故事研討會中，團隊中的每個人都會了解故事的細節，以便開發人員和QA瞭解工作的範圍。每個人都應該對故事的內容有相同的理解。
開發人員應該很好地理解提供故事所涉及的技術細節，QA應該知道如何測試故事，以及是否有任何障礙來測試故事。
有關：
- 如果對軟件測試、接口測試、自動化測試、性能測試、LR腳本開發、面試經驗交流。感興趣可以175317069，羣內會有不定期的發放免費的資料鏈接，這些資料都是從各個技術網站蒐集、整理出來的，如果你有好的學習資料可以私聊發我，我會註明出處之後分享給大家。
防止缺陷
在故事研討會中， 必須參與PO，BA，Dev和QA。
應該考慮場景（有效，無效和邊緣情況）（QA可以通過抽象地思考故事在這裏增加巨大價值）並寫在特徵文件中。
重要的是要注意，在測試產品時會出現缺陷（更重要的是），因此在此活動上花費的精力和時間越多，最終的結果就越好。
由於大多數缺陷都是由於要求不清晰和模糊，這項活動還有助於防止錯誤行爲的實施，因爲每個人都應該對故事有相同的理解。
同樣，在sprint計劃會議中，爲故事提供的估算應包括測試工作，而不僅僅是編碼工作。QAR（手動和自動化）也必須出現在sprint計劃會議中，以提供對故事測試的估計。
發展
測試自動化金字塔
如果對軟件測試、接口測試、自動化測試、性能測試、LR腳本開發、面試經驗交流。感興趣可以175317069，羣內會有不定期的發放免費的資料鏈接，這些資料都是從各個技術網站蒐集、整理出來的，如果你有好的學習資料可以私聊發我，我會註明出處之後分享給大家。
開發開始時，新的生產代碼和/或遺留代碼的修改應該由開發人員編寫的單元測試支持，並由另一個開發人員或熟練的SDET進行同行評審。
對代碼存儲庫的任何提交都應該觸發從CI服務器執行單元測試。這爲開發團隊提供了快速反饋機制。
單元測試確保系統在技術級別工作，並且邏輯中沒有錯誤。
開發者測試
作爲開發人員，表現得好像您在團隊或組織中沒有任何QA。誠然，QAs有不同的心態，但你應該盡力測試。
您認爲通過快速進入下一個故事節省時間，但實際上，當發現並報告缺陷時，糾正問題需要更長的時間，而不是花費幾分鐘來確保該功能正常運行。
遺留代碼的任何新代碼和/或重構都應該具有適當的單元測試，這些單元測試將成爲單元迴歸測試的一部分。
自動驗收測試和非功能測試
自動驗收測試包括集成測試和服務測試以及UI測試，旨在證明軟件在功能級別工作，並且滿足用戶的要求和規範。
自動驗收測試通常用Gherkin語言編寫，並使用黃瓜等BDD工具執行。
由於這些測試通常需要通信HTTP，因此需要在已部署的應用程序上執行，而不是作爲構建的一部分運行。
非功能測試 （性能和安全性）測試與功能測試同樣重要，因此需要在每次部署時執行。
性能測試應檢查每個部署的性能指標，以確保性能不會降低。
安全測試應檢查從OWASP派生的基本安全漏洞
至關重要的是，這應該是一個完全自動化的過程，只需很少的維護就可以從自動化部署中獲得最大的收益。這意味着不應出現間歇性測試失敗，測試腳本問題和破壞環境。
故障應僅歸因於真正的代碼缺陷而不是腳本問題，因此任何不是由於真正故障導致的故障測試應立即修復或從自動化包中刪除，以便能夠獲得一致的結果。
迴歸測試
不期望發現很多缺陷。他們的目的只是提供我們尚未破壞主要功能的反饋。應該進行非常少量的手動迴歸測試。
煙霧包 - 不應超過15分鐘
此包僅包含高級功能，以確保應用程序足夠穩定以進行進一步開發或測試。
例如，對於電子商務網站，此包中包含的測試可能是：
- 產品搜索，
- 產品審覈
- 購買物品
- 帳戶創建/帳戶登錄
完整迴歸包 - 不應超過1小時
此包包含完整的迴歸測試套件，幷包含煙霧包中未包含的所有其他內容。
在這裏，目標是通過更多的測試獲得快速反饋。如果反饋時間超過1小時，則不會很快。通過使用成對測試技術減少測試數量，根據風險創建測試包或並行運行測試。
UAT和探索性測試
沒有理由認爲UAT和探索性測試不能與自動驗收測試並行運行。畢竟，它們是不同的活動，旨在找到不同的問題。UAT的目標是確保開發的功能具有商業意義並對客戶有所幫助。
PO（產品負責人）應運行用戶驗收測試或業務驗收測試，以確認構建的產品符合預期並滿足用戶的期望。
探索性測試應該關注用戶場景，並且應該找到自動化錯過的錯誤。探索性測試不應該找到瑣碎的錯誤，而應該找到微妙的問題。
完成標準
完成上述所有活動並且未發現任何問題後，故事就完成了！
以上是關於敏捷測試策略文檔中可包含的內容的一些指導原則。顯然，這需要根據您組織的需求進行定製，但希望此模板可以幫助您創建自己的敏捷測試策略文檔。