有問題的bug report種類
Defective Bug Reports
http://blogs.msdn.com/imtesty/archive/2006/06/28/649862.aspx
June 28, 2006
Posted by Bj Rollison
Published in I.M.Testy
作者在這裡列出, bug report常見的一些問題, 很值得QA人員注意:
1. 不完整的repro steps
- 95%的人認為bug report最嚴重的問題就是repro steps不完整不詳細.
- RD, QA 會來來回回的確認問題在哪裡, 將會浪費兩邊大量的時間
- 造成此問題容易被放在最後才解, 並且也造成雙方不信任或是氣餒
2. 出現在像email形式的討論
- 不要出現太多廢話, 畢竟bug report是一種tech report
- 雙方人員容易迷失在無意義的對話中, 而忘記真正要處理的問題
- bug report 應該只包含以下資訊
# description of the problem
# the specific steps to reproduce the problem
# the actual results
# the expected results
# customer impact statement.
# additional notes from troubleshooting
# debug information
3. 缺乏細節和近一步的調查
- 當QA發現一個bug時, 它需要進一步了解是否有其他狀況也會發生相同的問題, 或是檢查一些可能造成錯誤的原因.
- 這樣narrow down問題, 會讓之後這個bug比較快速被處理掉, RD也會很感激和尊重你的專業
4. Bug 的變形 (bug morphing)
- 在解bug的過程, 發現這個bug其實是另一種bug, 或是找到另外一個bug.
- 這時候最好修改title, 或是另外submit一個bug來處理這個多出來的問題
5. 遺漏掉的資料檔案
- 有時候在bug report中提到有附上某些檔案, 但是忘記付上去
6. Environment/configuration資訊
- 有時bug只會在特定環境或設定下才會發生, 因此需要記得描述它
- Veritest Analyzer 2.0, Filemon and RegMon都是很好的工具可以幫助你收集這些資訊
7. expected results
- 有時候你若是沒有描述expected results, RD會不知道為什麼錯, 或是你所期望對的行為是什麼
- 這可以幫助RD知道問題是什麼, 以及有效率地做出你想要的答案. 不會因為他猜錯, 導致讓費更多時間在來來回回處理
8. 重複的bugs
- 在大型專案中, 這樣的狀況很難避免.
- 一個 bug會產生的方法可能有很多種, 但是RD只會注意是否是相同的root cause
- 可以多個相同類型的bug report, 在某些狀況下可以幫助RD快速了解這問題是什麼, 可以幫助他快速解掉. 尤其某些很難repro的case, 或許在review 一些雷同的bugs後, RD會有idea要如何去解決它
9. 沒有Debug Information
- 有時候當access violation出現時, 是需要用像WinDeg去得到dump file來幫助RD之後去解問題
- 尤其是某些random or intermittent exceptions, 你很難再次去產生它, 因此你必須掌握當下的機會,出產生dump files
10. 多個bugs寫在同一份report
- 大部分有經驗的QA不會這樣做
- 可能是因為在做exploratory testing, 再依連串的步驟後會找到一些不同的bugs, 因而導致把它們寫在一起
留言列表
