產品開發
測試左移,我們該關注的是需求的 bug 數還是程式的 bug 數
上一篇中我們提到了技術債,本篇就來分享另一個重要觀念-測試左移(Shift Left Testing)。 我們先來看一張很有趣的圖,這張圖的橫軸是開發階段,縱軸則是bug被修復的成本。從圖中我們可以看到 bug 如果發生在需求討論概念的階段,要修復的成本非常小,但隨著需求進入設計、開發、測試、發布階段,bug 的修復成本就以指數型成長。 舉一個很簡單的案例來說,想想,老闆有一天提了一個天馬行空的想法,現場的與會者每個人都對這個需求的效益感到疑惑,但礙於老闆的權威,沒有人敢提出質疑,所以這個需求就排入計畫開始進行設計,而在設計階段設計師們發現這個需求似乎跟現有的用戶需求間有所衝突。 比較理想的做法或許是重新討論這個需求的必要性或針對衝突的處理方式,但設計師覺得沒必要去挑戰高階主管們的決策,因此也硬著頭皮規劃了另一個功能分支,專門提供給對這個新需求有需要的朋友,從這個時間點開始,產品的功能就在主線之外,開始有了第二條分支。 來到開發階段,技術團隊一般不太對 PM 與設計師設計好的內容提出太多的 challenge,頂多說說這樣設計會帶來多少額外的工作量。而進入開發階段也意味著這個需