Who's doing what testing? Testers vs. Developers
I had an interesting discussion in Citcon about the different role of testing from Developers and QA/Testers. It seems (as an industry) we're still confused about the role between Developers and QA/Testers in terms of testing in the context of agile methodology.
This post will contains my personal opinion about the different role between Developers and QA/Testers in an agile context, as well as the challenges moving forward.
These are my views:
- developers should cover as much testing as possible to ensure the quality of their work (unit test, code coverage, functional/acceptance test, etc). This is not other people's work.
- It's not clear when the line should stop. Should developer stop at unit testing? or up to Automated User Acceptance Testing (selenium/watin,etc) testing?
- I acknowledge that QA/Testers can pickup bugs that devs can't and it's important to find the right fit in an agile context!
- However, I can't see any obvious fit in an iteration cycle for QA/Testers
- QA/Testers either need to be 1 iteration late from dev, or have a totally separate iteration (different user story , etc)
Some people (which as you might expect are QA/Testers) had strong reaction towards that opinion. I sense that current QA/Test Lead still forcing waterfall methodology; pre-planning, handovers etc into an agile team.
Instead of doing pre planning and Dev to QA/Tester handovers per release (as in waterfall approach), some people are doing them on a user story level. I'm not sure how these type of process can lead to a stable baseline for QA/Testers to do their work.
There also seem to be a push to elevate the role of a tester to become the proxy for the stakeholders. I think they must not like the current stake holders (product team, business analyst, end user) that much .
The main challenge seems to be that; to gain maximum effect, Developers and QA/Testers need to work in isolation. In order to work in isolation, proper planning and handover is essential. In a typical waterfall model approach this is not an issue. But in an agile team, the approach contradicts the very belief of the approach; which is getting rid of the friction between the stake holders and the developers, QA/Tester seem to get in the way.