Testes de aceitação e cobertura de código

Question

Qual é a melhor maneira de medir a cobertura para seus testes de aceitação?

Como você define quanto seus testes de aceitação cobrem e quando são suficientes?

Answer 1

Ao fazer testes de aceitação, prefiro olhar para o cobertura funcional ou seja, quantos recursos (ou histórias de usuário ou casos de uso) de um determinado aplicativo são testados. E para mim, para cada recurso (ou história do usuário ou caso de uso), todos os cenários ou caminhos possíveis devem ser testados. Em outras palavras, os recursos devem ser o ponto de partida para escrever um plano de teste e o objetivo deve ser cobrir os recursos, não o código. Essa é uma pequena diferença, mas importante: medir o teste de aceitação com cobertura de código é orientado para o desenvolvedor, a medição da cobertura funcional é orientada para o usuário final.

Em relação à medição, Ron Jeffries, um dos pais fundadores do Agile, escreveu um excelente resumo do que ele considera uma métrica, RTF ou execução verdadeiramente valiosa. Você pode ver o artigo aqui. Estou apenas citando uma pequena parte abaixo:

Qual é o objetivo do projeto?

Estou apenas supondo, mas acho que o objetivo da maioria dos projetos de desenvolvimento de software é um software que funciona e que possui o maior número possível por dólar de investimento. Eu chamo essa noção em execução testada [recursos] e, de fato, pode ser medida até certo ponto.

Imagine a seguinte definição de RTF:

1. O software desejado é dividido em recursos nomeados (requisitos, histórias) que fazem parte do que significa fornecer o sistema desejado.
2. Para cada recurso nomeado, existem um ou mais testes de aceitação automatizados que, quando funcionam, mostram que o recurso em questão é implementado.
3. A métrica RTF mostra, a cada momento do projeto, quantos recursos estão passando todos os seus testes de aceitação.

Quantos recursos definidos pelo cliente são conhecidos, por meio de testes definidos independentemente, para trabalhar? Agora há uma métrica com a qual eu poderia viver.

Para relatar o progresso, gosto especialmente de diagramas de fluxo cumulativos. Eles mostram claramente quando algo está dando errado, por exemplo (aqui um estilo de queimadura):

_{(fonte: xprogramming.com)}

Para um exemplo da vida real, dê uma olhada esta postagem ou Este (gráfico de estilo Burndown).