At the risk of beating a dead horse, I want to again call out unit testing. Salesforce doesn't require unit tests because a Salesforce executive got a bee in his bonnet about platform stability. Tests exist to help you properly architect, engineer, document, and refactor your code. They help you architect your code to handle bulk data situations, complex object interactions, and integrations with third parties. By modeling real-life situations in tests, you know just how the code will actually work. Likewise, unit tests help you engineer your code line-by-line to meet security, data access, and governor requirements. If you find that you cannot easily test something, then you are likely fighting the platform rather than leveraging it. If a design or class is hard to test, take a long, hard look at what your end goal is and how the platform's other tools may help you create this with greater ease. Lastly, tests help document the use cases, failure states, and exceptions you had in mind when it was developed. This is an invaluable tool for onboarding new team members. However, these tests as documentation will really shine when you start to refactor your code. Knowing what it does right now, before you start, frees you to refactor with abandon. You'll always know when your refactored work is ready to go, as the existing tests will pass. This is especially important when refactoring to clean up technical debt.
If I've convinced you that unit tests are a good thing, the inevitable question I always get is what should I test? Even after a dedicated chapter on unit tests, there are undoubtedly questions specific to your org, your business, and your industry sector that come to mind. For instance, much of my experience has been with the sales and marketing clouds. Your team may only be responsible for the service cloud, or perhaps you're using the sales cloud in a non-traditional market space such as Software-as-a-Service. The thing is, "what to test" isn't a question with a useful answer. Arguably, the answer is "everything"—or test as much as your company will let you.
Perhaps a better question is where should I start? The answer to that is always a judgment call, and relative to the org. Whenever I inherit an org, I look for a few things that usually end up being, well, areas for growth. The three biggest ones are: the oldest code—by API version—code written by third-party contractors, and finally, code that drives business decisions.
Old code is easy to spot and may be just fine, but the older it gets, the more likely there's a better, faster, stronger, and so on, way of solving that problem. Technical debt, sadly, is often delivered with each new release. Fortunately, if there are well-written tests already, refactoring is easier. On the flipside, I've found that old code is much more likely to have bad tests, or no real tests at all. Here is where the i++ tests of yore come home to roost. Rather than writing useful tests, old code may attempt to inflate the coverage by simply massing a great number of additive statements (this no longer works by the way). Fixing bad tests is burdensome but will help you in the end.
Looking for code developed by third party contractors is a bit more difficult. Often, the circumstances of their contract demand quick solutions without an adequate "ramp-up" time in the org. As a result, there may be inadvertent code duplication going on. Unfortunately, this is also where I find the majority of tests that have no assertions in them. Sometimes, they'll just be commented out, on the belief that once-proven working assertions can only impede deployment to production. If that's the case, just uncomment the assertions. Even if they aren't there, the tests are usually written out enough to exercise the code. Put in intelligent assertions and bring the tests up to speed. Then, and only then, should you consider refactoring that code.
Finally, talk to the business stakeholders and ask what reports they read and what data helps them make business decisions. Writing tests for business crucial calculations can change the bottom line for a company. At the least, you'll have evidence to suggest such calculations are done correctly. But you may also find, as I once did, that a company had been making opportunity discounts available based on an inaccurate calculation of the opportunity's total value, which led to discounts triple what they were supposed to be. If you ask three people at most companies what their top three business calculations were, you'll likely get five different answers. That's why these are the hardest parts of any system to ferret out. But when you do find them, test them vigorously.
Regardless of where you start, just make sure you start testing. Technical debt accrued through bad or too-little testing is beyond frustrating. Remember, someday, someone else will inherit your code and your tests. And that person may not only have your address, name, and phone number, but rage issues set off by badly-written or non-existent tests.