In Agile, Quality and Testing teams’ roles and responsibilities often overlap. That is because ideally, matrices are not required in Agile Projects. So, Quality teams are often merged into Testing teams for the sake of convenience, though it depends on a lot of factors. Also, as customers are closely involved in providing feedback every Sprint, even they can be considered as a part of Quality team.
In Agile projects, “Quality should be baked in.” What this means is that since coding, integration and testing happens in parallel, there is no need for quality being checked at a later phase, which in turn means that it has to be maintained from beginning till end, by the combined efforts of all the stakeholders. In other words, quality has to be fed into a product from the beginning, rather than trying to test it in later. Hence, even a Project Manager conducts a functionality testing if required. Even a BA conducts smoke testing if needed. And even the clients chip in with their random testing during demo and walk through. All of these efforts ensure that “Quality” is not a phase as such in Agile, it is an everyday activity.
Another thing to realize is that in traditional methods, quality should be allocated as much time as coding based on the relative importance, but more often than not this is not the case. What happens is that coding takes longer than allocated, and that is taken from the quality check/testing phase. But in Agile, each increment of coding is tested as soon as it is done, and in the immediate iteration after rectifying bugs. Developers can never actually get ahead of the testers, because according to Definition of Done, a code is not done till it is tested. This fundamental difference between these management frameworks is what makes Agile so much more Quality Conscious.
Regarding Testing, it is an altogether different approach in Agile frameworks. Instead of writing test cases from a requirement document build by a BA, even before any coding has started, the testers will have to write test cases for user stories as per the priority in an iteration just hours before actual coding takes place. It requires a collaborative approach between a business representative and a domain expert and/or programmer. Functional testing, exploratory testing, smoke testing, pair programming and more are done to ensure the quality of the iteration remains on the high side. When tests demonstrating minimum functionality are complete, the team can consider the story Done.