上次我們同時就投資方和工程師角度談了如何把測試做得更好。這次則是怎樣在商業競爭中發揮測試的作用。
測試的回報跟商業競爭有什麼聯絡呢？如果只是從產品角度而言，談不上太多聯絡，畢竟產品只是商業競爭中的其中乙個因素。但是試想如果測試不限於發現產品的bug
，而是再進一步，去發現專案的bug
和團隊的bug
呢？何謂專案的
bug？乙個專案的目標是要在給定的人力物力時間內生產預期質量的產品，如果乙個專案最終沒有達到預期目標，大多數情況下是由整個專案週期內產生的各種各樣的問題所導致的。這些問題或許在專案最後階段才暴露，但是通常是較早的時候就埋伏下來的。聽上去很像對bug
的描述吧？所以，你可以把它稱作專案的bug。l
舉個例子，測試用例如果覆蓋的範圍不夠，——這一點通常不容易直觀的發現，產品的一些部分或許從頭到尾就沒有執行或者驗證過。這樣有些產品上的bug
就找不到了，運氣不好的話就可以出現很嚴重的bug
。所以，測試用例覆蓋不夠，這就是一種專案的bug
，它呈現了專案執行中沒***產品具備足夠測試覆蓋的缺陷。
l另乙個例子，一些測試用例這段時間能通過，那段時間就通不過，也就是不夠穩定。這種情況要麼是因為產品不夠穩定，要麼是因為測試用例設計得不合理，如果是自動化的測試用例，則尤其容易是因為測試**不夠穩定。不管怎樣，到底產品有沒有bug
呢？這可不知道了，於是開發人員和測試人員容易在上面扯皮、吵架、不了了之，然後發布之後再暴露出來。所以，測試用例不能穩定的通過，也是一種專案的bug
，它呈現了專案執行中沒有充分了解測試用例失敗根源的缺陷。
那何謂團隊的
bug呢？乙個人的精力和工作效率是有限的，如果團隊成員花在無效工作上的時間比較多，相應的花在有效工作上的時間就較少。同時如果團隊成員感覺到自己花了較多時間在無效工作上，因為心理的因素，他/
她的精力和工作效率就會降低。這些問題會導致團隊生產效率下降，長時間的積累會導致士氣下降以及人員流失。對乙個追求長期及穩定業績的公司來說，這可不是個好事。這些問題也是較早的時候埋伏，後來才暴露，所以，你可以把他們稱作團隊的bug。l
」）的時間很長。為了把**提交到**庫，這樣的工作是無可厚非的質量保障。但是如果需要的時間很長，例如乙個程式設計師花了乙個小時寫**，等待一次提交所需的編譯檢查或者「路障測試」花了三個小時，如果他/
她的進度壓力很大，他/
她就傾向於花六個小時寫六倍的**，然後提交，下班，第二天早上再看看有沒有出問題。這樣做的結果是，要麼因為短時間寫了過多的**，質量非常差，一次又一次的通不過編譯檢查或者「路障測試」；要麼因為六倍的**需要十倍的小心，為保證質量工作強度過大或者工作時間過長，程式設計師心力交瘁或者失去熱情。可見在這個例子裡，團隊成員無意識地把時間花在不必要的過多**的質量保證上。問題是，很少人想到根本原因是等待時間，員工認為老闆逼著加班，老闆認為員工技術水平不夠。試想如果只需十分鐘的等待，還會有人一天只提交一次總共數千行的**，只因為受不了等十分鐘嗎？
l另乙個例子，修復bug
的階段，有可能**的改動速度非常快，產品內部版本的變動也很快，例如一天一次，回歸測試一次的時間卻非常長，例如乙個星期。那麼這個星期一開始的回歸測試，得到報告已經是下個星期一了。如果這裡面發現了乙個bug
，開發人員該在哪個版本上debug
呢？上個星期一的嗎？就算知道根源在哪又該如何修復呢？**都改得天翻地覆了，而且好像該修復的地方也改過了，所以只好說，再做一次回歸測試看看能不能重現吧。但是改得這麼快，bug
是很容易一會兒能重現一會兒又不能重現的。於是，幾乎每個找到的bug
都不了了之，每次debug
都不了了之，自然開發和測試團隊會扯皮吵架。這樣能不洩氣嗎？開發和測試團隊的關係能好嗎？他們還可能合作改善產品質量嗎？
這兩種bug
對軟體企業專案團隊的殺傷力在於，要麼問題不容易發現，要麼是專案情況逐漸變化，導致「每一步變化都好像沒問題，量變卻引起質變」，等到後果出現時，就好比產品已經發布，缺陷已經造成惡果了。而且造成的惡果往往被解釋為領導和員工關係、部門之間關係的緣故，這樣團隊成員走馬燈的換，結果卻沒多大變化。
這樣就跟商業競爭有關係啦？關係大著呢！軟體企業最重要的資產是什麼？大樓？電腦？資料中心？都不是，是團隊，是人力資源。如果軟體企業的團隊生產力被損害了，還能指望在商業競爭中勝出嗎？現在明擺著一系列殺傷團隊的bug
，測試團隊上去預防、發現和修復這些bug
，這是不是商業競爭的重要組成部分？
那麼乙個測試團隊該如何發現這兩種bug
呢？測試不外乎產生輸入、檢驗輸出。現在團隊作為乙個有機整體，無時無刻不在接受外界的各種輸入：需求、任務、計畫、進度……
所以，收集輸出並作出分析，就是最重要的手段，學術上稱為「衡量」（metrics
）。注意，大量書籍文章談論的是軟體度量（software measurement
或者software metrics
），這裡說的是對專案和團隊本身作為乙個系統的衡量。在上述的例子中，測試團隊可以衡量測試覆蓋率、測試結果穩定性、**提交驗證過程耗時、平均**提交頻率、提交驗證失敗率、回歸測試耗時、修復階段**提交速度（例如千**行/
天）、修復bug
的平均時間等等，目的在於發現專案和團隊在工程活動中各個影響因素是否產生了不利於專案和團隊長期和穩定業績的後果。
乙個測試團隊要高質量的做到這一點，需要相應的理論知識。這正是當前測試業界所忽視的乙個領域：系統工程（system engineering
）。系統工程關注作為整體的系統各部分及其相互影響的關係。顯然，計算機專業教授這門課的不太多，自然難以期望測試團隊普遍具備這方面的理論知識。正因為如此，誰占領了這個制高點，誰就更能成為軟體企業中的關鍵因素。
中國服務外包從優勢到勝勢
印度第一大軟體企業塔塔諮詢服務 在北京的分公司就設在中關村軟體園一棟別緻的小樓內。每當中國同行在此經過時，多少會感到有些異樣，因為他們知道，最強勁的對手已經打到了家門口 同樣，樓裡的印度人也覺得很不爽，因為中國人正在從各個方向衝擊著他們在服務外包領域的霸主地位。以往，像紐約服務外包大會這樣的場合完全...
《從優秀到卓越》讀後感
今天早上讀了 從優秀到卓越 這本書，感覺很好，裡面有很多的觀點是我很贊同的，所以就忍不住寫了一篇讀後感了，這裡主要寫出了這本書中的重要概念以及自己對它的理解。第五級經理人 謙虛 待人 堅定 做事 補償機制 不是為了讓不合適的雇員作出正確的舉動，而是要讓合適的雇員能夠上車，並保證他們能留在這兒 任何卓...
從優秀到卓越 反思應該如何創業
閒扯 最近也算忙裡偷閒，專案開發進度比較穩定就抽空出來看看書，恰好近期不止一次聽到別人推薦此書，甚至被推崇為創業的必讀書籍。讀完後感覺真是一本縱觀幾十年發展精華的大作，後悔未能早點看到。對於書中的一些觀點自己再總結歸納一下，以備後忘。精彩之處 這是一本分析了從1965 1995年美國上市公司發展的情...