敏捷專案測試策略文件模板
在一個敏捷工作環境種，我們的研發工作以衝刺期和高度迭代的形式展開。每一個迭代週期都關注少數的需求或者使用者故事，所以在文件在敏捷專案種的數量和內容方面都傾向於輕量化。
對於測試計劃這樣的文件也是如此，不過我們也確實需要為敏捷團隊去提供一個概要的敏捷測試策略，以供指導。
敏捷測試策略文件是為了給團隊提供一個最佳的測試實踐和一些形式的測試體系。記住，敏捷並不意味著沒有體系。
下面我們來看一個敏捷測試策略文件，看看我們都應該包含些什麼內容。
1. 一份測試策略中通常都會對於更寬泛的商業目的和目標做出任務說明。
一個典型的任務說明可以是：
“通過快速反饋和缺陷預防，持續的交付可工作的，滿足使用者需求的軟體，而不僅僅是缺陷發現”
細化以後：
“● 在定義完需求的接收條件/測試之後，程式碼才能進行編寫。
● 接收測試不通過，一個需求就不能被判斷為完成。”
在敏捷專案中，通常還會包含關於質量保證的提示：
● 質量保證是系統和可靠的保證產品滿足使用者需求的一系列活動。
● 在SCRUM（敏捷）中，質量保證是所有人的責任，而不單單是測試人員。在我們開發新產品的過程中，我們通過質量保證活動來確保正確的質量。
2. 測試級別
2.1 單元測試
WHY: 確保程式碼被正確開發
WHO: 開發工程師/技術架構師
WHAT: 所有新程式碼+歷史程式碼的重構+javascript單元測試
WHEN: 一旦有程式碼被編寫
WHERE: 開發本地環境+持續整合環境
HOW: 自動化, Junit, TestNG, PHPUnit
2.2 介面測試
WHY: 確保組建之間的互動正常工作
WHO: 開發工程師/技術架構師
WHAT: 新的web services, 元件, 控制器, 等
WHEN: 一旦新介面開發準備完畢
WHERE: 開發本地環境+持續整合環境
HOW: 自動化, Soap UI, Rest Client
2.3 接收測試
WHY: 確保使用者需求已達成
WHO: 開發/測試開發工程師/手工測試
WHAT: 對需求進行接收測試，驗證產品特性
WHEN: 當產品特性已被開發完成並通過單元測試
WHERE: 持續整合環境/測試環境
HOW: 自動化(Cucumber)
2.4 系統測試/迴歸測試/使用者接收測試
WHY: 確保系統整體整合後工作正常
WHO: 測試開發工程師/手工測試/商務分析/Product Owner
WHAT: 場景測試，使用者流程和典型使用者旅程，效能和安全測試
WHEN: 當接收測試完成後
WHERE: 預生產環境
HOW: 自動化(Webdriver) ，探索性測試
3. 產品代辦列表
軟體開發失敗最常見的原因，是因為需求的不明確和團隊不同成員對需求的不同解讀。
使用者故事應該簡單，精煉避免含糊不清。做為一個好的指導，在編寫使用者故事時最好遵從INVEST模型。
一個好的使用者故事應該：
獨立(與其他的故事)
可討論(不是某個軟體特性的具體協議)
有價值的
可估算的
體積小(可被一次迭代完成)
可測試
編寫使用者故事時應該遵從以下格式：
做為一個[角色]
我想要[功能/特性]
來[達成什麼目標]
注意不要遺忘“達成目標”部分，這樣所有人都知道開發這個需求的時候我們為產品增加了什麼價值。
接收條件：
每個使用者故事必須包含接收條件。這也許是最重要的要素，它能促使團隊成員就需求進行交流。
接收條件應該在使用者故事編寫的同時被定義完成，並且應被包含在故事內。所有的接收條件必須是可測試的。
每個接收條件應該展示一些接收測試範例，可以是使用Gherkin格式撰寫的一些場景，比如：
場景1: 標題
Given[上下文/背景]
And[更多條件]...
When[事件/動作發生]
Then[產生結果]
And[更多結果]...
4. 開發測試
做為開發，我們應該表現得像組織內不存在測試人員一樣去開展工作。確實QA會有不一樣的測試思維，但是開發也應該盡其所能的去測試。
開發可能認為儘快的去進行下個需求的開發是節省了自己的時間，但是在實際中，如果一個缺陷被發現並且報告了，比起在開發階段去驗證功能是否正常工作要花去你更多的時間。
任何新開發的程式碼和對於歷史程式碼的重構都應該有足夠的單元測試，這些單元測試應該是單元迴歸測試的一部分。
5. 自動化接收測試和非功能性測試
自動化接收測試包括整合測試和服務測試以及使用者介面測試，目標是確認軟體在功能性上工作正常，並且滿足使用者的需求和規格。
自動化接收測試可以採用Gherkin語言編寫，使用類似於Cucumber的BDD工具來執行。
記住：並不是所有測試都要實現自動化！
非功能性測試（效能和安全性等）與功能性測試是同等重要的，所以在每次部署時需要被測試。
效能測試應在每次部署時關注系統性能指標，防止系統性能滑坡。
應使用OWASP來確保系統的基本安全性指標。
重要的是這些應該是完全自動化的流程，不需要太多維護工作，結合自動化構建部署來達到最佳收益。這意味著不能有間歇性測試失效，測試指令碼問題和環境問題。
任何失效都應該是真實的程式碼缺陷而不是指令碼問題，所以任何不是由於真實程式碼缺陷引起的問題都應該被立即從自動化包裡修復或移除，這樣可以得到持續性結果。
6. 迴歸測試
我們不期望在迴歸測試中發現很多缺陷。迴歸測試的目的是提供反饋，讓我們確定重要功能未被破壞。手工迴歸測試工作量應該很低。
冒煙測試 - 不應超過15分鐘
冒煙測試包僅包含重要的功能，以確定產品對於後續開發和測試工作而言是足夠穩定的。
例如，對一個電子商務網站，冒煙測試應該包括：
- 商品搜尋
- 商品檢視
- 商品購買
- 註冊/登入
整體迴歸測試 - 不應超過1個小時
整體迴歸測試包，包含了所有的迴歸測試用例以及在冒煙測試中沒有涵蓋的內容。
在這裡，我們的目標是得到更大體積測試的快速反饋。如果這種反饋超過1個小時，那麼就不夠快速。要麼我們可以使用結對測試的方法來減少測試數量，要麼根據風險來排序測試，要麼讓測試併發執行。
7. UAT和探索性測試
UAT和探索性測試沒有理由不能與自動化測試一起執行。畢竟，他們是不同的測試活動，關注於不同的測試目標和問題。UAT的目標是確保開發的功能/特性對於客戶而言是商務上合理的且有幫助的。
產品所有者（PO）應該執行使用者接收測試（UAT）或者商務接收測試，以確定產品滿足使用者期望。
探索性測試應該關注於使用者場景，並且找到自動化測試遺漏的問題。探索性測試應該發現瑣碎問題而不是大問題。
8. 完成標準
一旦所有以上活動都完成了，並且沒有發現問題，那麼需求就完成了。
以上是對於一個敏捷測試策略文件可以包含內容的指導。顯然當你用於自己的專案和組織時是需要進行調整的，但是希望，這個模板可以幫助你去建立自己的敏捷測試策略文件。
譯自：https://www.testingexcellence.com/agile-test-strategy-example-template/