缺陷管理是貫穿于整個軟件開發過程、測試過程的關鍵環節，也是測試工作的根本，所以缺陷管理的流程是否規范，將是監控的重點。
首先，需要詢問測試經理，軟件開發過程中對缺陷的實際管理情況是如何的?不要讓測試經理背誦公司的管理規范，而應該以一個實際缺陷為線索，追尋這個缺陷的產生直到關閉的過程是什么?期間是否有相關的記錄，證明項目組的實施過程完全與描述相一致。標準的缺陷管理流程是怎樣的，這里就不做敘述了，如果大家有興趣可以查閱相關的資料。
在這個過程中，還需要注意一點：缺陷的提交和關閉是否都進行了復查。
缺陷提交和關閉的復查人可以是測試經理，或者測試經理指定的人選，一方面經過復查，可以減少缺陷的重復提交，提高缺陷報告的質量，另一方面在測試組中會有一個人對系統或一個大組件的質量情況有比較全面的了解，尤其在后期，這種了解會在很大程度上降低系統誤發布的風險。還有一個好處是，在測試人員和開發人員交互的過程中，這個復查人員起到了橋梁的作用，可以有效的隔離開發與測試之間的多頭溝通，在一定程度上提高了效率。這個角色可以是專職的，也可以是兼職的，關鍵看系統的大小。
配置管理工作是否規范?測試過程中涉及到的版本是否都可以完整的追溯?測試版本的發放頻度是否符合測試的實際要求?
配置管理工作是整個軟件開發過程的生命線，相比較而言，開發人員對此應該更為關心。對于測試人員來講一方面要保證可以取到自己想要的文檔版本，另一方面必須得到自己關心的程序的任意一個測試版本，以便可以在正確的版本上執行正確的測試用例。
在實際檢查過程中可以在缺陷庫中任意選擇一個缺陷，查看這個缺陷是在那一個版本的程序中發現的，隨即在配置庫中調出該版本，看是否可以調出。隨后，查閱該缺陷在那一個版本中修訂正確了，隨即也在配置庫中調出該版本，看是否可查到。
在這個過程中，還需要注意開發部門提交給測試部門版本的頻繁度，看是否過快或者過慢。過快或者過慢，沒有一個時間上的判斷。比如每2天提供一個新版本供測試人員進行測試，這個是過快還是過慢?判斷的依據關鍵要看測試人員所處的狀態，當版本提交的過快時，測試人員一直忙于對已修訂好的缺陷進行反測，沒有時間對新功能進行測試。當版本提交過慢的時候，測試人員的時間比較空閑。
在監控過程中，只需要詢問測試人員的測試工作的緊張程度，一般就能夠判斷出版本提交的頻度是否有問題了。
關鍵測試活動的關鍵測試資源是否如期到位?如沒有到位是否進行了合理的規劃來完成延誤的測試工作?
在測試過程中，某些關鍵測試任務需要用到特殊的設備或者特殊人員的技能，稱為關鍵資源。在測試實施過程中，要提前計劃會用到那些關鍵資源，以免耽誤項目進度。
作為測試的監控者，需要非常關心這些關鍵資源的使用情況，因為如果關鍵資源不能如期到位，勢必要影響項目的整體進度。
如果由于某種原因，關鍵資源沒有如期到位時，要注意測試人員是否對計劃進行了修訂，修訂的結果是否可以彌補已經造成的損失，或者能最大程度的減少損失。
測試策略，測試計劃，測試方案，測試用例是否都經過了正式評審?發現的問題是否都進行了更正?
作為測試的監控者，不可能在短時間內評估一份測試計劃制定的是否合理有效，一份測試方案是否可以正確實施，并且也不必要這么做。
測試策略，測試計劃，測試方案，測試用例等文檔都是測試過程中的關鍵文檔，也直接決定了測試工作的質量。監控者在評價這些文檔的質量時，首先想到的一點就是我要充分的閱讀這些文檔，以我的經驗和能力來判斷這份文檔的好壞。但是，作為一個項目組以外的人，很難能就所有的細節發表高質量的看法，其次，也不可能在短時間內完成所有文檔的評價工作。所以這不是我們的解決方案。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
