像許多奧地利人一樣，我喜歡“上坡滑雪”——在滑雪板上套上滑雪皮，徒步上山，也許休息一下，喝點舒服的飲料，然後滑下來。這需要攜帶一定數量的裝備。即使在低風險的情況下，你也需要一個包，裏麵有你的護目鏡，一個急救箱，一張地圖，額外的保溫層，水，一些食物，也許還有一個小的頭燈。對於一個更偏遠/崎嶇的地方，你可能想要增加你的食物供應，加上一個雪崩收發器，鏟子，雪探頭，和類似的東西。
這是一種微妙的平衡。你不想跳過你可能真的需要的東西——例如，萬一你被雪崩困住了。但是，如果您帶太多，您將無法達到所需的速度和敏捷性。在最壞的情況下，你的背包很重，一件東西太多，另一件卻不夠——讓你同時措手不及，負擔過重。
這就是大多數企業組織在軟件測試方麵的立場:測試太少和太多都是有罪的，過度暴露在風險中，無法快速轉向。讓我來解釋一下……
自定義應用程序:太多的測試
大多數“定製的”自定義應用程序實際上都被過度測試了。當測試外包給服務提供商時，過度測試尤其普遍，而服務提供商的報酬取決於定義和自動化測試的數量。這種情況經常發生，它導致公司為產生有限商業價值的測試支付過高的費用。
當通過測試人員生成的測試數量來衡量測試人員時，您得到的測試往往比實際需要的測試多得多——並且由於所有這些測試都在創建、執行和更新，發布常常會延遲。這就是為什麼測試通常被引用為應用程序交付過程中的頭號瓶頸的主要原因之一。更糟糕的是，您通常不會得到正確的測試。你會得到很多測試，一遍又一遍地檢查相同的東西。
如何解決這個問題?采用一種新的測試方法:關注業務風險覆蓋率，而不是測試用例的數量。
你可能聽說過80/20法則(也就是帕累托法則)。最常見的是，這指的是20%的努力創造80%的價值。軟件開發相當於20%的事務代表80%的業務價值……20%的需求測試可以覆蓋80%的業務風險。
即使測試人員真的試圖覆蓋您的主要業務風險(而不是僅僅創建一定數量的測試)，獲得正確的測試也不容易。直觀地說，大多數團隊隻實現了40%的風險覆蓋，並最終積累了一個具有高度冗餘(又稱“膨脹”)的測試套件。平均而言，67%的測試沒有對風險覆蓋做出貢獻——但它們使測試套件執行緩慢且難以維護。回到我們最初的類比，這就像在背包裏除了水什麼都沒有裝。這比你在雪地裏可能需要的水要多，而且這些水占據的空間和重量本可以更好地分配給食物和額外的保溫層等必需品。
如果“業務”為測試人員提供了應用程序功能如何映射到業務風險的準確評估，那麼測試人員就可以非常有效地覆蓋這些風險。這是一個巨大的未開發的機會，可以使測試更快、更有影響力。如果測試人員了解風險是如何在應用程序中分布的，並且知道哪20%的事務與那80%的業務價值相關，那麼就完全可以在不進行過高的測試投資的情況下覆蓋最高的業務風險。
一旦明確了真正需要測試的內容，下一步就是確定如何盡可能高效地進行測試。正如並非所有的需求都是被創建的一樣(從風險的角度來看)，為驗證這些需求而創建的測試也是如此。一個單一的戰略設計的測試可以達到與其他10個為相同需求“直觀地”設計的測試一樣多的風險覆蓋，如果不是更多的話。
這就是測試用例設計方法的用武之地。通過有效的測試用例設計策略，例如線性擴展，測試人員可以盡可能有效地測試最高風險的需求。他們被引導進行盡可能少的測試，以達到您的風險覆蓋目標和2)確保當測試失敗時，團隊確切地知道要調查什麼應用程序功能。
當涉及到定製應用的測試時，越少越好。為團隊和涉眾帶來更多價值。花更多的時間按時實現測試，這樣您就可以按時發布。當項目進程發生變化，測試套件需要進行重大更新時，還會有更多的靈活性。
像SAP和Salesforce這樣的打包應用就屬於過度測試-測試不足的另一端。測試SAP企業應用程序更改最常見的策略是什麼——是自定義更新、服務包還是緊急修複?完全不要測試更改!
打包應用程序:沒有足夠的測試
好吧，也許這並不完全準確。大多數組織都會對打包的應用程序進行一些測試。當需要將更新部署到生產環境中時，他們讓關鍵用戶對其進行測試。
但你猜怎麼著?關鍵用戶不喜歡測試。測試打包的應用更新通常是一個漫長的手工考驗。業務流程測試可能已經過時——或者更糟，沒有文檔記錄——這使得測試過程令人沮喪且容易出錯。而且這些測試任務在關鍵用戶本已繁忙的日程安排之上堆積如山。一些關鍵用戶向我承認，為了加快進度，他們主要測試他們知道會通過的用例。他們的策略是:“我們測試綠色!”
當然，這些對運營團隊來說都不是新聞。為了解決缺乏有效的預發布測試的問題，他們通常會添加一個”更新上線後的Hypercare階段。Hypercare是一種“全員出動”的時期，在此期間，組織最昂貴的資源(通常是開發人員和項目人員)被安排待命，以解決生產中突然出現的緊急問題。需要明確的是——這些都是在預發布測試中沒有發現的問題，如果在預發布測試中修複這些問題會更容易、更便宜!因為超護理階段是如此普遍，而且如此昂貴，所以有一些公司專門為客戶提供超護理支持。
超過90%的SAP企業客戶選擇這種部署策略，它既耗時又昂貴。關鍵用戶測試通常持續一到兩周。一個過度護理階段可以持續三個月，在此期間，由缺陷引起的大部分負擔由——你猜對了——那些糟糕的關鍵用戶感受到。
對於大多數依賴關鍵用戶測試+hypercare來測試打包應用的組織，我有一個壞消息，也有一個好消息。首先是壞消息。SAP(以及其他打包應用供應商)將比以往任何時候都更頻繁地發布更新。這意味著客戶必須想辦法跟上步伐。
現在有個好消息。除了關鍵用戶測試和過度護理之外，還有一個更好的選擇:變更影響分析。變更影響分析分析您的整個SAP生態係統(一夜之間)並報告。
- 什麼樣的更改會帶來業務和技術風險
- 確切地說，需要基於這些風險創建或運行哪些測試
- 哪些新的或現有的測試覆蓋了頻繁變化的“熱點”，因此應該自動化
- 您沒有使用的自定義代碼(並且不需要測試)。
簡而言之:它將幫助你明確需要測試的內容。你將進行生存所需要的測試，但你不會因過多的測試而負擔過重。
然而，對於變更影響分析有一個警告。考慮到大型打包應用程序的複雜性，某個中心組件的更改可能會潛在地影響許多對象，這將顯示為“受影響”。這削弱了該技術的有效性。要減輕測試負載，請進一步縮小測試範圍，考慮對象依賴關係(重點關注“風險最大”的對象)。
數據:測試不足
現代應用程序吸收、集成和轉換大量的數據。數據有無數的機會被泄露，通常很少有(如果有的話)形式化的流程來確保整個數據環境中的數據完整性。
也許你已經在所有收集數據並將其轉化為有價值信息的定製應用程序和打包應用程序中完成了適當數量的測試。但是底層數據測試的頻率和徹底程度如何呢?係統的每個其他組件看起來都完全按照預期執行，但如果數據關閉，則業務需求沒有得到滿足。事實上，公司正處於極度危險之中。
假設一個打包的應用程序更新對數據格式進行了細微的更改—這種更改使每100,000條記錄中有1條不被處理。你會立即知道嗎?還是會一直沒人注意到，直到憤怒的客戶(或挑剔的監管者)打來電話?如果您的組織引入了一個新字段(例如，用於COVID-19測試狀態)，那麼一個月後，當用戶配置文件更新時，一個團隊的bug修複最終會覆蓋該狀態，該怎麼辦?
有了自動的“質量閘門”，當數據進入並在應用程序中移動時，就會不斷地檢查數據，這樣就可以在出現問題時及時發現問題。您還可以在它們影響業務並需要大量手動數據檢查/修複之前消除它們。
到目前為止，金融、保險和醫療保健公司一直帶頭使用端到端自動化技術數據測試．他們取得了一些成就成果顯著-比如在20分鍾內自動測試2億個值的能力。如果您正在使用的應用程序使用、操作或輸出數據(哪些應用程序不使用數據?)，請不要忘記這一點。如果沒有它，細微的數據問題可能會迅速像滾雪球一樣變成危機，你需要相當大的雪崩鏟才能挖出來。
注意:本內容最初發表在新堆棧