Comments on: Four reasons to file the bugs you find in code review

By: Stan Taylor

Stan Taylor — Wed, 20 Jan 2010 18:39:31 +0000

@Seth - As a QA engineer, my nirvana is a system that shows work item IDs (defect, requirement) completed with each commit (or build) as well as a list of files changed with diffs (Let's not get bogged down here in the discussion of whether EVERY commit must have a work item). That provides both angles: the documentation (defect) angle and the ability to see what exactly changed.

Having the ability to look at diffs (preferably with an indication of why something changed, hence associating work item IDs with commits) serves several purposes: 1.) it allows me an easy way to familiarize myself with the code, 2.) it helps me decide how I need to test something, and 3.) it allows me to spot unreported changes and, at the very least, ask the developer why he changed it.

By: Jesse Gibbs (Atlassian Employee)

Jesse Gibbs (Atlassian Employee) — Wed, 20 Jan 2010 17:02:45 +0000

Great post! These are very good reasons for submitting bugs during code review. Too often the issues found during code review get lost in the shuffle.

Atlassian has tools for both bug tracking and code review, and we’ve integrated them such that you can create bugs from code reviews with just a few clicks: http://www.atlassian.com/software/crucible/tour/jira-integration.jsp

By: Rafe

Rafe — Wed, 20 Jan 2010 06:14:28 +0000

Generally all the code we check in is associated with an item in the issue tracker, either a feature request or a bug.

By: Seth

Seth — Wed, 20 Jan 2010 06:11:51 +0000

These are all about communication, and the assumption that filing a bug is a good way to communicate with developers, testers, and customers (and as zack adds, managers). I guess it depends on the local culture, but in my experience, developers only look at a bug report if it’s assigned to them. The revision control system is a better way to see what’s happened recently. There will always be a check-in when a bug is fixed, but other check-ins are relevant to everyone you mentioned and could just as easily cause any of the same problems. Will you also file a bug report when you check in new code that doesn’t fix a bug?

By: Jacob Davies

Jacob Davies — Wed, 20 Jan 2010 03:41:20 +0000

To expand on the last point, "every bug deserves a test"; that is, it is usually the case that a bug reflects a type of failure that is not obvious and could easily be repeated, otherwise it wouldn't be a bug. So put a test in to catch it (or if it's a UI bug, put a test in the test plan for it).

I'm not very good at this kind of thing either though.

By: zack

zack — Wed, 20 Jan 2010 02:13:49 +0000

While not as important as most of what’s on your list, filing that bug also provides visibility to management/clients about what you as a developer do/are doing. Never hurts to have that, but this is especially the case if your managers are non-technical doofuses (Not that this ever happens) or you are billing a client hourly.