What is bug tracking really about?<\/h2>\n\n\n\n
Before we get started with 6 simple bug tracking hacks, I\u2019d like to take a look what bug tracking really means. According to Technopedia<\/a>:<\/p>\n\n\n\n \u201cBug tracking is a process used by quality assurance personnel and programmers to keep track of software problems and resolutions.\u201d<\/p>\n\n\n Therefore a bug tracking system stores all the information about reported bugs and keeps track of the status of each bug. You definitely see the need of extensive information while tracking bugs. I really like the following image which highlights the relevant information while tracking bugs.<\/p>\n\n\n You probably see the drawback of tracking bugs in this picture. Providing sufficient information not only requires a huge amount of bug tracking resources (time) but also copious skills in the fields of software development.<\/p>\n\n\n\n Here’s how to make your bug tracking more efficient.<\/p>\n\n\n\n Ever been annoyed of an open bug which\u2019s been filed a couple of months, maybe years ago? Even worse, an open bug which hasn\u2019t been evaluated by anyone? Release fast, release often<\/strong> is a philosophy in software development which focuses on early and frequent releases by creating a tight feedback look between developers and testers. Bug queues with thousands of open bug report<\/a> are something every team should avoid. Keeping your bug management lean and tidy will hep to resolve issues faster.<\/p>\n\n\n\n Reporting bugs requires the ability to identify relevant information which needs to be added to every bug report. Modern bug tracking tools (like Usersnap<\/a>) offer the ability to attach this needed information automatically. Nevertheless there always will be some room for misunderstanding or missing information which results in a need for communication.<\/p>\n\n\n\n However I\u2019ve seen a lot of testing scenarios where no room for that kind of communication was established between developers and testers. Questions like\u2026<\/p>\n\n\n\n \u2026need to be answered at the beginning of the bug tracking process.<\/p>\n\n\n\n There are a lot of misunderstandings out there about the work of developers and testers. So bring everyone on the same page<\/strong> and create a feedback-orientated culture where the work of developers and testers are respected in the same way.<\/p>\n\n\n Never ever discuss bugs in a project meeting!<\/strong> Don\u2019t get me wrong. There\u2019s nothing bad about working together on reproducing and fixing bugs. It’s even highly appreciated \ud83d\ude09<\/p>\n\n\n\n But: Do not discuss bugs (Is it really a bug?, Do we have to fix this bug?, etc.) in lengthy meeting with your entire project team. I\u2019ve been to a lot of project meetings where different bugs (which have been reported by testers) have been discussed. Reporting bugs, then discussing them, afterwards addressing them in the next development phase and then going to re-tests is quite a slow approach.<\/p>\n\n\n <\/p>\n\n\n\n It\u2019s way more efficient to keep it one-on-one<\/strong>. As Yegor wrote in his post about the 5 principles of bug tracking<\/a> each bug report is linked between two people. As he named them: the problem specifier (=tester) and the problem solver (=developer). No matter how many people are involved in a project, there are only 2 formal responsibilities (with two different roles) for solving the reported issue.<\/p>\n\n\n\n Reporting a bug means that some problem or discrepancy to the defined requirements has been identified by the reporter. Do not add opinions or comments like \u201cI think I had a similar issue a couple of weeks ago\u201d to your bug reports. Use your chat tool (or email) for exchanging opinions – but not your bug reports. The bug report should be the place where relevant information for reproducing and fixing the bug is stored. Focus on solving that bug report instead.<\/p>\n\n\n\n Ever faced a discussion about closing a bug or not? Well, congratulations, you\u2019ve been in the worst possible bug tracking situation that could happen. 1. Who is responsible for giving order (= reporting bugs)? Take a look at the meaning of \u201cclosed\u201d<\/strong>. In most dev teams a bug is closed by the developer who fixed the bug. I\u2019d like to recommend closing the bug report by the person who reported the bug<\/strong>. Once the solution for a certain bug is provided by the developer the bug reporter should be asked to close the bug report. Why? Because he or she is the one who opened the bug report and is therefore responsible for a sufficient solution of the problem.<\/p>\n\n\n\n Having used some traditional bug tracking- and issue reporting tools, like Bugzilla or JIRA, you\u2019re used that a bug can have all kind of statuses. To be honest, statuses like \u201cuntriaged\u201d or \u201cstarted\u201d are an overkill for most projects. I believe that every ticket should only have two simple statuses: \u201copen\u201d and \u201cclosed\u201d.<\/p>\n\n\n\n While the bug report is still \u201copen\u201d it doesn\u2019t really matter how big the progress of the developer is, since the ticket is still open which basically means that the problem haven\u2019t been solved so far.<\/p>\n\n\n\n There a lot of bug tracking tools<\/a> who offer all kind of \u201ccreative statuses\u201d which keeps everyone busy playing with them. In the end only two statuses really count. Open & closed. Don\u2019t waste time setting statuses.<\/p>\n\n\n\n Every bug which is reported demands additional time in a project to be fixed. Bug tracking therefore requires sensitivity as well as great communication skills from the people tracking bugs as well as from those fixing them. With these 6 bug tracking hacks we at Usersnap try to be more productive while reporting & fixing bugs.<\/p>\n\n\n\n Do you have any tips for improving the bug tracking process? What is your favourite bug tracking hack? <\/strong><\/p>\n\n\n\n PS: If you prefer a summary of that post, also make sure to check out this presentation about 6 easy bug tracking tips & tricks on Slideshare<\/a>!<\/p>\n\n\n\n\n
Try Usersnap for Bug Tracking<\/h2>Try Usersnap Now<\/a><\/div>\n<\/blockquote>\n\n\n\n
![\"bug](\"https:\/\/usersnap.com\/blog\/wp-content\/uploads\/2015\/02\/bug-tracking-hacks.png\"){kind=tracking}
<\/a><\/figure>\n<\/div>\n\n\n1. Release fast, release often<\/h2>\n\n\n\n
\nOpen bugs which have been carried along for a long time are the worst thing for testers and make them feel less valued.<\/p>\n\n\n\n2. Create room for communication<\/h2>\n\n\n\n
\n
![\"bug](\"https:\/\/usersnap.com\/blog\/wp-content\/uploads\/2015\/02\/bug-tracking-process-hacks.jpg\"){kind=tracking}
<\/a><\/figure>\n<\/div>\n\n\n3. Keep it one-on-one<\/h2>\n\n\n\n
Try Usersnap for Bug Tracking<\/h2>Try Usersnap Now<\/a><\/div>\n\n\n\n
4. Avoid personal opinions – focus on solutions<\/h2>\n\n\n\n
5. Agree upon what a closed bug means<\/h2>\n\n\n\n
\nIf you ever find yourself in the given situation of discussing the status of a bug, please take a step back and ask yourself the following questions:<\/p>\n\n\n\n
\n2. Whose responsibility is it to accept results (solutions for bugs)?
\n2. What are the criteria of acceptance?<\/p>\n\n\n\n6. Only use 2 statuses: Open & closed<\/h2>\n\n\n\n
Wrapping it up<\/h2>\n\n\n\n