當交付給RD單位進行開發，到最後交付死線後則進入驗收測試階段，開始進行驗收的程序，至於驗收測試的程序該怎麼執行每個產品定義，又或專案團隊因產品屬性不同而導致規則不同各有各的規範就不在這邊特別贅述，今天就分享之前針對產品有關Privacy by Design的需求定義，所擬定的驗收測試文件，將依這驗收測試文件與擬定方式及注意事項跟大家經驗分享。

依據需求規範進行驗收

驗收其實也是類似昨天提到的產品上市前後的品質控管，其目的也是確保產品功能與品質基本上沒問題，要求RD依需求開發的完成品，是否如當初訂立的需求去做開發讓PM做最後的把關，而如何擬定一份驗收的checklist呢？就以GDPR的可攜權的功能為例，依據用戶資料數據下載規劃實作的可攜權需求設計規範(如下表所示)，這也是當初提供給RD團隊並要求依這需求設計規範進行設計開發。

當到了交付日期後便進行驗收測試作業，也是依據上表當初擬定的需求再去規劃擬定一份驗收報告，逐項地進行測試檢查，當驗收測試檢查完成後RD單位與需求單位的owner需簽名確認，以表示此產品的功能驗收作業完成。當初可攜權的驗收報告文件如下表所示。

將事情圓滿

基本的測試四大階段，1.單元測試、2.整合測試、3.系統測試、4.驗收測試，驗收測試為測試的最後一階段，若以軟體測試角度而言還可再細分成：阿法(α)測試與貝塔(β)測試，但這邊就合而為一個測試，到了驗收測試階段也可以說是將事情圓滿，該測試階段為依據當初的需求內容進行測試，目的也是讓行銷業務團隊同仁知道該功能於業務面該如何進行行銷包裝，讓產品某功能從無到有後進行交付驗收讓事情有個完美的milestone。