Why you still need centralized QA in agile organizations: Lessons learned

As a development approach, agile promotes the importance of having the QA function embedded within the development team. But agile methodologies, coupled with rapid releases, can still be a big headache for QA. Many organizations still have a centralized QA department to complement testers’ presence in the combined agile teams, even after switching to a hybrid or a fully agile development process.

You could argue about the pros and cons of whether to centralize or not for days on end. But some people, like Dave Edwards, author of "Organizing a QA Department for Agile Success," have done a great job providing a theoretical outline for making this process successful. As a seasoned QA manager, I’m going to focus on some of the fundamental reasons why I think centralized QA still makes sense and, more to the point, talk about what has worked for my organization in bridging QA and agile processes.

The problem with agile, according to QA

Most development managers I’ve spoken with clearly see the value of agile. Some say it makes their teams feel free to move a lot faster. However, for QA teams that are used to version releases every 8 or even 18 months, the move to agile created a huge change. The consequences of working faster sometimes meant working with less documentation and planning.

QA teams were used to working in a structured way, knowing when they should review specs, prepare tests, and execute new feature testing. They would wait for a long stabilization period to run regressions and verify defect fixing. Most important, they would get a formal build at regular intervals.

In short, many QA teams feel that the rapid release and decentralized structure of agile makes quality hard to control and assure. My teams could relate to that feeling. It felt as though agile was causing the earth to move under our feet.

The table below breaks down some of the changes and challenges that agile created for us:

What we did to align with agile processes

1. We decided to work according to the Scaled Agile Framework (SAFe) model and ensured organizational alignment. Every development unit was given a dedicated QA "system team," which included a QA lead working with the development manager as a peer (the QA lead reported to a QA group manager). These teams focused on end-to-end testing of integrated software. Then, for each Scrum team, we dedicated at least one QA engineer to work closely with the developers, join standup meetings, and be an integral part of the team (the QA engineers reported to their respective QA lead).
2. We set about empowering testers to not only test the feature, but to have the authority to decide if the feature could be released from a quality perspective. Then we made sure that the QA engineer working in the Scrum team was highly knowledgeable about the application under test. In many cases, they should be the go-to people for any product’s how-to. Finally, we defined coding skills as a must: Sure, all QA engineers should be writing or running automation tests, but sometimes they should start much earlier, with UI-less user stories that require testing using APIs.
3. We put automation in place. We realized that if we wanted more frequent releases, we had to shorten and automate regression cycles. In each QA team, we nominated at least one engineer to be the automation enabler who would write and maintain the automation framework. They would also make the writing and running of automation easily repeatable for the rest of the QA team. Finally, on the more advanced agile teams, we defined all team members as TestDevs, fulfilling both the QA and coding functions.

Why QA autonomy is still important

Dev and QA managers have different sets of priorities and perspectives. Although quality is important for dev managers, it’s not the most important thing. When quality issues arise in a version, and defect fixing will require more time than planned, quality might be traded off for a faster release. Here is a rough sketch of the priorities for dev and QA managers:

Image credit: Shlomi Zalma

At the top on the dev manager’s list is time frames, because that is their main deliverable. Breaching pre-agreed timelines may result in exceptions and management escalations. The second item, content, means that dev managers might trade off quality for a feature they feel is important. Last, fixing bugs is important to the dev manager, but in many cases, some of these bugs will be moved on to later sprints.

The QA manager's list is the inverse of the dev manager's list. It prioritizes content over time frames, because their holistic, end-to-end user-like view sees useful features as just one part of the overall UX and quality story.

From my experience, maintaining a balance between the different approaches is healthy, even if it takes some time and convincing until the correct decision is made. QA independence is the x-factor in this fine balance, and having all testers report into the dev manager will compromise that. A QA team must have the freedom to perform the following four tasks (at least!) without considering organizational implications or the dev manager’s view:

1. Present actual product quality to higher management
2. Set the severity of defects from a QA objective perspective
3. Set the testing priorities (what, when, and how long to test)
4. Set version quality release criteria

Getting the best of both worlds

We try to combine best practices in all areas:

In testing tactics and methodologies, we share working procedures and terminology, and we align teams when talking about bug status and severity levels.

In tools and workflows, we try to use the same management tools, which results in easier sync between teams and projects, an ability to produce end-to-end statistics (user stories to defects), and the production of cross-project status reports.

As much as possible, we build automation frameworks once and reuse automation assets.

Last, we have special QA functions in performance, automation, and security centers of excellence that share knowledge and reuse assets across teams.

I truly believe that a centralized team can work with agile teams to further boost quality better than a purely embedded team can. The approach of a SAFe "system team" has worked very well for us. With this system in place, we have testers on both sides. It allows testers on the agile teams to stay true to the QA role, preserve their professional self-identity, and ensure excellent product quality.

Do you still have a centralized QA department? Why or why not?

Image credit: Flickr

Keep learning

• Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.

• Put performance engineering into practice with these top 10 performance engineering techniques that work.

• Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.

• Discover best practices for reducing software defects with TechBeacon's Guide. 

• Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.