如何寫出一份好的Defect Report - (II)
這裡是另一篇, 也是講如何寫一份好的defect report的文章,他是出自Rex Black(Critical Testing processes)之手.
和上篇比較起來, 有些重點兩個作者都有強調, 我想你就可以知道這些部分一定非常重要, 否則就不會英雄所見略同.
不過這裡更強調是, 你必須要把你找到的defect好好消化, 不是只是囫圇吞棗地把它呈現出來. 像是isolate, generalize, compare和condense都是在做這樣的事. 它不希望defect report只是平鋪直述地, 把問題講出來而已, 而是希望programmers從中就能得知問題出在哪裡的線索.
我想你一定知道, 若是同一個問題, 由兩個QA來撰寫不同的defect report, 所顯示的精細程度, 有用性, 和可讀性一定大大不同. 某些人寫的就是簡單易懂, 直接命中要害, 一下就可以知道錯誤出在哪裡. 有些人寫的, 就是要跟他來來回回, 否則你還真不知他要表達什麼.
所以作者非常強調defect report的quality, 他認為這是QA工作的精華所在. 須知QA有很長的時間是花在寫defect report, 再加上programmers 和managers也同樣化很多時間在review, 你怎麼可以不謹慎呢?
1. Structure
- Good bug reporting begins with sold, organized testing
- It must be something other than just hacking on the product in an aimless attempt to break it
- Sloppy testing yields sloppy bug reports
2. Reproduce
- Reproducing the problem sharpens your understanding of the issue
- Reproducing the problem allows you to document a crisp set of steps that will re-create the failure.
- Please report intermittent bugs with a note about the intermittence
3. Isolate
- By changing some key variables, one at a time, in an attempt to change the behavior of the bug, you can write more insightful bug reports
- Good bug isolation builds tester credibility and gives the programmer a head start on debugging.
- Avoid getting into debugging or expending inappropriate amounts of time on trivial issues
4. Generalize
- Often, the symptom you see when you first find a bug is not the most general case.
- Trying to find the general rule for hoe the bug occurs deepens your understanding and help convince programmers and managers that the problem is not an isolated case
5. Compare
- Execute the same test with different builds in order to find more hints.
6. Summarize
- A good bug report includes a summary that communicates to the CCB or bug triage committee in a single sentence the essence and significance of the problem
- This summary is invaluable when it becomes time to priority the bugs
- It is the most important sentence in the bug report
7. Condense
- The best bug reports are neither cryptic commentary nor droning, endless, pointless documents
- Use just the words you need and describe only the steps and information that actually pertain to the bug being reported
8. Disambiguate
- The disambiguate is to remove confusing or misleading words that might make a reader wonder what I mean
9. Neutralize
- Attacking the porgrammer, criticizing the underlying error in the code, or using number or sarcasm to make a point generally back-fires.
- Bug report, once in a bug tracking system, often live forever and can be read by people not on the project team
- Try to be gentle and fair-minded in your words and confine your bug reports to statements of fact, not coniecture or hyperbole.
10. Review
- A bug report is a technical document. Peer reviews, inspections, walkthroughs are necessary
這裡是另一篇, 也是講如何寫一份好的defect report的文章,他是出自Rex Black(Critical Testing processes)之手.
和上篇比較起來, 有些重點兩個作者都有強調, 我想你就可以知道這些部分一定非常重要, 否則就不會英雄所見略同.
不過這裡更強調是, 你必須要把你找到的defect好好消化, 不是只是囫圇吞棗地把它呈現出來. 像是isolate, generalize, compare和condense都是在做這樣的事. 它不希望defect report只是平鋪直述地, 把問題講出來而已, 而是希望programmers從中就能得知問題出在哪裡的線索.
我想你一定知道, 若是同一個問題, 由兩個QA來撰寫不同的defect report, 所顯示的精細程度, 有用性, 和可讀性一定大大不同. 某些人寫的就是簡單易懂, 直接命中要害, 一下就可以知道錯誤出在哪裡. 有些人寫的, 就是要跟他來來回回, 否則你還真不知他要表達什麼.
所以作者非常強調defect report的quality, 他認為這是QA工作的精華所在. 須知QA有很長的時間是花在寫defect report, 再加上programmers 和managers也同樣化很多時間在review, 你怎麼可以不謹慎呢?
1. Structure
- Good bug reporting begins with sold, organized testing
- It must be something other than just hacking on the product in an aimless attempt to break it
- Sloppy testing yields sloppy bug reports
2. Reproduce
- Reproducing the problem sharpens your understanding of the issue
- Reproducing the problem allows you to document a crisp set of steps that will re-create the failure.
- Please report intermittent bugs with a note about the intermittence
3. Isolate
- By changing some key variables, one at a time, in an attempt to change the behavior of the bug, you can write more insightful bug reports
- Good bug isolation builds tester credibility and gives the programmer a head start on debugging.
- Avoid getting into debugging or expending inappropriate amounts of time on trivial issues
4. Generalize
- Often, the symptom you see when you first find a bug is not the most general case.
- Trying to find the general rule for hoe the bug occurs deepens your understanding and help convince programmers and managers that the problem is not an isolated case
5. Compare
- Execute the same test with different builds in order to find more hints.
6. Summarize
- A good bug report includes a summary that communicates to the CCB or bug triage committee in a single sentence the essence and significance of the problem
- This summary is invaluable when it becomes time to priority the bugs
- It is the most important sentence in the bug report
7. Condense
- The best bug reports are neither cryptic commentary nor droning, endless, pointless documents
- Use just the words you need and describe only the steps and information that actually pertain to the bug being reported
8. Disambiguate
- The disambiguate is to remove confusing or misleading words that might make a reader wonder what I mean
9. Neutralize
- Attacking the porgrammer, criticizing the underlying error in the code, or using number or sarcasm to make a point generally back-fires.
- Bug report, once in a bug tracking system, often live forever and can be read by people not on the project team
- Try to be gentle and fair-minded in your words and confine your bug reports to statements of fact, not coniecture or hyperbole.
10. Review
- A bug report is a technical document. Peer reviews, inspections, walkthroughs are necessary
全站熱搜
留言列表
