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 code, or something in the front-end.

Fine. We’ve all been there.

You have unit tests to write & run, debugging/logging statements to insert, sql statements to write & run, things you want to check with FireBug, etc.

Let’s say the first step is come up with a list of potential causes that you want to investigate.

Now you have to decide what order to do things in.

Do you:

1. Investigate causes in an order based on gut feeling?
2. Investigate causes in order from the quickest to check to the slowest to check?
3. Assume that the bug is specific to this feature, and investigate from most feature-specific code to least feature specific code?
4. Assume it’s someone else’s fault, and investigate from the most general code down to your specific code?
5. Something else I haven’t mentioned?

I have a feeling the first strategy is the most often used. Maybe just because I don’t work with many junior developers, and more senior developers tend to have decent intuition. Or maybe we just think we have decent intuition but should really be using a more systematic approach.

Any Thoughts?

Answer 1

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