業務分析指南/系統測試和驗收
測試的主要目的是確定和傳達所測試系統的質量。測試通常由開發人員、質量保證測試人員、使用者、培訓師和/或業務分析師完成。在一個專案團隊中，可能會有一個資源被分配到測試協調員角色。該角色預計將監督和協調專案的測試範圍。測試協調員的職責可能包括但不限於收集業務需求、定義測試策略、開發測試計劃、執行測試、管理系統缺陷以及協助使用者驗收測試 (UAT)。
注意：雖然業務分析師可以執行測試、測試計劃和測試用例的開發，但這些功能不會為 IIBA CBAP 或 CCBA 認證獲得經驗學分。請檢視 IIBA 手冊中的認證要求，網址為 http://www.iiba.org。
單元測試是執行的第一級測試，用於驗證特定程式碼單元是否按預期工作。它通常由開發人員在開發程式碼時執行。
整合測試是執行的第二級測試，用於驗證整合元件之間的介面是否按預期工作。它通常由開發人員在所有元件完全開發後執行。
系統測試也稱為端到端測試。它是執行的第三級測試，用於驗證系統是否滿足已定義的業務需求。它應該在系統完全整合並且所有整合測試成功完成之後執行（通常由質量保證測試人員或開發人員執行）。
驗收測試也稱為使用者驗收測試 (UAT)，是執行的最後一級測試。它在系統測試成功完成之後由系統使用者執行。它是對系統所有權之前滿足需求的最終驗證。
另見：軟體測試維基百科網站 - http://en.wikipedia.org/wiki/Software_testing
為了協助測試協調，測試策略可能很合適。測試策略向關鍵利益相關者（如專案經理和技術主管）傳達總體測試方法。測試策略定義測試範圍、要測試的系統、測試所需的資源、所需的測試型別、缺陷管理詳細資訊、測試任務和測試時間表。測試策略應在業務需求最終確定後完成。建議確定一位測試協調員來監督測試策略的完成。然後，應由專案經理或技術主管批准，以確保其準確性。如果範圍、需求、時間表或資源發生變化，測試協調員應根據需要審查和更新測試策略。
另見：測試策略維基百科網站 - http://en.wikipedia.org/wiki/Test_strategy
業務需求最終確定後，應定義測試用例。每個業務需求都應至少包含兩個測試用例：一個正向測試用例和一個負向測試用例。測試用例定義測試人員確定系統是否按預期工作所需的資訊。每個測試用例都應包括
- 測試用例識別符號
- 要測試的需求的參考
- 執行測試所需的條件
- 執行測試的步驟
- 輸入測試資料
- 測試的預期結果
- 實際結果（測試後完成）
另見：https://en.wikipedia.org/wiki/Test_case
測試計劃是一個正式的文件，列出了測試給定系統所需的所有測試用例。測試計劃有時用於描述測試策略。測試協調員將與技術主管合作協調測試用例和測試計劃的開發。
另見：http://en.wikipedia.org/wiki/Test_plan
缺陷管理是管理系統缺陷的過程。它從識別缺陷開始，到缺陷修復並關閉結束。缺陷管理也稱為缺陷跟蹤。
缺陷可以定義為“編碼、邏輯或應用程式元件組裝中的錯誤，會導致程式故障或產生錯誤/意外結果”。它也被描述為“軟體產品中不滿足軟體需求（如需求規範中所述）或終端使用者期望的狀況”。缺陷也稱為錯誤。
來源：http://softwaretestingfundamentals.com/defect/
應記錄有關缺陷的重要資料；請參見下面關於在記錄缺陷時可以捕獲的資料及其定義的圖表。
| 欄位 | 描述 |
|---|---|
| 摘要 | 缺陷的簡短描述。 |
| 應用程式 | 受缺陷影響的特定應用程式。 |
| 發現環境 | 最初發現缺陷的環境。 |
| 測試型別 | 發現缺陷時執行的測試型別。 |
| 嚴重程度 | 由業務使用者/所有者或測試人員確定的缺陷的業務影響。 |
| 優先順序 | 解決應用程式缺陷的優先順序，與該應用程式存在的其他缺陷相關。 |
| 描述 | 詳細說明所有相關資訊，包括記錄/交易示例。應描述何時以及如何檢測到缺陷，以及結果是什麼。還應指出預期結果應該是什麼。 |