How many times have you received bugs reported assigned to you, which you are totally clueless what the report is about? I have almost lost count the number of bugs assigned to me which I am totally unable to figure out what and where exactly the bugs is. More importantly, how many times have you reported bugs that you need to provide more information subsequently about the bug before the bug can be resolved?
The worst bug reported that I have received is a one statement description that goes like this: "This functionality (example: create member) is not working". Yes, it not working but due to what reason and what kind of error is the application or API throwing. These information are precious to whoever that are assigned to investigate the bug reported.
Reporting bugs is similar to conveying any kind of message. If your message is not understood by the receiver, then the sender is deem to fail in communicating. One of the most important principles of presentation is knowing you audience. You can imagine that you are giving direction to someone going to your house. You cannot effectively provide direction without knowing the location of the person. While providing direction, intermediate landmark should also be provided to ensure that the person is progressing accordingly to the direction you provided.
Doing yourself a favor by reporting a bug in the view of the person assigned to investigate or resolve the bug. If a user don't report a bug efficiently, then the longer it will take to resolve the issue as more collaboration is required for the whole process to complete.
Do your part and do not turn the whole development process into a bug driven development by reporting genuine bug effectively. Verify that there is a genuine error before logging it as a bug as the end to end process before the bug can be close is way too time consuming. Genuine is the key word above as non genuine bug reported is a complete waste of time and resources as the bug might be perceived by the person as an error, but it could really be a genuine error due to some incorrect behavior like missing input.
The worst bug reported that I have received is a one statement description that goes like this: "This functionality (example: create member) is not working". Yes, it not working but due to what reason and what kind of error is the application or API throwing. These information are precious to whoever that are assigned to investigate the bug reported.
Reporting bugs is similar to conveying any kind of message. If your message is not understood by the receiver, then the sender is deem to fail in communicating. One of the most important principles of presentation is knowing you audience. You can imagine that you are giving direction to someone going to your house. You cannot effectively provide direction without knowing the location of the person. While providing direction, intermediate landmark should also be provided to ensure that the person is progressing accordingly to the direction you provided.
Doing yourself a favor by reporting a bug in the view of the person assigned to investigate or resolve the bug. If a user don't report a bug efficiently, then the longer it will take to resolve the issue as more collaboration is required for the whole process to complete.
Do your part and do not turn the whole development process into a bug driven development by reporting genuine bug effectively. Verify that there is a genuine error before logging it as a bug as the end to end process before the bug can be close is way too time consuming. Genuine is the key word above as non genuine bug reported is a complete waste of time and resources as the bug might be perceived by the person as an error, but it could really be a genuine error due to some incorrect behavior like missing input.
No comments:
Post a Comment