敏捷測試策略

在敏捷環境中，我們在短期衝刺或迭代中工作，每個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計劃會議中，以提供對故事測試的估計。

發展

測試自動化金字塔

開發開始時，新的生產程式碼和/或遺留程式碼的修改應該由開發人員編寫的單元測試支援，並由另一個開發人員或熟練的SDET進行同行評審。

對程式碼儲存庫的任何提交都應該觸發從CI伺服器執行單元測試。這為開發團隊提供了快速反饋機制。

單元測試確保系統在技術級別工作，並且邏輯中沒有錯誤。

開發者測試

作為開發人員，表現得好像您在團隊或組織中沒有任何QA。誠然，QAs有不同的心態，但你應該盡力測試。

您認為通過快速進入下一個故事節省時間，但實際上，當發現並報告缺陷時，糾正問題需要更長的時間，而不是花費幾分鐘來確保該功能正常執行。

遺留程式碼的任何新程式碼和/或重構都應該具有適當的單元測試，這些單元測試將成為單元迴歸測試的一部分。

自動驗收測試和非功能測試

自動驗收測試包括整合測試和服務測試以及UI測試，旨在證明軟體在功能級別工作，並且滿足使用者的要求和規範。

自動驗收測試通常用Gherkin語言編寫，並使用黃瓜等BDD工具執行。

由於這些測試通常需要通訊HTTP，因此需要在已部署的應用程式上執行，而不是作為構建的一部分執行。

非功能測試 （效能和安全性）測試與功能測試同樣重要，因此需要在每次部署時執行。

效能測試應檢查每個部署的效能指標，以確保效能不會降低。

安全測試應檢查從OWASP派生的基本安全漏洞

至關重要的是，這應該是一個完全自動化的過程，只需很少的維護就可以從自動化部署中獲得最大的收益。這意味著不應出現間歇性測試失敗，測試指令碼問題和破壞環境。

故障應僅歸因於真正的程式碼缺陷而不是指令碼問題，因此任何不是由於真正故障導致的故障測試應立即修復或從自動化包中刪除，以便能夠獲得一致的結果。

迴歸測試

不期望發現很多缺陷。他們的目的只是提供我們尚未破壞主要功能的反饋。應該進行非常少量的手動迴歸測試。

煙霧包 - 不應超過15分鐘

此包僅包含高階功能，以確保應用程式足夠穩定以進行進一步開發或測試。

例如，對於電子商務網站，此包中包含的測試可能是：

• 產品搜尋，

• 產品稽核

• 購買物品

• 帳戶建立/帳戶登入

完整迴歸包 - 不應超過1小時

此包包含完整的迴歸測試套件，幷包含煙霧包中未包含的所有其他內容。

在這裡，目標是通過更多的測試獲得快速反饋。如果反饋時間超過1小時，則不會很快。通過使用成對測試技術減少測試數量，根據風險建立測試包或並行執行測試。

UAT和探索性測試

沒有理由認為UAT和探索性測試不能與自動驗收測試並行執行。畢竟，它們是不同的活動，旨在找到不同的問題。UAT的目標是確保開發的功能具有商業意義並對客戶有所幫助。

PO（產品負責人）應執行使用者驗收測試或業務驗收測試，以確認構建的產品符合預期並滿足使用者的期望。

探索性測試應該關注使用者場景，並且應該找到自動化錯過的錯誤。探索性測試不應該找到瑣碎的錯誤，而應該找到微妙的問題。

完成標準

完成上述所有活動並且未發現任何問題後，故事就完成了！

以上是關於敏捷測試策略文件中可包含的內容的一些指導原則。顯然，這需要根據您組織的需求進行定製，但希望此模板可以幫助您建立自己的敏捷測試策略文件。