This is often a bit of a mindset change for a lot of people. The simple answer is that the team is responsible for developing AND testing something in the same sprint, if that's too much work then they need to commit to less functionality.
Imagine work as a grid, each row represents a feature the team wants to implement, each column represents the various traditional stages. Dev, Test, Resolved, Done etc...
In a typically waterfall application the team would do the Development for all the features, then move into Test, Resolved... as I'm sure you know this approach often leads to large amounts of rework and poor communication.
A scrum team should contain all the skill sets to take a piece of a work from plan to Done (Done, should - unless you can argue a REALLY good reason should mean done and in Production with live customers).
So, instead of completing one entire column a team aims to complete a small number of rows at a time. Finishing a few of these each sprint and pushing them into live before starting the next set. There are many, many reasons why this is a good idea which I'll leave out of scope for this answer.
So, now we know that we want to take your small number of features from Ready to Done we can look at your question - how to help your team both develop and test in the same sprint (I also want to include deploy in this).
Firstly, make work visible. If people can see all the work that is required to get these features into Production then you'll stand a much better chance of completing it.
Next, it is the entire team's responsibility to complete the tasks. Testing isn't one person's responsibility, it's the entire team's jobs - sure some people may have more testing expertise but they can assist other team members, they are not the only people who can test.
Changing mindsets/culture is hard, but here are my main suggestions:
- Take a small number of small tasks and deliver them to live each sprint
- If developers find themselves with nothing to do don't let them pull in more work, they need to help the testing/deployment process
- Get testers involved early, use your refinement/planning sessions to identify the tests that should be run. Having tests like this planned out makes it much easier for non-testers to get involved in testing. Encourage developers to automate tests!
Encourage the team to deliver to production each sprint, this will naturally balance itself out for people to pick up less work but push it all the way through.
Think of your team members as engineers with different skills. There's no reason developers can't test and testers can't advise on development in progress. Planning the tests to be carried out as part of your Definition of Ready makes it much easier for testers to design tests for other team members to carry out.
I strongly recommend your Definition of Done includes getting something into live and stories are not closed until they are in production. This makes work piling up in test/awaiting deployment extremely visible and encourages frequent releases.