Call to Agile Folks: is There a Need for a Separate QA Team?
The Agile Zone is brought to you in partnership with Hewlett Packard Enterprise. Discover how HP Agile enterprise solutions can help you achieve high predictability and quality in your development processes by knowing the status of your projects at any point in time.
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.