讓開發部門參照與測試部門相同的測試案例進行品質測試

最近一個專案大概因為我們交付的成品送測後收到太多的錯誤回報，經分析後，有很多錯誤是顯而易見不應該發生的錯誤。原本 Lead Engineer 一再囑咐我們交付送測前必須參照測試部門使用的測試案例來確保交付品質，但是結果兩個開發團隊皆沒有完全施行。

實際上我認為讓開發團隊參照或是逐一依照與測試團隊相同的測試案例來進行交付品質的確認，基本上是本末導致的行為。原本開發團隊對於產品的架構、功能的侷限、不同功能之間的參數呼叫等有較多的資訊，開發團隊自有另外一套測試方法，好比說針對單一目的的程式碼或是函式進行單元測試、邊界值測試等等；測試團隊則是在產品成熟後，針對產品的各項功能 (features) 與各項界面進行測試，包含是以使用者的角度來進行測試，其測試的出發點與思考點是與開發團隊不一樣的，而為了有效的確保測試品質與測試涵蓋率，於是藉由撰寫明確的測試案例來加以輔助，因此這份測試案例使給測試團隊使用的。

實務上，有時某些測試項目需要重複性的建立相似的資料後才能加以測試，例如需要事先建立十筆甚至百筆用戶資料，然後進行搜尋測試，測試團隊會與開發團隊合作另行開發小的程式以匯入背景資料，來輔助實際想測試的搜尋功能。類似這樣的例子，在開發團隊身上的應用更多，例如要進行某項單元測試，於是另行編寫某小程式來加以輔助。

又或者舉例開發團隊要確保某日文化產品有確實日文化，沒有亂碼產生，則可能另行編寫小程式來掃描產品裡出現的所有字串其字元所屬的編碼區段，來加以判斷。

如今，如果要開發者照著測試團的的測試案例進行測試，例如要安裝好產品，開啟產品，然後逐一操作每一項功能、輸入資料、搜尋資料、刪除資料等等步驟，以確保產品的品質，這是說不過去的，不是不能做，而是搞錯各自應有的焦點了。理論上如果開發團隊果真把測試案例完整跑完，並且修正了所有發現的錯誤，然後交付測試團隊進行測試，那麼我們每次都可以得到零缺陷的測試報告，看似產品品質相當優良，但 stakeholders 大概沒多久之後就會考慮裁撤測試部門了。

總之，開發團隊交付的成品，其品質過低，所要採取的是不一樣的手段，該手段也許不會完美，但那也是為什麼我們需要將產品的品質把關交給最後一線的專業測試團隊為之的道理。