Bug advocacy start when you start writing bug. Some points you should maintain before you represent your bug:
- Your bug report is your representative
- Good reporting earn good reputation and bad reporting generate extra work for developer
- When you write a bug , you're just asking (whom you don't manage) programmer to look at the bug that you found
- Any bug report that you write is an advocacy document and that report repair bug
- Make your bug report effective sales tool (thilient)
- Some bugs are too minor impossible to understand, not reproducible. Report those bug and explain reason in meeting that will result problem/confusion in future.
- Take the time make your bug report valuable because so many people read and rely on this
- Draw the product owner/project coordinator/stakeholder attention to controversial bugs.
- Report defect promptly because it create confusion for manager. Also you've forgotten key details
- Never assume an obvious bug has already been filled. Lost of people knew about bug but assume someone else reported.
- Uncorner your corner cases.
- Keep clear difference between severity and priority
- Summary line is the most important line in the bug report
- Summary line is the best tool for selling the bug
- Summary can only be not more than 65 char
- Never exaggerate your bugs.
- Make your reports readable even people who are exhausted and cranky
Most common problems with developer...............
- Developer always discourage QA for posting bug.
- Developer like to comment in JIRA “not a bug”.
- Developer like to say “This is not a requirement”.
- Lots of bug no more bug will post today told by PC.
- No written requirement so developer change their requirement when they want.
- Cache not clear but developer already fixed bug
- Don't post bug I will resolve it within 2 minutes
