今天在聊測試之前，我們要先聊 Scrum 與敏捷開發。為什麽？等會你就知道了。

烽火下的 Scrum

思考一下以下兩句話：「我們這個 Sprint 先做功能，下個 Sprint 再補測試。」、「RD 這個 Sprint 先做功能，QA 下個 Sprint 再幫忙測試。」是否耳熟？是否是你自己也會考慮，甚至是經常做的事？

很多人號稱自己在 Scrum，卻忽略了一件很重要的事：Scrum 的 Sprint 產出物，要是「潛藏性可交付的產品增量（Potentially Shippable Product Increment）」。什麼意思？意思就是它不只要有增加新功能或修復，它還要是「潛藏性可交付」。也就是說，一個 Sprint 結束後，你的產品要保持在一個「不上線也行，要上線的話也隨時可以」的狀態。如下圖所示，每個 Sprint 交付的產品，都要「可以交付」，這才是 Scrum 要的產品增量：

圖片來源：https://community.atlassian.com/t5/Agile-articles/Scrum-Artifacts-with-pictures/ba-p/1265154

試想，如果你這個 Sprint 做的功能，下個 Sprint 才要測，不論那是自動還是手動，那你或你老闆敢「隨時上線」嗎？我們就說一個 Sprint 是兩週好了，老闆一月想到的絕妙新功能，二月才能上線驗證想法，到了那時，市場的最佳時機早就過了，那還敏捷個 P 啊？

「啊～ Scrum 沒用啦～ 用了 Scrum 反而慢！」是不是很容易推導出這種結論？

哪有這種事？明明是你自己沒有照人家 Scrum 規範，做出可交付的產品增量，哪能怪人家 Scrum 沒有用呢？

烽火下的 QA

然而，如果老闆還算理解 Scrum 的設計，真的要求要「可交付」，那第一個跳腳的就要是 QA 了。怎麼說呢？

筆者曾在國內培訓名師 Joey Chen 的一場講座上，聽 Joey 舉了一個非常貼切的例子，至今印象深刻：

就說你第一個 Sprint 做 10 個功能吧，那 QA 測 10 個不為過吧？如果 RD 輸出速度很穩定，下個 Sprint 也做了 10 個功能，請問 QA 要測多少功能？

答案：20 個。因為你要回歸測試啊！很快，5 個 Sprint 過去，RD 依舊每兩週開發 10 個功能，老闆很滿意，但 QA 可慘了！他得測 50 個功能，而且以後還會越來越多！試問誰能不跳腳？這時試想，這些測試如果都能自動化，那測 5 個功能跟測 50 個，甚至是 500 個功能，時間上能差多少？總不會差超過 5 分鐘吧？筆者曾經參與過一個有 1,500 個單元測試的專案，每次跑完全部測試也才 7 分鐘。你上哪去找 QA 用這種速度幫你測？ 所以說為什麼我們要先聊敏捷開發？因為自動化測試才是敏捷開發的根本啊！

Joey 曾說：「沒有自動化測試的敏捷，就只是在搞死 QA 而已。」

這不是開玩笑，這是真的。

自動化單元測試不是測試，是功能

沒有人煮飯不試味道的，越是高級餐廳的大廚，越要試味道。不試，怎麼知道味道對不對？寫程式也是一樣，你不測看看，你怎麼知道你寫的功能對不對？會說「沒有時間寫測試」的人，就是不把「試味道」當成做菜必要步驟的廚師。所以你估算時間時就要把「通過測試」列為完成條件，就像大廚估算料理時間時，不會漏了「試味道」這個環節一樣。

「可是，時間就很短啊，怎麼辦？」

你有兩條路可以走：

1. 不要接這麼多單
2. 練習煮快一點

如果你短期內兩件事都辦不到，那你還可以這麼做：「檢查看看廚房內的擺設或流程中，有什麼會造成你等待的，想辦法解決它」，譬如：

1. 換一台三口炮爐
2. 一樣的菜，一口氣炒完再分裝
3. 前一天把適量的肉拿來冷藏退冰
4. 搬動一下冰箱位置，讓動線更順暢

以此類推，你還有其他很多可以加速的方法。路是人走出來的，辦法是人想的，但無論如何，身為大廚你就是不可以讓客人吃到難吃的料理，不熟的更不行！就像無論如何你不可以讓你程式的使用者整天在幫你抓 bug 一樣。

世上有煮飯不試味道的人嗎？有啊，路邊攤的老闆啊。路邊攤嘛，一份餐點才收你那麼一點點錢，是要要求什麼？這時味道差一點無妨，客人也不在乎味道，你不要讓他們等太久就好。

謎之聲：「你覺得你是高級餐廳大廚，還是路邊攤老闆？」

Reference

1. Joey Chen 部落格：https://tdd.best/about/

tags: ithelp2021