現代軟體測試與 AI 實戰 (7)：Built-in Quality 內建品質與測試重用實踐

經過前幾篇探討的測試孤島與環境迷思，我們意識到將品質責任丟給 QA 團隊（丟過牆策略）往往是災難的開始。

在 DevOps 與 SAFe (Scaled Agile Framework) 等現代軟體工程思維中，最關鍵的原則之一就是：「Built-in Quality（品質內建）」。這意味著品質不該是最後一道防線的補救措施，而必須從一開始就深植於系統架構與開發流程中。

什麼是 Built-in Quality？

傳統觀念把品質當作「附掛 (Bolt-on)」，也就是在製造完成後再靠「最後的檢查 (Inspection)」來過濾瑕疵品。但是軟體系統何其龐大複雜？當程式碼寫完，內部包含了無數的糾纏邏輯與狀態變革。若在開發結束後才進行除錯，成本與風險將呈幾何級數上升。

Built-in Quality 的核心做法包含了：

1. 測試驅動開發 (TDD) / 行為驅動開發 (BDD)。
2. 頻繁的持續整合 (Continuous Integration)。
3. 消除技術債 (積極的 Refactoring)。
4. 制定強制的程式碼規範 (例如 Linting 與靜態分析，我們將在下一篇專文探討)。
5. 架構的低耦合與模組的獨立可測試性。

然而，當每位開發者都開始狂寫測試時，很快會面臨另一個問題：「寫測試太耗時了！一直重複寫一樣的測試打底程式庫。」

這時候，重用 (Reutilization) 就成為了賦能 (Enabler) 開發者徹底落實 Shift-Left 左移測試的關鍵。

Reutilization 作為 Enabler：重用測試資產

如果團隊裡每個成員在編寫單元測試或整合測試時，都需要自己「發明」Mock 設定或資料庫建置邏輯，那麼落實 Built-in Quality 就會因為阻力太大而宣告失敗。

為了成為推動左移測試的「Enabler (推手)」，我們應該強調以下實踐：

1. 建立 Shared Test Utils (共用測試工具包)

// BAD: 每次都在測項內手寫 mock
const userRepo = mock<UserRepository>();
userRepo.findById.mockResolvedValue({ id: 1, name: "Test" });

// GOOD: Shared Test Utils
export const createMockUser = (overrides = {}) => ({
id: 1,
name: "Test",
role: "User",
...overrides,
});
// 在任何測試裡都能一秒重用
const user = createMockUser({ role: "Admin" });

2. 利用 API 合約測試 (Contract Testing) 避免笨重跨服務 E2E

微服務架構中，A 服務呼叫 B 服務。傳統上我們為了驗證這點，會在測試環境把 A 跟 B 整組架起來打 (E2E)。這不僅極度緩慢又容易出 Flaky 錯誤。

在 Built-in Quality 思維中，團隊雙方會制定「API 合約 (Contract)」：

• 重用合約：B 服務開發者只負責驗證「自己產出的結構 (JSON Schema) 是否符合合約」。A 服務開發者利用同一份合約做為 Mock 來源。
• 好處：測試完全解耦 (Decoupled)，A 團隊的開發人員隨時可以跑完幾百個測試，再也不必依賴脆弱的上游伺服器。合約就成了團隊之間最珍貴的「可重用測試資產」。

結語與下集預告

品質不是靠 QA 查出來的，是開發者一行一行代碼堆疊出來的。 藉由「重用測試庫」以及「擁抱 DevOps 精神」，我們成功拔除了把測試左移推行到開發者身上的阻力。但光有「心法」是不夠的。工程紀律，終究需要系統級別的強硬手腕來維持。

在分枝一的最後一篇文章中，我們將透過 GitHub Actions 打造這條完美防線，告訴你何謂「Quality Policies」： 在 CI/CD 打造品質防線：設定 Quality Gate 拒絕爛代碼。