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