標籤:des blog http 使用 strong 資料
15.3.1 有些成功人士或公司認為不需要獨立的測試角色(Test),你怎麼看?
我猜想和踢足球類似,還是那幾個原因:
人太牛: 不世出的天才,例如高德納寫書時發現排版軟體不好用,就自己寫了一個。也沒聽說他為這個軟體項目請了什麼獨立測試人員。對了,他不讀Email,有秘書幫他處理這些事——這也是一種分工!
有些軟體工程師是在後台鑽研和開發高難度的演算法,或者做某種背景處理工作,這個工作本身的難度較高,測試主要是自己通過工具完成。如果一定要找一個測試人員,這個測試人員的水平要相當高才行,如果水平那麼高,那就不如也一起參與開發就好了。
事太小:“我寫了個小類庫,全部自己測試”,這當然不錯。
但是如果由此論點出發,大力順水推舟,推廣到所有情況,從而得出“程式員就應該自己測試,專職測試不需要”這樣的結論,明顯不合適。
人不夠: 那就自己動手多做一些事情,也挺好。就像前面提到的,一個人可以扮演多個角色。
無知: 這就不好說什麼了。
15.3.2 為什麼一些成功的公司不用測試人員
引起網上討論的兩篇文章在這裡:
http://sriramk.com/blog/2012/01/testing.html中文翻譯在:http://www.aqee.net/on-testers-and-testing/。
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)這樣的文化、流程、開發商和給力的前員工,而且你的軟體“大體上也不要太高品質”,你的確不需要什麼全職測試人員!
15.3.3 微軟是怎麼做的呢?
就像MSF原則講的那樣,有分工,有合作。微軟開發測試主要有三種角色[i]:
- SDE:Software Design Engineer,簡稱dev。
- SDE/T:Software Design Engineer in Test,也寫代碼,但是重點在測試。
- STE:Software Test Engineer。
對於如何更有效地開發互連網應用,微軟很多團隊都做過不少探索。微軟公司在創業之初也沒有多少專門的測試人員,在1984年的時候,開發:測試的比例是20:1. 後來隨著產品線的變化,有些項目的測試人員比例幾乎和開發人員一樣多。最近,一些團隊,是做互連網業務相關的,嘗試把SDE和SDE/T合成一體。每個人都負責開發/測試/發布這一整套流程。這種做法,根據我的觀察,有好處,也有額外的成本。
15.3.4
團隊應該如何安排
QA 和測試工作
測試、品質保障、軟體工程的品質,團隊和個人到底應該怎麼辦呢?我認為,
- 在初始階段(新項目,團隊進入一個新領域,人員剛進入一個項目),每個團隊成員都要盡量打通各個環節,多負責,把所有事情都搞懂,培養通才。
- 當項目/產業發展到一定階段(進入陣地戰的時候),要大力提倡分工合作,培養專才。同時,要把好的工具和流程整合起來,從每日構建,到準系統的自動化,都要儘快實現。
- 把自己項目的架構和流程做好,讓所有人都能比較容易地進行QA工作,這樣,團隊的“軟體工程品質”才會有提高。
- 培養“大家都要做QA,專人負責量化的Test,有條件多做測試自動化”的文化。
- 要明白自己項目的特點,避免照搬別人的做法。不要聽說某某偉大的項目的開發/測試比例是多少,因此就哭著喊著也要同樣的比例。
- 如果一個團隊是認真嚴肅地做軟體,那他們一定要考慮如何保證程式的品質/軟體工程的品質,以及達到這些品質,需要多少成本。
15.3.5 測試人員的職業發展
分工之後,每人負責一小塊東西,怎麼才能體現出個人的獨特而巨大的價值呢?例如,你剛到一家出版社,領導讓你做“二審”這份工作,或者你剛到一個軟體公司,領導讓你做“測試”這份工作,你怎麼才能展現出你獨特的價值呢?
請找到幾個軟體測試工程師(例如,軟體學院的測試專業早幾年畢業的師兄師姐,測試論壇上活躍的使用者,軟體公司的測試人員),和他們瞭解並探討測試這門專業。
[i] 這本書講了不少微軟公司各種角色的故事: How To Move Mount Fuji, 作者: William Poundstone, ISBN 0316778494