如何從測試自動化中實現價值

如果幾年前，質量管理部門都試圖透過ROI指標來證明對測試的投資是合理的，那麼現在情況發生了變化，是時候重新審視這個問題了。當實施連續測試，並且每天在不同的環境下以不同的角色執行多次測試自動化時，由於測量方法與以前大不相同，因此ROI成為不合時宜的術語。試圖衡量和證明測試投資合理性的未來5-10年的關鍵術語應該是VALUE。

連續測試的目的

在說明投資回報率一詞之前，讓我們先設定一下現代測試自動化尤其是連續測試的目標。

在敏捷測試宣言中，我用粗體標記了此類測試背後的關鍵價值。

持續測試超過在種種環境進行測試。

擁抱所有的測試活動而不僅僅是在自動化功能測試。

在整個團隊中進行測試，而不是在孤立的測試部門中進行測試。

產品覆蓋率超過程式碼覆蓋率。

如果要應用上述方法，則此類測試的主要目標是透過整個團隊對產品進行的高價值測試以及整個測試型別（功能性和非功能性）來識別業務風險。在上面的陳述中，除了測試的值之外，沒有任何度量或量化方法。

連續測試的關鍵支柱

為了實現連續測試， 組織應著重於內部建立測試自動化的能力，並在可靠的實驗室中以及一天結束時按需大規模執行它，或者使用智慧方法分析結果以使測試有意義量化的結果資料。

如果上述支柱符合組織的測試策略和優先順序，則用於建立和執行測試的工具和技術將相匹配是有具有非常重要的意義的。

這裡最大的問題是：我該如何證明在上面的提到的方面進行的投資？有哪些相關措施？每個步驟中誰都擁有什麼樣的權利？什麼樣子才是正確的？

從投資回報率到測試價值

為了解決上述問題，讓我們確定誰在當今的敏捷和DevOps實踐中進行測試。 提供高質量和高價值的軟體是功能團隊的責任。考慮到這一點，將業務測試人員，開發人員和測試自動化工程師一起工作，並建立自動化測試方案以及手動探索性測試以實現其目標。雖然可能有現代化的COE或質量領導職能來監督組織內部的測試策略，確定預算和工具，但實際工作實際上是在團隊內部完成的。

如果您與我一致認為價值是測試中最重要的事情，那麼讓我們嘗試將價值分解為度量：

週期內的測試數量

重複發現缺陷的測試數量

導致CI作業失敗的測試數量

因根本原因（物件ID，實驗室，編碼技能，平臺狀態等）分類失敗的測試數量

儘管還有其他指標， 但上面的指標清楚地表明瞭測試實際上是否符合他們期望的發現錯誤，或者僅僅是在製造麻煩和軟體團隊浪費。

從一些市場標準來看，每個KLOC（1000行程式碼）平均存在10-15個缺陷，每個KLOC都有0.5個缺陷逃到生產中。如果遵循這個數字，很明顯，現在發現和報告的絕大部分的缺陷都是誤報。要在連續測試中取得成功，需要有紀律和對價值的正確衡量，以確保報告為錯誤的大多數失敗測試確實存在問題，相反的情況會在整個DevOps團隊中造成混亂。

考慮到這一點，團隊必須承認測試質量和產品質量是及時的事實，因此，您需要不斷地對其進行測量和維護，以獲取產品的實際狀態。

如何實現比價值？

長話短說，在測試生命週期中，只有一個地方可以提供整個測試活動的價值，這就是測試報告！

如果您從編寫程式碼的那一刻起就考慮到測試的整個生命週期，包括除錯，執行和提交到現行中，那麼開發人員（無論可能是誰）都會在測試“透過”之時告別測試。在他的環境中。只有在正式測試周期中測試失敗（可能是CI，其他事件觸發的迴歸等）時，測試所有者和測試之間的團聚才會發生。這意味著，從測試整合到套件直到失敗為止，都有一個盲區。除了對測試感到滿意以外，沒有真正的理由來複盤它（如果它當然是一項高價值的測試）。現在，考慮一下一組1000個平均失敗率為10％的測試案例。這意味著我們現在有100個失敗的測試場景，需要有人審查和報告。每KLOC 10-15個缺陷，事實表明至少有80％的測試不是真正的bug。該團隊現在必須處理80個測試用例的除錯，這些除錯可能會也可能不會增加產品的價值。

我認為到目前為止，這一點很明確–> 測量測試自動化值是從上述指標開始的，並且大多數測試用例的概念在以10倍的時間作為迴歸執行時都不會揭示關鍵的錯誤。要了解哪些測試可以增加價值，什麼沒有增加價值，什麼僅僅是誤報和不穩定的軟體工程，您需要對測試活動的每個領域都具有適當的測試報告和質量可視性。

底線–投資時間，即金錢的資源，應牢記這些測試的附加值。每個週期使用老式的透過/失敗測試效果不錯，但無法跟上當今技術的步伐，因此，需要對測試如何實時，隨時間，針對每個平臺，針對每個功能區域進行更認真的檢查。不要太依賴您的測試程式碼，如果短時間後仍不能證明自己，只需刪除它即可。您只能透過報告評估測試是否帶來了價值。