[翻譯] 如何寫好一個錯誤回報

How to Write a Good Bug Report?
[翻譯] 如何寫好一個錯誤回報


How to write a good bug report?

One of the most important skills that you need to have in your tester’s tool box is the ability to write a good bug report. Finding defects is only part of the job, because if developers can’t reproduce the bugs you find, they’re going to have a very tough time fixing them. Your bug tracking software should include a number of mandatory fields to ensure that testers give a complete account of the defect they encountered. And testers should hone their descriptive skills.

A descriptive title

Everything starts with a title. It must be clear and descriptive, so that you get an idea of what it is about at a glance. It also has to be clearly differentiated from all the other bugs in the database.




Try to remain clear and concise in your description. This is an opportunity to explain the defect and put across all the pertinent details, but developers don’t want to read a novel. Describing something accurately and concisely is a skill that develops with practice. Remember that the person reading your description has not seen the bug and try not to make assumptions.



Expected results

You have to make it clear what you expected to happen and how the defect diverged from that expectation. This field helps to prevent any misunderstandings, and it gives the developer a clear idea of what went wrong.



Project and version

It’s not unusual for testers to work on multiple projects at the same time, and sometimes they’ll share a database, so ensuring that your bug is listed in the correct project, and section within that project, is vital. You also need to get the software version right. Sometimes a bug will be fixed when a different defect is addressed, or simply by some change in the newest version of the software. If the version is wrong, developers may be embarking on a wild goose chase.



Platform details

Any background information you can provide about your environment will help developers track that bug down. What device were you using? What operating system was it running? What model was it? What browser did you use? Every detail you can give about the platform will help.



Type and severity

These fields go hand-in-hand. A functional bug will generally be treated more seriously than a suggestion. Developers also need to know how severe the bug is. No product ships with zero defects, so having bugs categorized correctly in terms of type and severity really helps the decision-making process with regards to what gets fixed and what doesn’t. If you don’t understand these fields then ask for instruction, and review other bug entries in the database.



Steps to reproduce

You want to give a step-by-step account of exactly what you did to find any defect. Sometimes you can use software tools that catch your key strokes, or record screenshots or video files as you test, other times you’ll be writing from memory, so take notes as you go. Make sure that you test your own steps again before submitting the bug.

Give an indication of reproducibility as well. Sometimes you’ll be confident about your steps, but upon repeating them the bug won’t necessarily occur. If it happens every time, at random, or only once, then the developer needs to know that.




Attachments and comments

Supporting material is always gratefully received by those tasked with fixing defects. Usually this will be screenshots, but it can include audio and video files. Sometimes you’ll want to annotate your screenshots to highlight problems.

It may be worth adding extra comments if there’s something that you don’t feel fits elsewhere in the bug report, but could be worth noting.



Tags and linking

It can be a good idea to use descriptive tags that enable you to filter the database and find groups of related bugs. Sometimes you’ll want to include another bug ID or a link within your defect report to something that you feel is strongly related or similar, but not similar enough to be a duplicate.




It’s usually going to be up to the lead developer or management to assign bugs, but on occasion you might receive instructions about who to assign to. Leaving unassigned or wrongly assigned bugs in the database is a dangerous thing because they can potentially slip through the cracks. Make sure you’re clear on the expectations for assigning.



Put it all together

Bring all of this together and you should have a good bug report. If you’re uncertain about the quality of your bug reports ask for feedback. A quick chat with the developers can really help you understand what they need. You can also read the bug reports entered by experienced testers to get more pointers.





WordPress.com Logo

您的留言將使用 WordPress.com 帳號。 登出 / 變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 / 變更 )


您的留言將使用 Facebook 帳號。 登出 / 變更 )

Google+ photo

您的留言將使用 Google+ 帳號。 登出 / 變更 )

連結到 %s