軟件缺陷大致有三種：做的事情不是客戶想要的、做了不該做的事情、做錯了事情。
這裡我們不認為第一種是缺陷，出現這種情況的原因非常多，比如需求沒有挖掘到位、分析誤差導致設計偏離、開發人員理解差異導致實現的與需求不一樣，等等。
那麼，對第二種和第三種，原因主要就是編碼的問題了，基本上都是代碼的BUG問題，杜絕代碼錯誤，就能朝著 零缺陷 的方法邁進。
代碼錯誤只有通過測試來找，測試有黑盒測試、白盒測試，黑盒測試是有效的，但究錯誤源頭，大部分錯誤，還是只能通過白盒測試的方法來找，白盒測試一般只能由開發的自己做。而且假如是編碼運行時低級錯，假如不是由開發人員自己發現並修改，而是由測試人員發現出來，一個錯誤發現、修改、驗證，需要往復；測試發現了還好，假如沒有發現客戶使用時才發現，那其後果影響更大；許多錯誤累積，項目的周期、成本就這樣增大。
開發的自己測試有兩種，就是由具體開發人員自己測試，還有交叉測試，例如采用XP的結對編程方法，交叉測試也是有效的，但也費時，需要一些時間才能理解到別人編碼的含義，尤其編碼質量不佳時。
最直接的辦法的就是開發人員自己養成測試的習慣，用最笨也最有效的方法，那就是寫完代碼後立即實施基於單步跟蹤的測試。所花時間看似多一些，但總得來說比測試、客戶發現了缺陷再改時間要少得多。
在所有需要測試的方法、代碼執行分支（if代碼塊以及所有else代碼塊等等）設置斷點，代碼被執行到了就把斷點去掉，操作軟件測試運行並檢查中間變量值數據記錄等，或通過專門的測試界面、測試代碼、XUnit測試用例測試，直到所有斷點（紅色行）都被去掉。
修改已有代碼也一樣，變動的行都要單步跟蹤一遍，盡管自己對寫好的每一行代碼都有 101% 的信心。
自己寫的代碼當然都知道自己期望它該做什麼、不該做什麼，單步跟蹤，保證每行代碼都被執行到，都被執行至少一遍，這樣每行代碼沒有做不該做的事情、沒有運行時錯，就基本上是有保證的。
總結一句話：開發人員單步跟蹤測試自己的代碼，朝著 零缺陷 的方向，朝著勝利的方向
