今天在做年度考核，因為這個會計年度被任為品保角色，同時近期又有服務爆掉的事件，所以就被問了，對於程式品質檢查驗證應該如何分工這樣一個大哉問，對於有將需求分析及系統開發加以分工的公司，或是沒有開發人員採用外包模式的公司來說，以下提供個人對這項議題的想法。

功能性測試

首先，請參考我先前寫的功能性測試分類這篇文章對測試的分類，以這個分類為原則，說明各個測試型態對應角色的分工。

單元測試及整合測試

這兩類測試是針對系統未獨立的部分進行確認，應由開發工程師實做，而其案例可以由開發工程師獨力撰寫，包含預設的操作、例外及容錯處理，或者開發工程師與系統架構師依系統設計決定，例如類別互動的情境及參數的傳遞，而包含商業邏輯處理判斷的測試案例，則應該由需求分析人員在需求分析文件中提供適當的案例。

這裡很重要的一點在於，應該由提出案例的角色發動測試這件事，開發工程師除了自行撰寫的案例之外，若是需求分析人員沒有特別說明，即表示沒有商業需要驗測，因為測試案例需要並應商業邏輯段落，這是需求分析人員應該處理的專業，同時，在成本考量下也不該對所有商業邏輯進行驗測，除非該系統。

這部分是為系統與外部互動進行確認，由系統架構師負責撰寫這部分的測試，然而系統架構師往往事務較多，所以可以搭配品保工程師協助實做、整合及驗證。

對於端到端的系統測試，若是具備人機介面的情境，再細分為桌面應用與網頁服務兩方面，在桌面應用方面由需求分析人員依據其需求分析結果建立驗收計畫，透過手動操作進行測試較為合適，若是網頁服務方面則視情形，由需求分析人員手動驗測，或是需求分析人員提供案例，交由品保人員實做自動化測試。

對於未具備人機介面的情境，則可以考慮由開發工程師或品保人員建立對應的驗收工具交需求分析人員手動驗收，或需求分析人員提供案例交由品保人員建立自動化測試。

對於網路服務型的需求，有時還要加上壓力測試來確認服務的可用性及穩定性，由需求分析人員提供測試案例，品保工程師負責實做、操作及分析。

這部分由品保工程師透過工具收集執行數據，而執行程序則由需求分析師提供，採用系統整合測試的測試計畫項目來收集各項操作的效能數據。

這裡討論各項檢查驗證的分工，但絕非作為錯誤發生之後捉戰犯之用，而是確定開發期間中不同角色了解自已的定位及需要提供的資訊，畢竟品質不是檢查出來，而是生產出來的。