It is not uncommon for members of Scrum Development Teams who perform QA activities to complain about work being given to them at the end of a sprint leaving little time to complete tests of features. Here are some solutions that I have shared with one of my Scrum Development Teams to address this problem:
I've been going through the Retrospective feedback shared over the last few sprint and thinking of ways that I can address some of the problems that have been shared. One problem was the experience of having little time to QA features that were developed and code reviewed toward the end of the sprint. A correlated problem was the feeling that QA was relatively idle early in the sprint and then went into overdrive at the end of the sprint. These problems may have reduced in severity since we always have features in QA that move on to the next sprint. So, QA is busy finishing features that did not make it to Done in the previous sprint. However, I think that this is masking the problems rather than solving them. So, I wanted to present some solutions that I've used in the past that I hope will help once we have fewer cards moving across sprints.
The first solution is to turn the problem on its head by creating the tests for features before they are implemented. After we analyze and size features in Sprint Planning, instead of development immediately working on the feature, the QA team will create the tests (manual or automated) based on their understanding of the feature. This is a great way to make sure that any QA related questions about a feature are answered by the Product Owner. Once the tests are created, the features are implemented in code. Of course, there will still need to be an actual test pass once the feature is complete.
The second solution is an iteration of the first one. After features are analyzed and ordered during the Backlog Grooming session, the QA team can create tests for features at the top of the backlog. This will allow QA to "get ahead" of work that is likely to be worked on in a current sprint.
It's my understanding that the team has experience doing testing before implementation so I know that these are not new ideas. However, I hope that the team can use them to resolve some of the issues raised in past Sprint Retrospectives.