###Should developers do QA?
I guess it depends on what's more important to you: being a proud developer (and interpreting being a developer as "I ain't do testing stuff, only write code"), or delivering working software as part of a team (which would imply that everyone is helping out each other as needed, even by doing unpleasant or boring stuff when it has to be done).
So even though you may be employed as a "software developer", in Scrum your job title is not that important.
A Scrum team in a Scrum environment does not include any of the traditional software engineering roles such as programmer, designer, tester or architect. Everyone on the project works together to complete the set of work they have collectively committed to complete within a sprint. Because of this, Scrum teams develop a deep form of camaraderie and a feeling that "we're all in this together."
(Quoted from here.)
In other words, if Joe is held back with his task and can't complete it till the end of the sprint, it is of no use to the team if Jim is fully done with "his tasks" and sitting idle, or is working on something less valuable rather than helping Joe.
So yes, in a well functioning Scrum team, even though members may have different primary expertise areas, still developers occasionally (or even often) do testing, testers may help out writing SQL scripts, DBAs sometimes jump in to configure a development server etc. etc. It is often said that Scrum teams need T-shaped people.
In fact, I used to work in a Scrum team where we had no dedicated QA personnel at all; only four developers. And we did all the testing ourselves. It included building an automated, shell script based testing framework alongside developing the product and writing our unit tests. And actually it was much more fun than you might expect. But of course, the most fun was actually to see the project succeed :-)
###Why is there not enough QA people?
Looking at the larger context, your question raises some general concerns though. Sounds like your team may not be actually producing a potentially shippable product increment at the end of each sprint, rather having one or more integration/testing sprints before the planned release. This does create an imbalance and slows down your team, so depending on the circumstances it may be worth raising the question how your team can move towards more frequent deliveries. The answer may include test automation, involving the testers earlier, or slicing up your backlog items into smaller chunks. But these are just shots in the dark, without knowing more details about your actual situation.