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