Categories

工作態度 (1)    方法論 (5)    本土化 (9)    危機管理 (2)    死亡 (1)    自我成長 (1)    自我管理 (3)    決策管理 (1)    版本 (1)    社會 (2)    品管 (3)    風險管理 (1)    效能 問題 (1)    時間管理 (5)    專案 (10)    教育 (1)    產能 (1)    產業 (5)    軟體 (4)    測試 (10)    閒聊 (14)    溝通 (4)    道德 (1)    漫談 (23)    管理 (1)    機器翻譯 (1)    簡轉繁 (2)    翻譯 (8)    booksore (1)    Chinese (1)    Flash (1)    G11N (1)    I18N (3)    Industry (1)    L10N (8)    politics (1)    Project Management (6)    Revision (1)    Software (3)    Testing (4)    Time Management (1)    Translation (4)    UI Design (1)   

2009年4月24日

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

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

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

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

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

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

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

5 Comments:

通達人 提到...

有白字:
文章Title「讓開發部們...」的「們」應為「門」
「理論上如果測試團隊果真把測試案例完整跑完,並且修正了所有發現的錯誤,然後交付測試團隊進行測試...」前面的「測試團隊」應為「開發團隊」。

我會寫一篇文章來回應你。

arithmandar 提到...

感謝指正,看得還真仔細。

通達人 提到...

我寫了這篇文章《沒有紀律,何來執行力?-回應Arith的文章》回應你。

fuyichin 提到...

看了通達人譯站的<沒有紀律,何來執行力?>與 arithmandar 的<讓開發部門參照與測試部門相同的測試案例進行品質測試>兩篇文章。基本上我認同 arithmandar 所說,測試團隊與開發團隊應該有兩套不同的測試方式,不然根本就不需要有兩個不同的部門。

不過 arithmandar 也沒有說明為什麼兩個開發團隊皆沒有完成的原因,是人力不足,時間不足,還是沒有辦法建立起測試團隊所列下的測試環境?

很多時候,在小團隊裡,開發團隊與測試團隊實為二合一,誰有空,誰就拿著測試文件,完成測試的工作。

通達人譯站與 arithmandar 應該來自不同的背景,恐怕那是無解的習題啊。

arithmandar 提到...

謝謝 fuyichin 的意見
兩個團隊最初皆沒有依照 lead 的要求, 另一個團隊的原因我不清楚, 不過還有個背景可以稍加解釋就是早先 lead 只是提到可以參照,而非要求一定要依照。
因此在我們這的團隊認為應該要採用不同的方式來作交付測試前的品質檢查,其實也與 lead 溝通過,原先他也是認同我們的提案,並表達會找時間來 implement 。
另外還有些特別的專案背景,在這就先不提了。

「通達人」的觀點比較是在團隊的紀律之上,多數的見解我是認同的。

但也許不同類型不同分工與不同任務類型的團隊組成,會有不同的最佳方法,但以已有專業且獨立的測試團隊來看,原則上我還是傾向於讓每個團隊能夠發會各自的專長。因為我見過不少程式開發者對於測試的專門領域真是一竅不通,抓不到重點。