關(guān)于測試和測試人員
本文的作者Sriram Krishnan是一名程序員，曾在Yahoo和微軟工作過，開發(fā)過很多軟件，曾被紐約時報報道，寫過一本書，本文是他的一篇博客。
這些年來，我對測試工作、測試人員，以及整個軟件質(zhì)量管理體系形成了一些明確的觀點。受一篇關(guān)于Facebook的測試的帖子的啟發(fā)，我想把這些寫下來，用以拿給人看。有些觀點是有爭議的。事實上，即使在交談中稍微表現(xiàn)出這樣的看法，都會招致人們的鄙視。
本文的作者Sriram Krishnan和他的妻子
大多數(shù)的開發(fā)團(tuán)隊并不需要一個獨立的測試角色。即使有一個，他的所有的開發(fā)時間比上所有的測試時間應(yīng)該 >20:1。證據(jù)嗎?光看看一些從古至今最成功的軟件開發(fā)團(tuán)隊就知道了。不論是當(dāng)今的Facebook，還是30年前最初的NT團(tuán)隊，很多偉大的產(chǎn)品都是出自沒有或很少測試人員的團(tuán)隊。
開發(fā)人員應(yīng)該測試自己的代碼。沒什么可說的。背后的道理并不重要。這包括單元測試，全覆蓋的自動化測試或手工測試或組合測試。如果你的開發(fā)人員不能/不愿意或認(rèn)為這“不歸我管”，那你需要更好的程序員。
我有一些政治上不正確的話要說。一些大型的軟件開發(fā)公司會從一些不能勝任開發(fā)工作的程序員中選擇測試人員。我經(jīng)歷/聽說過很多在面試開發(fā)人員過程中有人說“他/她做開發(fā)不行。也許可以做測試?”這導(dǎo)致了一個被廣泛默認(rèn)，但很少公開宣稱的認(rèn)識：做測試的不如做開發(fā)的聰明。正是由于這普遍的偏見，少數(shù)一些對質(zhì)量和測試工作極具熱情和天賦的人受到了不公平的待遇。我知道他們，因為我曾經(jīng)和一些這樣的人一起工作過。
追求代碼測試覆蓋率是危險的。因為它很容易測量，它經(jīng)常會變成真正目標(biāo)的替代品——開發(fā)有質(zhì)量的軟件。如果你的開發(fā)團(tuán)隊把功夫都用在寫愚蠢的測試，來覆蓋每一個罕有能用到的代碼路徑——因為這些數(shù)據(jù)會出現(xiàn)在一些報告里——你有問題了。測試覆蓋率只是我們用的的很多指標(biāo)中的一個，你需要使用它，但并不是因為它以自然的數(shù)字呈現(xiàn)，它就能壓倒其它指標(biāo)。它成了古德哈特法則的犧牲品。
我也曾看到有些公司里有獨立的測試人員，他們寫出非常好的測試代碼。不幸的是，這被人們當(dāng)成了一種常識，即使是在根本不需要這樣的時候。
正像測試覆蓋率被過度使用，有些質(zhì)量指標(biāo)是被忽略輕視了。比如：過程中產(chǎn)生了多少技術(shù)支持郵件?自己是否在任何時候都在真正的使用自己的產(chǎn)品，檢測里面的問題?分析從生產(chǎn)環(huán)境和客戶安裝那里產(chǎn)生的日志文件。所有的這些策略都在上面的Facebook的帖子里有提到過。
技術(shù)領(lǐng)導(dǎo)的一個常見的減少測試隊伍的體積的辦法是做自動化測試。這是個巨大的錯誤。如果你有一個用戶直接接觸的產(chǎn)品，你絕對需要用人眼去測試它。如果你和微軟Windows團(tuán)隊的人坐下來一起和咖啡，你會聽到他們抱怨過度依賴自動化測試導(dǎo)致了Windows Vista大量的bug。這個錯誤說明的問題就是：你需要一個全職的測試人員來使用你的產(chǎn)品。
【編輯推薦】
