Métricas para testes automatizados

Métricas servem para diagnosticar problemas de qualidade nos sistemas de software. Sem métricas não há gerenciamento de qualidade do produto. Decisões estratégicas importantes devem ser tomadas com base em informações obtidas baseadas em indicadores. Métricas são compostas de diferentes medidas, e indicadores são obtidos através da interpretação de métricas.

O que realmente podemos considerar automação?

Teste automatizados não devem depender de intervenção humana para que seja corretamente executado. A suíte de testes deve ser executada através de ferramentas de integração contínua, seja através de agendamentos sistemáticos a cada período de tempo ou por gatilhos configurados no repositório de versionamento do código fonte de produção. O resultado deve ser sempre assertivo, ou seja, PASSOU ou FALHOU, sem necessidade de interpretação humana para obter essa resposta. A entrega contínua depende desse principio.

Os dados de teste são um fator essencial para correta execução dos scripst, visto que não deve ser necessário que um profissional prepare ou exclua os dados do teste. O script deve ser capaz de buscar e limpar todos dados que forem necessários.

Retomando os conceitos de F. I. R. S. T., cada caso de teste deve ser rápido, independente, repetível, auto-validado e construído no tempo correto. Independência se refere não somente à pré-condições de outros scripts, mas também dos dados envolvidos no teste.

O que realmente podemos considerar um teste?

Eventualmente encontra-se scripts automatizados construídos com intuito de ludibriar métricas de produtividade das empresas que esperam ter alta cobertura de testes como principal métrica de sucesso, e geralmente nestes casos os scripts simplesmente percorrem um processo sem validar nenhum aspecto do sistema pelo caminho. Isto não pode ser considerado um teste. Para o script automatizado de fato testar algo ele deve validar algo no sistema.

Testes manuais x Testes automatizados

Ao pensarmos em métricas para automação de teste, NÃO devemos considerar apenas a criação, desenvolvimento e manutenção dos testes automatizados versus testes manuais. Testes manuais sempre serão importantes. Mesmo com a automação, existem cenários nos quais será necessária a execução de testes manuais.

Testes redundantes ou repetitivos são grandes candidatos para a automação. Testes que precisam de observação humana, como determinar um bom visual estético de um website ou verificando se a navegação do menu é user-friendly, devem continuar manuais.

Lembre-se: os benefícios da automação são particulares para cada equipe, isso não pode ser generalizado.

Enfim, algumas métricas

1. Cobertura de testes automatizados sobre as funcionalidades do sistema (e não sobre todos os cenários de teste mapeados): dentre todas funcionalidades existentes no sistema, quantas possuem testes de aceitação automatizados?
2. Cobertura de testes automatizados por níveis do software: essa métrica deve ser interpretada com base na teoria da pirâmide de testes, que recomenda que quanto mais “baixo“ o nível dos testes, menor é a complexidade e o custo para implementar, então maior deve ser a cobertura de testes automatizados. Simplificadamente, podemos dizer que o teste estático (ou inspeção de código) deve ser aplicado em 100% do código fonte, os testes unitários devem cobrir aproximadamente 80%, os testes de API em torno de 60%, os testes de interface em média 20% (referentes aos testes de aceitação) e o teste de performance deve ter uma estratégia especial para cada contexto, normalmente para ser executado mensalmente.
3. Quantidade de defeitos identificados pelos testes automatizados, mapeados por funcionalidade: Essa métrica pode ser gerada automaticamente pelo próprio script de teste.
4. Cost avoidance, ou seja, calcular o custo economizado ao evitar que um defeito entre em produção: quanto antes um defeito for identificado, menor será o seu impacto. Uma boa bateria de testes automatizados oferece feedback rápido e constante sobre a qualidade do software, de forma que os problemas serão identificados rapidamente. Ainda assim, alguns defeitos podem chegar em produção, e o impacto financeiro deste defeito deve ser calculado, de forma que seja possível analisar a cada sprint os custos provenientes de problemas que entram no ambiente de produção.
5. Quantidade de defeitos que chegaram em produção: métrica essencial em um time de desenvolvimento, pode apresentar informações importantes à medida que a cobertura de testes automatizados aumenta.
6. Testabilidade do software: Temos acesso de leitura ao banco? Existe uma API de serviços dentro dos padrões arquiteturais? O front-end implementa IDs nos elementos HTML? O back-end permite facilmente a construção de testes unitários? É fácil utilizar mocks?
7. Quantidade de casos de testes automatizados com problemas: isso pode indicar fragilidade nos testes construídos, por exemplo, expressões xpath imprecisas, esperas mal utilizadas ou até mesmo má arquitetura. Podemos medir a quantidade de asserções por caso de teste automatizado. O ideal é de que cada caso de teste implemente exatamente uma asserção, pois muitas asserções em um mesmo caso de teste pode indicar que a página ou serviço fere o príncipio de responsabilidade única.
8. Duplicidade de código nos scripts de testes automatizados: em média, deve estar abaixo de 20%, ou indicará que são necessárias refatorações.
9. Inspeção completa de código de produção e também dos testes: as próprias ferramentas de inspeção de código geram e exibem métricas sobre os resultados obtidos neste teste.
10. Tempo de execução dos testes manuais x automatizados: tendo em vista que o tempo de execução do teste automatizado varia de máquina para máquina e também depende da disponibilidade de conexão, é interessante neste caso contabilizar a quantidade de instruções (ou statements) e a complexidade ciclomática do código fonte do script de teste automatizado para calcular sua complexidade e estimar seu desempenho.

ROI

Ao eleger quais casos de teste devem ser automatizados primeiro, é uma boa estratégia iniciar pelos testes simples e repetitivos. É fácil cair na falácia de que os testes mais complexos e demorados devem ser automatizados primeiro, mas estes vão trazer um retorno menor e um tempo de implementação maior. Fazendo a automação dos testes menores antes, ganharemos embalo para os próximos testes, além de perceber o ROI antes.

Abaixo apresento algumas perguntas que devem ser respondidas para que possamos estimar o Retorno sobre o Investimento em automação.

Investiremos em ferramentas proprietárias? (Normalmente não há motivos para isso). Devemos considerar investimentos em capacitação de profissionais para trabalhar com automação? Quanto economizaremos deixando de manter uma coleção de diferentes dispositivos físicos para testes mobile?

Para novas funcionalidades:

Quantas funcionalidades são entregues em média a cada iteração do time? Quantas horas são necessárias para cobrir essa quantidade de funcionalidades com testes de aceitação automatizados? Qual o custo/hora dos profissionais envolvidos nessa tarefa?

Para funcionalidade de regressão:

Teste de regressão é o processo de rodar testes antigos para garantir que as novas atualizações não introduziram ou reintroduziram problemas já depurados. Ao longo do tempo, esses casos vão ficando maiores e demandando mais tempo de execução. Implementar a automação de testes neste tipo permite rodá-los mais rapidamente e aumentar a confiança para a próxima entrega.

Qual a quantidade de testes de regressão que vale a pena ser testada automaticamente? Qual é o tempo médio de esforço para construção de um caso de teste? Qual é o custo/hora dos profissionais envolvidos? Qual é o esforço estimado de manutenção necessária nesta suíte de testes?

Outros aspectos a considerar:

O tempo de carreira médio de um analista de teste em uma empresa é de 3 a 5 anos. Quando o testador sai, conhecimento institucional é perdido. Os scripts de teste automatizados são uma base viva de conhecimento sobre o sistema e este valor deve ser considerado no cálculo de valor gerado pelo investimento em automação.

Referências

C. MARTIN, Robert. Clean Code: A Handbook of Agile Software Craftsmanship. Alta books, 2008.

D. ALBINO, Raphael. Metricas Ágeis: Obtenha Melhores Resultados Em Sua Equipe. Casa do Código, São Paulo, 2017.

VOCKE, Ham. The Practical Test Pyramid. martinFowler.com, 2018. Disponível em martinfowler.com/articles/practical-test-pyramid.html

6 formas de medir o ROI dos testes automatizados. Disponível em www.primecontrol.com.br/6-formas-de-medir-o-roi-dos-testes-automatizados.