上次翻譯了一篇文章——
Bug分析：爲bug預防奠定基礎， 強調軟件缺陷的預防。軟件質量是構建起來的，由軟件開發的整個過程質量所決定的，軟件質量肯定不是通過測試測出來的。所以軟件缺陷的預防自始至終是重要的。除了缺陷分析，另外一個很重要的實踐就是：代碼複審（code review）和測試用例的複審（Test Case review）。
1．Code review
在IBM、微軟等很多公司都有一個很好的實踐，那就是Code review - 代碼複審。這種代碼審查的過程，不是將代碼發給某一個人或某幾個人去看，而是強調程序員自己定期走上臺，向其他人講解自己源程序的活動。因爲要向大家講解自己的程序，show code to other guys, 程序員會極其重視自己的工作進度、代碼質量，在寫代碼時，就時刻想着——可能隨時會被選中去做code review, 所以非常認真對待每一行代碼。這種Code review 方式還有其它好處：
- 可以互相學習程序設計思想、方法和技巧，共同提高；
- 可以及時發現代碼的問題，包括代碼的Dependency的問題；
- 更多的人明白他人寫的代碼，今後代碼的維護也變得容易。
所以這種Code review 方式，被證明是一種行之有效的方法。
2．Test Case review
與Code review對應的，在測試/QA這邊進行Case review. 每一個QA工程師，都有機會被選中，通過投影機做Presentation，向大家講清楚他/她是如何設計測試用例（Test Case)的, 包括產品新特性的理解、對測試範圍的分析，考慮了哪些因素、哪些user scenario, 用例設計的思路是怎樣的？測試的覆蓋率如何？把主要的測試用例從頭到尾Show 一遍，等等。
每個人都有且必須有機會，這是關鍵。其次，Case review時，被選中的QA Engineer必須講解他/她如何寫Test case.
通過這樣的實踐和活動，可以更早地發現test case中的問題，相互啓發，相互學習test case design的技巧和方法，交流經驗。也督促每個人把測試用例設計好。好處也一樣多：
- 設計Test case之前，就會好好考慮各種因素、想清楚設計思路——覆蓋率提高。
- 認真寫好每一個Test case——單個case質量提高
- 更早地發現Test case的問題，包括相互影響的區域。
- 相互學習
- Test case維護更容易
Code review和Test Case review同樣蘊含了“缺陷預防”的思想。要提高質量，就如克勞士比所說，第一次就要把事情做對！如果系統分析員、架構設計師、設計人員、編程人員等所有人員都在第一次就要把事情做對，測試人員也許就不需要了。有一個例證，幾千人的印度軟件公司，只有5-6個真正的QA人員，但沒有一個測試人員，軟件產品質量依舊很好，再一次驗證了“質量是寫出來的，不是測出來的”。