It seems a comon problem. One of the first steps in implementing an agile process (such as scrum) is to put in place a fixed iteration cycle in development, but but then find difficulties fitting post-development testing (a.k.a “system testing” or “integration”) into the mix.
The main problem with testing after development is that any fixes to problems identified in the follow-on testing have a tendency to become tangled in upcoming work for the next iteration. This in turn can lead to no iteration ever being “clean” enough to actually release.
One possibility for a solution is to reconsider the development-led nature of an iteration, and instead lead it from a set of acceptance tests which are estimated, developed and executed alongside the scheduling and implementation of code changes.
Gojko Adzic, one of my current favourite bloggers on the subject of testing, has attempted to map out an iteration structure which incorporates this approach: