Qual é uma boa medida da eficiência dos testes / testadores?

Estou prestes a participar de uma discussão com a gerência sobre como medir nossa eficiência de teste como organização de controle de qualidade. A principal razão por trás disso é que metade da nossa equipe está terceirizada e nossa empresa gostaria de fornecer algumas métricas de quão eficaz / eficiente somos, para que tenhamos dados básicos para negociar os parâmetros do contrato com o contrato de serviço de nossos contratados .

Examinei um pouco e a maior parte da opinião que encontrei sobre esse assunto gira em torno da eficiência do desenvolvedor: linhas de código, histórias contadas, defeitos introduzidos, etc.

Mas e os testadores? Nossos testes são baseados principalmente em requisitos e uma mistura de testes manuais, semi-automáticos e automatizados (não porque não conseguimos automatizar tudo, mas porque algumas coisas não são automatizáveis ​​em nosso sistema de teste).

O número de testes gravados é inútil, e um alto número de bugs encontrados pode ser uma medida de desenvolvimento ruim e não de controle de qualidade eficiente.

As medidas de automação (cobertura de código, cobertura de recursos ...) podem ser boas, mas acho que elas ajudam mais o desenvolvimento (como desenvolvedor, saberei se eu quebrar algo acidentalmente) do que os clientes (eu quero fazer isso e isso não funciona).

Como a qualidade é boa se os clientes não encontrarem problemas, uma boa medida da eficácia (e não da eficiência) de uma equipe e processo de controle de qualidade é a medida dos erros encontrados pelos clientes que não foram encontrados pelo controle de qualidade .

O principal problema dessa métrica é que pode haver um atraso considerável entre o trabalho realizado e quando você começa a ter números significativos.

Existem algumas métricas que usamos no meu último trabalho para avaliar o controle de qualidade:

• Número de bugs encontrados. Eu odeio esse. É como "Número de linhas de código gravadas" para um desenvolvedor.
• Número de casos de teste automatizados produzidos.
• Porcentagem do total de aplicativos cobertos em testes funcionais.
• Número de erros encontrados no preparo versus produção.

No final, o trabalho da sua equipe de controle de qualidade é encontrar os bugs antes que eles saiam da natureza. Suas métricas devem se basear em realmente atingir esse objetivo. Se houver uma baixa cobertura de casos de teste, quantidade mínima de testes automatizados e uma alta taxa de erros na produção, eles não estão fazendo um bom trabalho. No entanto, se eles têm um bom histórico de encontrar os bugs muito antes de atingirem prod, suas métricas devem ser bem altas.

O controle de qualidade deve ser medido por duas métricas principais: quantos bugs passam pelo controle de qualidade encontrados no campo? Qual é a gravidade deles?

Você pode conseguir o controle de qualidade para encontrar erros graves mais próximos do lançamento do que o dev-complete. Você poderá executar o controle de qualidade por não concluir o teste até a data estimada de conclusão (por recurso).

Embora, no final, eu tema que você gaste mais dinheiro tentando medir a eficácia de sua equipe de contratação do que as economias obtidas com a equipe de contratação ...

A empresa em que trabalho utiliza várias métricas de controle de qualidade.

O que eu acho mais relevante é a cobertura do código. Uma ferramenta como o EMMA funciona muito bem ao escrever testes automatizados completos, além dos testes manuais.

Faça o que fizer, não se concentre no número de testes. Isso é tão útil quanto o LOC por dia.

Muitas maneiras de medir o desempenho nas fases de desenvolvimento e teste durante a execução do projeto. Usamos as medidas abaixo em nossos projetos. Desempenho do desenvolvimento medido por 4 métricas populares do código (índice de manutenção, complexidade ciclométrica, profundidade de herança, acoplamentos de classe). Para C # vai obtê-lo no Microsoft Visual Studio. Para cobertura de teste, o Ncover / Ndepend é muito útil. Teste de desempenho medido por nenhum erro de desenvolvimento - rolando nos últimos 4 sprints Erros de teste do sistema rolando nos últimos 4 sprints. Nenhum teste de automação passou em uma versão específica / Recursos entregues.