How to report a bug or issue effectively?

Official announcements and latest news, awards from medias, and sucess stories.
Post Reply
User avatar
TerraMaster Team
Posts: 2419
Joined: 10 Mar 2020, 14:04

How to report a bug or issue effectively?

Post by TMroy » 02 May 2020, 18:10

Dear TerraMaster community,

Given that software is exceptionally complex, layered, and feature-heavy in the current digital environment, most QA pipelines generate multiple bugs. Developers often work on multiple development projects simultaneously, which means they have a considerable number of bugs requiring attention. They have to operate under significant pressure and can be overwhelmed without the right resources.

Good bug reports tell the tech team exactly what needs to be fixed and help them get it done faster. This prevents software releases from being delayed, offering faster time-to-market without compromising on quality.

Elements of an Effective Bug Report
What does a bug report need to tell the tech team? A bug report should be able to answer the following questions:
  • What is the problem?
  • How can the tech team reproduce the problem (to see it for themselves)?
  • Where in the software (which webpage or feature) has the problem appeared?
  • What is the environment (browser, device, OS) in which the problem has occurred?
How to write an Effective Bug Report
An effective bug report should contain the following:
  • Title
  • Environment
  • Steps to reproduce a Bug
  • Expected Result
  • Actual Result
  • Visual Proof (screenshots, videos, text) of Bug
1. Title
The title of the report should provide a quick description of the bug. For example, “The SMB file service in "Control panel" always fails to be enabled".

2. Envirement
A bug can appear in a particular environment and not others. For example, a bug appears when running the website on Firefox, or an app malfunctions only when running on an iPhone X. These bugs can only be identified with cross-browser testing or cross-device tests.

When reporting the bug, you must specify if the bug is observed in one or more specific environments. Use the template below for specificity:
  • Model number: Hardware and specific model number
  • OS: Your computer or phone OS name and version, web browser name and version
  • Software version: The version of the software which is being tested, and in which the bug has appeared.
  • Rate of Reproduction: The number of times the bug has been reproduced, with the exact steps involved in each reproduction.

3. Steps to Reproduce a Bug
Number the steps clearly from first to last so that the tech team can quickly and exactly follow them to see the bug for themselves.
  • 4. Expected Result
How is the software supposed to work, with regard to the particular area in which the bug appears? The tech team needs to know what the requirement is, in order to gauge the extent to which the bug is disrupting the user experience.
Describe the ideal end-user scenario, and try to offer as much detail as possible. Don’t just leave it at "my NAS does not work", " my backup failed", "the TOS not more acccessable".
  • 5. Actual Result
Detail what the bug is actually doing, and how it is a distortion of the expected result.
Elaborate on the issue
  • Is the software crashing?
  • Is it simply pausing in action?
  • Does an error appear?
  • Or is it simply unresponsive?
Specificity in this section will be most helpful to the tech team. Emphasize distinctly on what is going wrong. Provide additional details so that they can start investigating the issue with all variables in mind. For example:
  • “Link does not lead to the expected page. It shows a 404 error.”
  • “When clicked, the button does not do anything at all.”
  • “The main image on the homepage is distorted on the iPhone X.”
6. Visual Proof of Bug
Screenshots, videos, log files must be attached to clearly depict the occurrence of the bug. Depending on the nature of the bug, the tech team may need video, text, and images.

Text logs, visual logs (screenshots), video logs, console logs, and network logs, make it easy for QAs and the tech team to detect exactly where the error has occurred, study the corresponding code and implement fixes.

Thank you very much!
To contact our team, please send email to following addresses, remember to replace (at) with @:
Support team: support(at) (for technical support only)
Service team: service(at) (for purchasing, return, replacement, RMA service)

Post Reply