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. Bug tracking isn't that much fun. But promise me: it can be super-fun.
I’d like to present you 6 simple bug tracking tips for your next bug tracking project, which will help you feel way more comfortable while tracking & fixing bugs.
According to Technopedia bug tracking is defined as:
"...a process used by quality assurance personnel and programmers to keep track of software problems and resolutions.”
Therefore a bug tracking tool 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.
For further read, I recommend the following blog posts:
>> surprisingly easy bug tracking hacks: http://usersnap.com/blog/easy-bug-tracking-hacks-developers/
>> How to set up a bug-free environment: http://usersnap.com/blog/bug-free-development-environment/
6. According to Technopedia:
“Bug tracking is a process used by quality
assurance personnel and programmers to
keep track of software problems and
resolutions.”
10. Release early, release often.
Ever been annoyed of an open bug which
has been filed a couple of months, maybe
years ago?
Even worse, an open bug which hasn’t been
evaluated by anyone?
11. Release early, release often.
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.
13. 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.
14. Room for communication.
However: There always will be some room
for misunderstanding or missing information
which results in a need for communication.
15.
16. Questions to answer.
• 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?
18. 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.
19. Keep it one-on-one.
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.
21. Avoid opinions – focus on
solutions.
Tracking bugs means that some problem or
discrepancy to the defined requirements has
been identified by the bug reporter.
22. Avoid opinions – focus on
solutions.
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.
24. Agree what a closed bug report
means.
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.
26. Open & closed.
In 99% of all use cases there is no need to
use further statuses like untriaged or started.
While the bug report is still “open” it doesn’t
really matter how big the progress of the
developer is.