Most GNU packages run on a wide range of platforms. These platforms are not equally important.
The most important platforms for a GNU package to support are GNU and GNU/Linux. Developing the GNU operating system is the whole point of the GNU Project; a GNU package exists to make the whole GNU system more powerful. So please keep that goal in mind and let it shape your work. For instance, every new feature you add should work on GNU, and GNU/Linux if possible too. If a new feature only runs on GNU and GNU/Linux, it could still be acceptable. However, a feature that runs only on other systems and not on GNU or GNU/Linux makes no sense in a GNU package.
You will naturally want to keep the program running on all the platforms it supports. But you personally will not have access to most of these platforms–so how should you do it?
Don't worry about trying to get access to all of these platforms. Even if you did have access to all the platforms, it would be inefficient for you to test the program on each platform yourself. Instead, you should test the program on a few platforms, including GNU or GNU/Linux, and let the users test it on the other platforms. You can do this through a pretest phase before the real release; when there is no reason to expect problems, in a package that is mostly portable, you can just make a release and let the users tell you if anything unportable was introduced.
It is important to test the program personally on GNU or GNU/Linux, because these are the most important platforms for a GNU package. If you don't have access to one of these platforms, please ask maintainers@gnu.org to help you out.
Supporting other platforms is optional—we do it when that seems like a good idea, but we don't consider it obligatory. If the users don't take care of a certain platform, you may have to desupport it unless and until users come forward to help. Conversely, if a user offers changes to support an additional platform, you will probably want to install them, but you don't have to. If you feel the changes are complex and ugly, if you think that they will increase the burden of future maintenance, you can and should reject them. This includes both free or mainly-free platforms such as OpenBSD, FreeBSD, and NetBSD, and non-free platforms such as Windows.