Time and time again I get asked, how does static analysis fit into my existing bug tracking system? “I need an integration with my system (i.e. Bugzilla) because that is what we use everyday. Every time I find a bug I need to track this through my system.”
This is where I take a deep breath as I scream on the inside. Taking every bug and putting that into your bug tracking system is just wrong. Horribly wrong.
The best way I can describe this is through the compiler analogy. Every time you add a feature or bug fix, you run your compiler. Your compiler complains, saying you have a syntax error and you just fix that, rinse and repeat. Would you ever send your syntax errors to your bug tracking system? Uh, no. So why do the same for static analysis? Just because it is a critical buffer overflow or memory leak? No.
Why impose any kind of workflow for the developer when it comes to bugs? There should only be one thing the developer has in mind. Either fix the issue or ignore it. Just like they do for any syntax error from the compiler.
This is really a discussion of your usage of your static analysis (or source code analysis) tool. What I’ve described is the process where the developer is using static analysis at the desktop, in their favorite text editor or IDE. Of course, there is an exception to this. You can use static analysis on the full system run only. I highly discourage this for various reasons but I’ll save that for another discussion.
The chances are that you could have a product that is already established, so you probably have a backlog of issues. Static analysis can certainly be used to triage these bugs and output them to your bug tracking system.
I hope my message is clear, if you use static analysis correctly (allowing the developers to fix bugs as they create them) and a bug appears, just plain fix it. Yes, it’s that simple.