What do I need to do to help my, apparently, limited imagination come up with ways that my project could possibly be broken?
In most cases, I'd say absolutely nothing. You shouldn't be trying to dream up things that might be causing the program to break. You should be systematically determining what is causing it to break.
You should be going into the debugging process with the following pieces of information:
- the steps that were taken and the values that were entered to produce the bug;
- what the program should be doing when given those steps and inputs;
- what the program is doing when given those steps and inputs.
If there's an error message, get all the information you can about it. If the error message itself isn't clear, and you don't know what it means in practice (some error messages aren't always particularly useful), then use Google, or StackOverflow, or any other online resource to find information about it.
If there isn't an error message displayed on the front end, check any logs the application writes to for error messages during the time period you reproduced the bug. The code may have executed to completion, but encountered an exception that's being handled along the way which is throwing off the end result and producing an entry in the logs. Look for those, do the same above and identify exactly what they mean.
If there are stacktraces provided with exceptions thrown by your code (and there should be), look at the lines of code mentioned. The line itself may not be the one that's actually producing the issue. If you get a NullPointerException in a piece of Java code, the stacktrace will tell you where you tried to use something that was null when you expected it not to be. That doesn't exactly point you to the line causing the problem, but it generally does tell you what variable doesn't have the value you expect it to, so you can look at any references/assignments to that variable to determine that the value isn't being set or that the value is being set incorrectly.
If none of that has helped, fire up your debugger. If you've narrowed it down to a section of the code that you know is causing the issue - but you don't know exactly which line(s) - then step through that. If not, just step through the entire thing. This is where you need to know exactly what the program should be doing with given inputs, because you need to look at each value after each line and determine exactly where it's deviating from what you're expecting it to do.
Still don't have a clue what the problem is? Ask somebody for help. A co-worker, a friend, an online community. Show them all that work you just did. Show them the error messages, the stacktraces, explain what the program does in general terms (if they don't already know), what it should be doing in this particular instance (e.g. returning the value 4), what it's actually doing (e.g. returning the value 5). If you've narrowed it down to a few lines of code in the debugger, say "I know the issue is caused by these lines in the code, it's setting the value to X when it should be Y, but I can't see why that's happening".
Spending a few hours staring blankly at your screen definitely isn't fun, but there's no reason you should be doing that. If there's a problem with your code then you need to be reading or stepping through the code.