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

　　◆ 第四，報告不可重現的缺陷，有助于測試人員和開發人員對這類問題和系統表現進行跟蹤。

　　◆ 最后，測試人員在報告不可重現的缺陷時，應該在缺陷報告中明確提示該缺陷不可重現或者難以復現，避免在進度壓力太大的情況下，開發人員將精力過多地放在這種類型的缺陷修復上。

　　4)清楚地報告而非解決缺陷

　　缺陷報告是測試過程中最重要的輸出之一，編寫良好的缺陷報告也是提高軟件質量的重要保障。清楚的缺陷報告對測試團隊而言具有重要的意義：

　　◆ 可以減少被開發人員拒絕從而打回來的缺陷數量。

　　◆ 加快缺陷修復的速度。

　　◆ 增加測試人員測試能力的可信度。

　　◆ 加強開發人員和測試人員之間的團隊合作。

　　◆ 更加高效地提高軟件質量。

　　因此，測試人員在提交缺陷報告的時候，應該從不同的方面保證缺陷報告的質量，一個好的缺陷報告應該具有下列特征：

　　◆ 精簡的：缺陷的描述應該是清晰而簡要的。在缺陷報告中要剔除不必要的無關的信息。在缺陷報告中包含所有缺陷相關的信息，并且確實是相關的，多余的信息只會使得缺陷的描述含糊不清。

　　◆ 正確的：提交的問題確實是一個缺陷。假如提交的缺陷最后證明是由于測試人員的理解錯誤或者配置錯誤引起的，可能使得測試人員在開發人員面前失去可信度，同時會對彼此之間的溝通帶來一些影響。當然，不能因為害怕提交錯誤的缺陷，就對可能出現的缺陷視而不見，這比提交錯誤的缺陷影響更惡劣。因此，在提交缺陷報告之前，測試人員應該針對以下方面仔細檢查：

　　確保搭建了正確的測試環境。

　　確保測試的版本是正式的測試版本。

　　確保不是前面執行的測試用例配置的信息干擾了測試結果。

　　確保網絡通信沒有問題。

　　確保測試人員正確地理解了產品的工作原理。

　　◆ 中立的：對缺陷及其特征進行實事求是的描述，避免夸張、幽默、諷刺的態度，避免在測試缺陷報告中帶有個人感情色彩，因為這種感情色彩可能會影響團隊之間的合作和溝通。

　　◆ 準確的：準確而明白地描述問題，不僅對做了什么進行描述，而應該對發生或者發現了什么進行描述。

　　◆ 隔離：盡量尋找簡短的步驟復現缺陷，即將缺陷進行隔離，例如：缺陷所屬模塊、缺陷的觸發條件等。對問題進行隔離定位，很大程度上體現了測試人員對測試對象的了解程度，同時可以提高測試效率和項目整體的效率。

　　◆ 推廣：確定系統其他部分是否可能也存在同樣的問題，以及使用不同的數據時是否也會出現這種問題等。測試人員在缺陷方面的推廣有助于節約開發人員修正缺陷的時間，提高缺陷解決的效率。

　　◆ 復現：確定系統是否可以復現這個問題，以及復現該缺陷的步驟。對于能夠復現的問題，應該提供簡單的步驟和輸入。對于難以復現的問題，盡量提供一些告警信息、日志信息;或者問題發現時，可以和開發人員一起進行跟蹤調試和定位。對于實在無法復現的問題，在缺陷報告中應明確說明，并且在后續測試中持續跟蹤。

　　◆ 證據：如同寫測試用例需要測試條件一樣，在缺陷報告中，需要提供測試的期望結果和實際得到的輸出結果或者行為之間的差距，以及提供測試的依據。

　　◆ 評審：在提交缺陷報告之前，最好有一個有經驗的測試人員閱讀一遍。

　　測試人員在提交缺陷報告的時候，不要試圖在缺陷報告中解決問題。因為測試人員和開發人員的角色和職責是不一樣的，調試和解決問題是開發人員的主要職責。

　　5)明確缺陷優先級和嚴重程度

　　正確處理和區分缺陷的嚴重程度和優先級是所有軟件開發和測試相關人員的一件重要的事情。缺陷的嚴重程度和優先級是含義不同但相互聯系密切的兩個概念，它們從不同方面描述了軟件缺陷對軟件質量、用戶、開發過程的影響程度和處理方式。一般來說，嚴重程度高的缺陷具有較高的優先級。嚴重程度高說明缺陷對軟件造成的質量危害性大，需要優先處理，而嚴重性低的缺陷可能只是軟件的瑕疵，可以稍后處理。但是優先級和嚴重程度并不總是一一對應的，也存在優先級低但嚴重程度高的缺陷，或者優先級高但嚴重程度低的軟件缺陷。

　　修改軟件缺陷并不是純技術的問題，有時候需要考慮軟件版本發布和質量風險等因素。下面是關于缺陷嚴重程度和優先級設置方面的一些建議：

　　◆ 如果某個嚴重的缺陷只在非常極端的條件下產生，則可以將缺陷的優先級設置得比較低。

　　◆ 如果修正一個軟件缺陷需要重新修改軟件的整體架構，可能會產生更多的潛在缺陷，而且市場要求盡快發布軟件版本，那么即使這個缺陷嚴重程度很高，也需要仔細考慮是否需要修改。

　　◆ 對于有些缺陷，可能它的嚴重程度很低，例如：界面單詞拼寫錯誤，但假如這是公司的名稱或者商標，則這個缺陷的優先級就很高，必須盡快進行修復，因為這個關系到軟件系統和公司在市場上的形象。

　　6)報告缺陷之前得到開發人員的確認

　　測試人員在測試環境中發現缺陷的時候，假如條件允許，在提交缺陷報告之前，可以和相關開發人員進行確認。當然，對于非常容易判斷的功能性缺陷或者其他非常明確的缺陷類型，測試人員可以直接提交缺陷報告。而對于穩定性、功能行為表現復雜或者難以復現的缺陷，可以要求開發人員在測試現場確認發現的缺陷，這樣可以提高項目的整體效率，有利于團隊之間的合作：

　　◆ 首先，開發人員可以現場查看一些軟件的打印信息和異常表現，有利于開發人員后面的缺陷復現和定位解決。

　　◆ 其次，開發人員可以幫助測試人員確認發現的問題是不是缺陷，避免測試人員提交一些不是缺陷的缺陷報告(例如：由于測試人員理解錯誤、配置錯誤等而導致的一些系統異常)，同時避免開發人員在不是缺陷的缺陷報告上面浪費時間和精力，提高測試團隊和開發團隊的效率。

　　◆ 第三，有利于開發人員和測試人員的溝通，包括對軟件系統的理解，從而在項目團隊之間更好地合作。

　　7)缺陷分析和測試進度管理

　　缺陷分析是測試過程中最重要的測試活動之一，通過缺陷分析，可以了解項目的測試進展和軟件產品的質量。缺陷分析也可以用來評估當前軟件的可靠性，并且預測軟件產品的可靠性變化。同時，缺陷的分析和評估也可以確定測試的重點，判斷測試是否達到了測試出口準則等。

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