If an application of any significant size and complexity isn't properly segmented, it can be quite a daunting task to know how and where to begin writing tests. With a little practice in testing legacy systems it will become easier.

The when to write tests within a legacy system can easily be answered with, "When it makes sense to." It would be difficult to sell the idea to any business owner that time (and money) should be spent going back to write tests to cover the existing functionality of a legacy system. It makes much more sense to add tests as enhancements are added to the application or when defects are being addressed. As you're working in the code and have immediate context surrounding the functionality that you wish to test, that is the optimal time to begin to test parts of a legacy application.

So, how do you begin to write tests against a legacy system? Isolate small functions that can be easily tested. Extract methods and smaller classes as needed. Ensure that functionality is not being modified, but that code is simply being reorganized in order to facilitate testability.

It may be necessary to change a private method to be protected so that it may be tested.  Changing the scope of the method does make it more available and can reduce the effective abstraction, but if the change is required to aid in testing, the trade-off is almost always worth it. You might also consider that private methods made public might better belong to a different utility or helper class, and so can remain public. It depends on the method in question, but there are certainly options available to help you make a legacy system more testable.