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, so even they can be considered as a part of Quality Team.
Now, in Agile projects, ideally, “Quality should be baked in”. What it means is that since coding, integration and testing happens in parallel, so there is no concept of 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 put together. 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 walkthrough. All of these efforts ensure that “Quality” is not a phase as such in Agile, it is an everyday affair.
Another thing to realize is that in traditional method, quality ideally 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 compromised in the quality check/testing phase. But in Agile, each increment of coding is tested as soon as it is done, and immediately 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 both the methodologies is what makes Agile so much more Quality Conscious.
Regarding Testing, it is an altogether different approach in Agile Methodologies. 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, a domain expert and/or programmer. Functional testing, exploratory testing, smoke testing, pair programming etc. everything is done to ensure the quality of the iteration remains on the higher side. When tests demonstrating minimum functionality are complete, the team can consider the story finished.
