為什麼我們堅持寫測試?省下的是半夜的電話

先講結論:我們堅持寫自動化測試,不是因為追求工程上的完美,是因為我們自己的電商每天在收單,半夜系統出事,電話是打給我們自己的。被那通電話叫醒過幾次,你就會懂測試不是成本,是保險。

一張錯單教會我們的事

說一個丟臉但真實的故事。我們自營電商有一次改版,單元測試全部通過,一片綠,信心滿滿上線。結果第一張正式訂單金額就算錯了。事後追查發現是兩個 bug 剛好互相掩護——各自的單元測試都對,湊在一起卻是錯的。從此我們多了一條鐵律:單元測試全綠不等於系統會動,上線前必須用真實金流把整條鏈路跑一遍。這條鐵律後來變成我們對客戶專案的交付標準,細節寫在這一篇。

這個故事的重點不是「我們曾經出錯」——每個團隊都會出錯。重點是:如果那是一個沒有測試文化的系統,這種錯會反覆發生,而且每次都在半夜、都在最忙的檔期、都在你最不想接電話的時候。

測試買到的不是「沒有 bug」,是「敢改」

很多經營者以為測試的價值是抓 bug,其實那只是表面。測試真正買到的東西是修改的勇氣。

一個沒有測試的系統,活得越久越沒人敢動。工程師改一行程式,不知道會不會弄壞另外十個地方,只好用最保守的方式往上疊,疊出來的就是技術債。套件不敢升級,因為不知道升了會壞什麼;老舊的架構不敢重整,因為沒有安全網。最後系統變成一間沒人敢動格局的老房子,只能一直加違建。

有測試的系統完全相反。想重構就重構,測試會告訴你有沒有弄壞東西;該升級就升級,跑一輪測試就知道相容性;新人進來敢放手改,因為犯錯會被接住。系統的壽命,取決於它敢不敢被修改——而敢不敢,就看有沒有測試。

測試不是在防 bug,是在買一種自由:三年後的你,還敢放心地改今天寫的程式。

給發案的你:怎麼確認廠商有沒有在測

如果你是委託開發的業主,不用懂技術也能驗證這件事。問三個問題:一,「這個專案有自動化測試嗎?可以給我看測試報告嗎?」——有測試的團隊拿得出來,沒有的會開始解釋為什麼不需要。二,「上線前你們會用真實金流跑一次完整流程嗎?」——答案是「測試環境都測過了」的,要小心。三,「上線後如果我要加功能,你們怎麼確保不會弄壞現有的?」——答案裡沒有「測試」兩個字的,代表未來每次改版都是賭博。

常見的反駁是「寫測試不是會拖慢開發嗎」。短期看是的,前兩週一定比較慢。但一個專案的生命週期裡,寫程式只佔一小部分,更多時間花在改程式、找 bug、驗證沒弄壞別的東西——測試在這三件事上把時間十倍奉還。我們自己的體感是:專案超過一個月,測試就開始回本;系統要活超過一年,不寫測試才是真正的慢。而多數對外的網站和系統,哪個不打算活超過一年?

測試會讓報價貴一點、時程長一點,這是事實。但那筆錢買的是之後每一次改版的安全,以及你半夜不會接到的那通電話。以我們自己同時當工程團隊和系統擁有者的經驗:這是整張報價單裡,最不該省的一行。