69

I suppose that this is a common situation: I test some code, discover a bug, fix it and commit the bug-fix to the repository. Assuming that many people work on this project, should I first create a bug report, assign it to myself, and refer to it in the commit message (e.g. "Fix bug #XYZ. The bug was due to X and Y. Fixed it by Q and R")? Alternatively, I can skip bug report and commit with a message such as "Fixed a bug that caused A when B. The bug was due to X and Y. Fixed it by Q and R".

What is considered a better practice?

Improve this question
6
  • 4
    Depends on the size of your company and team, and the characteristics of the bug. On small and fast teams, that's just not necessary, as you can communicate with your fellow developers by just shouting at them. On big teams, large organizations, distributed development environment, it's good to log your work, but is also an overhead that'll drag your production level down if you work on several small bugs. Unless it's a serious bug, which is always nice to have documented, unit-tested to avoid regression and closed.
    – Machado
    Oct 20, 2016 at 11:33
  • 16
    Don't forget that some bugs don't stay fixed - they spontaneously reincarnate if you ignore them for a while. Knowing how somebody attempted to fix it last time around can be valuable. At the very least, there should be some documentation saying what you did to the code and why, even if it's only in comments in the code.
    – alephzero
    Oct 20, 2016 at 20:40
  • 5
    In addition to the previous comments, it also depends if the bug made it out into the wild but you were lucky enough to not have any customers encounter it, or if it was introduced and fixed within one release cycle.
    – whatsisname
    Oct 21, 2016 at 4:19
  • 3
    When in doubt, shout it out. To me it never hurt to open and close a bug report. In some circumstances, it's good to have such things documented and official.
    – phresnel
    Oct 21, 2016 at 9:22
  • 1
    Related to @alephzero's comment, something that happened to me recently: Fixing a bug in one part of the code revealed bugs elsewhere. They had unintentionally canceled each other out in the part I had not touched, and the maintainer's first instinct was to undo my fix.
    – Izkata
    Oct 21, 2016 at 14:46

8 Answers 8

Reset to default
71

It depends on who the audience of a bug report is.

If it is only looked at internally by developers, to know what needs to be fixed, then don't bother. It's just noise at that point.

Non-exhaustive list of reasons to log anyway:

  • Release-notes include information about fixed bugs (to some threshold which this bug meets) - especially if there is a vulnerability exposed by this bug
  • Management wants a notion of "Time spent bugfixing" / "Detected bug count", etc.
  • Customers can see the current state of the bugtracker (to see if their issue is known about, etc.)
  • Testers get information about a change that they should test for.
Improve this answer
8
  • 1
    You might also want to record a bug if it exposes a vulnerability, to notify users that they should upgrade (or to get the bugfix added to a separate "security updates only" branch, if your product is doing that).
    – Colonel Thirty Two
    Oct 20, 2016 at 19:45
  • 56
    The most likely spot for a bug to occur is a spot that a bug previously occurred. I'd recommend recording it in virtually every scenario.
    – corsiKa
    Oct 20, 2016 at 20:10
  • 19
    #4: Testers use the bug tracker to guide their testing. They will test that the fix works and that it didn't cause new bugs or regressions.
    – jpmc26
    Oct 21, 2016 at 0:18
  • 2
    @corsiKa When the medicine is worse than the disease? ;-)
    – hBy2Py
    Oct 21, 2016 at 0:23
  • 2
    @BradThomas to rephrase what you quoted: "The bugtracker is used as a TODO list, and nothing more" + "Fixed bug" -> "no TODO". I agree in almost all other situations, you want a record
    – Caleth
    Oct 21, 2016 at 15:43
53

I'd say, it depends whether your product was released with the bug or not.

If it's released with the bug that you found, then yes, create a bug-report. Release cycles can often be long and you don't want your bug being reported as a new issue while you have already fixed it.

If your bug hasn't shipped yet, then I wouldn't follow the same path. You will now have people trying to recreate your bug which they can't because it isn't in a release yet, essentially wasting their time.

Improve this answer
1
  • 2
    Further to this, if you're checking in code against work items, consider checking-in the bug-fix against the original work item when fixing bugs that haven't made it to a product release.
    – wablab
    Oct 20, 2016 at 17:26
25

You should do this if it is a bug that could have been reported by a customer. Worst case: You fix the bug, but nobody knows. Customer reports the bug. Your colleague tries to fix the bug, but cannot reproduce it whatsoever (because you fixed it already). That's why you want a record of the bug.

It's also useful if you do code reviews, where usually code would be written for some task and then reviewed. It's better in that case to have that bug fix isolated, which may require putting something into your task list and then doing all the work.

Improve this answer
10

This depends on several factors.

Both Pieter B and Caleth list some in their answers:

  • Has the bug been part of an official release?
  • Is the number of bugs/time spent on them tracked specifically?

There can also be internal procedures to follow, often backed by the requirements of a certification. For certain certificates, it's mandatory for every change in code to be traceable to a record in an issue tracker.

Additionally, sometimes even trivially-looking bugfixes are not as trivial and innocent as they first appear. If you silently bundle such a bugfix to delivery of an unrelated issue, and the bugfix later turns out to be problematic, this will make it much harder to track down, let alone isolate or revert.

Improve this answer
1
  • 2
    Of course you should mention the bugfix in the commit message, and preferably make a separate commit for the change that fixed the bug. (And maybe a separate pull-request or patch-series, if it's a change that stands on its own). The only exception to that would be if the bug is fixed as a side-effect of changing something for a different reason (but then still mention it in the commit message). The only question is whether to bother with the bug-tracker, not whether to bundle the change in with other stuff in a single commit!
    – Peter Cordes
    Oct 21, 2016 at 6:59
3

This question can only really be answered by your project lead, or whoever is in charge of the "ticketting process".

But let me ask the other way: why would you not record a bug you patched?

The only fathomable reason I see is that the effort for filing the bug report, committing against it, and closing it, is orders of magnitude larger than the time to fix the bug.

In this case, the problem is not that the bug is so easy to fix, but that the paperwork takes too long. It really should not. For me, the overhead to create a Jira ticket is pressing c, then entering a short 1-line summary, and pressing Enter. The description is not even overhead, as I can cut&paste that into the commit message, together with the issue number. At the end, . c <Enter> and the issue is closed. That boils down to 5 key presses overhead.

I don't know about you, but that's little enough to make it a policy in even small projects to record every bugfix in this way.

The benefit is obvious - there are quite a few people who can easily work with a ticket system like Jira, but not with the source code; there are also reports generated from the ticket system, but not from source. You definitely want your bug fixes in there, to learn about possible developments, like a steadily increasing influx of small 1-line bugfixes, which could provide you with some insight into process problems or whatever. For example, why do you have to do such small bug fixes often (assuming it happens often)? Can it be that your tests are not good enough? Was the bugfix a domain change, or a code error? Etc.

Improve this answer
3

The rule I follow is that if the section that you're working on has never been released and it doesn't even run yet and no user has ever seen it, fix every little bug you see quickly and move on. Once the software has been release and is in production and some user has seen it, every bug you see gets a bug report and gets reviewed.

I have found that what I think is a bug is a feature for someone else. By fixing bugs without having those bugs reviewed, I might be creating a bug instead of fixing it. Put in the bug report what lines you would change to fix the bug and your plan on how it should be fixed.

In summary: If this module has never been in production, fix every bug you see quickly and follow the spec. If the module is in production already, report every bug as a bug report to be reviewed before fixing.

Improve this answer
2

Yes.

There are some answers already which expose situations in which it is worth creating a bug report. Some answers. And they differ.

The only answer is that nobody knows. Different people, at different times, will have different opinions on the matter.

So now, when encountering a bug, you have two solutions:

  • ponder whether it is worth opening a bug report, or not, maybe ask a colleague's opinion... and then later, in some cases, regret that you didn't because someone is asking about it and if you had the report already you could just point them to that
  • just create the report

Creating the report is faster, and if it's not... automate it.

How to automate it? Presuming that your tracker supports scripting, just create a script that you can call and which will use the commit message (title and body) to submit a bug report and close it as "implemented" immediately, with the commit revision associated for tracking.

Improve this answer
0

I am going to agree the other answers all offer good rules of thumb and several even touch on this point, however I think there is only really sure-fire answer here.

Just ask your manager. Well your manager or alternatively project lead or scrum master etc depending on how your group is structured.

There are many different systems of good and poor practice about but the only way to know you are doing the right thing for your team is to ask.

Something along the lines of a one minute corridor conversation would do: "Hey (boss), if I fix a minor bug that only takes a few minutes is it worth making a ticket for it or should I just mention it in my commit message?" and you will know for sure. All the good practice in the world is useless if that method annoys your team and your manager.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.