業務分析指南/系統測試與驗收
測試的主要目的是確定和傳達所測試系統的質量。測試通常由開發人員、質量保證測試人員、使用者、培訓師和/或業務分析師完成。在專案團隊中，可以將資源分配給測試協調員角色。該角色負責監督和協調專案的測試範圍。測試協調員的職責可能包括但不限於收集業務需求、定義測試策略、制定測試計劃、執行測試、管理系統缺陷以及協助使用者驗收測試 (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/
應記錄有關缺陷的重要資料；請參見下表，該表顯示了在記錄缺陷時可以捕獲的資料及其定義。
| 欄位 | 描述 |
|---|---|
| 摘要 | 對缺陷的簡短描述。 |
| 應用程式 | 受缺陷影響的特定應用程式。 |
| 發現環境 | 最初發現缺陷的環境。 |
| 測試型別 | 發現缺陷時執行的測試型別。 |
| 嚴重程度 | 由業務使用者/所有者或測試人員確定的缺陷對業務的影響。 |
| 優先順序 | 處理該應用程式的缺陷相對於該應用程式中存在的其他缺陷的優先順序。 |
| 描述 | 對所有相關資訊的詳細描述，包括記錄/事務示例。應描述何時以及如何檢測到缺陷，以及結果是什麼。還應說明預期結果應該是怎樣的。 |