The easiest and, probably, most useful technique is debug output. Instead of looking for bugs try to print values of your variables in the middle of the program and check if they are correct.

For example, if you try to solve a quadratic equation, you may print the discriminant just after you found it:

def solve_equation(a, b, c):
    assert(a != 0)
    d = b**2 - 4*a*c
    print "d = ", d
    if d > 0:
        return [(-b + d**0.5) / (2*a), (-b - d**0.5) / (2*a)]
    elif d == 0:
        return [-b / (2*a)]
    else:
        return []

So, if you are getting wrong answer on some test and you know this test, you may print out intermediate states of your program and find out the buggy step.

You can also use a debugger (I use gdb, some may prefer any visual one) to see intermediate values of variables, but it is usually slower. However, there are good ACMers who would not agree with me.

Debugging depends on whether you have a wrong test case or not.

If you have a test that your program solves wrong, then debugging is easier than you think. You simply should start outputting most of the values during the calculations (as the example with discriminant above) and see which ones are wrong. If some value is wrong, then either other values used in its computations are wrong or the computation is wrong. If you have everything printed you can easily track the part of the code that produces wrong values and therefore fix it.

Now if you do not have a test that your program solves wrong, but you know it is wrong (from system feedback for example) it's harder. You can either start using the above method, print detailed calculations, and look for error by going through your code and checking each line, but those might turn out to be slow. In those cases I often make a test generator and checker and just run them in infinite loop so I can get a test that my solution fails on, which can often be even slower. However, whatever way you choose, it's considerably slower than having a wrong test case.

Seeing a bug by just looking at the code is extremely difficult as you've written the code, and most likely you will subconsciously feel that it's correct.

Of course there is no universal way of debugging. For example on this year's Balkan Olympiad I had a problem that gave me 0 points. At first I had a wrong test case and I fixed it. Still 0 points, however. I proceeded to look through the code, print debugs and try to find a mistake. I found a few bugs, but still 0 points. Finally I wrote a test generator and checker to find another bug, and got 100 finally. In total I spent around 3 hours and a half on that problem only.

So debugging may always turn out to be more time-consuming than you thought but if you practice a lot and are used to printing debugs to locate the error, you'll be able to remove most bugs pretty fast.

Of course, stuff like heisenbugs are always a pain in the ass! :D