Having separate debug and release builds is a good idea, because it does make development easier.
But debug builds should be for development only, not for testing. You test release builds only. And you don't use developers to test those builds, you use testers.
It's a simple policy that gives the best of both worlds, IMO.
Edit: In response to a comment, I think it's obvious that debug and release builds (can) generate different code. Think "-DDEBUG" vs. "-DNDEBUG", and "#if defined(DEBUG)", etc.
So it's vital that you test the code that you end up shipping. If you do generate different code in debug and release builds, that means testing twice - regardless of whether or not it's tested by the same person.
Debug symbols are not that big an issue, however. Always build with debugging symbols, keep a copy of the unstripped binary, but release a stripped binary. As long as you tag each binary with a build number somehow, you should always be able to identify which unstripped binary corresponds to the stripped binary that you have to debug...
How to strip binaries and load symbols in your debugger from an external source is platform-dependent.
Best Answer
Alpha Release - This is the release when the feature which you are developing is incomplete or partially complete. Suppose in a Ticket booking system you have developed the seat selection but the payment implementation is remaining. In this case you can release it to testers to test the initial phase of feature. Lot of Open source products do their Alpha release.
Beta Release - This release is done when the product feature is complete and all the development is done but there are possibilities that it could contain some bugs and performance issues.This release mostly done to users who test the product and who can report the bugs. Even UAT (User Acceptance Testing) phase could be considered as Beta release.
For more details read the below wiki- https://en.wikipedia.org/wiki/Software_release_life_cycle