QA Feature owner - when testers become project managers II

We have been using QA Feature Owner (QFO) methodology for two months now so I guess it's time for me to review where this is going. My vision is very clear to me:

• I (QA manager/Team Leader) don't want to decide what will be tested in each build

• I want to increase testers' commitment and familiarity with "their" features
• I want each tester to be skilled in all three testing methodologies we employ (Greybox/Integration tests, UI automation tests and manual tests) as well as with core QA methodologies and skills such as reading a specification document, analyzing it, deriving risks etc'

If that wasn't clear enough, I'll now emphasize what team I don't want:

• I don't want a team in which I have to decide which test will run in each new build. Too many test cases and too many changes in each build for me to do this effectively.
• I don't want a team of domain experts who only test their area of expertise. I don't want the UI automation expert doing nothing but recording scripts and I don't want the person who is used to testing manually treat automation like black magic.
• I don't want testers who test features when they assigned to them and forget them after the testing is done. I don't want tester who move from feature to feature.
• I also don't want tester who got job security because they are the only ones who can "do this thing". This is not exactly QFO related so I'll deal with the versatility issue in another post.

Since we started using the QFO methodology, we are testing differently. When we get a new build I sit with each QFO, asking her what she wants to test and why. Why is this test left out? Why do we run that test again? While I'm there to supervise, each QFO is responsible for creating "test runs" (that's how a collection of tests is called in Testopia, our testing suite) for new and existing features. QFOs run some of the tests themselves, other tests they delegate to other team members. That's OK, that's how the system works.

This system is obviously not suited for every testing team. Team members need to be able to (and want to!) take responsibility over their features. Team members need to delegate tasks to other team members and perform testing tasks which aren't "theirs" so good communication skills are also required. It is geared towards responsible testers who want to be involved with the product and not just perform tests assigned to them by some authority figure.