English | EN 
This is a question that many people ask me. From those who believe in centralized quality offices for quality governance in agile, to those who argue that quality is a crosswise responsibility in agile teams, so no specific quality roles need to be considered in agile. Let’s talk about it!
Yes, in agile, quality (as a central aim) needs to be addressed through a crosswise and whole-team responsibility mindset. However, quality assurance (as a set of practices to be performed, including testing) needs to be taken over by different roles, depending on the level and the type of validations to be done. There are different testing levels as there are different sources of potential defects. And there are different types of testing, as we may need to ensure different types of quality gates in a project (functional, performance, security…) depending on the risks we are going to assume. Moreover, in large organizations with more than one agile team, an “agile of agiles” layer needs to be established for addressing crosswise company quality strategy, metrics, best practices, standardization, provision of specialized quality professionals and end-to-end quality validations.
Yes, developers may (must) design, automate and execute tests. But not all tests at all levels and for all types may be done by developer roles. Developers in agile are encouraged to test their own code contributions through unit test cases, since their specific contributions (we are still “craftsmen”) may be the cause of some defects. But what about potential defects related to the integration of different development contributions, to the use of services through APIs, to the execution of end-to-end business processes crossing functionalities developed by different agile teams, to the challenge of security and performance, to the quality of our user interfaces (usability)… or even related to the defects caused by new changes that affect previously working scenarios at all levels? These are the reasons why we need to include testing and quality assurance roles in the composition of our agile (and “agile of agiles”) teams, because further than unit testing, we have a wide scope of quality activities to be performed and pushed, taking into account the quality risks and particularities (that will be the base to adjust the number and percentage of participation of each role) of each product to be developed.
Yes, business roles define user stories as requirements artifacts, but a key base of agile is cocreation of these artifacts by involving different point of views in order to make more explicit from the beginning what we are going to build (that means satisfy business expectations, codify, test,…) by anticipating defects and aligning all roles in the same page. Consequently, testing and quality assurance profiles need to be part of agile teams from the very beginning, as they are essential for enriching user stories and acceptance criteria from the point of view of the specialized quality mindset.
Yes, we need quality governance. And it means that Agile Definitions of Done (DoD) need to include, for each project, the corresponding quality assurance and testing tasks to be done at different levels (iteration 0, regular iterations, freeze periods and releases). And if there is more than one agile team in the same company, an “agile of agiles” tribe needs to be established with the following objectives: quality governance, quality metrics evolution, quality assurance methods and best practices, specialized quality professionals pool, acceptance end-to-end testing of before-go-live new processes, and end-to-end regression testing.
Yes, as said by Johann Wolfgang von Goethe, “There is nothing insignificant in the world. It all depends on the point of view.” And the point of view of quality is essential in agile.
