QA productivity metrics

In a lot of companies the QAs productivityi s measured through the number of defects she raised: the more defects she finds, the harder she works, therefore the better she is.

This approach has an interesting corollary: if you have really good QAs you don’t have good developers. If your QAs are finding a lot of defects this means that your developers are quite poor and are regularly introducing defects in the code base.

This approach isn’t obviously team oriented: QA and Development are seen as two separate and independent entities that interact through a specific contract.

If we truly believe in collaboration the most important productivity metrics are not related to a specific role/skills set but to the team capability of deliver quality software in time and in budget.

We need to ask ourselves why the defects are finding their way into the application deployed in the live environment (incomplete acceptance criteria? not enough analysis or understanding of the domain? gap in the test suite?), and fix the issue as a team, not just using that number as the boundary between two work streams.