（Photo by Mateus Campos Felipe from Unsplash）

在PMBOK（註1）的定義裡，完整的品質管理計畫包含「品質保證」（Quality Assurance, QA，中文簡稱「品保」）與「品質管制」（Quality Control, QC，中文簡稱「品管」）兩個面向，其中，品保的目的是確保產品交付的品質，例如軟體開發專案中，交付的軟體是否能符合規格文件內所定義的功能。在編制完整的組織內，也可能會有QA這樣的角色（Quality Assurance engineer，即品質保證工程師），協助PM檢驗產品品質。

PM雖然不一定需要親自對產品進行品質驗收（視專案的規模與組織架構而定，也有許多PM是必須身兼數職的），但若能對流程與驗收方式有基本的了解，將可促進PM與QA之間的協作，確保每一項檢驗都是必要且確實的，如此一來，PM只需掌控驗收的進度，就可放心交由QA執行驗收細節。

產品的驗收有許多層面，以軟體為例，除了基本功能之外，還需要考量不同作業系統相容性、環境設定、例外操作情境（使用者以非預期的方式執行某個功能，會發生什麼事？）、資訊安全等，甚至在開發過程中，開發人員也會進行一些單元測試（註2）。為了找出產品可能潛藏的問題，專業的QA通常會盡可能設計各種測試案例，從不同的角度進行驗證，因此是一門相當深入的學問。本篇文章只以PM（註3）的角度淺談測試案例（test case）的應用，希望能協助PM們與QA的協作更加緊密。

測試案例是用來檢驗產品是否如質的工具之一，內容包含：

1.標題

為了能一眼辨識，通常會描述情境與預期結果，例如「用戶點擊下載檔案，顯示檔案列表」這樣的命名方式。

2.前置條件

說明測試前需完成的條件或狀態，以前述標題為例，前置條件可能是「用戶需先登入」，代表此功能只提供給會員使用。

3.測試步驟

測試的步驟必須逐步、逐項描述確實，以便不同的測試人員都能理解且使用對的方式執行。

4.預期結果

執行上述操作後，預期的結果，例如「畫面出現提示」、「用戶取得檔案」等明確的描述。

5.優先順序

測試項目的重要性排序（例如分為高、中、低三類），當產品驗收的時間有限時，PM可以選擇只驗證高順位的測試案例，或者暫時不修正順位低的案例所遇到的問題，因此通常會由PM來定義優先順序。

常用的test case工具包括 Excel、TestRail 或 Jira等，視不同的團隊或公司需求而定，但不論使用何種工具，重點是test case需盡可能與功能規格對應，確保涵蓋的測試範圍是足夠的。下圖是使用Excel建立的簡易的test case範例，在描述「訂單」這個相關功能的驗收方式，由於此範例所定義的訂單有使用權限的限制，因此驗收時便以不同權限的用戶作為區分，每個身分會有對應的操作方式與預期結果。

為了有效掌握驗收情況，我在表格後方增加了驗收人員、狀態、日期，以及結果說明，方便PM統計及追蹤成效，驗收失敗的項目若能對應至工程修復的需求單（例如Jira），將會更有一致性。有時驗收階段會發現規格定義不清楚的情況，因此在紀錄驗收結果時，也可以描述問題類型，例如bug、規格修正、環境問題...等，定義越明確，後續的分工與追蹤就更有效率 : bug交由工程師排除，規格需PM補充，環境問題則可能要系統人員協助處理。

基本上，工程師開發軟體、QA驗證產品品質，都根據「輸入（input） / 輸出（output）」的大原則在進行，也就是下什麼指令，得到什麼結果。PM將使用者需求轉化為產品規格的過程中，若能以此思維進行，盡量將操作步驟、預期結果描述清楚，這樣將有助於後續任務的展開，降低PM、工程與QA對規格的認知差異。

註1 : PMBOK  : A Guide to the Project Management Body of Knowledge，專案管理知識體系指南，是美國國際專案管理學會所發行的專案管理著作，定義專案管理的標準。

註2 : 單元測試，是針對軟體設計的最小單位（或稱模組）進行驗證。在此階段通常不考量該單元與其他單元之間的複雜關聯，僅針對程式的合理反應做測試（例如是否可確實傳輸呼叫成功/失敗的訊息）。

註3 : 此處的PM並非單指專案經理，事實上在台灣，多數公司內專案經理與產品經理的界線並不明顯，專案經理並不會只單純管理專案進度、規劃管理原則等，更多時候是被賦予產品經理的期望，因此需要投入產品本身的規劃與設計，此時對於如何驗收，或者如何協助QA將規格轉化為test case，就顯得格外重要。