Get certified - Transform your world of work today

Independent QA or Integrated QA?

How a QA organization could align and work with Scrum teams

07/28/2014 by Ravishankar N

In any large IT organization there will be an independent Quality Assurance (QA) section, which would typically be a shared service. This organization provides testing services to multiple portfolios or lines of business within IT. In an Agile context, the Scrum team is a set of people with cross-functional experience and multiple skills, including design, development, and testing. Then how does an independent QA organization work in an Agile setup?

This article explores how a QA organization could effectively work within an Agile context, aligning its teams with the Scrum teams and their ways of working.

The authors of this article recognize the difference between "quality assurance" and "quality control." In the following sections, the term QA is used to represent testing. The focus of the article is on QA team-related changes rather than on testing tools/platform-related aspects.

Role of a QA function

QA is the systematic process of checking to see whether a product or service under development meets the specified requirements. The QA system aims to detect flaws in a product or a service before it is made open for customer use. The QA organizations use manual and automated methods to detect flaws and flag issues. The end objectives of the QA function are to improve the quality of the products and services and increase customer confidence.

Benefits of an independent QA function

IT organizations establish an independent QA function to achieve several objectives, including the following:
  • Objectivity. The independent QA team assures an unbiased view that would increase the chances of uncovering defects. The independent team does not rely on assumptions and tacit knowledge while testing, and this helps them take a fresh look at the application every time it is put up for testing. Because of their independent position, the team is not influenced by stakeholders of the development team while qualifying an application to promote it to the next stage.
  • Cost advantage when outsourced. Typically, large IT organizations outsource the QA function to vendor partners. This leads to cost efficiencies and flexibility for ramping the team up and down based on release schedules and other priorities of the IT organization and business.
  • Testing expertise. The independent QA team is usually staffed with expert testers who have the skills to unearth flaws quickly and raise flags about potential issues. Usually the expert testers would have also picked up the necessary domain knowledge over time, and this helps them quickly identify functional deficiencies.
It is not feasible in a large IT organization to quickly reorganize the QA teams while going through the Agile transformation journey.

How does this work in an Agile scenario?

Agile teams are cross-functional, and the team members are expected to own the functionalities and to design, develop, test, and deliver them. In such a scenario, the testers cannot maintain their individual identity and focus only on testing. One approach to alleviate this situation could be to bring in the testers only during the "testing stage" of the sprint. But this approach has many flaws, such as loss of knowledge and continuity, varying team size, and lack of commitment to the sprint goals.

A more viable option would be to enable the QA team to align with Scrum practices and function as an integrated team along with designers and developers. In this approach, testers would be part of the Scrum team within the chosen team size and would be retained within the team throughout the development cycle until the release of the application.

In this case the testers could still belong in the QA organization and have a dotted-line relationship with the QA manager, but they would be part of the Scrum team and perform their tasks as per the sprint backlog. This structure is illustrated in the figure below:


With the above structure, the QA people become an integral part of the Scrum team. They participate in backlog grooming and sprint planning. They contribute to estimation. They contribute to test-driven development and perform many other activities beyond the boundaries of QA.

Along with the skills of the team, the QA organization also provides testing tools and platform services to the Scrum team.

The following sections describe how the QA members would be effectively leveraged in a Scrum-based project in the setup above.

QA with product owner

The QA members would work with the product owner (PO) in story elaboration and articulation of the exact requirements through child stories. They would also help develop the Definition of Done and the final acceptance criteria for the completed functionalities. They would provide pointers to the PO on testing the nonfunctional requirements (NFRs) so that these are reflected in the relevant stories in the product backlog and tasks in the sprint backlog.

QA for estimation

Estimation is an interesting exercise in an Agile project. In the beginning it may be amusing to the QA members to see how story points are arrived at. But over time, the QA members would actively participate in arriving at realistic story sizes by anticipating what test scenarios would have to be considered and how many test cases would have to be developed and executed before "passing" a story.

QA with developers

As part of the integrated team, the QA members would work closely with the architects and developers in designing a robust application. They would work with the developers in developing the test cases for test-driven development. They could also work with the developers in conducting unit tests -- sort of pair testing!

The QA members would also engage closely with the operations team to test the NFRs before the solution went to production for release.

Factors for success

For the model above to work effectively, the IT organization should take several factors into account, and everyone in the Agile journey should help with the change. The stakeholders in the development organization should not focus on the internal functional boundaries and should promote sharing and collaboration.

Product owner

The product owner should view the QA members as an integral part of the Scrum team and involve them in story elaboration and prioritization. The PO should enable them in writing test cases, developing acceptance criteria, and validating the completed solution.


Developers should not view QA team members as "just testers." They should be open to accepting them onto the Scrum team and encouraging them to contribute throughout the sprint -- from planning to product demo. They should understand the value the QA team would add to the final product.

QA leadership

QA leadership should move from traditional methods of resource allocation and management and allow flexibility to the testers in processes, documentation, and reporting. They should design effective mechanisms to leverage the metrics from the Scrum teams in the QA organization's governance reviews and reporting.

QA team members

QA team members should share knowledge and best practices from the large pool of the QA organization. Eventually, with cross-training and commitment, the QA members could even play the role of developers.

Thus in an IT organization adopting Agile practices, the QA members could seamlessly transform into the Agile way of working by becoming an integral part of the Scrum teams.

This article was coauthored by Indhu Kp.