The correct way to log bugs

You as QA, tester, developer, project manager, product owner or any role you have on your company may came across or may be related or informed about the bugs logged by the team within the project, bugs touches all team members because in some phase or in some moment everyone will see the bugs and review them.

First of all let's be clear, bugs are not intended for QAs to bring out a developer's error or to criticize their job, bugs are intended to discover failures before the client or some stakeholder do, this will be worst and may generate a negative impact to the company and the project, this also may cause the client to lose confidence on the company or team. This is not a competition about how many bugs QA found and the seniority level of a QA is not measurable by how many bugs he/she finds, I do not agree that if a day passes and QA didn't log any issues is because QA did no work, perhaps there were a lot of meetings, or QA was doing test cases, feature files, or simply there were no bugs and the developers delivered a high quality module or software.

There are a lot of bug management tools like Jira, Mantis, BugZilla, even Excel or Google Docs (please try not to use Excel or spreadsheets for this), etc. There are a lot of tools, some of them free, use them, and some of them are great and have a lot of configurations to make life easier for everyone.

I always ask on interviews what are the parts of a bug and I have received a lot of answers, some of them basic and some of them with a lot of details, for me a great bug must have the following info:

• Summary
• Severity
• Priority
• Reporter
• Assignee
• Environment where the bug was found (QA, development, live, etc)
• Bug type (functional, UI, security, performance, etc)
• Steps to reproduce
• Obtained result following the steps to reproduce
• Attached image or video (don't add lots of images if you can just attach a video)
• Version affected by the bug
• Phase or sprint you are at

People often confuses severity with priority, this is a common mistake, but don't forget severity is the impact of the bug (major, minor, blocker, critical) and priority is the order the ticket needs to be fixed (urgent, immediate, not urgent, or low, medium or high, your call). You also need to really know what is a blocker, a critical, a major or a minor bug, there are a lot of websites about different bug severity, I won't talk about that in here.

You can add more information to the bug, like a due date, some components, labels (I really like to use labels, they help for filtering and to separate stuff, like Front End, Back End, Design, etc, if you have them, use them) and more fields you can think of, but for me, the items mentioned above are the necessary fields and information for all people on the project to understand a bug.

I want to be clear on something here and is that QA must do a full description of the bug with evidence, QA don't need to explain the developer how to solve it (this is a plus) sometimes integrations, incorrect data on the data base and complex stuff may be the cause, don't forget a bug is the consequence, not the cause, QA needs to focus on the problem found and describe it really good and the developer must focus on the solution based on what the QA logged. 

Everyone on the project must demand QA to log bugs correctly, remember, bugs will be seen by all the team if needed and if some other QA folk starts on the project, he/she must understand the bug, don't just write bugs for you write them for the team.

Please make sure you log bugs in a correct way no matter if you are not a QA, bugs are for everyone not only for developers and QAs.

@LuchoAgileQA