TDD 實施流程與 qTest 模組對映

將 TDD 微型開發迭代（Red-Green-Refactor）與 qTest 品質大腦（Requirement, Plan, Execution, Defect）進行點對點對齊，落實可度量的軟體工程。

TDD 流程 & qTest 模組對照矩陣

在敏捷 DevOps 團隊中，開發人員的每一動，都對應著 qTest 品質管理系統中的一個明確狀態。這建立了端到端的完整追溯鏈：

1. qTest Requirement (需求)

對應為 **TDD 的規格起點**。開發人員的測試代碼與功能代碼，皆必須為了解決 qTest 中登錄的需求規格而生。

2. qTest Plan (測試案例規劃)

對應為 **TDD 的 RED (失敗測試) 階段**。開發端需將 qTest 中規劃好的測試案例 (Use Cases) 直接衍生為自動化測試腳本。

3. qTest Execution (測試執行)

對應為 **TDD 的 GREEN (通過測試) 階段**。本地自測綠燈後，程式碼發布至測試區，由 Key Users 執行 UAT，並將測試結果登錄於 qTest。

4. qTest Defect / Issue (缺陷管理)

對應為 **TDD 的 REFACTOR / Reactive Bug-fixing 閉環**。當執行失敗時，登錄的 Defect 將觸發專屬的重構與修復流程，直至 Issues 歸零。

日常 TDD 開發流程細則

遵循以下四個開發步驟，嚴格將 qTest 的品質要求灌注在每一行生產代碼中：

STEP 1

解析需求規格 Requirement

從 qTest 讀取已審核通過的需求條目與規格書。明確該功能的商務邏輯與邊界，將需求當成開發唯一的起跑點。

STEP 2

編寫會失敗的測試 (RED) Plan - Use Case

開發人員直接拉取 qTest 中規劃好的測試案例 (Use Case)，在本地環境編寫自動化測試代碼。此時執行該測試必須是**紅燈**，藉此確立目標規格。

STEP 3

實作功能並交付執行 (GREEN) Execution

編寫最簡單的 MES 功能代碼使測試變為**綠燈**。本地自測綠燈後程式部署至 Test Area，啟動 qTest Execution 進行用戶 UAT，確保交付有據。

STEP 4

安全重構與缺陷回歸 Defect - Issue

消除重複並優化代碼，確保測試維持綠燈。若 UAT 失敗登錄 Defect，則強制轉為「先寫測試重現 bug，再行修復」，迴歸測試通過後方可解鎖。