The Clean Coder 無瑕的程式碼 番外篇 Chapter 7 驗收測試 觀後感 口說無憑，程式為真

       第七章作者主張用驗收測試做為產品開發人員與業務單位、客服單位之間驗收的標準，用來確定需求已經完成。

需求的溝通

作者Bob舉出以前他與現場客服主管Tom的故事，說明溝通的重要性。

「理想很豐滿，現實很骨感」沒有寫過程式的人都會覺得寫程式很簡單，Tom原本找Bob去教他寫程式，最後演變成Tom描述需求，然後Bob寫程式。

Bob有感而發客戶與客服的需求經常是天馬行空，經不起實際程式的檢驗。

過早精細化

「世事多變」隨著專案的進行，客戶與業務的需求都會變化，常常客戶與業務看到初步的成果之後，會有大膽的想法。

需求會一直改變，造成軟體開發人員無法預估正確的工作完成時間。

遲來的模糊性

光憑文字溝通，有可能會出現一段模糊文字，各自表述的情況。

驗收測試

為了避免雞同鴨講的情況，作者認為要有驗收測試。

驗收測試定義為業務方與開發方合作編寫的程式，其目的在於確定需求已經完成了。

完成的定義

完成意味所有程式碼寫完，通過所有測試，QA與需求方已經認可。

溝通

驗收測試的目的是「溝通」，讓開發方、測試方與業務方達成共識。

自動化

避免手動測試，自動化測試可以解省時間節省人力成本。

額外的工作

自動化驗收程式並不是額外的工作，而是為了能夠驗收，確定真正完成的工作。

驗收測試什麼時候寫，又該由誰來寫

驗收程式會交給QA或是開發人員寫，如果是開發人員寫，寫測試程式的人與寫產品程式的人最好不是同一個人。

業務分析員測試正確路徑，證明功能正確可用。QA測出錯誤路徑，邊界條件、異常、例外情況。

驗收測試應該越晚越好，通常是功能完成的前幾天。

開發人員的角色

開發人員有責任讓驗收測試通過。

測試的協商與被動推進

寫測試的人也有可能會犯錯，開發人員要與測試人員溝通。

驗收測試與單元測試

兩者是不同的工作，單元測試是給程式設計師自己看的，驗收測試與業務、程式設計師有關。

測試真正的目的不是「測試」，而是文件與規格。

圖形介面與其他複雜因素

GUI要和業務邏輯分開，測試系統時應當呼叫真實的API。

GUI很容易變化，儘量減少GUI測試。

持續整合

持續整合系統應由原始程式碼管理系統觸發，只要有人更新程式，持續整合系統就會開始建置，並執行所有的測試。

如果發生失敗，每一位成員必須停下手邊的工作，排除錯誤之後才能繼續工作。