QA 在 code review 能看到什麼，RD 自己不容易看到的

QA 在 code review 能看到什麼，RD 自己不容易看到的 目錄 1. 那個 PR 我沒有參與，結果我測出了 bug 2. RD 看 PR 的視角和 QA 看的差在哪裡 3. 我在 PR 裡會看哪些地方 4. 怎麼讓 QA 參與 code review 不變成阻礙 5. 結尾 那個 PR 我沒有參與 一個 bug 被修復的成本，和它被發現的時機密切相關。IBM 系統科學研究院的研究顯示，在需求階段發現的缺陷修復成本若為 1，同樣的問題在生產環境才被發現，修復成本可能高達 30 到 100 倍。Code review 是開發流程中最後一道「便宜的防線」——QA 在這個階段介入，抓住的每一個問題，都是在用最低的成本解決它。 那次 我們的 App 要上一個新的計時模式：專注衝刺模式，50 分鐘計時，完成後給雙倍硬幣。 PR 出來，RD 互相 review，兩個人都沒問題，合進去。我拿到 build 開始測。 測了一個小時，發現一個問題：免費版帳號進到這個模式，介面會讓用戶選擇開始計時，計時跑完，結算畫面出現「雙倍硬幣 50 枚」，但點擊領取之後——畫面卡住，什麼都沒有發生。 底層的問題是：雙倍硬幣是 Pro 功能，後端拒絕了免費帳號的領取請求，但前端沒有處理這個錯誤回應，只是靜默失敗了。用戶看到「領取成功」的前置動畫，然後頁面就停在那裡。 我去看那個 PR，邏輯本身沒錯。獎勵服務 的 API 拒絕請求是預期行為，問題是 code review 的時候沒有人問：「如果 API 回了非 200，前端怎麼處理？」 這個問題，RD 在 review 邏輯正確性的時候不容易想到。但 QA 想測試這個功能的第一步，就是問：「哪種帳號會有什麼限制？」 視角差異 RD review PR，通常看的是： 邏輯有沒有錯 效能有沒有問題 符不符合既有的 coding style 有沒有潛在的安全問題 這些都重要。但有幾個維度，RD 在實作完之後看自己的 code，天然有盲點： 用戶狀態的組合 RD 在開發時，腦中通常有一個「正常用戶」的預設模型。但真實的用戶有很多狀態：免費版、Pro 版、試用期剛到期、剛退款、帳號被封鎖。這些狀態和新功能的交叉點，是 QA 第一個想到的，是 RD 最後一個想到的。 錯誤路徑的處理 RD 寫 happy path 的時候是清醒的，寫 error handling 的時候通常是補的。「API 超時怎麼辦」、「網路斷掉怎麼辦」、「資料格式異常怎麼辦」——這些在 PR 裡很難審，因為 RD 看的是「error case 有沒有 catch」，不是「catch 了之後 UX 對不對」。Capgemini WQR 2024 25 指出，超過半數的 production bug 是 error handling 不完整所導致，而這類問題在 code review 和整合測試階段本可以被更早攔截。 邊界條件的完整性 「計時 0 秒完成算不算」、「硬幣餘額是負數的時候能不能繼續種樹」——這類邊界值，RD 在 review 的時候不一定記得每個都想到，QA 在設計測試案例的時候會系統性地列出來。 我在 PR 裡看哪些 我進 PR 不是要找程式邏輯的錯，那是 RD 的工作。我看的是「測試角度的風險點」： 1. 狀態變更的地方 任何修改帳號狀態、訂閱狀態、計時狀態的邏輯，我都會問：「這個狀態改了，其他依賴它的地方有沒有同步更新？」 我們的 App 的訂閱狀態會影響可用的樹種、硬幣倍率、白噪音選項。一個 PR 改了訂閱到期的判斷邏輯，其他三個地方依賴這個狀態，PR 只改了一個。 2. API 的 error response 處理 我會看前端有沒有對所有可能的 error code 做處理。不只是「有沒有 catch」，是「catch 了之後用戶看到什麼」。靜默失敗對用戶來說比顯示錯誤訊息更糟，因為他不知道出了什麼事。 3. 新增了哪些假設 RD 在 PR description 寫的東西，有時候有隱性假設。「假設用戶一定有登入」、「假設裝置時間是準確的」——這些假設在某些情況下會被打破，我看到就會留 comment 問。 4. Migration 或資料格式改動 如果 PR 改了 API response 的格式，或者資料庫 schema，我會問：「舊版的 client 拿到新格式會怎麼樣？」這種跨版本的相容性問題，在 review 的時候是最容易漏的。 不變成阻礙 QA 參與 code review 最大的風險是：review 速度變慢，或者 QA 的 comment 讓 RD 覺得是在阻礙合 code。 我的做法是： 不 block，只問問題 我的 comment 幾乎不會是「這樣不行，要改」，而是「這個情況下的行為是預期的嗎？」讓 RD 確認，而不是讓 QA 裁定。如果 RD 說「是，這是預期行為」，我知道我測試的時候這個情境是 pass 的條件；如果 RD 說「喔，這個沒想到」，那就是在 code 進去之前抓到了一個問題。 只針對高風險的 PR 不是每個 PR 我都進去看。UI 文字修改、logging 調整、重構沒有邏輯改動——這些我不進去。我只針對「這個 PR 會影響用戶的核心行為」的情況介入：計時邏輯、硬幣入帳、訂閱狀態、帳號系統。 PR description 裡先說清楚測試重點 我會請 RD 在 PR description 裡寫一行：「QA 測試的重點是什麼、哪些情境我已經想過了」。這讓我在 review 的時候有起點，不用從頭猜。 結尾 那個計時衝刺模式的 bug，如果我在 PR 階段就問了那個問題，它不會進到 build 裡。 但更重要的是：RD 和我都從那次學到了一件事。現在那個 RD 在寫涉及帳號狀態的功能時，會主動在 PR 裡寫一段「免費版用戶行為：OOO，Pro 版用戶行為：OOO」。他把這個維度納進自己的思考了。 QA 進 code review 的長期價值，不只是抓那一個 bug，是讓 RD 開始用不同的眼光看自己的 code。 參考資料 1. Google Testing Blog — Code Review Best Practices — Google 工程師如何在 code review 中融入可測試性思維 2. Capgemini World Quality Report 2024 25 — Error handling 缺陷與 production 問題的相關性調查 3. Martin Fowler — Code Review — Shift left 測試策略與早期品質介入的工程原則 4. ISTQB — Static Testing — Code review、walkthrough 作為靜態測試技術的標準框架 5. DORA 2024 State of DevOps Report — 程式碼審查品質與軟體交付穩定性的相關性研究