Test the worst case before the normal one

Instead of testing my tool with a typical, easy example first, I now test it with the worst realistic case I can think of. An empty field. A duplicate order. A customer with no email at all.

Normal cases are the ones that were always going to work. The worst case is the one that tells you whether the tool can survive contact with your actual business. If a tool handles the ugly case gracefully, the easy cases take care of themselves. Testing this way early also saves you the discomfort of a tool failing quietly during a real client interaction instead of during your own quiet check.

Try this today: think of the single messiest situation your new tool might face, build that exact case as a test, and run it before you try anything easier.