My team struggles with a similar issue having multiple input streams, that are running on different iteration/sprint cycles into a common product. We tried testing in the dev int area for each team for a while and then marking items done at that point, but we quickly discovered that was too early in the process. We could verify that new functionality was working, but we couldn't test at the integration level which was where most of our defects actually occur. So we basically moved our definition of 'done' to be later in the next cycle, I guess you could call that a hardening sprint since it comes after the initial sprint where the dev work occurred or we call it the 'QA Offset'. Our management team really wanted 'testing' to be 'done' during the same section of time as dev, but this just wasn't practical based on the type of system we are testing. We have been attempting to add different layers of automation, to help us get to done earlier, but on a legacy product that can be challenging.
So to answer your original question, we generally monitor the build and whenever there is a large enough quantity of items in it, we will grab them and start testing. Since we build daily it is about every other day that we will restart testing, which includes the new functionality and a mini-smoke to verify that the older items continue to work.