通常的做法是通過更多的
單元測試 （Unit
test） 和code review，使得我們在開發階段發現更多的問題，從而減少bug數。的確，開發人員經常單元測試，具有良好的測試和編程習慣，在每次check-in之前，或每次打baseline之前，項目組都有代碼cross review，同級或跨級評審，自己代碼每日評審能大大保證代碼質量，在提交給測試組之前就消除大量的bug。但往往發現更大多數的bug是我們通過 Unit test和code review所不能發現的。為什么？
1、首先是需求的不明確，比如客戶原先對軟件的部署的需求就是和一般軟件一樣，沒啥特定需求，后來項目進行到后期部署階段發現有更多的部署需求，比如Failover，并行部署，對vista的兼容性等等。這些都帶來的新的問題和代碼修改量。
2、其次是需求理解的偏差，設計理解的偏差，比如一個員工對保險業務不熟悉，去開發保險業務IT系統的時候，往往開發出來的功能和實際業務需求相差很遠。對需求理解的偏差，以及對設計理解的偏差，也有部分原因是因為溝通，沒有良好的溝通，導致沒有傾聽客戶的訴求和用戶的反饋，和客戶溝通的問題導致需求偏差，軟件沒有對客戶產生價值，這種bug的比例非常高。
3、再次是程序員本身能力的限制，比如代碼前期都認真經過了單元測試和功能測試，但后期發現運行效率很低，性能不好，原因在于程序員是用他們不熟悉的語言進行開發，而且對性能設計沒有經驗，開發中根本沒有性能上的考慮。如何保證一個程序員進入一個項目開發之前，已經掌握了足夠的編程語言知識和技能，已經掌握了足夠的業務知識？如果這些程序員經過技術和業務兩方面的培訓，可能會避免這方面的問題。
4、最后是沒有一套好的研發流程，質量管理體系，和配套的支持工具。這是最大的一個問題。如何找到一個適合自身公司文化和項目情況的process？
總之，軟件開發和編程是一項智力活動，從獲得需求、理解需求、程序設計、程序編碼（數據結構 + 算法）、單元測試、功能測試、提交的整個過程中，任何一步出現偏差都可能產生bug。
當然，測試組的嚴格測試能保證軟件的質量，但問題是如何主動防范bug？
1、程序員的技術能力和經驗很重要，比如：代碼設計能力，良好的編程習慣，良好的數據結構和算法，編程規范的遵守，隨時資源的釋放，避免內存泄漏，避免導致性能下降的代碼，異常處理，以及對維護、部署、可用性、性能、穩定性的全面，良好的文檔和注釋習慣等等。另外，項目采用新的架構、框架或技術（例如Spring， Castle， WCF），都會因為程序員不熟悉而引入更多的bug和風險。
2、程序員的業務積累和經驗很重要，大大有助于對需求的理解和把握。這非常關鍵。例如一個程序員做過老版本的銀行清算系統，他不僅熟悉清算業務流程，而且知道老系統存在的問題，就會主動防止這些問題，準備高效的實現新系統。
3、測試組的測試活動不僅僅是找出bug，而且要通過測試來規范項目開發過程，從而提高軟件產品的質量。測試通過了，bug都改完了，項目結束了？其實測試組可以總結和分析下bug產生的原因和分布，這個bug list和分布圖交給開發組長和開發人員，可以分析發現開發人員經常哪兒引入bug，從而在以后的開發活動中避免這些問題，實現項目組的積累。其實可能80%的bug分布在20%的模塊，因此從各個方面分析bug的根源，可以總結出項目組可以改進的地方。
最后，從根本上來說，作為軟件產品與服務的提供者，只有真正理解客戶的業務、順應客戶的需求才能提供令客戶滿意的產品與服務。應當以一個用戶角色的眼光去重新審視為用戶提供的技術解決方案和產品，是否是用戶所真正關心的，是否真正解決了用戶的問題。對于客戶而言，最有價值的不是你掌握哪些技術，而是你能幫他們解決哪些問題，產生哪些價值。IBM推行OnDemand隨需應變的服務， 因為在當今市場競爭日趨激烈的今天，“求變” 已經是必不可少的生存法則。這個求變的過程，需要軟件公司到技術人員的蛻變，從靈活多變的業務，到隨需應變的技術，不管客戶的業務和管理流程、需求如何變化，技術都只是業務變革的推進動力和實現工具，bug free（無缺陷）的軟件背后其實是對業務和需求的深刻理解和行業積累，先進的技術實力，完善的質量管理體系，和軟件開發流程。