There has been a great deal of time and energy spent discussing what is and what is not a bug. It is more difficult to address a bug when the reporter simply says “there is something wrong,” but does not identify what is wrong or where the problem is occurring.
Errors can be swiftly corrected if the problem is clearly communicated. Below are three great ideas for maximizing efficiency and clarity in bug reporting.
Be specific! Don’t hold back on an explanation!
One of the largest hurdles in bug reporting in a localization project is that many of the people who will need to read the report may not have a perfect command of the language in which the bug report is written. By providing specific, detailed information about a particular issue, it can help an engineer or linguist find where the problem is coming from and correct the problem swiftly.
Also, keep in mind that many of the engineers or technical writers that created the source texts are not linguists! If the bug is due to a linguistic issue, where a sentence structure is incorrect or incorrect usage of singular vs. plural for a particular word or phrase, a precise explanation should be given in the report as to why the usage is incorrect. These bugs can often be a result of incorrect coding or internationalization, and the engineers or technical writers may have to investigate how much work will be needed to make the appropriate corrections.
Don’t be a copy cat! One issue, one bug!
The greatest deflator of an enthusiastic bug-fixing meeting is finding out that the majority of the bugs being reported are duplicates. This is likely to occur when there is more than one person doing any type of quality assurance (QA) for a project. Before submitting a bug, always search to see if the bug has already been reported.
A picture paints a thousand words – show me the errors!
There is only so much explanation that a person can write about a bug, indicating where it is from or under what circumstances it was found. By taking a screen capture, a tester can clearly communicate where the problem is occurring and where in the coding it needs to be fixed. This has the added benefit of speeding up the time it takes to fix the bug in question. This is especially true in localization, when two engineers can speak different native languages but both understand the same error highlighted in a screen capture.