1、測試要盡早
公司的產品已經修訂一段時間了，但是由于任務繁忙和人手不足，因此測試一直拖后，因此當進行集中測試的時候Bug集中爆發，因此感覺更加的繁忙，另外由于很多功能和修訂，都已經修改了很長的時間，因此程序員再次進入修改的時候，往往需要重新分析和理解，造成Bug的修復周期延長了很多。
建議當完成功能修訂后，要盡快進入測試狀態，以縮短Bug的存在時間，降低程序員修訂成本。
2、使用好的缺陷管理工具
之前公司只是使用一個BBS作為缺陷的跟蹤和管理工具，但是，效果很不理想，雖然缺陷管理的工具很多，但是都有自己的長處和短處，后來使用了TD，效果的確好的多。
3、缺陷描述要準確
很多測試人員反饋的缺陷，程序員讀起來十分的費勁，甚至比理解缺陷本身還要難懂，因此，如果缺陷后，在登記的時候，一定要盡量描述準確和清晰，以免造成錯誤的理解，反而更加干擾缺陷的修訂。如果缺陷的確很難描述，可以將缺陷的發生過程錄制下來，或者干脆手工給程序員演示一遍，效果就更好了。
4、缺陷描述不完整
很多缺陷都是有前世和今生的，因此把缺陷產生的出發條件描述的完整，對解決缺陷起著很重要的作用。
5、缺陷要分等級
缺陷都是要優先級別的，嚴重的當然要盡快解決，低級別的放一放。
6、開發和測試最好不同步
公司是早上8：30上班，一般是9：00左右才能給測試部一個新的測試版本，而如果Build出現意外，則新的版本發布就會推遲，因此開發和測試一定要有個時間差，開發部最好在早上第1時間給測試部一個最新的測試版本。一種是開發部早點來，一種是晚點走，最后我們的約定是下午4:30分開發部Build版本給測試部明天使用。
7、優先驗證Fixed狀態的缺陷
測試部每天最優先的任務就是驗證新版本中Fixed狀態的缺陷是否正確，這個很主要，因為開發部剛剛修正，如果沒有驗證通過，程序員可以立刻進行修訂，如果過了很長時間才通知沒有通過，那么可能程序員還得重新理解和分析代碼。
延伸閱讀
文章來源于領測軟件測試網 http://www.anti-gravitydesign.com/
