Implementation of New Bug Reporting Process

Purpose of the meeting

• Uniform workflow
• Reduced time for bug resolving
• Avoid double reporting
• Avoid involving more resources than needed
• Better information availability
• Save time for everybody
• Happy colleagues
• Happy customers

Critical issues/Show stoppers

Critical issues are issues that prevents the customer from accessing Quick3 and doing critical tasks like handling their customers in the store (cannot create orders, cannot take payments) and this is caused by system failure.

Critical issues are causing problems for multiple customers.  If everything is OK for all customers except the customer that is reporting the issue – it is most likely a configuration issue for that one customer, and NOT a critical issue.

Only really critical issues is to be reported directly to first available resource in development team – ideally after verification by 2nd line.

Bug / issue reporting

https://quickt.visualstudio.com/Quick3/_wiki/wikis/Quick3.wiki/136/Managing-Your-Workspace-in-Azure-DevOps

Bug = Result in error message, incorrect response and similar.

Issue = Minor issues (things looking weird, wrong translations and similar)

Feature or improvement requests is not bugs… (not on todays agenda)

• Bugs only to be reported in DevOps (not email, Teams or similar).
• Only verified bugs (ideally verified by 3rd line) should be reported as bugs.
• Good description, including examples, reference to customer, screenshots is important.
• Reproduction steps is important!  Saves lot’s of time
• Add links to FreshDesk items for reference.
• The resource reporting the bug should always tag the following resources so they are notified about the bug:
  • The resource that originated the bug
  • Per Arne (only bugs, not minor issues)
• “Follow” the item so you will be notified on status updated.  Then you will know when the bug is resolved so you can provide feedback to the customer.

No access to DevOps?  Send request to Per Arne (per.arne.jakobsen@quick.no).