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

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

在 DevOps 與 SAFe（Scaled Agile Framework）等現代軟體工程思維中，最關鍵的原則之一是 Built-in Quality（品質內建）。品質必須從一開始就深植於系統架構與開發流程中，不能留到最後一道防線再補救。

什麼是 Built-in Quality？

Built-in Quality 是在設計與開發時就放進品質檢查，讓檢查點分散在每個階段，不靠專案尾段的最後一關 QA 攔截 Bug。

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

Built-in Quality 的核心做法有這幾項。

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

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

這時候，重用（Reutilization） 就成了讓開發者徹底落實 Shift-Left 左移測試的推手（Enabler）。

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 團隊的開發人員隨時可以跑完幾百個測試，再也不必依賴脆弱的上游伺服器。合約就成了團隊之間最珍貴的「可重用測試資產」。

結語與下集預告

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

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