Bug Hunting Strategies?

Question

Let\'s say you have a bug that was found in functional testing of a fairly complex part of the software. It could stem from bad/unexpected data in the database, middle-tier cod

Answer 1

Here's some helpful hints:

• If you use a language that has generates a stack trace on exceptions start from there.
• Get a copy of the original data that caused the problem if you can.
• Use a good debugger.
• If you have access to one there are things like the ODB for various languages that can be helpful by allowing you to fast forward or reverse through the execution after the event occurs
• Exclude the impossible and you will be left with the solution!

Answer 2

I find the Rubber Duck Debugging strategy works well, too.

Answer 3

I tend to go with gut feeling, and a divide-and-conquer approach; isolating chunks of code of decreasing size where I think "the bug" is.

This doesn't work if you don't know, or don't understand the codebase - if that's the case, find someone who does, and go with their gut feeling.

Answer 4

Listen to how the experts debug software on Software Engineering radio:

Dave Thomas talks about software archaeology which has some really great tips on debugging.

Andreas Zeller appears in an episode devoted to debugging.

Answer 5

I suggest reading Debugging By Thinking.

Andreas Zeller has also done some work in systematic debugging studies.

Answer 6

I would say it doesn't matter, as long as it's documented and methodical. It's an odd little truism in programming that sometimes doing things in a random order is more efficient than spending a lot of time trying to figure out the "best" way.

Never underestimate the gut feeling; that's experience giving you a heads up. I almost always start with what you'd probably consider to be my "gut" feeling. I look at the error, and check the steps that I think are likely to cause that sort of problem.