現代軟體開發幾乎都會做測試。版本要發布前，通常得先通過所有測試——單元測試、整合測試、E2E 測試通通過關。很多人會直覺地想：「覆蓋率很高、系統測試 100% 通過，應該已經沒有 bug 了，可以放心上線。」

但在醫療軟體裡，這還不夠。通過測試只代表「我們把產品做對了」，卻不代表「我們做的是對的產品」。

查證（Verification）與確效（Validation）

在醫療軟體開發中，有兩個觀念需要被釐清，可以用底下問題來區分：

1. 查證（Verification）:Are we building the product right?
2. 確效（Validation）: Are we building the right product?

查證/驗證（Verification）

• 定義：透過檢查與提供客觀證據，確認指定的要求已被滿足。在軟體開發的環境中，主要是證明軟體設計與開發階段的輸出符合該階段的輸入要求。
• 關注焦點：符合規格書與設計規範。
• 主要活動與方法：
  • 單元測試（Unit Testing）與模組層級測試
  • 整合測試（Integration Testing）
  • 系統功能測試（Software System Testing）
  • 程式碼審查（Code Review / Inspection）、逐項檢查（Walk-throughs）
  • 靜態與動態分析（Static/Dynamic Analysis）
  • 追溯性分析（Traceability Analysis，如確認架構與需求互相對應）

確效（Validation）

• 定義： 透過提供客觀證據，證實軟體規格符合使用者需求與預期用途。
• 關注焦點： 滿足真實使用者（如醫師、病人）的實際需求，以及產品在真實或模擬使用環境下的安全與有效性。
• 主要活動與方法：
  • 臨床測試（Clinical Testing）
  • 可用性/易用性測試（Usability Testing / Human Factors Testing）
  • 在實際或模擬的使用環境（Simulated Environment）中進行端到端（E2E）場景測試

所以查證（Verification）以及確效（validation）是兩件不一樣的事情。查證確認開發各階段的輸出符合已定義的要求；確效則以客觀證據確認軟體規格符合使用者需求與預期用途。確效應依預期使用者、用途與環境規劃，可能包含實際或模擬使用情境下的評估。查證結果是重要依據，但測試通過率或覆蓋率本身，不能證明產品已完成確效。

從測試方法到可檢查的證據

前面列出的活動是可能採用的方法。不能只看測試名稱，就判定它屬於查證或確效；還要看它要回答什麼問題、依據哪些需求，以及實際取得什麼結果。查證與確效也不是互不相干的兩份工作：開發過程中的查證結果，可以支持後續對產品確效的判斷。

要讓結果可以回頭檢查，每項活動可以記錄對應的需求或預期用途、受評估的軟體版本、方法與條件、事先訂定的判準、實際結果，以及發現問題後如何處理。列出測試計畫，不等於測試已執行；測試已執行，也只能支持它實際檢查過的結論。

小結

查證確認開發成果符合已定義的要求；確效確認軟體是否符合使用者需求與預期用途。測試結果可以支持相應的查證，但不能只憑通過率認定產品已完成確效。

Ref:
FDA《General Principles of Software Validation》
IMDRF《Software as a Medical Device: Clinical Evaluation》