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

　　有效地溝通可以在缺陷管理中避免項目利益相關者之間的相互指責，支持收集和解釋目標信息。缺陷報告的準確性、合理的分類和客觀的表述有助于改善缺陷報告提交人員和缺陷修復人員之間的關系。測試人員應考慮到缺陷的重要性，并提供可用的客觀信息。

　　缺陷評審會議應致力于進行適當的缺陷優先級和嚴重程度的判定。缺陷的跟蹤工具可以促進成員之間的溝通，缺陷評審會議并不能代替缺陷跟蹤工具。有效的溝通和良好的工具支持有助于實現高效的缺陷管理。下面介紹缺陷溝通過程的常見問題和注意事項。

　　1)缺陷的認定

　　測試人員提交缺陷報告后，經常會出現測試人員認為這是軟件系統的一個缺陷，而開發人員認為這是正常的系統功能。到底是缺陷還是正常功能?這是測試人員和開發人員在缺陷問題上經常出現的分歧。

　　測試人員對測試對象進行測試的時候要使用正確的測試依據(例如：需求規格說明)。軟件開發過程中，主要涉及的項目技術人員包括系統人員、開發人員和測試人員。他們之間的角色和職責定義有助于解決缺陷認定的問題。圖1是三者之間的簡單關系示意圖，系統人員是軟件開發和軟件測試的基礎和核心。系統人員將產品的用戶需求轉化為詳細的產品需求規格說明。在需求規格說明基線化后，軟件人員以此作為基礎進行系統概要設計和詳細設計，而測試人員根據規格說明進行測試用例的設計。同時，軟件開發人員和軟件測試人員都需要和系統人員緊密合作，將各個階段的開發活動和測試活動得到的信息反饋給系統人員，完善和優化系統需求規格說明。按照這樣角色和職責的定義，測試人員和開發人員在碰到缺陷認定的時候，首先可以由系統人員做出相應的裁決。

　　圖1項目開發的三種角色

　　當然，這種關于是不是缺陷的解決方案是基于相對成熟的軟件開發過程的。由于有了明確的角色和職責定義，軟件開發人員和測試人員的工作都是基于系統人員提供的產品需求規格說明。因此，在測試過程中發現的問題可以基于共同的理解和基礎，從而減少對具體問題的分歧，提高溝通的效率，同時可以提高開發和測試活動的效率。

　　對于測試中發現的功能問題，開發人員和測試人員之間比較容易達成共識。但是，對于軟件非功能相關的問題，由于相關的規格說明中經常沒有進行詳細定義，因此容易出現缺陷認定方面的爭議。此時，測試人員需要具有良好的溝通能力，并對測試理論和領域知識有比較深入的了解。下面是在缺陷認定出現不一致的時候，缺陷相關人員可以借鑒的一些建議：

　　◆ 首先，測試人員應該讓開發團隊理解提交缺陷的目的并不是對開發人員的成果進行挑刺，相反，測試人員和開發人員的目標是一致的，都是為了提高軟件產品的質量，滿足客戶的需求。

　　◆ 其次，需要和開發人員進行有效地溝通，讓開發人員理解測試的目的不僅僅只是針對軟件的功能而開展，還包括了可靠性、易用性、效率、維護性、可移植性等其他質量屬性。因此，發現非功能特性的缺陷時，開發人員不應該因為系統需求規格說明中沒有詳細定義，而否認存在的問題。

　　◆ 第三，測試人員應該站在用戶的角度對軟件的使用質量屬性進行有效地測試，包括軟件的有效性、生產率、安全性以及滿意度等。

　　◆ 第四，假如測試人員和開發人員在缺陷認定溝通失敗的情況下，可以通過項目的變更控制委員會，討論確定提交的缺陷報告是不是缺陷的問題。

　　2)缺陷信息共享

　　缺陷信息共享主要是指在測試執行過程中發現的缺陷，在不同項目成員之間進行共享。低級別的測試(例如：組件測試或集成測試)通常由開發人員完成;而高級別的測試(例如：系統測試或驗收測試)由獨立的測試團隊完成。在開發人員正式提交版本的系統測試前，開發人員需要進行基本功能的測試，并提供關于版本的發布說明。由于在每個測試級別和不同的測試階段都有可能發現缺陷，因此，在不同的項目成員之間進行缺陷信息的共享顯得尤為重要。主要包括：

　　◆ 開發人員和測試人員之間的缺陷信息共享，例如：在開發人員提供的版本發布說明中，提供當前版本中存在的主要缺陷、對后續測試的影響以及建議的測試重點等。這些信息可以為測試人員進行的測試提供參考，同時可以避免測試人員提交一些已經存在的缺陷報告，從而避免浪費時間和精力，不斷提高測試的有效性和效率。

　　◆ 測試人員之間的共享。在測試執行過程中，測試人員應該將提交的缺陷信息在項目的測試團隊中進行共享，例如：通過郵件的形式，或者通過測試團隊內部簡短的會議等。特別是嚴重的缺陷可能會導致阻塞很多測試用例執行的缺陷，應該在測試團隊內部發布該缺陷信息。通過在測試人員之間共享缺陷信息，可以在團隊內部形成共同分析和解決問題的氛圍，提高團隊的測試熱情和測試效率。

　　3)難以重現的缺陷

　　在測試執行過程中，經常會碰到一些不可重現或者很難重現的缺陷，特別是在進行系統的非功能性測試的時候，例如：穩定性測試、壓力測試、滿配置測試、兼容性測試等。在非功能性測試過程中發現的缺陷往往是嚴重程度比較高的，例如：系統不穩定、系統在不可預測的時候重啟等。假如軟件產品交付給用戶之后，在用戶現場或者系統運行過程中出現由于這樣的缺陷而導致的失效，那么將會大大影響用戶對產品的信心。

　　雖然有的組織和項目可能不統計無法重現或很難重現的缺陷，甚至忽視難以復現的缺陷。但是測試人員還是應該提交這種類型的缺陷報告，主要原因包括：

　　◆ 首先，在缺陷或者問題發現的時候，測試人員可以捕獲一些異常的系統打印信息，這些信息能夠幫助開發人員跟蹤和定位缺陷發生的原因，從而有利于開發人員解決這種類型的缺陷。

　　◆ 其次，報告不可重現的缺陷可以形成項目的不可重現的缺陷數據庫，定期瀏覽這些缺陷，并進行集中的分析，可能會在不同的缺陷描述中發現一些共同的或者可能有聯系的信息，有助于問題的解決。

　　◆ 第三，報告不可重現的缺陷，如果該缺陷可能對用戶的使用有較大的影響，測試人員需要在測試報告中描述這樣的缺陷，告訴用戶缺陷的表現，可能導致的問題，以及可能的補救方案。

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