有问题的bug report种类

作者在这里列出, 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, 因而导致把它们写在一起