Avoiding Duplicate Bug Submissions
Background: As you may already know, duplicate bugs are not allowed on uTest projects – both bugs submitted by other testers and bugs on the customer’s list of known bugs (if any). Therefore, your ability to find duplicated/known bug on the reporting stage is necessary to save your bug from being rejected as duplicate, which results in a decrease in your rating, let alone wasting the time you spent to report the bug.
In order to avoid this mishap, it’s necessary to perform quick and effective searches for duplicate bugs.
Tester should look for duplicated bugs from:
- Known issues list attached to test cycle (if any)
- From ‘Scope & Instructions’ tab, a list of known (or out of scope) issues may be specified
- List of bugs previously submitted by fellow testers in the test cycle
- List of previously reported bugs is found by clicking on Bugs & Test Cases directly from the test cycle
- In some instances, reported bugs from previous test cycle(s) of the same project may also be counted as duplicates (this will generally be specified in the Scope & Instructions tab)
Note: A search in test cycle bugs currently occurs only for text in the summary field and not in anywhere else (actions performed, expected result, etc.).
Tips and Recommendations to avoid duplicate bug submissions
Here are few tips how to search for duplicated bugs in the quickest manner:
- Analyze your bug and identify the most unique keyword(s). The keyword can be name of the buggy feature or at least section/tab/page where bug occurs. For example, if a bug report has a summary as follows: “Catalog page - ‘Featured products’ button leads to 404 error page”, then the keywords could be ‘Featured products’. Where there are suspicions of a duplicate bug, you can always click on the bug of interest to review its contents in full (e.g., actions performed, expected result, actual result, environment, etc).
- Although it’s easy to search using these keywords, it may still not be effective, as the search may fail to find duplicates if there are mistakes made by reporting testers or intentionally shortened keywords. For instance, bug summary of duplicate bug may contain key words like: ‘Featured prod.’ or ‘Featur. product’ or ‘Featurd product’. It is a good practice to check against these keywords as well. Where there are suspicions of a duplicate bug, you can always click on the bug of interest to review its contents in full (e.g., actions performed, expected result, actual result, environment).
- In order to optimize your keyword search, extract the most unique part(s) of the keywords and search against them. E.g. in our case optimized key word will be ‘Featu’ or ‘tured prod’. Such searching will be most effective, but in order to achieve the best result in cases where the search fails, I recommend repeating your searches with a different twist. For example, you can use the name of the section/tab/page as the keyword. This is needed to verify if the tester reported a bug with a well-formatted but too generalized summary, such as: “Catalog page - button on the page leads to error.” In this case you will be able to find duplicate bug by the page name. Where there are suspicions of a duplicate bug, you can always click on the bug of interest to review its contents in full (e.g., actions performed, expected result, actual result, environment).
In conclusion, even if you follow clever and creative procedures, there is still a chance that your repetitive search won’t find a true duplicate. However, these practices will help eliminate the majority of duplicates that have been reported by other testers.
Note: There is no need to search in known issues or reported bugs list if it contains small number of bugs (up to 10). You can simply review them all at once by skimming the summary (or even clicking on a particular bug of interest to review its contents) and not waste your time using the search feature.
