Bug report之后(2)

　　技巧：

　　為了在一個產品中找到更多bug，這是你可以使用一個已修復的bug作為啟發的一些具體的方法：

　　查看第一個bug被發現的相同地方。你已經知道去檢查bug的修復是可行的且沒有引入新的問題。同樣尋找可能被第一個bug掩蓋了的潛在的bug。

　　在另一個平臺上尋找相同的bug。你的產品可能被移植到不止一個的操作系統中，或者可能在一個本地化編譯的應用程序和一個Web應用程序中有重疊的功能?？纯茨闶欠窨梢栽趯崿F的相同功能中找到一個相似的bug。

　　在產品的其他地方尋找一個相似的功能，以檢查是否有相似的bug正在折磨著這些地方。你或許會發現由于修復bug引起的用戶界面變更為了保持一致性而被傳播到其他地方。

　　如果原先的bug涉及到一個極限場景，那么更遠的推進到極限。 如果你使你的測試數據比以前更有壓力或者不尋常，你可能找到另外的bug。

　　檢查文檔。Bug修復可能會改變用戶可見的行為，因此用戶文檔可能需要更新以反映這些變更。如果你已明白了以前沒有被文檔說明的局限或一些難以形容的細節，那么考慮一下它在文檔中是否可以幫助用戶注意到這一點。

　　尋找和你正測試的bug修復無關的bug。如果你仔細地觀察，沿著你從未嘗試的方法你將留意到其他的bug。

　　當我仍然處于為發現另外的bug來歸檔的頭腦風暴時，我發現保持已修復的bug為open狀態和在我的隊伍內是很有幫助的。 如果我被另一個任務，午餐等分心的話，我在bug庫中仍然有這個提示，這在我試圖立刻瞞騙很多任務的時候是特別重要的。 如果你的組織要求你盡快關閉bug報告，你可能需要改為保持一份關于測試想法的單獨日志。

　　How It Fits In

　　當我利用一個已修復的bug來產生尋找另外bug想法的時候，我常常發現一陣新發現的我需要報告的問題。如果我沒有找到任何格外的bug，并且實際上我允許open的bug數量下降，我會感到我好象遺漏了什么事情。如果你也有這樣的感覺，那么你已成功的吸取了使bug增加的習慣。

　　我通常在我正在測試一個有著許多bug的產品時結束項目。如果你正在測試一個成熟的產品，你或許不能發現如此多的格外的bug。但是你直到自己看到了才會知道。

　　如果你被要求遵從一個非常結構化的流程，你可能會困難的發現足夠多的時間去探究我所建議的你已計劃責任之外的另外的地方。如果是那樣的話，我推薦花一兩分鐘去看看是否你發現任何新的征兆。如果你這樣做的化，告訴你的經理你對你所發現問題的擔心，并且詢問可否安排一些時間去探究那些地方。你或許已發現所測試應用程序的一個區域。如果你已徘徊在其他人負責測試的地方，和他分享你的發現，并且利用他在最佳方法上的專業知識以指出那個區域中的問題。

　　你或許正在疑惑我為什么不建議你在歸檔一份bug報告之后使用這份checklist，而不是等到缺陷被修復后。這些信息可能幫助你更進一步隔離你已發現的一個bug或者基于你剛報告的一個bug發現更多缺陷。不過，我建議在一個bug被修復之后使用檢查表是因為在那點上經做了一個設計的決定已。 一旦你知道一個bug如何被修復， 你有關于在你最初報告bug的時候很難預言的修復的范圍的有價值信息。一旦你知道已經被應用修復的地方的邊界，你準備用另外的測試想法去探索那些邊界。

　　這些想法已經幫助我提交過一次bug報告的無情的猛攻。當open的bug數量繼續提高時，開發人員最好的希望是bug的嚴重級別正在平均的減少。 我希望你能使用一些這些想法使你自己的bug報告增加。 

原文轉自：http://www.kjueaiud.com