Write tests!

Got it

Write tests before writing code!

Sure.

Write tests before fixing bugs!

Huh? No time!

It might sound obvious to write tests before fixing bugs as part of TDD, but this part is really important. And honestly, do you do that? If yes, congrats and you can stop reading.

Every sufficiently complex piece of software has bugs. When you (or the customer) find a bug, first write a unit, integration or even system test to capture and reproduce it. The test should be red. You may analyze the reason, but you should not fix it. Write a test first!

Write a test, that covers the "spirit" of the bug. Write a test that represents the business case as best as possible. Then fix it and hope to make the test green. This is really important, because sometimes, you will be very surprised when the test is still red. Why? Because this might either not the root cause or not the only one. Think of the situation where you would just have fixed the bug, maybe even deployed it to the customer system, telling the customer "everything's fine" and the next day you get call with an angry customer telling you its still broken.

Thats why most of the time it is better to write a system test for bugs that users report.

Take the time to do it. Another benefit is avoiding regression bugs. After someone else changes something else, they might reintroduce the bug. This even more embarrassing when the customer calls to tell you "We've got the same bug we had two months ago. WTF?". Explain that to project/product managers and when they're not completely stupid, they should understand and grant you the time to write a test.