Call to Agile Folks: is There a Need for a Separate QA Team?
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.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)
Comments
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.
Regards,
Marco
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 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
Marco Tedone replied on Wed, 2011/05/18 - 9:42am
in response to:
Zqudlyba Navis
Ben Ooms replied on Wed, 2011/05/18 - 4:07pm
Walter Bogaardt replied on Wed, 2011/05/18 - 4:47pm
Torsten Schmidt replied on Thu, 2011/05/19 - 7:51am
in response to:
Zqudlyba Navis
Philopator Ptolemy replied on Fri, 2011/05/20 - 8:49am
in response to:
Marco Tedone
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.
Philopator.
Patroklos Papapetrou replied on Sat, 2011/05/21 - 2:22am
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
Marco Tedone replied on Mon, 2011/05/30 - 11:21am
in response to:
Loren Kratzke