How to Test
Take your testing seriously enough to make some simple test cases (a software design concept). You should also document them at least to some moderate degree. For example, you could list your expected results, save screenshots for every “browser and test subject” pair, and add a note stating what is problematic and what needs to be fixed. You should also indicate the date of the test and maybe the revision id of the version control system your tested design is residing on. By the way, I am strongly for using a version control system. It could be SVN, Git, or something else, but the little extra effort it might take to use it will save you tons of problems if you accidentally delete something, overwrite the wrong code, or when (not if) your work machine breaks down irreparably.
If your test concludes that something needs to be fixed, once you have made the modifications, you should perform a second test, exclusively for the parts which are affected by your changes. Remember to note the reason for the modification along with your documentation, and possibly also in the code. You should repeat this step until, hopefully, your design looks sufficiently well in all of your tested browsers, and no more changes are needed.
But what if due to various factors you end up repeatedly making changes to fix a problem in one browser, just to find that your fixes cause another problem in the same browser or in a different one?
Problems While Testing
If you cannot fix the problem with the above methods, you should make a compromise. In order to remedy it, you could either choose to revisit the design, use a different approach if possible, ease the requirements, or maybe as a last resort, pick out an unfortunate browser to take the fall. Of course, this is something the customer must agree to as well. If it is the case, there is no shame in admitting that something is not possible in the current circumstances.
Testing Additional Changes
The key is to estimate what the changes will affect and to concentrate your testing on these parts. This estimation should draw on your knowledge of HTML and CSS and on the previous history of changes you had with this project. If you know that a change is not supported well in a certain browser, or you know that it will appear differently, test it. If it involves a new technology, also test it. If it is in an area of the design which took a large amount of corrections in order to get it, then test it as well.
In general, the more structured and organized you are with your testing the less time you will waste hunting down issues during the initial implementation and further changes and maintenance. A real test case procedure might appear too tedious, but it is time well spent, as it increases the quality of your work. If you follow through with it properly, you will have a design that looks good across all your target browsers and to all your target audience, while future alterations will be easier to perform.