更好的團隊合作之缺陷篇：有效溝通的10個建議(3)

　　在缺陷分析和評估的過程中，可能會使用不同的缺陷相關的度量，例如：各種缺陷狀態的累計數量、新提交的缺陷和已處理的缺陷之間的對比關系、新提交的缺陷和已關閉的缺陷之間的對比關系、缺陷不同優先級的分布情況、缺陷不同嚴重程度的分布情況、發現的缺陷在不同模塊之間的分布等。根據不同的組織策略和項目特點，可以選擇不同度量指標對測試進度、測試質量、產品質量等進行分析。

　　8)不要期望修復所有發現的缺陷

　　測試的主要目的是發現軟件中的缺陷，同時為項目成員和管理人員提供關于軟件系統的足夠的信息，幫助他們做出正確的決定。從測試人員的角度，總是希望發現的缺陷能夠全部解決，而項目管理人員對缺陷的修復考慮得可能更多。例如：

　　◆ 項目層面：全局考慮缺陷的嚴重程度和優先級。在有限的時間內，首先解決那些優先級或嚴重程度高的缺陷。

　　◆ 風險因素：修改每個缺陷都可能在代碼中引入新的缺陷。假如修改一個小的缺陷可能產生更嚴重的軟件錯誤，或者存在產生更嚴重軟件錯誤的風險，就需要考慮是不是在當前版本中修改這個缺陷。

　　◆ 成本因素：有的缺陷修復的成本可能會高于修復后得到的收益，例如：缺陷所在的軟件模塊，在用戶使用中的優先級并不是很高，而項目的進度很緊。這個時候，項目團隊可能會選擇先發布軟件版本，而在下一個版本中修復該缺陷。

　　不管是對測試活動，還是對測試中發現的缺陷的修復，都需要在時間、成本、質量和風險之間平衡。測試人員也應該站在更高的層面對待測試活動，以及每個測試活動的工作產品。

　　9)不要讓延遲修復的缺陷消失

　　在測試過程中發現的一些缺陷并不一定在當前版本中修復。對于不在當前版本修復的缺陷，測試人員和項目管理人員都應該對它們進行跟蹤和管理，避免此類缺陷的消失。假如延遲修復的缺陷計劃在下個版本中進行修復，那么下一個版本啟動的同時，就啟動這些缺陷的修復任務，因為這個時候項目的進度壓力、工作量壓力和時間壓力是最小的。

　　10)變更和變更的溝通

　　測試過程中經常發生的一個問題是：當測試人員提交缺陷報告后，開發人員直接拒絕了缺陷報告，并通知測試人員系統的設計已經被修改。為了避免類似情況的發生，測試人員或者測試經理需要采取一些措施，例如：

　　◆ 在提交缺陷報告之前，假如時間和條件允許，要求開發人員在測試環境中確認缺陷的存在，可以避免這樣的問題。

　　◆ 假如組織或者項目有成熟的版本管理系統，那么要求開發人員按照版本管理的要求進行相關文檔的修改，從而可以使測試人員了解軟件設計的變更，避免測試時間和測試資源的浪費，提高測試的效率。

　　◆ 假如組織或者項目沒有版本管理系統，那么測試經理和開發經理之間需要有良好的溝通。測試經理可以要求開發經理在作為測試依據的開發文檔發生變更時，告知測試經理，從而避免這種問題的發生。

原文轉自：http://www.anti-gravitydesign.com