Feature Freeze 與 QA 驗證——穩定化的關鍵
一句話總結：Feature Freeze 不是停止一切程式碼變更，是從「加功能」模式切換到「穩定化」模式。QA 的 Sign-off 是 Release 品質的最後防線。
結論先講：Feature Freeze 最常失敗的原因不是工程師不守規矩，是 PM 不停塞東西進來——「就加這一個小東西，很快就好」。Freeze 後的每一個變更都應該被視為有風險的。
Feature Freeze：分水嶺
Feature Freeze（又叫 Code Freeze）標誌著「新功能開發結束，進入穩定化階段」。它的意思是：
- 不再合併新功能
- 只接受 Bug 修復（而且要審查，確認是真的 bug 不是「順手加個小功能」）
- Release Branch 切出來了
Feature Freeze 不是停止所有程式碼變更。它是模式的切換。
Freeze 的時長取決於 Release 規模：
| Release 規模 | 建議 Freeze 時長 |
|---|---|
| 小型（1-3 Feature） | 1 天 |
| 中型（5-10 Feature） | 2-3 天 |
| 大型（10+ Feature） | 3-5 天 |
| 重大版本（架構變更） | 5-7 天 |
Freeze 後什麼能做什麼不能做？
這個必須白紙黑字寫清楚，不然 Freeze 形同虛設。
| 允許 | 不允許 |
|---|---|
| QA 發現的 Bug 修復 | 新功能開發 |
| 文案、翻譯修正 | 「順便」改善的 UI |
| 關鍵效能問題修復 | 重構或程式碼「改善」 |
| 安全漏洞修復 | 非關鍵的依賴升級 |
| 阻塞性技術問題 | 任何「很快就好」的小改動 |
最後一項我要特別講。「很快就好」是 Release 流程中最危險的四個字。每一個 Freeze 後的「很快就好」都有可能引入新的 bug，而這些 bug 沒有經過充分測試就直接進了 Release。
Exception Process
如果 Freeze 後確實需要加入變更，走例外流程：
- 提出申請：說明變更內容、原因、影響範圍
- 風險評估：Tech Lead 評估對 Release 穩定性的影響
- 審批：Release Manager 或 Tech Lead 批准
- 加強測試：此變更必須有額外測試覆蓋
- 記錄：記錄此例外，納入覆盤
預設答案是「不」。 除非有充分理由。
如果每次 Freeze 都有大量 Exception，問題不在 Freeze，在規劃。
QA 驗證：品質關卡
QA 測試涵蓋兩大區域：
新功能測試——驗證本次 Release 的所有新功能和 Bug 修復是否符合驗收標準。回歸測試——驗證現有功能是否被新程式碼影響。
回歸測試的範圍看變更影響面：小型 Release 做局部回歸（相關模組 + 相鄰模組），大型 Release 或架構變更做完整回歸（所有核心功能的 Happy Path）。
測試環境要盡可能接近 Production：同版本的中介軟體、脫敏後的生產資料（不是空的資料庫！）、跟 Production 結構一致的環境變數。
Bug 嚴重等級分類
QA 發現的 Bug 必須分類，這是 Go/No-Go 的直接依據：
| 等級 | 定義 | 範例 | Release 影響 |
|---|---|---|---|
| P0 — Blocker | 核心功能完全無法使用，無 workaround | 無法登入、無法結帳 | 必須修復 |
| P1 — Critical | 核心功能嚴重受損，有困難的 workaround | 付款偶爾失敗 | 強烈建議修復 |
| P2 — Major | 非核心功能異常，有簡單 workaround | 匯出報表格式錯 | Known Issue |
| P3 — Minor | 細微問題 | 文字拼寫錯誤 | 記錄即可 |
Go/No-Go 的底線：P0 = 0 個、P1 = 0 個（或有 Release Manager 簽核的風險接受書）、核心流程測試 100% 通過、回歸測試通過率 > 95%。
QA Sign-off
QA 完成測試後要正式簽核。不是口頭說「測完了」，是一份正式的報告：
## QA Sign-off Report — Release v2.5.0
### 測試摘要
- 測試期間：2024-09-10 ~ 2024-09-12
- 總測試案例：156
- 通過：152 / 失敗：4（已修復 re-test 通過）
### Bug 統計
| 等級 | 發現 | 已修復 | 未修復 |
|------|------|--------|--------|
| P0 | 1 | 1 | 0 |
| P1 | 2 | 2 | 0 |
| P2 | 3 | 1 | 2（Known Issue） |
| P3 | 5 | 2 | 3 |
### 簽核結論
- Go / No-Go：Go
- QA 負責人：Alice / 2024-09-12為什麼要這麼正式？因為出了事之後，你需要有紀錄來回答「QA 測過了嗎？」、「當時知道有什麼 bug 嗎？」、「誰同意帶著 Known Issue 上線的？」。這不是在追責，是在建立可追溯的決策鏈。
這篇的重點回顧
Feature Freeze 是模式切換，不是停工。Freeze 後的變更走 Exception Process，預設答案是「不」。QA 驗證分新功能測試和回歸測試。Bug 分四級（P0-P3），P0/P1 是 Release 門檻。QA Sign-off 是正式的品質簽核。
系列文章：
- Release 方法論（一）：Release vs Deploy
- 你在這裡 → Release 方法論（二）：Code Freeze 與 QA 驗證
- No-Go
- Release 方法論（四）：Production Release 與 Post-Release
- Release 方法論（五）：Release Cadence、Hotfix 與反模式
「Feature Freeze 就像報名截止——截止後才來說要報名的，一律下次請早。」