我看了之後,由於自己不認同Arith的某些觀點,所以在自己的部落格留下我的看法。
Arith覺得
讓開發團隊參照或是逐一依照與測試團隊相同的測試案例來進行交付品質的確認,基本上是本末導致的行為。
因為
開發團隊自有另外一套測試方法,好比說針對單一目的的程式碼或是函式進行單元測試、邊界值測試等等。
測試團隊則是在產品成熟後,針對產品的各項功能 (features) 與各項界面進行測試,包含是以使用者的角度來進行測試,其測試的出發點與思考點是與開發團隊不一樣的,而為了有效的確保測試品質與測試涵蓋率,於是藉由撰寫明確的測試案例來加以輔助,因此這份測試案例使給測試團隊使用的。
但我從Arith的文章中看到的問題,不是「開發團隊要不要參照測試團隊相同的測試案例來進行交付品質確認」這麼表面,而是其他更重要的問題。為此,我從文章中歸納出了兩個結論。
第一個結論
我認為:這個開發團隊的測試方法品質不足!
如果開發團隊的測試方法有效果:
- 為何開發團隊找不到Arith所說「顯而易見不應該發生的錯誤」?
- Lead Engineer就不會「 一再囑咐我們交付送測前必須參照測試部門使用的測試案例來確保交付品質」
而且,很明顯Lead Engineer已經知道開發團隊的測試方法不可靠!
但他可能受限於時程、人力、權力、或其他的因素,無法在短時間內改善這些因素,所以他才提出「緊急應變處置手法」-要求開發團隊直接使用參照測試部門使用的測試案例來確保交付品質。
不幸的是開發團隊連這基本的要求也作不到,但這又是另一個問題了!
第二個結論
承上文,開發團隊不接受Lead Engineer的指示,我認為這表示這個開發團隊欠缺紀律。
因為一個有紀律的開發團隊,決對會服從Lead Engineer的指示,絕不會發生Arith所說「結果兩個開發團隊皆沒有完全施行」的情況。
「開發團隊的測試方法品質為何不足?」
這是我要問的第一個問題。
為了回答這個問題,我先從Bug從發生到解決的過程來說明:
註1:上半部是開發團隊的階段、下半部是測試團隊的階段
註2:每個活動名稱和細節可能會因為組織文化而有所差異。
開發團隊應該在交付測試團隊之前:
- 須管制所有的測試案例和Bug
- 排定每個版本該加入的功能、該修正的Bug
- 設計新功能的的測試案例、或將Bug轉換成單元測試(Dev Test Case)的測試案例
- 參照排定的版本依照測試案例(Dev Test Case)進行測試
- 依照測試結果提供Pre-Release Note交付測試
當然,前題是:
- 開發團隊已經制定、建立了上述的流程或方法,
- 開發團隊願意執行這套流程或方法。
這個流程或方法才能發揮效用。
但這個流程或方法要建立,則有一個很重要的障礙:開發團隊必須清楚地知道自己需要執行完整的(單元)測試。
這個障礙
看來很簡單,對專業的開發團隊一點都沒問題,因為他們早就接受這個觀念、並行之有年;但對不專業的開發團隊而言,卻很不容易接受這個觀念。
根據我的經驗,這些開發團隊總能想出些似是而非的藉口:
- 開發的時程過於緊湊
以致於抽不出時間寫測試個案 --> 但他們卻願意花時間解Bug?
當案也抽不出時間測試 --> 但他們卻有時間改Bug?
- 開發的人力不夠
抽不出人力寫測試個案 --> 但他們卻願意花更多的人力改Bug?
抽不出人力測試 --> 但他們卻願意花人力改Bug?
- 為了讓測試團隊有事作、不被裁員 --> 如果開發團隊果真把測試團隊的測試案例完整跑完,stakeholders 大概沒多久之後就會考慮裁撤測試部門了。
瞧!這些藉口是不是聽起來很熟悉?
「開發團隊為何欠缺紀律?」
這是我要問的第二個問題。
在《A→A+(Good to Great)》這本書中特別強調紀律:
有紀律的部隊才能打仗,沒有紀律的部隊就僅只是散兵遊勇。有紀律的員工、有紀律的思考,有紀律的行動,才能使企業邁向A+;因為員工有紀律,便不需層層管轄;思考有紀律,就不需官僚制度;行動有紀律,就不需過多掌控。
但Arith口中的開發團隊竟能忽視Lead Engineer的要求,令人覺得不可思議,更令人不可思議的是,有人竟視之為理所當然的事!
深究其原因,有可能是:
- Lead Engineer本身並沒有被授予更多的權力,以致無法約束、要求成員;
- Lead Engineer本身的工作太重,以致自顧不暇,無法兼顧數個專案;
- Lead Engineer本身的能力不足,無法領導成員;
- 開發團隊的能力跟不上信心自我膨脹,以致不願服務Lead Engineer的指令;
- 開發團隊根本沒有制定適合的開發規範/流程,以致成員無法遵行
當然也有可能隨著組織不同而有其他的原因,但不論是那個原因,Lead Engineer和他的主管都有責任必須認真檢討背後的真正原因。
如果是因為欠缺適合的開發規範/流程
那Lead Engineer和他的主管都必須檢討,是否該是訂定這些規範的時候了!
因為,如果開發團隊真的有訂定符合成員成熟度的開發規範/流程,根本不會流出像Arith所說「顯而易見不應該發生的錯誤」的軟體。
如果是和Lead Engineer有關
那就得觀察Lead Engineer的權、責是否相符,讓Lead Engineer能有足夠份量的棒子與胡蘿蔔要求組員。當然,Lead Engineer也必須為最後的結果負責。
此外,Lead Engineer本身的專業能力、工作經驗、管理能力都必須達到一定的水準,才能勝任,這個就得靠Lead Engineer的主管才能確認了!
如果是和開發團隊有關
那就得確認到底是能力的問題,還是意願的問題。
如果是能力問題,那還算容易克服,加強教育、並充份訓練,只要找對的方法,這個問題就能解決。
如果是意願問題,那就複雜了。管理階層就必須願意花時間和成本,和開發團隊充份溝通責任、成本、與品質的觀念,讓他們了解:
- 開發流程內的「下工程」就是客戶,每個上工程(自己)都有責任必須充份滿足他們的需求;
- 軟體系統若沒有一次作到好,再次修正的成本至少是原本一次作到好的三倍以上。
如果是和企業文化、風氣有關
這個就很難解了!因為,個人要改變這個環境幾乎是不可能的事,更何況會產生這個情況的絕不會無中生有、絕對其來有自。
遇到這個情況,我會建議你,你應該有腳,換下一個地方可能會更好,與其花精力和環境對抗,不如找個更適合自己的環境。
小結
我認為「軟體品質,人人有責」,在軟體開發流程內的每個成員,都必須將開發流程內的「下工程」視為客戶,並負起責任充份提供高品質的產出以充份滿足他們的需求。
如果他們能說出「但那也是為什麼我們需要將產品的品質把關交給最後一線的專業測試團隊為之的道理。」這種把品質交給別人把關這類不專業、而且是很落後的品質觀念(這個我會在之後的文章中說明)的論調,這除了證明了他們是不專業的工程師之外,我想不出這還能證明什麼事。
有那一個Google的工程師會在Blogspot上秀出「顯而易見不應該發生的錯誤」?
當然不會!
既然如此,誰能說自己的觀點一定正確?
謝謝回應,以及為自己以及大家分享了這麼篇縝密思考過後的文章。我原本的文章未經長時間思考,因此包含錯字以及多少夾雜些矛盾處,在所難免,感謝指教。
回覆刪除不過我原本並沒有「完全不認同」這麼強烈的感覺,難道我字裡行間這麼透露了?這我得好好檢討檢討。
實際上我所處的環境還更有趣些,我們做的是軟體本土化產業,所以嚴格來說不是從無到有的開發。本土化過程中,為了分工,發展出來一些方式來管理,適用於多語言同步上市的開發流程,或是適用於英文本上市才發展其他語言的開發流程。
常見的屬於後者。在這狀況之下會交雜著如果參考版本(英文版)已經有錯,那麼本地化版本修正與否的問題。有機會我再另文分享。
我原本的思考著眼點在於各有專職,開發團隊不是不注重品質,而是開發團隊在配有專業的測試團隊輔助之下,應當更能專注於開發之上。
我先僅簡單的表達幾個想法。您試想,測試領域裡有多少的測試方法來進行測試?blackbox, whitebox, full, smoke, sanity, BVT, FVT, regression, bounary, critical, stress....
如果要想為品管好好把關,那可以思考出很多不同的品管方式以應付各種開發的狀況。然而,當已經有專業的測試團隊存在之下,試問要求開發團隊照著測試團隊手上的完整測試案例,逐一對著產品進行測試,這用意何在?
我寧可相信測試團隊專業的測試經驗,寧可與測試團隊更加密切的配合與溝通,寧可盡量給測試團隊更充足的時間對產品進行品質把關,我也不覺得我應該花太多時間讓開發團隊的成員去執行測試團隊手上的測試案例。很淺顯的一點是,多數的開發團隊成員對於測試領域不熟,或說對於品管的方法不熟,這些成員熟的是程式,是產品開發。
我相信有些公司裡,專業的測試人員手上的測試案例是來自開發人員之手。但也請試想另一種狀況,及開發團隊所撰寫的測試案例是供開發人員使用,而測試團隊另行依照產品規格書去撰寫測試案例的狀況。這在大型專案裡其實是相當常見的。
因此我認為必須要先釐清公司裡的開發與測試團隊彼此之間的合作方式與默契是怎樣,再來討論怎樣是最佳的方式。
寫在最後,您有些評論或許針對常見的案例來下筆,不見得是針對我這的狀況,畢竟我也沒列出太多的前後背景,因此我想我也不必要逐一回應。只是整篇看下來,如果真是針對我所遇到的狀況來寫的話,那真是冤枉大了。
To Arith,
回覆刪除謝謝你的回應。
DEAR
回覆刪除我是ZDNet的蔡宜秀,請問可以引用這篇文章嗎?
Hi 宜秀,
回覆刪除請引用!