1. It's A One-On-One System:
Each bug is a link between two people – one who detects the bug and one who solves the bug. No matter how many people are there in the channel of the bug resolution, the two main characters matter the most and play the lead roles. One who reports the bug should stand with his/her ticket and defend the issue. There might be several discouraging issues for the bug reporter but the bug needs to be kept alive anyhow. Responsibility of the bug solver is to defend the solution. If a bug is assigned to someone to resolve it, then it's the bug solver's job to convince the bug reporter that best solution is in place. In order to create the best solution, bug solver should understand the problem first, probe into all the possible options and then propose the best solution. However, the bug solver has to convince the reporter that the bug is resolved.
2. Close Bug As Soon As Possible:
Bug ticketing is not like any chit-chat session. It's all about closing the bug as soon as possible. When a ticket is assigned to someone, the bug resolver's main focus should be how soon it can be closed. Sooner a bug is closed, it's considered better for the project. If a bug is remained unresolved for a long time, then it might become nightmare for the management. Then it also becomes difficult to track them and control them. If any bug/ticket becomes longer than expected, then it should be closed without any delay.
3. Don't Close It Completely:
Every time a bug is raised, project resources are consumed in some other way. Every bug means there is some amount of money which is spent on the project for finding the problem, reporting it and then finally fixing it. If the bug is closed without solving the problem properly then it means the money is completely misused. As every bug consumes project time and budget resources, there should not be any temporary solution. When the bug is started, there is definitely something in mind. If the bug is closed without solving the problem then same problem may arise again and similar bug will be reported too. If there is actually no issue and the bug was irrelevant, the bug resolver should document it in right way in the source code to prevent any confusion in future.
4. Address Comments For Every Bug:
If a bug resolver posts a message to a bug, then it needs to be addressed to someone. Comments are not only about opinion but they are for communication. A bug, as we know, is nothing but conversation between two people. If the bug is resolved, then the comment should be addressed to the ticket reporter. If any solution is wrong, comments are marked for the assignee. Generic opinions are least required in case of bug resolving and comments should be very specific. Your comments can help the project a lot, remember that.
5. Broken Product Should Always Be Reported:
Every bug is reproducible and nobody can beat this fact. Every time a bug is reported, explanation is required how a product is broken. It's mandatory to prove that the software didn't work as expected, or documentation was not done properly and basic requirements were not satisfied. Every bug should be formatted in a particular way. Even if there is a question then the format should be followed. If there is any question it means there is some problem with project documentation and the reason behind why it is broken will also be known. If there is no proper explanation, then it should also be mentioned on the ticket.
No comments:
Post a Comment