The testing distribution is an automatically generated distribution. It is generated from the unstable distribution by a set of scripts which attempt to move over packages which are reasonably likely to lack important bugs, and to do so in a way which ensures that dependencies of other packages in testing are always satisfiable
Have a look at the testing home page, and, in particular, the update excuses and update output files.
A (particular version of a) package will move into testing when it satisfies all of the following criteria:
A package which satisfies the first four of the above is said to be a Valid Candidate.
The structure of the distribution archives is such that they can only contain one version of a package; a package is defined by its name. So, when the source package acmefoo is installed into testing, along with its binary packages acme-foo-bin, acme-bar-bin, libacme-foo1 and libacme-foo-dev, the old version will be removed. The old version may have provided a binary package with an old soname of a library, such as libacme-foo0. Removing the old acmefoo will remove libacme-foo0, which will break any packages which depend on it.
Evidently, this mainly affects packages which provide changing sets of binary packages in different versions (in turn, mainly libraries). However, it will also affect packages upon which versioned dependencies have been declared of the ==, <= or << varieties.
I believe this is bound to be answered by question 4 above. In some way, directly or indirectly, installing the package will break some other package.
Remember to consider your package's dependencies. Suppose your package depends on libtool, or libltdlX. Your package won't go into testing until the right version of libtool is ready to go in with it. That won't happen until installing libtool doesn't break things already in testing, in other words until all other packages which depend on libltdlY (where Y is the earlier version) have been recompiled, and all their release critical bugs are gone, etc.
I believe the release manager can override the above in two ways. He is capable of deciding that the breakage caused by the installation of a new library will make things better rather than worse, and letting it go in along with its flotilla of dependents.
He is also capable of manually removing packages from testing that would be broken, so that new stuff can be installed
(Preserved by Rick Moen to prevent Jules Bean's work from vanishing, now that it is no longer available at http://people.debian.org/~jules/testingfaq.html.)