Get certified - Transform your world of work today

Close

Independent QA or Integrated QA?

How a QA organization could align and work with Scrum teams

28 July 2014


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:

Independent-QA-or-Integrated-QA-Diagram.jpg

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

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.


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 2.5 (2 ratings)

Comments

Tim Baffa, CSM, 7/28/2014 2:18:14 PM
While there is a wealth of knowledge within QA departments in non-agile IT shops, accomodating or even advocating an approach where this knowledge silo is maintained seems very anti-agile to me.

Personally, I think it is unwise to call anyone within a Scrum effort by their expertise (i.e. - QA team, Dev team, etc). This promotes the handoff concept and defeats efforts at team collaboration.

What is critical is asking ourselves how do we go about integrating this QA knowledge base within the Scrum teams, and not on a rotating basis but as permanent members of a team.

Also, this article seems to promote the iteration as a mini-waterfall, which will only serve to slow the adoption of Scrum within an organization. There is no "testing phase" within an iteration.
Tao Chen, CSM, 7/29/2014 3:12:40 AM
I agree most of the points in the article, and we do work like mini-waterfall at the first step in to Scrum. But I have some concern, maybe not for the topics, it is how should we improve our technical level for each role? You know, dev can do tests, and also can do works like writing AC or something, also dev can help SQA to finish some work on automation test, but who can help dev to improve, especially the dev team is composed of young devs?
Tim Baffa, CSM, 7/29/2014 8:20:37 AM
Tao,

This is what I have had success with in the past, perhaps some of it may work for your situation as well.

My first thought is whether the team has self-formed and consists of developers that are young and inexperienced, or if upper management has formed the team (common first practice). In either case, a helpful exercise is to question them on what an ideal "Scrum" team is. Typically, their responses (team members and management) will promote diversity within the team (age, gender, experience level, roles, etc).

Once provided with that input, simply question them on whether the current team make-up reflects their ideal team structure. In your case, the team is too inexperienced and needs one or two more experienced members to balance it out.

Easier said than done, I know. The benefit of having various roles and experience levels on a team is that practices like pair programming (or simply working together on tasks) can greatly accelerate learning, cross-training, and team bonding. In some instances, I have had senior-level developers (SME's) as
"floaters" between established teams, working with them as needed for a few sprints when the topic falls within their area of expertise. This is an accomodation more than anything though, and is sometimes done when experienced individuals are not initially comfortable in a team structure and value their autonomy and expertise.

Hope some of this helps.
Tao Chen, CSM, 7/29/2014 9:39:10 PM
I agree most of the points in the article, and we do work like mini-waterfall at the first step in to Scrum. But I have some concern, maybe not for the topics, it is how should we improve our technical level for each role? You know, dev can do tests, and also can do works like writing AC or something, also dev can help SQA to finish some work on automation test, but who can help dev to improve, especially the dev team is composed of young devs?
Mohit Mishra, CSM, 7/30/2014 1:05:37 AM
I have a different take when it comes to QA,In my opinion we need to have multiple flavors of QA in the process of development, first and the foremost one is the "Enabler" responsible for pairing up with development in ensuring that Development is able to complete the user stories without any bugs, complies with system requirements and felicitates the feedback process from the Product Owner. The other important flavor of the QA is to certify the product/application developed is in compliance with company defined QA standards.
In my experience I have seen most of the companies adopting this model, wherein they employ internal QA as an enabler/facilitator to the development and independent QA to certify the application.
Robert Day, CSM, 8/11/2014 5:09:45 AM
I have had experience of being integrated into a Scrum team as a QA practitioner. There were pros and cons, of course.

The good thing was that as someone with a QA and BA background, I was able to step back from the pure development task and bring that knowledge to the team. Often I found myself working as a bridge between system users out on the floor and developers who were interpreting the specification that I and my colleagues had collected from users. Each Sprint brought its own challenges and testing time was built into the task estimations.

On the other hand, the QA team was also responsible for a range of QA activities across the organisation, including QA of high-level reports and documents. This was business-critical work that was accorded highest priority by senior management, and so rather broke the rules over Scrum team members being dedicated to that work exclusively. However, if the QA was wrong there was a very high risk that senior managers would have to do media appearances or be exposed in legislative scrutiny sessions, so we really just had to cope with the less desirable dual role. Resources were not available to allow separate people to be allocated to Sprint work and the high-profile QA work.

You must Login or Signup to comment.

 

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.