Bug advocacy

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