Role of a QA-person in an Agile team

It's been a long time since I wrote anything on my blog. AgileTuning keeps me busy - but that's good, isn't it? I decided to finally shut down my own instance of Wordpress and to start using blogger.com

From some time I've been thinking about recoridng a podcast on role of a QA person in an Agile team. Is this about automating tests, facilitating retrospectives, defining acceptance criteria? Maybe a little bit of both?

A few days ago I had a very interesting discussion about that. On the one hand everyone is responsible for quality in the team - developers write unit tests, a Scrum Master or a Project Manager facilitates retrospectives and Customers writes acceptance tests... And everyone is really motivated to do their best!

On the other hand there's this thing called... reality. Unit tests don't cover everything and customers don't have enough time, or tech skills, to play with test automation tools. When deadlines are approaching PMs don't waste teams' time on chit-chat. And this is when we need a QA who's more than just a tester. A QA that will either work out acceptance criteria with the customer, or won't be afraid of saying "stop" and will have enough understanding of business to convince management to this decision.

Many years ago I heard Tadeusz Golonka saying that in order to successfully share responsibilities in a project one must not combine any of the following roles: technical leadership, customer representation and quality assurance (I hope I remember the first 2 correctly, anyway - I'm sure of the third). Quite much has changed in the IT since than but it sounds like this rule still holds true.