Scrum 團隊測試策略的最佳實踐

Scrum 減去測試計劃等於類固醇的 POC。

如今，大多數成功的項目都是從概念驗證 (POC) 開始的，這是對一個想法的相對較小規模的評估，其中首先驗證所選的技術和功能包，評估對業務用戶的潛在影響，然後，一旦證明值得投資，一個完整的項目團隊被分配來設計和交付功能齊全的產品並將其部署到生產中。

這是 Scrum 團隊的完美案例。 團隊可以快速開發原型，在每個衝刺中添加大量新功能，而業務用戶可以實時觀看快速進展以及如何在大約 10 個衝刺內從頭開始構建想法。 它給人留下了深刻的印象（無論如何這是 POC 的主要目標），但它也有一個重要的屬性——測試活動最少或沒有，甚至考慮測試過程都會是一個直截了當的笑話。

在 Scrum 團隊中，這不是什麼有趣的活動，人們大多喜歡在沒有流程的情況下進行開發的想法，這會減慢他們的速度。 這基本上是任何測試活動都會隱式執行的操作。 在我們最需要給最終用戶留下深刻印象的時候，誰想要不必要的緩慢？

如果項目團隊在 POC 期結束後以相同的方式繼續進行，則會發生這種情況，我將其稱為POC on steroids – 生產系統的規模和功能不斷增長，但仍然表現得像 POC – 一個 wannabee 完整的產品隱藏的缺陷和未探索的角落案例，只等待嚴重的崩潰。

但在它轉換到那里之前，團隊將很難從 sprint 到 sprint 跟上穩定版本，因為修復滾動問題只會變得更加複雜。

這裡有一些技術在我處理類似問題時被證明是有效的，我相信它們可以被命名為實施可靠測試過程的最佳實踐，仍然不會過多地擾亂開發進度——因為這是我們所有人都希望成為的一個 Scrum 團隊。

分散痛苦

在處理不必要的麻煩時，除了分擔痛苦，我們還能從哪裡開始 :)。

我的意思是製定一個計劃，該計劃將需要開發人員在各處進行少量的額外活動，但隨著時間的推移，這將以漸進但始終如一的方式為共同目標做出巨大貢獻。

#1。 為每個創建的新代碼開發單元測試代碼

如果你設法說服你的 scrum 團隊在其“完成定義”子句中為衝刺中創建的每個新代碼添加單元測試開發，那麼從長遠來看，這將是一項偉大的成就。

原因很明顯：

它將迫使開發人員思考代碼的各種非標準路徑。 –

• 這樣的單元測試可以插入到自動化的 DevOps 管道中，並在每次部署到開發或測試環境時執行。 此外，管道中的指標可以輕鬆導出，然後用於向業務用戶演示直接綁定到源代碼的測試用例的覆蓋百分比。

最重要的是盡快開始。 單元測試開始開發的時間越晚，開發人員在衝刺中添加它們的注意力就越分散。

• 為已經存在的代碼向後開發單元測試需要付出很大的努力。 代碼的某些部分可能是由其他開發人員創建的，並且當前開發人員並不完全清楚它在每個代碼部分中應該如何工作的確切知識。 在某些情況下，到目前為止，向修改後的代碼添加單元測試比為衝刺開發功能更改花費更多的時間（這是在衝刺計劃期間肯定沒有人計算的狀態）。

#2。 制定在開發環境中執行單元測試所有部分的例程

即使在創建將新代碼合併到 Master 分支的拉取請求之前，在開發環境中測試功能代碼和單元測試代碼也應該是一項標準活動。 通過這樣做，將確保：

• 單元測試代碼實際上對每個部分都起作用（最終它只是另一個必須驗證的代碼）。 這一步經常被完全跳過。 以某種方式假設，如果單元測試以任何方式插入到 DevOps 管道中，它最終將默認在某處執行和測試。 然而，這只不過是將問題推向了衝刺活動的更高層次，團隊通常沒有更多的時間和更多的壓力來完成每個提交的故事。
• 開發人員對新功能代碼進行了基本功能測試。 顯然，不能期望從該測試中完全驗證業務功能，但至少該測試將確認代碼按照開發人員預期的方式運行（暫時忽略業務邏輯可能在開發過程中被錯誤理解）。

#3。 期望代碼合併到主分支後執行單元測試

在本地分支上擁有功能代碼（除了分支所有者之外沒有人在開發新功能）是一回事，但是在拉取請求之後讓相同的代碼工作並合併到主分支中是完全不同的事情。

master 分支包含其他 Scrum 團隊成員的更改，即使解決了衝突並且一切正常，合併和衝突解決後的代碼基本上仍然是未經測試的代碼，不先驗證就繼續發送是有風險的它仍然工作正常。

因此，這裡被證明有效的只是簡單地要求執行相同的單元測試——之前已經在開發環境中完成——也在從主分支代碼版本構建的環境中執行。

對於開發人員來說，這可能是他們需要在生活中加入的一個額外步驟，但這並沒有那麼大的努力，因為在這種情況下，不必發明任何新東西——只需重新執行已經做過的事情。

現在，在一個特定情況下可以跳過此步驟：

• DevOps 管道中的自動化單元測試非常全面，它們已經涵蓋了在此之上執行的整個手動測試。

雖然達到這種狀態絕對是可行的，但我在現實生活中從未經歷過這樣的狀態。 對於開發人員來說，創建如此詳細的自動化單元測試可能太費時了。 產品負責人很容易無法接受讓團隊在這項活動上投入如此多的時間，因為這會對沖刺中交付的故事數量產生明確的影響。

但是，對 sprint 內容的偏好永遠不應成為不進行單元測試甚至最小化單元測試的藉口。 通過這樣做，團隊將再次轉換到代碼缺乏太多單元測試覆蓋率的狀態，然後要趕上來，可能已經太晚了（同樣，完成單元測試的工作量比實際的工作量更大）衝刺的代碼更改）。

出於所有這些原因，我建議毫不猶豫地在主代碼版本上重新執行單元測試。 與它將帶來的價值相比，這是一個如此低的努力。

它將對發布測試階段的主分支準備情況進行最終檢查。 此外，這將有助於發現大部分技術錯誤（例如，阻止源代碼成功執行直到成功結束的錯誤），留給下一階段專注於業務功能的驗證。

準備功能測試

所有先前的測試活動都應得出一個特定的結論——主分支代碼沒有技術錯誤，並且端到端功能流的可執行性沒有問題。

這是一個一個人就可以輕鬆搞定的階段，這個人甚至不需要有技術背景。

實際上，如果這由與開發人員脫節但具有業務用戶期望代碼行為的功能意識的人執行會更好。 有兩個主要活動需要完成：

#1。 新的衝刺故事有針對性的功能測試

理想情況下，每個衝刺都應帶來一些以前不存在的新功能（衝刺目標增量），因此應對其進行驗證。 重要的是要確保新軟件的工作達到業務用戶現在樂於擁有它的程度，因為他們顯然至少在整個最後一個衝刺中都期待它:)。

當（長期）承諾的功能最終宣布發佈時，這真是一種悲傷的經歷，前幾天才發現它實際上不能正常工作。

因此，正確測試新的 sprint 功能至關重要。 為了使其成功，最好提前收集重要的測試用例並從相關利益相關者（來自產品所有者甚至最終用戶）收集，並列出其中內容所需的所有此類測試用例衝刺。

乍一看，這可能讓人不知所措，但根據我的經驗，它又完全可以由一個人來管理。 由於衝刺大多很短（比如兩週的時間），所以它幾乎從來沒有太多的新內容，因為衝刺還包含其他活動，如技術債務故事、文檔、設計/尖峰故事等。

然後執行測試用例，目的是首先驗證所需的功能。 如果結果出現任何問題，只有相關的開發人員（擁有與此特定缺陷相關的更改的人）希望盡快解決問題。

這樣，開發人員將花最少的時間進行功能測試，並且仍然可以專注於他們最喜歡的活動。

#2。 回歸測試用例執行

功能測試的另一部分應該是確保到目前為止一切正常的工作在下一個版本之後也能正常工作。 這就是回歸測試的目的。

如果在每次發布之前定期維護和重新訪問回歸測試的測試用例，則它們是最好的。 根據具體的項目細節，最好使它們保持簡單，但要涵蓋貫穿整個系統的大部分核心功能和重要的端到端流程。

通常，每個系統都有涉及許多不同領域的流程，這些是回歸測試用例的最佳候選者。

在某些情況下，回歸測試甚至還隱含地覆蓋了衝刺中的新功能，例如，如果衝刺中的新故事正在改變現有流程的某些特定部分。

所以在大多數情況下，完成回歸測試和新的 sprint 故事功能測試並不復雜，特別是如果在每個產品發布之前定期完成，並且產品發布的周期不是太小。

堅持在每次產品發布前執行質量保證測試

質量保證 (QA) 測試是發佈到生產環境之前的最後一步，而且通常會因為不重要而跳過該測試。 特別是如果 scrum 團隊針對新內容進行了積極的管理。

甚至業務用戶也會說他們對新功能感興趣，而不是對保留功能或保持低缺陷數量感興趣。 但話又說回來——隨著時間的推移，這就是開發團隊最終不得不放慢速度的主要原因，然後業務用戶無論如何也得不到他們想要的東西。

QA 測試應僅由 Scrum 團隊以外的人員執行，最好由業務用戶自己在專用環境中執行，該環境盡可能接近未來的生產環境。 或者，產品所有者可以在這裡替換最終用戶。

無論如何，從最終用戶的角度來看，這應該是一個乾淨的功能測試，與開發 Scrum 團隊沒有任何联系。 它將呈現產品的最終視圖，並可能以 Scrum 團隊中沒有人預料到的方式使用（根本不是理想情況，但它肯定會發生）。 還有時間進行最後的修正。

或者，很明顯 Scrum 團隊沒有很好地理解期望，在這種情況下，至少我們可以在實際生產發布之前就後續計劃達成一致。 這又不是一個理想的情況，但仍然比在報告成功的產品發布後立即承認失敗要好得多。

從這裡下一步去哪裡？

將這些實踐應用到日常 scrum 工作中可以真正讓你養成更穩定和可預測的 sprint 發布習慣，而不會延遲生產發布或花費整個 sprint 只是為下一個發布做準備，甚至不需要強迫 scrum 團隊中的每個人做他們不做的事情也就是說，在大部分衝刺中，我真的不喜歡或不知道如何有效地完成。

但你肯定不需要在這裡停下來。

性能測試包含是這裡要提到的一個主題。 這些通常被忽略或被認為是不必要的，在第一輪“scrum 活動優化”中被淘汰。 然而，我一直懷疑如果不定期檢查性能，人們如何期望生產系統隨著時間的推移而發展。

更上一層樓也意味著引入自動化測試。

我已經涵蓋了一組自動化測試（管道中的單元測試）。 但是，您可以開發完全自動化的完整端到端回歸測試，並在每次部署到測試環境後自行執行。 這將進一步解放開發 scrum 團隊，但需要專門的團隊來開發和維護此類自動化測試。 這將成為持續不斷的工作，因為每當生產代碼發生變化時，一些現有的自動化測試就會變得無效，因此必須更新它們才能繼續在管道中工作。 只有少數人願意為此付出努力，但開發 Scrum 團隊的好處是巨大的。

這些主題遠遠超出了本文的範圍，並為此處提到的每種測試類型確定了正確的時間表和時間安排，以便您可以在衝刺窗口內完成。 下次我會很樂意潛水！