【要有快速解決問題的想法】
bug管理一直測試工作的核心之一，所以對于整個項目來說bug管理是非常關鍵的一環(huán)，那么該如何使用更有效的進行bug管理呢？
經過多年的測試實踐，我覺得在大多數情況下bug管理應該用輕管理。所謂的輕管理其實就是簡化bug的描述和bug流轉的步驟，雖然從正規(guī)的流程中來看這樣會存在很多弊端，但凡事總歸有好有壞，就看如何權衡其中的利弊了。
我認為是利大于弊的，原因有以下2點：
測試人員花費大量的時間在描述bug上了，包括預置條件，操作步驟，預期結果，實際結果等等，甚至還有附件或者截圖，最后還要自己讀幾遍看看有沒有錯別字或者表達的歧義。而最后開發(fā)人員也未必會仔細看，甚至還是會產生不理解或者錯誤的理解，于是這些時間付出和收益并沒有成正比，看似忙的很辛苦，但實際卻有很多無用功。
還有一點就在于現在的項目都是頻繁迭代，很多項目都開始使用敏捷開發(fā)，用過去的重管理模式會拖慢整個項目的進度。有時候描述一個bug的時間開發(fā)都能把bug修復了，而且這樣就占據了很多實際測試的時間，本來測試時間就非常不夠，還執(zhí)著于bug管理就是本末倒置了，最后要不就是加班，要不就是測試不完全就上線。
當然也不是說輕模式就有多好，但從各種實踐來看，bug管理只是一種手段，而非目的。而對于測試來說最寶貴的是測試時間，讓測試和開發(fā)能夠同時工作，而不是測試在bug管理上花費時間的時候，開發(fā)沒有事情做。原因其實已經分析差不多了，那么實際上如何減少在bug上花費時間呢?
我覺得有以下幾點建議：
太過于復雜和很難描述清楚的bug可以叫開發(fā)人員過來看，如果條件不允許的話可遠程演示或者錄屏保存發(fā)送，當然bug還是要記錄的，只是記錄一個大概問題，不必太詳細描述，只需要自己心里知道bug如何重新和如何驗證就可以了。
除了bug描述上可以從簡，其實從bug的流轉上也可以“偷懶”。一般提交bug到開發(fā)這邊，開發(fā)往往會解決了問題而不把bug狀態(tài)改成fix狀態(tài)，于是要催開發(fā)改狀態(tài)，改完之后發(fā)現bug還沒修復，于是又把狀態(tài)改成reopen重新發(fā)給開發(fā)人員，然后開發(fā)改完又要催他改狀態(tài)。周而復始幾次就耗費大量時間，除了記錄bug的狀態(tài)不停更新，并沒有什么實際用處，而對于bug管理目的只有2個，記錄bug和最后bug被修復驗證通過，因此其實只需要等bug驗證通過后closed，中間那些流轉過程則可以選擇性的“省略”。
最終目的就是不要被bug管理束縛，解決問題才是關鍵。
用bug的輕管理能讓測試人員從其中解放出來，從而投入到真正需要花時間測試的地方，無論從測試人員本身或者項目的進度上來說都是利大于弊的，我想這也是未來測試的趨勢吧。
