Quality

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


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.

清楚的標題

每個人都先看標題,標題必須清楚與可讀,可以一眼就看出問題是哪一類。也應該在資料庫中容易能與其他的臭蟲區分出來。

Description

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.

標籤與連結

使用可讀的標籤來確保臭蟲能夠在資料庫中被辨識與歸類。再加上與其他相似臭蟲的連結就更好了。

Assigning

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照片

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

Google+ photo

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

連結到 %s