DevOps Zone is brought to you in partnership with:

I'm an Agile and Lean Strategist specialised in coaching and managing the transformation of IT departments, from startups to enterprise-scale organisations, to highly efficient, productive and energised environments. I also have experience as senior development manager and architecture governance in large enterprises, especially in the finance sector. Marco is a DZone MVB and is not an employee of DZone and has posted 26 posts at DZone. You can read more from them at their website. View Full User Profile

Call to Agile Folks: is There a Need for a Separate QA Team?

  • submit to reddit

Recently I confronted myself (yet again!) with a contradiction between theory and practice. All the Agile books I have read and the courses I've attended and all Agile people I've been speaking to have been saying the same thing: you don't need a QA team: the team does QA as well as everything else.

This might be bad news for QA folks who suddendly might become enemies to Agile, frightened with the idea of suddently losing their jobs, or maybe it could be the inspiration for some of them to change their skills and roles and join an Agile team as fully flagged, fully valued Agile team members!

The current reality I'm in has got a QA team, although we like to say we follow Agile methodology and I can assure you that the QA team and what they do are very much valued.

So the first question is: why in Agile don't we need a QA team?

The purists and thought leaders will reply: "Of course you don't need a QA team because everyone should be able to do anything and everyone is part of the team, you don't need special skills and therefore special teams".

In realities like mine they will reply: "Are you mad? Of course we need a QA team; they ensure the system is defect-free before handing it to the business for UAT, while the development team codes the next feature / release".

I must say I lean towards this latter view (that of having a QA team) although in doing so, I'm sure I won't be accepted in the London's Gota of Agile practitioners (sorry Craig Larman, I'll never be a fully flagged SCRUM practitioner!).

Regardless of what Agile says (no trend is perfect no matter how cool it is) the amount of time involved in thoroughly testing a complex and large system, in following defects with the business, in managing issues and coordinating with (up | down)stream systems is copious. If developers had to do it, there would be a lot less time (if any at all!)  available to work on the actual business functionalities.This does not mean that the QA team should not be involved in the requirements definition and in the design of acceptance tests as well as this does not mean that the code hasn't been fully designed and tested through unit / integration / performance / system tests.

What is your view on this? Do you think one can be Agile while delegating thorough system tests to a separate QA team?

Looking forward your answers.


Published at DZone with permission of Marco Tedone, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)



Tomas Malmsten replied on Wed, 2011/05/18 - 4:59am

I think it depends on several factors.

If it is a product company with several agile teams which combined work is released to the customer, yes. You need a dedicated QA team that will test the full product.

If you are working with a smaller team delivering then no. Then QA becomes a function within the team. One or two of the team member will have this as their main priority whilst the rest works with code. This also helps both programmers and tester to better understand and value the others role and perspective.

If QA is a separate team I also think it's important to roll in other team members for an iteration ever so often. There is a lot that both can learn. Testers will benefit from tooling and mind set from programmers. The ability to create well structured code to test. The programmer will better understand the real world of the code they write.

Marco Tedone replied on Wed, 2011/05/18 - 5:49am in response to: Tomas Malmsten

Hi Thomas,

 Thank you for your answer. You could say that we follow in the first category. I'd be interested to know why you would differentiate between smaller and larger teams.



Tomas Malmsten replied on Wed, 2011/05/18 - 6:35am in response to: Marco Tedone

In some product companies you will have teams that work on different parts of the system. When the system is then built and shipped each of the parts are assembled into a single piece of software, or at times even hardware where the software ships with the hardware. You will typically have different teams working on different parts. The QA department has, in such environments, as their speciality to oversee the quality of the complete shippable product. They basically function as integration testers. No developer will have the complete overview in enough detail to be able to test the complete product within a sprint or development cycle. So it's not larger teams, rather large organisation with many small teams.

Philopator Ptolemy replied on Wed, 2011/05/18 - 8:17am

An interesting blog post on this subject.

Personally, i believe do believe that QA must have a different mindset from developers in order to find errors that escaped the developers. If a developer has some misconception, he is unlikely to detect it during testing.

Zqudlyba Navis replied on Wed, 2011/05/18 - 8:25am

I'm a developer.

I wouldn't want to cut half my brain doing system testing where I click buttons all day.

It's hilarious enough to see them write tests cases in MS Word forever and a day. We have a dedicated QA Team consisting of unskilled highschool dropouts who love doing routine repetitive tasks that developers won't do.

If you start pushing many system testing tasks to developers, they'll leave in droves.

Developers can always perform System Testing from the get go, but you wouldn't be able to get a Tester to write production code on the spot.

Marco Tedone replied on Wed, 2011/05/18 - 9:40am in response to: Philopator Ptolemy

Philopator, shouldn't code be built starting from the tests?

Marco Tedone replied on Wed, 2011/05/18 - 9:42am in response to: Zqudlyba Navis

Zqudlyba, so do you think that QA activities require less skills than development ones? What about TDD?

Ben Ooms replied on Wed, 2011/05/18 - 4:07pm

Zqudlyba, I'm part of a QA team and two scrum teams are delivering sprint. Its possible you always met high school dropouts as QA team members but as development is a skill so is QA. I love beside the QA part also the development part. In my opinion depending on agile teams involved and not to forget complexity of the system and context its good to have a separate QA team in most cases. This is because of the mindset of the agile team and the QA team. Let me try to motivate this. As an agile team the mindset is to achieve max business value in short amount of time. As an QA team the mindset is to achieve max business value with the best quality possible. Both can help in each other goals. We from the QA can learn from the agile team in using tooling and automation and the agile team can learn from us how to improve business participation and understanding.

Walter Bogaardt replied on Wed, 2011/05/18 - 4:47pm

What I see in Agile development is more of a dynamic/hybrid team. Reporting structure for everything administrative you have your traditional team/skill grouping. Yet when working on agile projects it's an assembly of differnt member sof the organization driving a set of usecases through each sprint till release. In Agile development, now teams are comprised as resources rather than who they are grouped with for reporting/hr. That's simply because HR is not agile.

Torsten Schmidt replied on Thu, 2011/05/19 - 7:51am in response to: Zqudlyba Navis

I think you mix testing with QA. Testing is only one part of it and is normaly not done by the QA team. QA is defining the tests and gives UML stuff to the developer. So they can easyly fill methods with code.

Philopator Ptolemy replied on Fri, 2011/05/20 - 8:49am in response to: Marco Tedone

shouldn't code be built starting from the tests

First of all, i think that even if code was TDD'd, it still requires independent testing.

Second of all, I think some code is better suited for TDD than other. I wouldn't TDD GUI, etc.Also, I find that experienced programmers manage to design and modularize the code (SRP, ISP, Liskov, Demeter) properly even without TDD. But i totally support TDD when people find it useful.


Patroklos Papapetrou replied on Sat, 2011/05/21 - 2:22am

Very interesting article and hot topic. To be honest I cannot answer with a simple Yes or No. I prefer though to present our case in the company I work.
We have a very small QA dept (3 people) where as our total developers count to 25.As you can imagine there is a bottleneck in QA stuff, so we have tried to wear the tester hat in some agile teams and do the testing inside the team. The results, however, vary. Some times "testers" inside the dev-team do greate job,especially when they feel that the software is their child. There are cases,though, where QA team with different approaches catch some defects that are not "seen" by dev-members, or do a more detailed testing.
To be honest I believe that a mixed combination maybe the best scenario :-) I am not sure... We are still try to learn

Loren Kratzke replied on Mon, 2011/05/23 - 12:08pm in response to: Marco Tedone

No! Code should not be built from tests.

Marco Tedone replied on Mon, 2011/05/30 - 11:21am in response to: Loren Kratzke

Why do you think this is the case?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.