注意我們提到了“角色”,角色是有人來扮演的,如果一人扮演了“開發”的角色,又能夠來扮演“測試”的獨立角色,當然很好。但是條件是她要以“獨立”的心態測試,而不是想:“這代碼就是我寫的,哪會有什么錯…”而草草了事。
那么獨立的測試角色怎么才能發揮最大作用?從上面的壞現象中,我們不難總結出來。其實MSF原則都講到了。
·充分授權和信任(Empower team members)
·各司其職,對項目共同負責(Establish clear accountability and shared responsibility)
有些成功人士和成功的公司號稱沒必要有獨立的測試角色(Test),你怎么看?
我猜想和踢足球類似,還是那幾個原因:
1、人太牛:
不世出的天才,例如高德納寫書的時候發現排版軟件不好用,就自己寫了一個。也沒聽說他為這個軟件項目請了什么獨立測試人員。對了,他不讀email已經很多年,有秘書幫他處理這些事-這也是一種分工!
2、太?。?/p>
“我寫了個小類庫,全部自己測試”這當然不錯。
我以前的一個優秀實習生后來一個人嘗試寫一些UI的控件,寫得很高興的時候說了一句“我現在軟件工程的原則都不管了…”為了玩得爽,不妨打破束縛,諸法皆空,挺好。
但是順水推舟,推廣到所有情況,從而得出"程序員就應該自己測試,獨立測試不必了"這樣的普適結論,未免有點過。
3、人不夠:
那就自己動手多做一些事情,也挺好。就像前面提到的,一個人扮演多個角色,只要能入戲就行。
4、條件特殊:
近年來,軟件產業百舸爭流,魚龍混雜,在海里裸泳的弄潮兒也不少,出現了種種類型的分工合作和開發模式。不在有些情況下(例如一窩蜂模式,主治醫師模式),強力的dev是可以搞定很多事情。運用之妙,存乎一心。
引起網上討論的文章在這里:
http://www.quora.com/Is-it-true-that-Facebook-has-no-testers
其中打分最高的回答來自前雇員(Evan Priestley),他總結了Facebook這個公司為什么貌似沒有全職測試人員:
a、全公司人員經常使用自己的軟件產品!(如果你開發的軟件是航天飛行某控制模塊,你怎么能經常使用呢?)
b、使用log來分析問題可能出在哪里。(我們的一些程序員寫程序都沒有log,那大家看什么呢?
c、利用用戶的反饋和實時狀態分析(比較過去一小時和上周同一時間的數據來判斷是否有bug)
d、應用開發商給Facebook報bug。(開發商其實比較不爽,但是FB有時就是無預警地修改API,你除了趕緊報bug,還能怎么著?
e、很多人自愿給Facebook報bug,這位貼主自稱每月給他的前雇主報13,000個問題.(沒錯,是每月一萬三千個!)
f、最后這位前雇員還加了一句:還有一個原因是,Facebook大體上也不需要搞出太高水平的軟件。
當你的公司也能有a)到e)這樣的文化,流程,開發商和給力的前員工,而且你的軟件“大體上也不要太高質量”你的確不需要什么全職測試人員!
微軟是怎么做的呢?
就像MSF原則講的那樣,有分工,有合作。
微軟開發測試主要有三種角色:
·SDE: Software Design Engineer,簡稱dev。
·SDE/T: Software Design Engineer in Test,也寫代碼,但是重點在測試。
·STE: Software Test Engineer.
對于如何更有效地開發互聯網應用,微軟很多團隊都做過不少探索。例如一些團隊嘗試把SDE和SDE/T合成一體。每個人都負責開發/測試/發布這一整套流程,根據我的觀察,有好處,也有額外的成本。
結束
一位網友說得好:分工是社會和行業進化的結果。開發和測試其實是軟件工程的兩分支。不同的軟件/服務需要不同方式和程度的測試。獨立專業的測試等同于第三方代表客戶對產品認證。
拉拉扯扯這么多話,團隊/個人/角色到底應該怎么辦呢?我認為:
·在初始階段(新項目,團隊進入一個新領域,人員剛進入一個項目),每個團隊成員都要盡量打通各個環節,多負責,把所有事情都搞懂,培養通才。
·當項目/產業發展到一定階段(進入陣地戰的時候), 要大力提倡分工合作, 培養專才。
原文轉自:http://www.uml.org.cn/Test/201306061.asp