【要有快速解決問題的想法】
bug管理一直測試工作的核心之一唾糯，所以對于整個項目來說bug管理是非常關鍵的一環(huán)函卒，那么該如何使用更有效的進行bug管理呢君纫？
經(jīng)過多年的測試實踐竿开，我覺得在大多數(shù)情況下bug管理應該用輕管理。所謂的輕管理其實就是簡化bug的描述和bug流轉的步驟掸读，雖然從正規(guī)的流程中來看這樣會存在很多弊端串远，但凡事總歸有好有壞宏多，就看如何權衡其中的利弊了。
我認為是利大于弊的澡罚，原因有以下2點：
測試人員花費大量的時間在描述bug上了伸但，包括預置條件，操作步驟留搔，預期結果更胖，實際結果等等，甚至還有附件或者截圖催式，最后還要自己讀幾遍看看有沒有錯別字或者表達的歧義函喉。而最后開發(fā)人員也未必會仔細看，甚至還是會產(chǎn)生不理解或者錯誤的理解荣月，于是這些時間付出和收益并沒有成正比管呵，看似忙的很辛苦，但實際卻有很多無用功哺窄。
還有一點就在于現(xiàn)在的項目都是頻繁迭代捐下，很多項目都開始使用敏捷開發(fā)，用過去的重管理模式會拖慢整個項目的進度萌业。有時候描述一個bug的時間開發(fā)都能把bug修復了坷襟，而且這樣就占據(jù)了很多實際測試的時間，本來測試時間就非常不夠生年，還執(zhí)著于bug管理就是本末倒置了婴程，最后要不就是加班，要不就是測試不完全就上線抱婉。
當然也不是說輕模式就有多好档叔，但從各種實踐來看，bug管理只是一種手段蒸绩，而非目的衙四。而對于測試來說最寶貴的是測試時間，讓測試和開發(fā)能夠同時工作患亿，而不是測試在bug管理上花費時間的時候传蹈，開發(fā)沒有事情做。原因其實已經(jīng)分析差不多了步藕，那么實際上如何減少在bug上花費時間呢?
我覺得有以下幾點建議：
太過于復雜和很難描述清楚的bug可以叫開發(fā)人員過來看惦界，如果條件不允許的話可遠程演示或者錄屏保存發(fā)送，當然bug還是要記錄的咙冗，只是記錄一個大概問題表锻，不必太詳細描述，只需要自己心里知道bug如何重新和如何驗證就可以了乞娄。
除了bug描述上可以從簡添忘，其實從bug的流轉上也可以“偷懶”采呐。一般提交bug到開發(fā)這邊，開發(fā)往往會解決了問題而不把bug狀態(tài)改成fix狀態(tài)搁骑，于是要催開發(fā)改狀態(tài)斧吐，改完之后發(fā)現(xiàn)bug還沒修復，于是又把狀態(tài)改成reopen重新發(fā)給開發(fā)人員仲器，然后開發(fā)改完又要催他改狀態(tài)煤率。周而復始幾次就耗費大量時間，除了記錄bug的狀態(tài)不停更新乏冀，并沒有什么實際用處蝶糯，而對于bug管理目的只有2個，記錄bug和最后bug被修復驗證通過辆沦，因此其實只需要等bug驗證通過后closed昼捍，中間那些流轉過程則可以選擇性的“省略”。
最終目的就是不要被bug管理束縛众辨，解決問題才是關鍵端三。
用bug的輕管理能讓測試人員從其中解放出來，從而投入到真正需要花時間測試的地方鹃彻，無論從測試人員本身或者項目的進度上來說都是利大于弊的郊闯，我想這也是未來測試的趨勢吧。
