Automated test suite is certainly a good idea.
Since more and more implementations implement ES5 now, running the test suite for your script/library/application in newer browsers is a good way to ensure compatibility.
I have an ES5 compatibility table, listing level of support of some of the more popular implementations. Its not exhaustive, but it shows overall direction — that latest IE, WebKit, Chrome and Firefox all have quite good ES5 support. For a complete conformance test, you can always run official ES5 test suite (which I have online for convenience right here).
If there's no test suite (which should really exist, as it is very useful for few other reasons), you can just run script/library/application in one of the newer (ES5 conforming) implementations and see what works and what fails.
Consulting Annex E is another way to go. Note that even though the list seems quite large, it's not as bad as it seems. One of the goals of ES5 was to make transition from ES3 more or less painless, moving more radical changes into the realm of opt-in strict mode.
Many compatibility changes from that list are likely to go unnoticed. Take for example, change in 15.1.1, where global undefined
, NaN
and Infinity
are now read-only. Considering that sane applications do not reassign these global properties — except by mistake — this change is more of a pleasant "error-catcher" rather than "app-breaker".
Another liekly innocent change is in 15.10.2.12, where whitespace character class (\s
) now also matches <BOM> (U+FEFF
) character. Considering all the deviations in current implementations (even in regards to ES3), this change is likely to go unnoticed in majority of applications.
However, there are also more dangerous changes, such as that in parseInt
and how it no longer treats strings beginning with 0 as octal values. parseInt('010')
should not produce 8
anymore (although some implementations chose to deliberately violate that behavior). And still, relying on parseInt
without second "radix" argument was never a good practice. So if your application always specifies radix, there's nothing to worry about.
So consult Annex E, test your script in newer implementations (preferably, multiple ones), and follow best practices. That's a good way to ensure compatibility.