什麼人做功能測試比較好？這是我寫這篇《功能測試誰來做》的想法。

經常有人會跟我說他們公司開發過程很好，配備了獨立的功能測試組，有的成立了獨立的測試部門。也有顧問告訴我，要有獨立的測試人員。也有相當的人想著用測試來和開發制衡。

首先我承認要有功能測試組，而且我也會在專案中採用功能測試這個環節，但是對於什麼樣的人能做功能測試，我有自己的看法。

對專案組來說，誰設計誰測試，既然是功能顧問、功能分析設計人員做的業務分析和設計，那麼就應該由他們做功能測試，而不是新手或者對業務不熟悉的測試人員，獨立的功能測試部門，因為要參與多個專案，不可能精於某一領域的業務，所以他們的測試往往只是流於表面，稍微深一些的業務就無能為力。至於開發人員能不能做測試？一看規模，二看角色合併程度，我認為如果一個人業務和技術能力都很強，就更應該將功能測試交給他，而不必增加新的人手。

最理想的功能測試人員是業務使用者，但是很難抓到他們，而且他們也沒有時間去做用例，再完善的場景設計和用例，也無法完全覆蓋，同時基於成本，也不能無休止的進行用例編寫測試應該把上線前後的兩個階段，使用者驗收測試和上線試執行，視作功能測試，也就是說開發期的結束不是在上線前，而是在驗收後，這樣做就需要定義自己的專案開發過程和開發方法。

越快將可執行的系統提交給客戶越好，Agile的各個流派提供了很多成功實踐，我再提提我的看法，正好也把這篇BLOG和我以前的幾個聯絡起來：
1、業務驅動，專案組必須要有強有力的業務顧問和分析人員，做好專案策劃，這個可以參考我前面說的“四種模式”。對於熟悉的業務領域，做好積累。對於不熟悉的業務領域，做好上線後反覆的準備。
2、縮短原型開發時間，把上線的系統視作原型，把使用者視作功能測試人員，讓使用者真正使用系統，提出業務細節的變更，找到錯誤。
3、開發人員要能業務、技術能力同樣突出，省掉多餘的環節，他們是士官，能指揮小組，並且也能打仗，沒有業務理解和分析能力、純粹的編碼人員將被淘汰。
4、做深一個業務領域，產品化。
5、不迷信流行的開發方法論，什麼樣的世界觀決定什麼樣的方法論。