測試左移，我們該關注的是需求的 bug 數還是程式的 bug 數

上一篇中我們提到了技術債，本篇就來分享另一個重要觀念-測試左移(Shift Left Testing)。

我們先來看一張很有趣的圖，這張圖的橫軸是開發階段，縱軸則是bug被修復的成本。從圖中我們可以看到 bug 如果發生在需求討論概念的階段，要修復的成本非常小，但隨著需求進入設計、開發、測試、發布階段，bug 的修復成本就以指數型成長。

舉一個很簡單的案例來說，想想，老闆有一天提了一個天馬行空的想法，現場的與會者每個人都對這個需求的效益感到疑惑，但礙於老闆的權威，沒有人敢提出質疑，所以這個需求就排入計畫開始進行設計，而在設計階段設計師們發現這個需求似乎跟現有的用戶需求間有所衝突。

比較理想的做法或許是重新討論這個需求的必要性或針對衝突的處理方式，但設計師覺得沒必要去挑戰高階主管們的決策，因此也硬著頭皮規劃了另一個功能分支，專門提供給對這個新需求有需要的朋友，從這個時間點開始，產品的功能就在主線之外，開始有了第二條分支。

來到開發階段，技術團隊一般不太對 PM 與設計師設計好的內容提出太多的 challenge，頂多說說這樣設計會帶來多少額外的工作量。而進入開發階段也意味著這個需求進入改動產品的階段，開發團隊的人數一般是多位，而且投入的各種成本也是多倍。

隨著測試、上線，中間牽涉到的已經不僅僅是開發團隊，還包含行銷、服務、業務等各部門的資源。而這也意味著如果我們在上市後才發現問題，整體付出的代價將是非常可觀的。

如果，我們能在早期與老闆談論需求的階段就先將一些明顯有問題的地方加以釐清，或者直接中止了這個需求的開發，公司都可以因此省下可觀的成本。

而測試左移的倡議，很大一部分目的就基於此。當我們能將 80% 以上的 bug 在早期發現並排除，我們將可以省下非常可觀的成本，這些成本除了人力物力外，最關鍵的就是時間，而時間，將決定一家企業能否在競爭中勝出。

這件事在執行上有一定的難度，但在軟體工程領域中，其實有一個很不錯的解決方法來確保我們能更早的發現問題，讓技術債的累積速度大幅降低，它就是 V-Model。

V-Model

在軟體工程領域，為了確保軟體的產出是符合需求，且具有一定品質，早就發展出一些很成熟的管理框架，如 CMMI 或 V-Model，CMMI的框架太過複雜，我自己雖然也經歷過 CMMI Lv4 的認證過程，但我並不認為所有人都該去學習一套這麼龐大的框架，但是 V-Model 的概念我卻認為所有軟體從業人員應該都要了解。

V-Model 是將整個軟體交付過程從概念、系統需求、設計、開發這種從大到小的展開過程視為解構概念階段，而開發後的單元測試、系統驗證、需求確認到後續維護視為整合階段，藉由這些過程來保證需求沒有被錯誤理解，並盡可能的確保開發的成果可以符合原先所預期。

多數的測試工作，原先都著重在 V-Model 的右半邊，而測試左移的概念，則希望大家應該多多重視左半邊。

V-Model 左右兼顧了，聽起來感覺很不錯吧，但說就簡單，做起來到底有多困難呢？以下讓我們來稍微拆解一下套用 V-Model 的開發團隊在進行整個開發工作上的複雜度吧。

當你提出一個概念後，你可能得先做市場調查，研究市場需求、競品，也要先評估過這個概念能帶來的效益，提出一份提案計畫，然後經過一些專家的審議後才能準備進入產品的排程內；

而概念一般會先被解構為系統需求與功能特性，也就是開發團隊能理解的那些文件，同時還需要跟當時的概念提案者反覆確認這些這些系統需求與功能特性的描述是否跟他的概念一致，若一致，則往下；

從需求文件、設計文件中展開發計畫，一樣得逐一確認開發團隊的理解是否正確，並在開發工作告一段落後先做過單元測試，確保單一功能使用上沒有問題，單一程式在執行上符合原先的規格定義；

接著進入整合測試，將多個功能、多個程式整合在一塊一起測試，以確保不會有各自拆開都正常，組合在一起卻出差錯的狀況發生；

緊接著才進入最關鍵的交付驗收階段，雖然花了很多的時間做驗證與確認(Verification & Validation)，但這仍不保證最終推出的產品能 100% 符合一開始所提出的概念。

加上若要完整的執行這個流程，需要花費很長的時間，過程中需求可能會有多次變化，而這也會導致團隊交付出來的成果雖然符合初始概念，但卻不符合市場需求的狀況發生。

從這段描述中，我們大致可以看到 V-Model 非常嚴謹，但投入的成本異常龐大，不太符合當今快速變化的軟體世界，因此它與瀑布式(Waterfall)開發被大家所遺棄的原因雷同。

但我必須要為 V-Model 說句話，V-Model 所提到的核心觀念都是好的，需求本來就需要被驗證及確認，所以才會發展出 PoC(Proof of Concepts)、MVP(Minimal Vaiable Product)、雛型法(Prototyping)等低成本的驗證方法。

而品質本來就該是個該受到重視的議題，提早發現問題，並針對各個交付物進行品質驗證，並透過持續整合、持續交付讓提高交付的順暢性與品質。

而這也正是近幾年大家談論 agile、DevOps、持續交付(Continuous Delivery)等概念的核心關鍵點。

從上面談論 V-Model 的內容中，我們或許可以看到 V-Model 的優點與缺點，V-Model 是一個嚴謹的模型，唯一的缺點就是對變化的應變速度太慢，而在資訊年代，對很多企業來說應變速度的重要性更優先於品質。也因此，軟體圈中也有人提出了更具有敏捷精神的 V-Model，稱之為 Agile / DevOps V-Model。

不過我個人認為單純的將 V-Model 套用快速迭代的概念還是很難被理解，我個人建議是取用 V-Model 的精神，但在作法上可以根據產品的現況來套用其他更合適的方法。

早期的概念驗證階段

這一塊我們在談論敏捷跟 MVP 的概念時應該談到爛了，如果要趁早知道用戶與市場需求，你需要的是盡快推出產品來獲取市場回饋。

並盡可能減少在概念驗證階段就去改動產品的頻率，能用其他替代品，例如類似的產品、服務、功能來驗證，如果沒有其他可參考對象，那就以雛型、wireframe 或其他設計工具來示意，這些都一樣可以達到驗證的目的，而且會大幅減少投入的成本。

而在 AI 逐漸成熟的現代，你完全能用 AI 在短時間內做出一個產品雛形，直接用雛型去進行需求溝通與驗證。

開發過程的快速迭代階段

一但進入開發過程，其實關鍵就是敏捷性，縮短交付週期，並讓每個迭代都能帶來價值，所以良好的需求溝通、優先級管理、系統架構設計、團隊分工與流程管理將是能否加快迭代速度，盡快交付價值，並減少每個交付所需負擔成本的關鍵。

做好品質控制的交付階段

如果前面兩個段落做得都不錯，按理來說團隊應該已經走在做正確的事(do the right thing)這條道路上，但若要確保團隊把事情做對(do thing right)，我們還是要把交付的環節給做好。此時你可能得更重視持續整合、持續交付、自動化測試，甚至思考測試驅動開發(TDD, Test-Driven Testing)。

AI-Driven Development 時代，許多觀念或許都會有新的做法，但盡早驗證，降低驗證代價，盡早修正，盡早創造價值的核心概念，基本不會有太多改變。

但身為產品開發人員，一定得與時俱進善用新的科技來提高開發效率與品質。

如果你覺得我內容寫得還不錯，歡迎訂閱我的電子報，我每雙週會發送一封電子報到你的信箱。訂閱連結在這，過往的電子報也在這：Gipi電子報

也鼓勵你可以將我的電子報分享給你認為有需要的朋友們，也許你的舉手之勞，將會改變另一個人的思維與習慣。