First, I want to reiterate Jeff Sutherland's concern, that he biggest problem is that too many teams are not getting to working product (working software) within a Sprint (a 1 to 4 week consistent timebox).
In my view, the absolute minimum Definition of Done for a typical software "story" or PBI (product backlog item) is:
* requirement defined
* unit tested
* functionally tested (aka acceptance tested)
* all identified bugs fixed
* reviewed by the Product Owner, and all 'problems' fixed
This is the minimum definition, assuming one starts with significant impediments. The ideal definition includes live, in production, being actively used by the customers with normal volume.
Now, let's add a key principle: The bad news does not get better with age. In other words, it is much cheaper to slow down and test and fix now (even though it does have some cost) than to not test in the Sprint and discover the bad news later (where the price is much higher).
So, our answer is that good professional testers must be in the Scrum team. Ideally that means 100% allocated to one team. At a minimum, 50% allocated to one Scrum team.
Where does QA fit in? Well, usually the testers are aka QA people. Sometimes QA means truly "quality assurance" per se, in which case the QA people look at the Scrum team (and the process elsewhere as well) to see if sufficient quality is being baked in in the best possible way.
Liz, we are also asking that coders help testers, and vice versa. And each side no longer looks at the other side as an enemy. Still, the testers are always trying to "break it." So, they maintain that attitude. And each coder views any break identified now as a 'win' for the team, not as a loss for his ego.
Also, usually in large firms that is a 'landing strip'. By which we mean some final testing where the code of say 3 teams comes together into one stream. And is 'finally' tested.
A common pattern is that a 'test scrum team' does the final testing, and sends bugs back to the 'development' teams. Obviously, QA people populate most of the test scrum team. -- This is a common pattern when you have lots of impediments; and not a bad pattern in that situation.
So, Liz!, have I answered your question?
(There are other situations and complexities that might be addressed, but I wanted to hit just the highlights.)