When it comes to bug tracking there’s a lot of discipline required from everybody involved. Tracking & solving bugs encourages everyone involved to stand to the rules. Especially in creative- & startup-driven industries it can be pretty hard to discourage any informal communication. And in many cases people won’t name bug tracking as their favourite part of a project.
I’d like to present you 6 simple tips for your next bug tracking project, which will help you feel way more comfortable while tracking & fixing bugs.
[otw_is sidebar=otw-sidebar-1]
What is bug tracking really about?
Before we get started with 6 simple bug tracking hacks, I’d like to take a look what bug tracking really means. According to Technopedia:
“Bug tracking is a process used by quality assurance personnel and programmers to keep track of software problems and resolutions.”
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.
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.
Here’s how to make your bug tracking more efficient.
1. Release fast, release often
Ever been annoyed of an open bug which’s been filed a couple of months, maybe years ago? Even worse, an open bug which hasn’t been evaluated by anyone?
Open bugs which have been carried along for a long time are the worst thing for testers and make them feel less valued.
Release fast, release often 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 are something every team should avoid. Keeping your bug management lean and tidy will hep to resolve issues faster.
[otw_is sidebar=otw-sidebar-2]
2. Create room for communication
Reporting bugs requires the ability to identify relevant information which needs to be added to every bug report. Modern bug tracking tools (like Usersnap) 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.
However I’ve seen a lot of testing scenarios where no room for that kind of communication was established between developers and testers. Questions like…
- Who are the testers and developers in charge?
- How can I get in touch with the testers/developers in charge?
- What kind of communication takes place in my bug tracking system and which does not?
- Is it alright to ask for feedback via phone/email/chat messenger?
…need to be answered at the beginning of the bug tracking process.
There are a lot of misunderstandings out there about the work of developers and testers. So bring everyone on the same page and create a feedback-orientated culture where the work of developers and testers are respected in the same way.
3. Keep it one-on-one
Never ever discuss bugs in a project meeting! Don’t get me wrong. There’s nothing bad about working together on reproducing and fixing bugs. It’s even highly appreciated 😉
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’ve 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.
It’s way more efficient to keep it one-on-one. As Yegor wrote in his post about the 5 principles of bug tracking 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.
4. Avoid personal opinions – focus on solutions
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 “I think I had a similar issue a couple of weeks ago” 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.
[otw_is sidebar=otw-sidebar-3]
5. Agree upon what a closed bug means
Ever faced a discussion about closing a bug or not? Well, congratulations, you’ve been in the worst possible bug tracking situation that could happen.
If 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:
1. Who is responsible for giving order (= reporting bugs)?
2. Whose responsibility is it to accept results (solutions for bugs)?
2. What are the criteria of acceptance?
Take a look at the meaning of “closed”. In most dev teams a bug is closed by the developer who fixed the bug. I’d like to recommend closing the bug report by the person who reported the bug. 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.
6. Only use 2 statuses: Open & closed
Having used some traditional bug tracking- and issue reporting tools, like Bugzilla or JIRA, you’re used that a bug can have all kind of statuses. To be honest, statuses like “untriaged” or “started” are an overkill for most projects. I believe that every ticket should only have two simple statuses: “open” and “closed”.
While the bug report is still “open” it doesn’t really matter how big the progress of the developer is, since the ticket is still open which basically means that the problem haven’t been solved so far.
There a lot of bug tracking tools who offer all kind of “creative statuses” which keeps everyone busy playing with them. In the end only two statuses really count. Open & closed. Don’t waste time setting statuses.
Wrapping it up
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.
Do you have any tips for improving the bug tracking process? What is your favourite bug tracking hack?
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!
This article was brought to you by Usersnap – a visual bug tracking and screenshot tool for every web project.
[otw_is sidebar=otw-sidebar-4]
Resolve issues faster with visual bug reporting.
Simplify and reduce issue & bug reporting efforts with screen recordings, screenshots, and annotations.
And if you’re ready to try out a visual bug tracking and feedback solution, Usersnap offers a free trial. Sign up today or book a demo with our feedback specialists.
