在進入測試的細節之前，先繞道談談 Scrum 與敏捷開發。這個切入角度其實是有原因的。
烽火下的 Scrum#
下面這兩句話，看起來是不是很熟悉？
- 「我們這個 Sprint 先做功能，下個 Sprint 再補測試。」
- 「RD 這個 Sprint 先做功能，QA 下個 Sprint 再幫忙測試。」
不少團隊號稱自己在跑 Scrum，卻忘了一件關鍵事項：Scrum 的 Sprint 產出物應該是「潛在可交付的產品增量」（Potentially Shippable Product Increment）。意思是 Sprint 結束時，產品不只要有新功能，還必須處於「想上線就能上線、不上線也行」的狀態。
如果這個 Sprint 做的功能要等下個 Sprint 才測，無論是手動還是自動，產品就無法達到隨時可上線的標準。一個 Sprint 假設兩週好了，老闆一月想到的點子要等到二月才能上線驗證，市場最佳時機早就溜走，敏捷的意義也消失了。
「用了 Scrum 反而變慢」這種結論其實是個誤判，真正的問題是團隊沒有按 Scrum 的設計做出可交付的增量，與 Scrum 本身無關。
烽火下的 QA#
如果老闆真的理解 Scrum，並要求每個 Sprint 都要可交付，第一個受不了的通常是 QA。
設想 RD 第一個 Sprint 做了 10 個功能，QA 測 10 個還算合理。下一個 Sprint RD 又做了 10 個，這時候 QA 要測幾個？答案是 20 個，因為要做回歸測試。再過五個 Sprint，QA 得測 50 個功能，而且只會愈來愈多，這誰受得了？
這時若所有測試都能自動化，測 5 個與測 500 個的時間差距其實非常小。曾有 1,500 個單元測試的專案，全跑一次也只要七分鐘——這種速度沒有任何 QA 能在手動測試中達到。
也因此可以說：自動化測試才是敏捷開發的根本。沒有自動化測試的敏捷，等於在折磨 QA。
自動化單元測試不是測試，是功能本身#
世界上沒有不試味道就出菜的廚師，越是高級餐廳的大廚越要試味道。寫程式也一樣，不測一下，怎麼能保證功能正確？真正的問題不在於「沒時間寫測試」，而在於估算工時時是否把「通過測試」算入完成條件。
「可是時間真的很短」這個情境也是常見的。能走的路其實只有兩條：
- 不要接這麼多單
- 練習做得更快
如果短期內兩件事都做不到，那就把眼光放到「廚房擺設與流程」上：
- 換一台火力更強的爐具
- 同樣的菜一次炒好再分裝
- 前一晚把肉先放冷藏退冰
- 調整冰箱位置讓動線更順
對應到開發場景，就是改善工具、流程與架構。但無論如何，身為廚師都不能讓客人吃到難吃或不熟的菜，這就跟身為開發者不能讓使用者整天替自己抓 bug 一樣。
當然，世上也有不試味道的人，多半是路邊攤老闆，因為價格便宜，客人對品質沒什麼要求。問題是，你想成為的是哪一種角色？
原文出處#
- 原書/iThome：https://ithelp.ithome.com.tw/articles/10259532