Cross functional teams are possible
I know that everyone inside a scrum team should be labeled as "developer". Also I know that ideally everyone should be able to perform any task regardless of her technical strength. Developers must try to be cross functional and that's good!
If you really find people thirsty for technical knowledge then your chances are good to achieve cross functionality.
But.. do not expect high quality software from programmers
People in a scrum team most of the times are programmers. As I pointed out, if programmers are thirsty for technical knowledge then they will accept easily to code in areas not so familiar to them.
For example a Java developers working with Spring Framework may want to try a little bit of front end development using AngularJS. Probably she will know something about Databases so she may look for opportunities to become a full stack developer by learning front end technologies too.
Most of the times this is expressed as the T-Shape skills model (http://blogs.ptc.com/2014/12/03/why-engineers-need-to-develop-t-shaped-skills). The core of this model is having engineers very good in a programming language but in the same time able to understand and work more or less in other programming languages related to the project.
Well from my experience I came to the conclusion that most of the times programmers are thirsty for getting skills related to programming languages and development frameworks. Cool tools and so on.
They are not really interested to become skilled quality assurance persons. I think every programmer realized in some point of her career that the quotes saying that programmers cannot test their own code good, its a fact.
There are thousand of articles in the internet explaining that. I picked one to post here: http://qablog.practitest.com/2010/05/why-cant-developers-be-good-testers/.
My most important reason though is that Quality Assurance needs too much thinking during the Sprint! The same thing is necessary from a programmer to do before he starts coding. The mind effort to produce a clean, extendable code for the Sprint is very big! The same is true for someone who sits down and thinks of any kind of weird user story scenarios to assure that the application is not crappy after its declared DONE.
So do not expect a programmer to achieve both. The most possible output will be technical debt and crappy software.
Dedicated person/s doing QA
So it seems that quality assurance must be performed by dedicated persons to this role. They will give total focus on how these user stories will be transformed to bug free stable features in the end of the Sprint.
This requires planning at the early phases of the Sprint. Test automation design and test cases must be written to cover not only happy paths, but strange behaviors from the user and so on. When programmers say that some part of a user story is committed then the QA persons can start putting in action their tests.
Most of the times this will reveal a big number of development bugs early in the sprint so the programmers will have to think again the solution they decided and fix the issues. Weird use case scenarios trigger weird discussions in the team because they are starting to realize that maybe its not the simple straightforward feature they had in mind, but it requires more attention to details... and details most of times means quality!
QA people have things to say about what Done means
Well this mean that if the quality is not good, there will be open issues in the scrum board. Having everything in the scrum board even development bugs is critical. Have a look here why its important: http://www.nikosraptis.com/#!Why-keep-everything-in-the-sprint-board/c1sbz/568acd310cf2e866691c85ee.
Visible tasks (bugs) of a user story in the scrum board will prevent closing it without having all issues fixed or at least discussed within the team or the PO. Sometimes something cannot be declared as a bug but it could be something that a QA person does not agree with. It is still an issue that it should be discussed before the user story changes to Done state.
The dangerous part here, which may create bottlenecks, is if the team thinks that after fixing a issue found during the sprint, they must wait the QA people to test it again and verify that its OK. Sure that could be done but is is not the goal. Cross functional here means that the programmers must learn how to use the tools of the QA people to run again the automated test related to fixed issue.
Apart from that they could create some automated tests for their happy path scenarios related the user stories they implement. Its important to realize that the dedicated QA person or persons inside the team will bring the imagination in testing and many more erroneous path test cases. They are not there to replace totally the testing that a programmer must do.
How many QA People?
Well, having the size of a scrum team in mind I think two persons should be enough. Maybe one is OK but then you have to guarantee that if she is away for vacations the people left behind should cover her work and not reduce the quality.