This is fairly common, if not typical. To answer what are several questions:
- What should be the right approach to track activities in such scenarios?
- Will features get done without QA but with defects?
- How can I track the efforts seamlessly?
- Should testing be part of "Done Definition"?
- What are the pitfalls if it is not?
I would take an overall approach that:
- enables the testers to add value
- gives them authority
- maximizes their value
- encourages QA folks to train developers
and to do that (and answer your questions) I would:
Also, yes, some features may get done without QA but with defects. I often find QA is a second set of eyes. Sometimes this role can be filled by another developer. Personally I find this finds some errors, but not all the ones that a different QA mindset might find.
Testing should be part of done but that does not mean that the QA person has to do the testing. Given the shortness of resources and an Agile environment that eschews specs that QA can look at, QA need to be involved with learning the users domain, design meetings, point grooming meetings, standups, retrospectives, etc.
As for the big question of testing strategy, use the Agile testing quadrants to guide you:
Integrated | Performance
Unit | Exploratory
The developers may already be doing Unit Tests. A key area that QA may add value by covering is in Integrated testing and by using UI automation.
Good exploratory testing is also very valuable - it's not just clicking every link on the page, it's about learning the end users domain and what using the application means to them.
For the ratio of QA's to testers also consider the testing triangle:
Individual Unit Tests
whereby one exploratory or integrated test can represent dozens if not hundreds of unit tests by exercising the whole 'stack'.
Also consider that as in Agile teams there should generally be an approach of anyone can code, anyone can test. The key of course is giving folks the guidance and structure so that they can do what is needed and giving them training for the other area.
In terms of the actual ratio, I disagree about the preciseness of David's answer of 3:1 or 4:1 In some organization where developers are writing good unit and integrated tests this might be ok to be 7:1 In an organization with very little testing done by developers this might need to be 1:1 It really 'depends' on the organization, structure, knowledge, industry, etc, etc.