我們知道開發人員與測試人員在某種程度上可以說是冤家對頭，因為開發總是認為我做的產品是完美無缺的，沒有Bug的，但是測試總是想方設法給你挑刺，因而產生了“矛盾”。很多公司對開發的績效評估里就有一條是每千行代碼產生的Bug量，當然是越少越好了，但是對于測試的績效評估也有一條平均每天提交的Bug量，所以表明上看起來這種矛盾真的是無法避免的，因為大家都要“混飯”吃的。
但是大家其實心里都很清楚，一個產品不可能沒有Bug的，或多或少，或大或小，總是會有Bug存在，不然微軟也不會這樣經常發布補丁了，連微軟這種級別的公司都會Bug，所以對于Bug的存在，我們大可以泰然處之。
雖然可以泰然處之，但是對于Bug我們還是需要很重視，因為既然產生Bug，總是某一方面沒有想到或者是想錯了，所以我是建議可以通過對Bug分布進行分析，找出哪些地方特別容易出Bug，然后在開發過程中特別注意。對于我們公司而言，之前說過了我們是用TechExcel DevSuite 系統來管理，所以我們在開發中會加入幾個強制檢查項，比如說是否兼容不同數據庫，是否支持不同語言，是否考慮過不同瀏覽器，開發在完成代碼如果不檢查這幾項的話，是無法把開發任務直接交給測試來測的，這樣就可以從某種程度上避免一些Bug的產生。
不過即使避免了總還是會有一些Bug會被找到的，呵呵，沒有Bug還要測試干嘛呀？在很多公司里測試人員的數量都大于開發人員的，像微軟這種公司，可能是2：1的關系，為什么需要這么多測試呢？
第一方面，當然是他們的產品太大了，太復雜了
第二方面，一個產品的質量光靠開發是不行的，因為開發雖然能把產品做出來，也可能可以用，但是他們可能沒法考慮其他一些方面，比如用戶體驗上，比如壓力測試上，比如不同語言下的應用，甚至是不同操作系統下的應用等等，這些方面光靠開發可能沒法想全，甚至即使想全了也做了，你能保證在哪些環境就一定不出問題嗎，畢竟開發編程總是在一個環境下的編的，他編完即使自己測了一下也不可能把所有環境下都測過的。
第三方面，因為一個產品/一個功能需要在很多外在環境下測試（操作系統，數據庫，瀏覽器，網絡），另外一個功能需要測試點又很多（正常輸入，非正常輸入，臨界，壓力值等），所以即使是一個功能，需要測試的地方就很多，何況產品大功能多的了。而且，我們知道一個人再強，他能想到的測試點總是有限的，所以我還需要另外的人對一個已經測過的功能點進行再次驗證測試 （關于這個方面，由于我們公司是用DevSuite 方案中的 DevTest 工具來管理測試覆蓋面的，所以稍微可以減少一些測試人員配置）。另外對于一個開發來講，由于功能點是他做的，所以別人發現了問題讓他修，其實他是可以修起來很快，代碼都輕車熟路的，所以如果一個測試配一個開發的話，可能發現的Bug量無法讓開發完全忙起來，從領導角度說這個比較浪費成本的。
所以考慮到這些原因，一般大公司就會有很多的測試人員了，當然現在的情況又有不少改變了，隨著自動化測試的引入，需要人工的地方會相對減少，所以有不少公司開始減少純手工測試的活，但是做過開發的人也知道，如果一個產品很復雜，光靠自動化測試是遠遠不夠的，所以呢，我相信手工測試還會在很長時間內存在，至少在我能看到的范圍呢，好像還沒法用自動化測試來代替。
不過在國內的話，我接觸到的大多數軟件公司里，對測試人員的配置都不太多，當然我不認為他們是忽視軟件質量，他們可能認為功能做出來了，開發直接測一下就好了，測試人員的話只要最后綜合跑一下就Ok了。我相信這個是怎么保證軟件質量的一種認知的觀念問題，我認為這樣就可以保證產品質量，你認為那樣才可以保證質量，大家各有說法，但是從我們公司的角度來說，我們還是比較看重質量的，可能也跟我們公司背景有關吧，外企，跟國外比較接軌。所以我們公司現在的開發與測試配置是大于1：1的，不過比微軟還是差一點。
介紹了一下測試的必要性，再回過頭來繼續說開發與測試的“矛盾”，其實這個矛盾從本質上來說是由于績效管理時過分強調了開發人員造成的Bug，而這個“過分強調”又必須是測試人員一定要強調的。所以呢，矛盾就開始產生了，開發說，這個不是Bug，或者說我不能重現，還說，你干嘛老是提Bug，是不是對我有啥不滿的。久而久之，“矛盾”產生了，激化了，產品質量下降了......從領導層角度來說，他們當然也希望開發做出來產品是沒有Bug的，這樣子我連測試人員都不用配了，成本下降很多了。當然，大多數領導也知道這個是不可能的，與其由于產品質量下降造成產品不好賣，還不如配幾個測試人員了。配了測試人員，又出現“矛盾”了，我想許多公司的領導已經處理得很好了，不過我還是想簡單介紹一下我們公司的處理方案：
1、把產品的銷售業績與開發、測試綁定，也就是說銷售得好，獎金就多，當然要銷售得好，產品質量也得好，那就得開發與測試相互合作了?，F在許多公司其實開發與測試工資與獎金比較固定，不會因為業績好而增加獎金之類的。我們公司有明確規定，這個產品利潤的百分之幾是歸開發，百分之幾歸測試，從而從制度上就讓開發與測試有了定心丸，去好好把產品質量搞好。
2、在對于各個銷售人員的績效考核上，增加其他考核項，把每千行Bug的產生量權重降低，增加諸如，Bug修復成功率，類似功能再次出現Bug的百分比，與測試人員合作效率等考核項，這樣子的話，開發人員就會開始很重視和測試人員的交流，因為他們開始知道跟測試人員的合作好壞決定了他們能拿到的Money。（剛才有人問怎么拿到這些類似Bug 修復成功率這種值，一般好一點的 Bug 管理工具里都能拿到，我們在 DevSuite 系統里自動生成的）
3、當然對測試人員也需要增加一些新的考核項，比如是Bug的描述是否能讓開發一次看清楚等。
通過這些措施，開發與測試的效率提高很多，從而使得產品質量也提高很多。哲學上說，矛盾是事物發展的動力，學會利用這種矛盾來讓公司健康穩健地發展是每個成功公司需要學會的，我們公司現在來說不能算特別成功，但是我們在這個方向上前進著。
后序：有個朋友評論說：（以下是原話）
軟件測試部門是輔助軟件開發部門將產品做好！
他們不是對立的關系，而是互相幫助的關系。
現實中，經?？吹窖邪l部門看不起測試部門，而測試部門則叫板研發部門，說產品存在如何多的問題。。。
牢記產品是做出來的，不是測試出來！
測試團隊一定要擺正自己的位置，是協助研發團隊將產品做好，提高產品質量！發現問題，跟蹤解決問題！一定不要將與研發人員的關系搞僵！
時刻牢記：大家是一個團隊！大家有一個共同的目標：將產品做好！開發與測試應該認識到大家是一個團隊，一個整體，只有緊密合作才能把產品做好出來。
其實大方向我還是比較認同的，確實，開發和測試需要緊密合作，發揮團隊精神才能把產品做好，這樣子產品才能有機會賣好，公司也才能發展，所以這個朋友評論的話，我覺得可以認為是一種理想的開發與測試關系。但是要實現這個理想的關系，光靠這兩個部門自身是無法徹底實現的，我們需要在整個公司層面制定合理的制度，從根本上解決問題。假設我給開發的考核中代碼質量（也就是每千行出得Bug數）權重很大，而給測試人員考核時每日發現Bug數權重很大，勢必會造成開發與測試之間的某種矛盾加劇，其實他們也知道要合作，不能有矛盾，但是自己是出來打工的，你給我提這么多Bug，我錢就會少拿；我不給你提這么多Bug，我錢也少拿。 所以我寫這篇文章的目的，其實是怎么讓開發與測試達到一個理想的關系，而不是說開發與測試應該達到一個怎么樣的關系。