在電子工程中,我很快就學到:只測試電路中的某一個點,能告訴我的關於整個系統健康狀況的資訊非常有限。一個元件可以通過檢驗,組裝完成的電路板卻在加載時失效;電路板可以在工作臺上表現完美,一旦安裝到實際運行環境中卻行為不同。因此,品質是透過多層次的驗證來確立的,每一層回答的都是不同的問題。轉入品質保證(QA)工程後,我發現幾乎相同的原則隱藏在不同的術語背後。

在軟體 QA 中,我可以把驗證想成三個階段:產出物驗證、功能驗證與系統驗證。

產出物驗證

產出物驗證從最貼近實作的層級開始。原作者與審查者在程式碼、測試、設定檔或其他開發產出物進入版本控制之前進行檢視。證據可以包括程式碼審查紀錄、靜態分析報告,以及刻意展示在錯誤條件下會失敗的測試。這讓我想到在組裝電路之前先檢查一個個電子元件:一顆電阻的阻值可能正確,一顆 IC 可能通過檢驗,但這些結果都無法證明完成的電路板能正常運作。同樣地,乾淨的靜態分析與通過的單元測試是有價值的證據,但它們只驗證了軟體的其中一層。

功能驗證

功能驗證把焦點從*「這個東西有沒有被正確地建構出來?」轉向「它的行為是否符合需求?」在這個階段,產品與 QA 在發布前共同承擔責任。對於確定性的功能,這可能涉及驗收標準、邊界值分析、負向測試,以及預期與實際的斷言比對。AI 驅動的功能則帶來另一種挑戰,因為輸出未必總是存在唯一正確的字串。在那些情況下,驗證可能需要可接受區間的定義、一份黃金資料集(golden dataset)*,以及留下紀錄的人工評估。電子工程中的對應做法是:把組裝完成的電路拿去對照它的設計規格進行測試——個別元件可能是健康的,但我仍需驗證它們組合後的行為能在公差範圍內產出要求的輸出。

系統驗證

最後,系統驗證要問的是:當這些各自通過驗證的零件開始互相作用之後,產品是否仍持續正確運作。此時 QA 與維運關注的是整合之後、甚至上線之後的端到端行為,使用的證據包括 E2E 測試結果、生產環境抽樣、監控與告警紀錄。這就像在貼近真實的運行條件下為完成的電子系統通電。元件通過了,電路通過了,現在我想知道的是:當整個系統遇上真實的輸入、相依服務、流量與故障條件時會發生什麼——因為生產環境有一種驚人的天賦,總能找出沒人邀請它進 sprint 的測試案例。

還記得上一章的 Aurora Shop 嗎?那是我為了情境需要而虛構的電商平台。它由大約十幾人的團隊營運,其中只有兩人分擔 QA 職責。公司上線了一個 AI 客服助理,用來回答客戶關於訂單、出貨與退貨政策的問題。

我認為這個三層模型最有用的一點在於:每個階段都有*明確指名的負責人、生命週期中定義好的時間點,以及其他人可以獨立驗證的證據。*產出物驗證保護的是實作,功能驗證保護的是預期行為,系統驗證保護的是整合後的產品。如果某一層有負責人卻沒有留下可重現的證據,這個驗證就難以被信任;如果它有證據卻沒有人清楚負責,缺陷就可能悄悄變成別人的責任。

請記住,「負責人」實際上會因誰擁有這些測試階段的使用權、權限與職權而有所不同。這不是一個黑白分明的概念。這裡的數字是示例演練資料,並非精確的量測值。