[Dúvida] Como vocês medem a cobertura de testes automatizados?

Eu gostaria de saber se vocês medem e como medem a cobertura de testes automatizados. Exemplo: Qual a porcentagem das regras de negócio do software possui teste automatizado?

Na empresa em que trabalho percebe-se muita dificuldade de mensurar a cobertura de testes funcionais automatizados, então geralmente é usado a “quantidade de testes automatizados” para extrair algumas métricas. O que não é uma boa ideia, porque um teste simples que só faz uma pesquisa, por exemplo, pode contar como um teste complexo, que executa uma verificação do fluxo principal da aplicação.

Cobertura de teste, assim como “code coverage” para teste unitário é meio que uma falácia… cobertura de teste pode não se traduzir em teste relevante.

No seu exemplo, uma ‘busca’ pode passar por funções e não necessariamente testar por completo aquela classe.

Para novas histórias, uma boa cobertura de automação de teste funcional é cobrir os critérios de aceite… Uma vez com eles englobados, você sabe que aquela história dificilmente vai quebrar no futuro sem você saber.

Agora no caso de regressão, acredito que seja necessário mapear as funções ( com suas respectivas importâncias), seus desdobramentos e ai sim entender o que será coberto…

Métrica por métrica acho meio que cretinice…

Na minha opinião, toda métrica tem como objetivo responder a uma pergunta chave, por exemplo: porque é importante para vocês saberem o percentual de cobertura? qual resposta ou problema vocês pretendem resolver com esse número? Definido o objetivo, fica mais fácil de criar uma métrica mais assertiva e dentro do seu contexto.

Acho cobertura de teste uma falácia quando usada como base para medir a qualidade do software, mas em geral ela ajuda a medir a progressão dos testes e nos passa uma certa segurança por meio dos testes regressivos.

Leonardo comentou como geralmente as métricas são criadas para testes funcionais automatizados para novas histórias e legado, se elas corresponderem com a resposta que você procura, ótimo, mas nada impede você criar sua própria métrica.

Tester

Pessoal,

Obrigada pelo retorno.

Leonardo,

Talvez utilizar o termo “cobertura” não seja uma boa ideia, já que ele lembra “cobertura de testes unitários”, e não é essa relação que desejo fazer.

Citei como exemplo o teste de pesquisa x um teste que executa uma verificação do fluxo principal da aplicação, para demonstrar que pode não ser uma boa ideia, para se avaliar “crescimento de automação de testes” - por exemplo, utilizar o número de cenários de testes automatizados.

Mario,

Respondendo tuas perguntas. Um dos meus objetivos é saber quantas regras de negócio possuem testes automatizados; quantos fluxos possuem testes automatizados e assim por diante.
A questão aqui é como medir isso: se deve ser feito um controle manual ou se existem outras alternativas. A ideia é saber se alguém já faz isso, e como faz.

Fazemos isso na empresa que trabalho.

O controle é feito de forma manual, definimos que uma “funcionalidade” vai ser considerada 100% coberta por testes automatizados funcionais quando foi investido um tempo nela planejando, elaborando os scripts e implementado os melhores testes dentro do nosso contexto.

Dessa forma, temos uma métrica semelhante a isso:

Módulo Suprimentos = 50% de cobertura por Testes Automatizados Funcionais ( (100+50+0)/3)

  • Solicitação de Compra = 100%
  • Pedido de Compra = 50%
  • Nota Fiscal = 0%

Tester

@marioramos18, com seu exemplo acho que entendi melhor o que a @aniela-cole quis dizer…
Por exemplo,

  • Solicitação de Compra --> 10 testes possíveis
  • Pedido --> 20 testes possíveis
  • Nota Fiscal --> 50 testes possíveis

dizer que temos 50% das funcionalidades cobertas por teste automatizado não seria muito correto, já que temos apenas 20 testes automatizados dos 80 possíveis. Ou seja, não é justo considerar a Solicitação (com 10 possíveis testes) sendo igual à Nota (com 50 possibilidades).

Aqui na empresa onde trabalho temos uma métrica de teste semelhante a esta… definimos que para a entrega da versão, precisamos que 80% das solicitações de mudanças do sistema sejam testadas. Mas pode acontecer isso, 20% das SMSs não testadas corresponderem a uma fatia muito maior do que 20% das alterações daquela versão.

Para ter a métrica ideal, teria que se saber a quantidade de testes possíveis e a quantidade de testes feitos. Mas na fase dos testes funcionais de sistema, saber a quantidade exata de possibilidades de teste é muito difícil, dependendo do tamanho do sistema.

@bruno-fernandes Faz total sentido o que vc comentou. Mas essa foi a métrica que adotamos para satisfazer um problema que queriamos resolver, como expliquei no outro comentário, cada equipe cria sua métrica com um objetivo e respeitando seu contexto, e foi isso que fizemos cientes de alguns riscos. Após realizar uma análise de risco e automatizar testes funcionais dos principais fluxos ou regras de negócio da funcionalidade por exemplo, esses testes irão corresponder a uma boa cobertura, apesar de ser um número muito menor comparado (todos os testes possíveis) e causar uma primeira impressão de um % muito baixo de cobertura, ele tem uma representatividade muito maior pelo fato de se tratar das principais regras de negócio do sistema, o que nos fez simplicar e considerar 100% da funcionalidade coberta.

Tester

Olá pessoal, pegando o gancho desta dúvida da @aniela-cole algum de vocês já conseguiu coletar/medir automaticamente o nível de Cobertura de Testes Funcionais Automatizados em seus projetos de automação?

@Willy Salazar eu já brinquei em utilizar o cobertura, instrumentei o .war e consegui medir a cobertura da minha aplicação.

Log in to reply

Looks like your connection to Agile Testers was lost, please wait while we try to reconnect.