You are likely having this problem because testing isn't being included in your "definition of done" for each story. You should include testing for each story in your Sprint Backlog, and as a column on your kanban if you use one.
Testing as a Story Requirement
Generally, Scrum teams will include unit testing in the development work, and Quality Assurance (QA) or User Acceptance Testing (UAT) as a defined process step before a story can be considered complete.
When decomposing stories for the Sprint Backlog, it may be useful to add an explicit task for QA/UAT to the backlog for each story. This makes it a checklist item, and any story that hasn't completed this task at the end of the Sprint is counted as incomplete.
In many cases, experienced teams don't include testing as an explicit item because it is baked into their estimates, and part of the team's "definition of done." In such cases, testing is an implicit requirement for a story to be considered complete, but the same rule applies: if the testing hasn't been done, then the story is incomplete.
Furthermore, many agile practitioners use kanbans to track stories through the team's work-flow. Having unique columns for testing that stories must pass through before being placed in the "done" column ensures that there is a visual reminder that testing is intrinsic to the process.
Finally, because testing should be part of the definition of done, adequate buffers for testing should be included in your story estimates. When testers don't participate in planning sessions, or when testing isn't part of the formal definition of done, this essential practice might be overlooked.
When to Test
Testing should be inter-weaved throughout your process. Testers should:
- Be involved in Sprint Planning and story estimation.
- Work with developers to identify and build tests during feature development.
- Work with the technical writers to build tests that act as self-documentation for the product.
- Have their own process step or kanban column through which stories flow during each iteration.
- Actively participate in the daily stand-up to coordinate with developers, technical writers, and other members of the team.
- Raise blocked tasks during the daily stand-up.
- Raise process issues (such as waiting until the end of the Sprint to test) during Sprint Retrospectives.
If testing becomes integral to your team's process, you are less likely to require last-minute testapaloozas at the end of each iteration. Additionally, because testing is a team responsibility, all members of the team will need to pitch in on testing tasks that are behind schedule in order to complete stories by the end of each Sprint.
Create a strong incentive for the whole team to be cognizant of the resource and time requirements for testing, both during planning and during each iteration. If you do that, testing will stop being something that is "thrown over the wall" to the testers at the end.