Bug report之后

　　摘要：我們刻板地制造些bug報告然后期望它們會象飛鏢一樣返回，這樣我們就可以檢查看看bug是否被修復。 在這個星期的專欄里，Danny R. Faught分享了他從近來經歷中提取出來的一些想法，那可能會使你在歸檔bug報告之后成為一個優秀的客戶代言人。

　　在bug返回之前

　　你所在團隊中的人可能會給bug報告添加些意見，以作為正在進行中的關于怎樣處理bug的對話中的一部分。 這給你了一個有關決定以及另外關于bug和修復性質的細節的好歷史記錄。在你提交bug報告并寄發出去之后，對你而言可能有更多的機會提供另外的有用信息。

　　在我當前的項目里，那些編程人員在他們學習新信息時，傾向于在分配給他們的bug報告里添加些意見。他們也可以添加意見在把bug轉發給開發經理以尋求反饋。我有機會去查看是否有更多的我能夠提供的有關問題性質方面但我不想在最初提交bug時包括的信息。此外，我可能會評論并給出對已提議的修復將會如何工作的看法。比起在我有機會檢查之前讓編程人員徹底地實現一個修復，那大大縮短了溝通途徑。

　　我們的bug追蹤系統會在發布一條新意見時通知團隊，那樣就很容易追蹤這些談話。如果你的系統使得看見意見被發布很困難，或如果活動將使得監視你所感興趣的事情變得不實際，你可能不得不等待直到飛鏢返回給你。此外，如果編程人員在他們正解決一個bug時對收到的反饋是持敵對態度時，你最好遵從一個更加正式的流程。

　　When the bug is fixed, more or less.

　　飛鏢回來了。。。在許多組織中，要求歸檔bug報告的人在修復完成后驗證修復?；蛘吣憧赡苷秊槠渌颂峤坏囊粋€bug測試修復。我的目標是完成這一步驟時至少有和我開始時一樣多的bug。

　　當然，你應該設法按你最初報告它的方式增加bug。 有時，問題仍然存在，好象根本沒有被修復一樣?？赡苁且驗?STRONG>配置管理的故障，并不在你所擁有的版本中修復?；蛟S有些我既沒報告，編程人員也認為不是重要的，關于我配置的特殊事項。當我拒絕一個bug被完全修復時，我試圖包括關于我的配置和我如何重現bug的格外的一些細節。 與我第一次相比，我使用不同的詞語以幫助減少任何的誤解。并且我用一種表示為難而不是譴責的音調書寫。 在大多數的情況下，編程人員真的努力去修復bug了，并且我們需要承認那份努力。

　　如果修復的很好但并沒有將bug處理得令你滿意，那該怎么辦呢?你有打一個判斷的電話。如果軟件的變更代表了一些進度，并且如果沒有更進步的改善，能夠獨立，然后我推薦關閉bug為已修復。 我不喜歡保持一份bug報告為open狀態太久，從而產生太多的變化，而且可能多次改變它的焦點。

　　打開一份或更多的新的bug報告，描述你想看見的另外的變化。在關閉現有的缺陷之前做這件事將幫助確信你不會變得心煩意亂而忘記跟進，并且在你關閉舊的報告時，它將為你能在意見里為新缺陷引用ID號碼。在相關的bug之間留下一個痕跡是很好的。

　　另一方面，如果修復真的未完成，繼續拒絕它;把bug發回給編程人員?；蛟S引入了一個明顯的新bug，或者一些小的細節被忽略了。當代碼在他們心里仍然很新時，編程人員徹底清理這些東西將會比等待一份新的bug報告而過濾系統更容易些。決定是拒絕修復還是提交一份新的bug報告通常是很艱難的，但是如果你已經與那些編程人員發展了一種好的工作關系，你按兩種方式中的任一種都將得到一個好結果。

　　While you're at it...

　　當我檢查一個缺陷修復時，我輕視在應用程序相同區域里的其他bug。如果代碼正在增長或者變更地很頻繁，我通?？梢酝诰蛄硗鈫栴}的問題來報告而不帶很多的額外工作。Bug傾向于聚中在一起，并且bug修復傾向于暴露你以前不能看見的潛在缺陷。

　　即使你是在強硬的時間表壓力下，花費幾分鐘歸檔一些bug是很值得的。支持探索測試的組織很有可能會了解到這次格外工作的價值。

　　Not a bug?

　　哎唷。當某人說你如此仔細隔離并且報告的問題最終其實不是一個問題的時候，那是不好玩的。 這是我曾碰到過的一些新近的案例：

　　我正測試的軟件有一個由第三方提供的關鍵組件。有幾次我歸檔了一些開發人員在注釋里說無能為力的bug。在那時，作為客戶代言人我氣壞了。用戶不會關心問題是在我們的代碼里還是其他人的代碼里。他們只關心軟件不能夠工作。這樣的話，我將盡力解釋問題對用戶的影響，并且可能建議我們一種繞過問題的辦法。 我將會對一種變通辦法可能是很昂貴來實現的事實感到敏感。

　　另一個例子是編程人員判定我認為是問題的bug根本不是一個問題。 我報告了一個可能會導致用戶幾個小時都不能登陸到應用系統中的bug。開發人員說這是期望的行為，并且得到開發經理的同意。我被在外投票決定，但并沒有放棄。 與其在bug報告的意見里繼續討論，不如我給編程人員和經理發送一封解釋我為什么認為不去修復問題是一個錯誤的電子郵件。不僅他們同意我，而且經理也通過把我的消息公布到bug意見中批準我的意見。 但是傳奇到那里還沒結束。我認為已實現的修復確實還不足以解決問題。 因為修復象設計一樣工作并且沒有引入任何新的問題，我把它關閉并且打開一份新的bug報告(要更多)。 鑒于已做的改進，我們全部能同意這個新請求是有效的，除了它的優先級別較低。

　　成為一個優秀客戶代言人的關鍵是要考慮開發過程中的人性因素。在維持與編程人員和經理的有效溝通時，實踐在影響用戶的問題上堅守陣地的最佳藝術。但愿我在這些方面給你了一些有用的信息。

　　***************************************************************************************************************

　　A Bug Begets a Bug

　　摘要：Danny R. Faught在他的《After the Bug Report》(2005年4月專欄)一文中建議你在測試一個bug被修復時，也應該尋找另外的bug。這個星期，他詳述了那個想法，讓你看看一份bug報告怎樣才可以增加更多的bug。

　　作為一個測試人員，你知道當你看見一個bug被修復時，你正在做你自己的工作。當你利用那個bug作為一個指南讓你看看在你產品中的什么地方潛伏了更多的bug時，你可以做甚至更好的工作。我的個人目標是由于檢查早先提交的bug的修復情況而打開至少一個以上的bug。

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