軟件測試過程的監控方法(3)

　　如果是比較大的軟件開發項目，還會牽扯到：上線、割接、維護，一般會寫在前期 的合同中，客戶會按照上述階段點階段性付費，所以如果上述階段點沒有明確的成功、失敗判定標準的話，對于公司尾款的收取是個挑戰。

　　通過以上的詳細詢問，我相信，測試工作范圍界定的是否有問題，測試工作是否規劃的全面、細致，監控者應該比較清楚了，下面的任務就是將你的疑問記錄下來，留待后面做證實。

　　測試實施期

　　在這個階段，測試工作進行了一段時間，測試人員的工作應該已經步入正軌，按部就班的完成一些任務。這個階段的特點是：開發人員和測試人員都按照日常的規范開始有條不紊的工作，有可能對一些問題已經習以為常，或者已經被同化。作為測試工作的監控者，應該在看似合理的工作中找出影響質量的問題，規避風險。

　　在這個階段，應該關注以下問題。

　　l 缺陷管理流程是否規范?每個缺陷的提交和關閉是否都有復查?

　　缺陷管理是貫穿于整個軟件開發過程、測試過程的關鍵環節，也是測試工作的根本，所以缺陷管理的流程是否規范，將是監控的重點。

　　首先，需要詢問測試經理，軟件開發過程中對缺陷的實際管理情況是如何的?不要讓測試經理背誦公司的管理規范，而應該以一個實際缺陷為線索，追尋這個缺陷的產生直到關閉的過程是什么?期間是否有相關的記錄，證明項目組的實施過程完全與描述相一致。標準的缺陷管理流程是怎樣的，這里就不做敘述了，如果大家有興趣可以查閱相關的資料。

　　在這個過程中，還需要注意一點：缺陷的提交和關閉是否都進行了復查。

　　缺陷提交和關閉的復查人可以是測試經理，或者測試經理指定的人選，一方面經過復查，可以減少缺陷的重復提交，提高缺陷報告的質量，另一方面在測試組中會有一個人對系統或一個大組件的質量情況有比較全面的了解，尤其在后期，這種了解會在很大程度上降低系統誤發布的風險。還有一個好處是，在測試人員和開發人員交互的過程中，這個復查人員起到了橋梁的作用，可以有效的隔離開發與測試之間的多頭溝通，在一定程度上提高了效率。這個角色可以是專職的，也可以是兼職的，關鍵看系統的大小。

　　l 配置管理工作是否規范?測試過程中涉及到的版本是否都可以完整的追溯?測試版本的發放頻度是否符合測試的實際要求?

　　配置管理工作是整個軟件開發過程的生命線，相比較而言，開發人員對此應該更為關心。對于測試人員來講一方面要保證可以取到自己想要的文檔版本，另一方面必須得到自己關心的程序的任意一個測試版本，以便可以在正確的版本上執行正確的測試用例。

　　在實際檢查過程中可以在缺陷庫中任意選擇一個缺陷，查看這個缺陷是在那一個版本的程序中發現的，隨即在配置庫中調出該版本，看是否可以調出。隨后，查閱該缺陷在那一個版本中修訂正確了，隨即也在配置庫中調出該版本，看是否可查到。

　　在這個過程中，還需要注意開發部門提交給測試部門版本的頻繁度，看是否過快或者過慢。過快或者過慢，沒有一個時間上的判斷。比如每2天提供一個新版本供測試人員進行測試，這個是過快還是過慢?判斷的依據關鍵要看測試人員所處的狀態，當版本提交的過快時，測試人員一直忙于對已修訂好的缺陷進行反測，沒有時間對新功能進行測試。當版本提交過慢的時候，測試人員的時間比較空閑。

　　在監控過程中，只需要詢問測試人員的測試工作的緊張程度，一般就能夠判斷出版本提交的頻度是否有問題了。

　　l 關鍵測試活動的關鍵測試資源是否如期到位?如沒有到位是否進行了合理的規劃來完成延誤的測試工作?

　　在測試過程中，某些關鍵測試任務需要用到特殊的設備或者特殊人員的技能，稱為關鍵資源。在測試實施過程中，要提前計劃會用到那些關鍵資源，以免耽誤項目進度。

　　作為測試的監控者，需要非常關心這些關鍵資源的使用情況，因為如果關鍵資源不能如期到位，勢必要影響項目的整體進度。

　　如果由于某種原因，關鍵資源沒有如期到位時，要注意測試人員是否對計劃進行了修訂，修訂的結果是否可以彌補已經造成的損失，或者能最大程度的減少損失。

　　l 測試策略，測試計劃，測試方案，測試用例是否都經過了正式評審?發現的問題是否都進行了更正?

　　作為測試的監控者，不可能在短時間內評估一份測試計劃制定的是否合理有效，一份測試方案是否可以正確實施，并且也不必要這么做。

　　測試策略，測試計劃，測試方案，測試用例等文檔都是測試過程中的關鍵文檔，也直接決定了測試工作的質量。監控者在評價這些文檔的質量時，首先想到的一點就是我要充分的閱讀這些文檔，以我的經驗和能力來判斷這份文檔的好壞。但是，作為一個項目組以外的人，很難能就所有的細節發表高質量的看法，其次，也不可能在短時間內完成所有文檔的評價工作。所以這不是我們的解決方案。

　　在監控過程中，首先要相信項目組自身的能力，假定他們有能力完成這些工作，這樣工作就簡單了，也變得可以操作了。

　　首先，查閱這些文檔，大致看看，有沒有明顯的問題。其次，應該檢查這些文檔的評審記錄，看看相關的人員是否參加了該評審，都發現了什么問題，大家的意見和建議都有那些。最后，看看所有的發現的問題是否都得到了解決，文檔是否按照解決的方法進行了修訂。

　　在監控的過程中，默認參與評審的人員技術能力都符合要求，這樣只需要關注評審的過程就可以控制質量了。但是，如果有證據證明，評審的人員或者組成不符合要求，作為監控者應該宣布該文檔的評審無效，需重新進行評審，以解決問題。但是，使用這項權利的時候要小心，而且要充分論證，否則會擾亂項目組的正常次序。

　　l 測試的相關文檔是否都按照項目目前的實際情況進行了更新，并嚴格遵照執行?

　　經常會聽到一句話就是：計劃趕不上變化，這個問題就是沖著這句話來的。我在講課的過程中問過很多人這樣一個問題：不做計劃，直接做事情行不行?至今我還沒有遇到一個說行的。但是，如果計劃和行動不同步，這個和沒有計劃又有什么區別?

　　項目中有各種各樣的理由告訴你，我沒有同步計劃是合理的，但是我們的要求一定是必須有計劃，而且必須嚴格遵照執行，這才是降低系統風險的唯一合理方法。

原文轉自：http://www.kjueaiud.com