您有全面的測試策略嗎？讓我們看看反應式測試出錯的地方，以及用於全面E2E測試的更好測試哲學。
在所有經典街機遊戲中，Whack-A-Mole可能是最令人沮喪的。您無法贏得Whack-A-Mole的遊戲。每當您認為自己撞上痣時，小流氓總是會找到一種方法可以在其他地方再次彈出，而您總是落後一步。
在端到端測試的世界中，當我們對生產中彈出的錯誤進行反應性編寫測試以防止它們再次出現時，我們可能會陷入Whack-A-Bug的困境。我喜歡稱這種練習為Whack-A-Bug測試，因為它是一種通用方法，但很容易成為一個無休止的循環，測試人員始終落後一步。作為我們組織的領導者，我們必須想出如何向前邁出一步，致力於開發更勇敢，具有遠見的E2E測試策略。
為什麼Whack-A-Bug測試如此常見
質量保證團隊生活在一個令人羨慕的世界中：除非出現問題，否則他們的工作基本上不會被注意。然後，他們面臨解釋他們不進行測試的決定的決策，特別是如果結果要花費組織金錢的話。我們聽到過很多次，“為什麼沒有對此進行測試？” 不管是什麼原因造成影響收入的錯誤，如果質量檢查“未能”確保質量，則公司的其他領導者可能會對其加以譴責。因此，質量檢查負責人和工程師承受著巨大的壓力，需要他們防止錯誤並確保相同的錯誤不會多次出現在生產中。
在共同創建ProdPerfect之前，我曾與工廠進行過一些諮詢工作。煉油廠之類的業務部門可以清楚地跟蹤與收入和成本直接相關的指標，因此可以相當容易地做出與投資回報率相關的決策。在煉油廠中，您可以輕鬆地衡量每天生產多少桶石油，從而優先考慮進行哪些投資以增加該日產量。許多工廠對他們的行動沒有看到ROI，而對工廠中發生的最新問題做出反應。但是，當他們確實承諾將工作重點放在高投資回報率改進上時，衡量結果就相當容易。
當您衡量組織內軟件質量檢查的性能時，您無法衡量以桶為單位的六個工時代碼。測試代碼的價值並不一致，並且每次更新對業務的影響都不同（好壞）。由於存在這種差異，很難解決多個相互競爭的優先事項：我們如何在不犧牲速度的情況下交付價值和質量？衡量速度，價值和質量的過程不夠清晰，使工程師無法獲得清晰的ROI協議和統一的生產率KPI。
儘管衡量工程性能的工作具有挑戰性，並且在組織上通常還不清楚，但是對於工程師來說，執行的壓力仍然存在。而且，由於質量檢查團隊通常會受到這種壓力的首當其衝，因此，質量檢查領導者經常被迫在其E2E測試策略中採取被動態度進行操作。換句話說，由於缺乏明確的優先級度量標準，許多團隊都選擇打Whack-A-Bug進行測試以安撫整個組織。在測試中堅持高投資回報率計劃很困難，但與煉油廠一樣重要。
Whack-A-Bug測試的謬誤
為了挑戰這種做法，我們作為領導者首先需要自問：在應用程序的某個部分中漏入的錯誤是否會增加在同一位置再次發生錯誤的可能性？我喜歡思考賭博中類似但普遍存在的謬論：如果您將老虎機拉了六次卻沒有中獎，這是否意味著下次您提起老虎機時，中獎的可能性更高？儘管我們的膽量可能會告訴我們其他方式，但這兩個問題的答案最終都沒有。
Whack-A-Bug測試的謬誤是假設，如果我們在以前看到錯誤的位置創建另一個測試，則比在其他地方編寫該測試更安全。根本不是因為錯誤發生在某個區域，所以隨之而來的是，該錯誤再次發生在該區域的可能性增加了。Whack-A-Bug測試不是一種主動的測試策略：Whack-A-Bug測試不會將測試添加到最需要測試的應用程序區域。相反，這是一種被動的策略：我們正在測試某個區域，以應對在那裡看到的錯誤。上週出現錯誤的事實並不會改變我們組織對高優先級區域進行測試的組織重點：這些區域更可能產生錯誤，對客戶使用很重要或直接影響收入。
為什麼Whack-A-Bug測試傷害最大的是幫助
Whack-A-Bug測試傷害工程組織的原因有幾個：
- 它使我們無法編寫優先級高的測試。在生產中出現任何錯誤之前，QA團隊已基於某種優先級排序機制制定了測試對象的策略。當我們編寫Whack-A-Bug測試時，我們會將測試寫資源從其他優先級劃分機制轉移到Whack-A-Bug測試中。結果，我們延遲了編寫未來的高優先級測試的時間。
- 它給您的團隊增加了維護負擔。Whack-A-Bug測試會降低您的團隊編寫未來的高優先級測試的能力。每次編寫E2E測試時，您都致力於維護該測試。這將產生固定的，不可避免的持續工作水平，從而降低您用相同數量的工程師編寫更多測試的能力。我見過的大多數團隊都試圖通過簡單地僱用更多人來彌補這一點。
- 這會減慢顯影劑的生產率和速度。在連續交付過程中，每個新的E2E測試都會增加測試套件的運行時間，從而延長您的迴歸週期。如果您的測試套件需要花費半小時的時間來運行，並且每次提交都在運行，則意味著1）開發人員在這段時間內不生產任何東西，或者2）您的開發人員較少簽入代碼，因為他們沒有不想等待測試運行（或同時運行）。在這兩種情況下，您都將失去開發人員的工作效率，併為每個構建版本提供較少的質量反饋，這意味著每次Whack-a-Bug增量測試都會消耗開發人員的速度。
- 它會使您的測試套件膨脹，並增加不穩定性。在某個時候，您的測試套件將變得足夠大，以至於很有可能由於不穩定而在給定的運行中失敗。一旦不穩定達到一定的臨界值，測試套件就會頻繁失敗，以至於開發人員不再關注。發生這種情況時，它開始提供負值：增加部署運行時間而不增加質量。
修復Whack-A-Bug測試的損壞
我們如何扭轉Whack-A-Bug測試的損害？首先，我們的組織需要通過空白練習重新檢查我們的測試選擇。我們必須自問：如果我們要重新從頭開始制定這項策略，我們的測試重點是什麼？我們將測試什麼以平衡測試覆蓋範圍與速度，維護負擔和穩定性？定義了最適合我們進行測試的內容之後，我們需要將該前景覆蓋在當前正在測試的內容上。這是困難的部分：我們需要有勇氣關閉與該策略不符的測試。我們需要繼續前進。
在此過程中，一個有用的幫助是評估套件中已有6個月或更長時間的測試並進行檢查：最近6個月中是否捕獲了任何錯誤？如果沒有，您的團隊應該強烈考慮退休，因為他們可能不值得優先考慮。除非您致力於測試各種可能的行為排列，否則必須重新設置優先級。通過此練習，我們瞭解到，大多數Whack-A-Bug測試實際上從未捕獲到錯誤。面對組織的政治壓力，Whack-A-Bug測試可能會給我們短期的安慰。但是，當我們讓數據說話而不是人為衝動時，我們發現在絕大多數情況下，編寫Whack-A-Bug測試幾乎沒有提供任何實際的商業價值。
最終，從頭開始制定新的測試策略以突出您最重要的優先事項，這將釋放您的開發人員和質量檢查資源，以正確涵蓋對您的業務真正重要的內容。好處是三方面的：1）更好的質量，2）更好的速度和成本，以及3）測試套件中開發人員的信任度更高。
分享對更好的質量檢查的承諾
許多QA團隊訴諸Whack-A-Bug測試，因為他們承受著應對產品質量問題的壓力。只有當我們組織中的所有領導者都共享並履行堅持團隊QA策略的承諾，而不是在每次出現問題時都m之以鼻時，更好的QA做法才有可能。
首先，對於工程和產品負責人，與質量檢查負責人一起認識到Whack-A-Bug測試不一定能改善質量保證至關重要。我們必須瞭解，某個地方出現的錯誤並不一定會改變測試內容的優先級。我們的領導者必須堅持在速度，生產率和質量保證之間建立明確的權衡機制的承諾。每個組織的權衡都是不同的，並且會隨著時間而變化，但是在任何給定時間都必須保持神聖。當我們看到代碼中的錯誤時，我們需要承諾：“我們需要重新考慮我們的戰略，還是可能需要重新考慮我們的折衷點？我們是否在優先考慮正確的方法？我們是否在正確地做出承諾？可接受的測試水平看起來如何？我們的測試方法將如何過度負擔我們的團隊？”
在ProdPerfect，我們彼此的承諾是我們在確定質量檢查優先級時不會做出反應。我們邀請您加入我們的承諾中：我們不會因膝下意識的反應而立即對每個錯誤進行測試。相反，我們將從錯誤中學習。我們將通過監督漏洞在何處滑出以及它們所造成的損害，在一段時間內對它們進行評估。然後，我們將做出以數據為依據的決策，以告知我們的測試策略。我們將共同承擔更改測試策略的後果和成本。但是，我們不會通過測試方法來對Whack-A-Bug做出反應。
做出這一承諾需要所有人的組織紀律和勇敢的領導。我們所有的領導者都必須同意將質量保證視為一種夥伴關係，在這種夥伴關係中，組織需要有效地平衡其測試優先級並確定業務的最佳覆蓋範圍。我們每個人都能從做出這樣的承諾中受益，我邀請您與我分享這一承諾。與其通過被動的Whack-A-Bug測試來加重我們的流程和團隊的工作量，不如讓我們通過主動思考並讓數據獨自推動我們的測試策略來對它們進行良好的照顧。
閱讀更多 一名小白人員 的文章
