No matter what you call them – bugs, defects, or even design side effects – it is impossible to eliminate them completely. For a project to be successful moving forward, it is very important to be able to correctly write an error report, as well as to know what to pay attention to in it.
In a good bug report, three things should be described: • How to reproduce the error – as accurately as possible – and how often the error manifests itself. • What was supposed to happen – how do you see it? • What is actually happening – at least the data you were able to record.
The volume and quality of the provided information equally characterize the report’s author, as well as the error itself. A short angry report (“This function – “That sucks!” doesn’t really tell the developers much other than that you had a bad experience. mood. A report containing detailed information about the context of the incident, facilitates the reproduction of the error and earns the respect of the entire team, even if the error delays the release of the version.
The error report is like a conversation, and everyone can see it from the very beginning. Don’t shift the blame onto others and don’t deny the very existence of the error. It’s better to ask for additional information or think about what you might have missed.
Changing the status of an error, for example from open to closed, is a public statement of your opinion on the error. Don’t hesitate to take the time to immediately explain why you deemed it possible to close this error. This way, you will spare yourself from long and tedious explanations with dissatisfied managers and clients in the future. Changing the priority of the error is also a public statement, and if the error seems trivial to you personally, for someone else it might be a reason to stop using the product.
Do not overload the report fields with information that is personally necessary for you. Note. “IMPORTANT:” in the report title may help you sort the results more easily. a specific error report, but eventually, others will start copying this note, inevitably with typos. Or it might need to be removed and applied to another report. It’s better to use a new value. or a new field and describe how it is used, so others don’t have to repeat it.
Make sure everyone knows which specific issues the team should be working on. Usually, a public query with an obvious name is used for this purpose. Ensure that this query is the same for everyone, and if It is necessary to change it, be sure to inform the team that the work plan is changing.
Finally, remember that a discovered bug is not a standard unit of labor measurement, just as the number of lines of code is not an accurate assessment of the effort expended.