While developing (either features or bug fixes) I sometimes happen to discover bugs that are not directly related to what I'm working on. What should I do in that situation. Just fix it? Try to remember to fix it later? Write it down somewhere? Or enter it into the bug tracking system?
I generally enter it into the bug tracking system and let the process play itself out (i.e. triaging, assigning, etc.). However I have hardly ever seen another developer enter a bug. (Why is that?)
If you discover a bug, I can't think of any good reason not to enter it into the bug tracking system, whether you fix it or not. That's what the bug tracking system is for, after all.
In some cases it might make more sense to report it to a QA person who has more experience dealing with the system, but in any case the bug should be tracked.
It's possible that there might be some reason, valid or not, that developers shouldn't be entering bugs. One possible reason might be that the bug tracking system is visible to outsiders, and having too many reported bugs looks bad. That's a very bad reason, which should be addressed in some other way that still allows bugs to be tracked. Ask your boss.
(Of course if there's a bug in code that you're still working on, and it doesn't show up in anything that's been released, there's no need to track it in the system, though a TODO comment in the source code may be a good idea. To take an extreme case, "This code won't compile because I haven't yet typed the semicolon at the end of this line" is not a reportable bug.)
As for why other developers don't enter bugs, you'll need to ask them. They probably should.
You must enter the bugs in the bug tracking system in both cases:
when the bug concerns directly the code you are working on,
when the bug concerns the code you're not working on right now or the part on which another developer works.
This is essential, since the bug tracking system is made to... track bugs. Every bug. If you discover something wrong, don't just fix it. Document it through bug tracking system. When later, a customer running a previous version of the software will report a bug which is an exact duplicate, you will be able to link it to your report. If you have nothing to link to, you'll waste your time (or your colleague) searching for the bug in previous revisions, then try to solve it, and finally find that the bug was already magically solved.
This also explains why freelancers must use both version control and bug tracking system: those two tools are not only for teams.
There is no valid reason not to enter a defect into the defect tracking system. The only places where I have seen bug fixes applied without tracking is because the process was fundamentally broken. If this is the case, fix the process.
reasons for not entering are :
Fixing the bug right away is probably a bad idea. First, someone else might be working on the same fix, resulting in duplicated effort, and also, depending on the development methodology you're following, prioritizing what to work on next (fixing a bug or implementing a new feature) is more of a management decision then a development decision.
The decision is not clear cut, and involves tradeoffs.
(some) PROS
Bug tracking is essential for communication, especially on large teams. One of the best benefits of having multiple eyes on the code is the ability to detect problems earlier, and that benefit is lost if bugs are not logged or tracked as you are developing.
Logging bugs as you find them is, generally speaking, a good habit to have.
(some) CONS
Entering bugs into a bug tracking system can be onerous and time consuming, and can be really disruptive to development work - more often so when working in large teams. You may be expected to:
Sometimes bug tracking is just not the most efficient use of your time.
These are two general principles which can be hard to balance - finding a good strategy is a bit of an art. In situations like these, I think it's best to adopt a flexible heuristic, that I tweak as required for a given project, team, work environment, and your general skills. My strategy usually follows a pattern like approximately as follows:
Take time at the beginning of each new work-day, as part of your warm-up for work, to deal with the stickies. I take 10-15 minutes to go through my list of detected issues from the day before and do whichever of the following is quickest:
Over time, I've found all sorts of tweaks as useful. For example:
I find that, generally, as you follow this type of strategy, more and more of your peers and other company members will start to respect your work, and commitment to quality. After enough time, you'll have the respect and authority required to optimize the entire process to your liking. Keep an eye out for such opportunities, and take them as appropriate.
I believe that if a developer encounters a bug that is not related to what they are working and that they will not be fixing, they should enter it into the system just to have some record of it. That way, when QA starts testing (and they're still not fixed) you can give them this list bugs as "known defects" so they don't start reporting the same bugs.
Perhaps other developers who find bugs keep track of it on their own if they plan to fix it, but in that case they run the risk of 2 developers independently finding and fixing the same bug.
I would add that even if the bug has already been fixed (which shouldn't have happened before recording it in an issue tracker) it is a good idea to track it.
This way, if the issue should arise again in the future (regressions happen!) it is relatively easy to recognize the issue as "already dealt with" and read how it was fixed the first time.
Why is that? Because most developers look at the issue they have to raise and the code they have to write and figure it's easier not to bother.
But, whether that's the right thing to do depends on your process. Do you have a QA team? Do you think they mind if you just go changing code which won't be tracked? What about code-reviews? Will it skip by that crack? What about the business? Do they need to know you've fixed a bug so that they don't raise the same one later?
What about other developers? What if they fix it in a different way at the same time? What if they find a similar bug later and all you can do is say "oh, damn, I know we've had something like this before -- now what was it?"
There are about a million reasons for recording bugs in the bug-tracking system. If you're SURE you don't hit any of those issues then by all means, don't bother. But if you're at all unsure then you should record it, even if most people don't.
Of course you should enter it. Or at least report it to your QA people if that's your normal process.
Even if you do just fix the bug yourself, you'll want a record of the change so that it can then be tested to ensure that the fix actually works and that there hasn't been a regression. It's also possible a user might report the bug at some point, and if it's in the system and marked as fixed, your support people can tell them that it's already been addressed.
Programming is a complex work fundamentally. The bugs are complex. so I used to assess a bug by two factors:
I would classify a bug into one of the following types:
In case 1, a cookbook or FAQ is a good device for the team to fix such bugs in future.
In case 2, an elaborate and comprehensible record is the necessary for the team because it is a waste of effort if another programmer endures such bugs again. For example: memory leak.
In case 3, I think it is not a big deal that there is nothing left for record because you won't spend too much time to fix an easy bug. For example, a typo for id of element in HTML.
In case 4, such bugs create a dilemma. It needs some time to write an elaborate and comprehensible record to describe such bugs. But this record is rarely used in future. Without a record, however, appearing of such bugs would be a struggle again. For example, such bugs appear because of computer virus in somebody's computer.
Indeed you should be recording them in the system, and in case it's not practiced then it's good to start off.
In my past I was part of a product team, and we were on the beta release of a new product and at times we occasionally found bugs which at that point we used to note down and mail to the respective persons handling the modules (we had a bug tracking system, but we didn't think of pushing them there). Later on when days went by the items in the mail started to get ignored because of other priorities and that eventually lead to some sleepless nights.
Then, bang one day, Nirvana! Why are we not using the bug tracker, even if you found something which seems like a bug and could be possible that it isn't one (your thought about the process is wrong/flawed). It at least makes up on the list which could then be tested and most important of all a feedback as to why it's critical or on the flip side it is perfect and that's how it should work because of reasons 1... 2....
Now you have the list and also for those who have misunderstood some parts of the application they have the feedback based on which they can clarify their thoughts. A win-win situation.
Assuming its already-tested (and particularly if released) code absolutely.
There are a number of reasons for this:
Memory - The system is really unlikely to forget the bug, any given developer may.
Metrics - The number of bugs found, closed and the time taken can be good easy-to-capture metrics to tell you how the quality of your code is progressing
Urgency - It might seem like the most important thing in the world to the developer, however the time spent fixing this issue may be better spent on something that the end users want first (see also memory).
Duplication - Maybe it's already been spotted and is under examination / fix by someone else. Alternatively maybe it has fallen foul of the urgency rule and been put off. Of course the fact that you've found it again doesn't just mean that it shouldn't be done, it might mean that (as it keeps coming up) that is is now more urgent to fix.
Root cause analysis - The easiest bug to fix is the one that was never there. It may be that the team should be looking at this bug to find out how it came to be. This is definativley not to punish the one responsible (that never helps) but to find out how the situation can be avoided in the future.
Wider impact analysis - The cheapest bug to find is the one you knew about before you found it. By looking at this bug (particularly after doing root cause analysis) it may quickly become clear that this problem could exist in other places in the code. As a result the team can choose to go find it before it raises its ugly head at a more embarrassing moment.
The amount of time that is spent on these (if any) is largely dependent on the maturity and quality level of the code. Root cause analysis is likely to be overkill for a tiny team working on demonstration code, but a large team on business critical development probably need to learn the lessons effectively and efficiently.
From experience there are two broad reasons that developers avoid using the tool:
Item 1 implies that a better/simpler system may be required; or alternatively a more compelling justification of the existing system might be in order.
Item 2 should be a useful warning sign to the development lead about current task allocations.
I mostly agree with FrustratedWithFormsDesign but I think it is even clearer if the whole issue is broken down into two areas:
These are often treated as being the same and separating them will almost certainly help a lot.
These can be handled with: Bug Reporting:- put it in the system, as everyone says.
Bug fixing:- Every week or two (adjust to your development schedule, etc.) everyone gets together on the project and decides what should be fixed, by whom, etc. This was everyone is on the same page and can see what needs to be done. In Agile Development this is the Sprint Planning meeting.
A good tool that people want to use also makes a big difference. I like Pivotal Tracker and it passed my 'really useful tool' test when I started using it just to keep track of things I want to do or fix in my own private projects!
If you see something then say something!
I even enter bug reports about my own modules because I do not want to interrupt my current task. And I can ensure all the steps to reproduce are included :-)
And it's even better when someone else can see that you've listed something as a known bug. They like to know someone else has found it too.
I think this is more a political question than a question about bestpractice.
In my opinion it is a good practice to add non trivial bugs into the tracker system but the management has to decide how to cope with this.
For non trivial cases you should not fix the issue without consultating somebody else to make shure that
