Write your scripts in a POSIX conforming manner, and then test with a completely different shell, like
pdksh or what have you. Avoid dark corners and gray areas of the shell language; do everything in "canonical" ways.
Of course, that doesn't prove your code isn't stepping on some Bash bug in an old version, but it improves the confidence. For one thing, Bash bugs are more likely found in Bash-specific constructs (which are not exercised by portable scripts) and in those dark corners and gray areas (which are not exercised by many scripts).
In other words, don't do be the world's first shell scripter to land a quadruple reverse eval.
One benefit of making the script portable is that, suppose a user does find that your script doesn't work in their installation which has an older Bash. Well, since the script isn't Bash-specific, maybe they can get it to work with an alternative shell, and one that they are already have installed.
There are only two ways to know whether your code steps on some historic Bash-specific bug. Only one of those ways is halfway reliable (the one you don't want to do: pull out old versions of Bash and test). The other way is to pore over the Bash change history and try to determine whether bugs which existed in any old versions that you care about might be affecting something that your script is doing.
I would just keep a virtual machine hosting some older distribution, and do a regression test on it from time to time.