My boss and I had a meeting today and the topic was concerned with downtime for dev or QA. We currently work in an Agile environment. My boss wants to start working on dev for the next cycle while QA is going on for the previous sprint. His concern is that this goes against Agile convention. The compromise would be that the branches of development for the current sprint and future sprint would be kept separate. We agreed that it would behove us to reach out to the community and get feedback on the issue.
Actually, we're doing this exact thing you mention.
Testing in the same three weeks as development is nefarious for testing time and quality overall, as you seem to have experienced. So, we're testing for two or three weeks after the development sprint has finished.
By delaying testing for a few weeks, you'll be working on a fully delivered sprint contract. This is beneficial in multiple ways:
- no useless defects are logged (as would be when the stories are only partly developed)
- and the inverse is true: stories might impact each other. Once they're all developed, testing becomes much more interesting in terms of quality control.
Also, have a tester (or analyst) sit next to a developer and walk through the new screens or changes, before the dev sprint is done. It only takes an hour or two but gives the dev an opportunity to fix some easily spotted bugs before the actual testing round begins.
Of course, it might go against the Agile spirit, but just like the V-Model or Waterfall, it is a theory. You need to modify it to make it work in your IT department. If you all feel that the change would improve the general development and testing process, don't hesitate.