“Conheça a visualização “funil” da Eficácia de Testes de Software”
A visualização “funil” da Eficácia de Testes, uma ferramenta para reduzir seus custos de qualidade e melhorar o valor do seu processo de desenvolvimento de software.
Gostamos de classificar praticamente tudo, e muitas das vezes em apenas dois grupos como por exemplo se determinada orientação política é direita ou esquerda, se algum produto/serviço é bom ou ruim, se alguém é rico ou pobre, desconsiderando todas as possibilidades que existem entre estes extremos. Assim também agimos com nossos projetos, ou com a qualidade de nosso trabalho.
Possuímos um sentimento de polarização intrínseco onde ou corremos riscos assumindo que tem 100% de Qualidade ou provisionamos um esforço adicional muito maior que o necessário (desperdício de recursos, ou a famigerada gordurinha na estimativa) por acreditarmos que algo não tem Qualidade.
Estes instintos ou mecanismos que praticamos inconscientemente podem ser comparados com a ilusão (ilusão Müller-Lyon), onde apesar ambas as linhas serem rigorosamente do mesmo tamanho, uma parece maior do que a outra.
Outro exemplo pode ser encontrado na Aviação civil, quando as tragédias ocorrem ficamos aflitos (obviamente pela perda de vidas) e questionamos a sua qualidade e confiabilidade. Porém, segundo a consultoria To70 em uma matéria cedida a Deutsche Welle, a taxa de acidentes fatais para aviões de grande porte no transporte aéreo comercial de passageiros foi de apenas 0,18 por milhão de voos em 2019. Ou seja, 1 acidente fatal, em média, a cada 5,58 milhões de voos.
Trazendo este contexto ao ciclo de desenvolvimento de software, questiono o quão atentos estamos a estes tipos de comportamentos durante a construção dos nossos produtos (isso mesmo DURANTE, pois depois é tarde e caro demais)?
Somos condicionados a medir a qualidade em nossos produtos, desde o início de sua concepção. Seja escrevendo bons requisitos de qualidade (o sistema deve responder em até 3 segundos) ou incluindo Critérios de Aceite às User Stories, mas e quanto a qualidade do processo de desenvolvimento em nossos projetos?
Vamos resgatar a famosa pirâmide de testes de Mike Cohn’s, onde o quanto mais acima na pirâmide, cada nível é representado pelo menor número de testes:
No topo da pirâmide, estão os testes na Interface de Usuário, em sua maioria E2E com o objetivo de imitar o comportamento do usuário final (seja este uma pessoa, um arquivo ou outro sistema em qualquer outro tipo de API).
Na camada do meio, temos os testes de integração, com o intuito de verificar se um conjunto de unidades se comporta da maneira esperada, porém com menor abrangência do que os testes E2E.
Na base, temos os testes de unidade, onde buscamos a menor unidade de código testável, para verificamos o seu funcionamento.
Porém em cada fatia da pirâmide temos várias opções de abordagem, como por exemplo quanto dos testes de UI devem ser automatizados e quantos devem ser Testes Exploratórios?
Robert C. Martin descreve visualmente o número de diferentes tipos de testes em seu livro, “The Clean Coder: A Code of Conduct for Professional Programmers”:
Neste momento talvez, você deva estar a se perguntar:
– Mas o que isso tem a ver com a qualidade do processo de desenvolvimento em nossos projetos?”
– E sobre nossa tendencia a polarização, onde tudo isso se encaixa?
Oras, avaliação e melhoria do fluxo não existem sem métricas e indicadores, ou KPIs (em inglês Key Performance Indicators). Um dos indicadores chave de desempenho no processo de desenvolvimento de software é a Eficácia de Teste que mede a Eficiência de Detecção de Falhas para as diversas etapas de Teste realizadas. Assim sendo é totalmente possível avaliarmos o número, escopo e abordagens dos nossos testes nos diferentes estágios da pirâmide.
Essa avaliação de eficácia pode ajudar em muito a esclarecer algumas das questões de performance dos investimentos em TI, por meio do alinhamento de recursos tecnológicos assegurando funcionalidade e eficiência dos processos (desde pipelines CI até workflows de GMUDs).
Vamos ilustrar com um cenário próximo do ideal com boa agilidade de escalonamento em um fluxo de integração contínua (CI) e implantação contínua (CD):
Em cada mudança se obtém um rápido feedback aos desenvolvedores, uma vez que sempre é testada em vários níveis, incluindo o ambiente de implantação, porém testar e corrigir melhora o PRODUTO não necessariamente o PROCESSO. Por melhor que o produto seja, não pode atrasar e ultrapassar o orçamento ou possuir um ROI negativo.
Os testes de qualidade para requisitos não funcionais também são automatizados, e o pipeline de CI / CD se esforça para automatizar todos os testes, enquanto alguns testes funcionais (exploratórios e usabilidade) continuam sendo realizados manualmente.
Um sonho, não?! Mas acredite, mesmo com todas as boas práticas, defeitos ocorrerão em Produção!
E se eu te disser que o “Projeto A”, removeu 130 bugs durante seu ciclo de desenvolvimento, porém ocorreram 5 bugs em produção! Desconsiderando as severidades, você me diria que isso é muito, ou pouco, bom ou ruim?
Uma das formas de responder essa questão é por meio do cálculo da Eficácia de Testes (EfT), já que bons testes resultam em uma EfT entre 93% a 96% (segundo nossa própria base histórica de indicadores de qualidade de +300 projetos).
Se no pipeline da figura anterior, o número de bugs encontrados nos Testes de DEV, QA, Aceite e Produção for, respectivamente, de 20, 100, 10 e 5, podemos calcular várias Eficácias de Teste:
- EfT testes DEV = (20)/(20+100+10+5) = 20/135 = 0,14 ou 14%
- EfT testes QA = (100)/(100+10+5) = 100/115 = 0,86 ou 86%
- Obs.: Para este cálculo retiramos as 20 falhas localizadas pelos testes unitários
- EfT testes Aceite = (10)/(10+5) = 10/15 = 0,66 ou 66%
- Obs.: Para este cálculo retiramos as 20 e 100 falhas localizadas pelos testes unitários e de sistema
- EfT global dos testes = (20+100+10)/(20+100+10+5) = 130/135 = 0,96 ou 96%
Isso significa que além da avalição do Processo de Qualidade do Trabalho como um todo, podemos medir a qualidade a cada etapa, e obtermos a direção do “que”, “onde” ou “quem” procurar para melhorar o processo. Abaixo alguns insights como exemplo:
- Baixa EfT nos testes de DEV – pode ser um sinal de necessidade de ajuste das tecnologias ou que os prazos de desenvolvimento não condizem com o capacity de produção do time;
- Baixa EfT nos testes de QA – geralmente envolvem o esforço de automatização, que pode estar com a cobertura incompleta não testando todas as condições relevantes (regras, caminhos etc.), “viciada” na massa de dados, ou até muito focada em UI negligenciando serviços e APIS;
- Baixa EfT nos testes de Homologação – pode ocorrer por falha na promoção do código entre ambientes, mas na maioria das vezes trata-se de requisitos ou estórias de usuário incompletos, inexistentes, ambíguos, irrelevantes e ou não testáveis. Afinal não adianta desenvolver o software certo em termos de código, se não agrega ou resolve os problemas do negócio;
Outra característica que preciso destacar é o custo das correções segundo a “Regra 10 de Myers”. Criada por Glenford Myers um dos pioneiros na área em testes de software, esta regra estabelece que o custo de correção de um Bug, é bem mais elevado quanto mais tarde (na linha do tempo de desenvolvimento) o defeito é encontrado.
Se adicionarmos ao nosso exemplo um custo de correção de R$150,00 por defeito, teríamos a seguinte projeção aproximada:
Percebam que que a baixa EfT nos testes de DEV, causam uma anomalia e um alto custo de correções em QA.
Mas se ajustarmos o processo, assim como recomendado na pirâmide de testes com o objetivo de obtermos uma EfT em DEV superior, teremos uma redução significativa nos custos de correção:
Em comparação com o projeto temos a mesma EfT de 96%, porém os custos com correções diminuíram de R$ 82.500,00 para 45.300,00, o que significa uma economia de R$ 36.000,00, ou seja, custos 43,64% menores!!!
Assim sendo, nossa representação gráfica ganha um formato que se assemelha um “funil”. A ideia aqui é criar uma metáfora visual, que nos faça refletir sobre a relação custo x eficácia dos nossos trabalhos.
Mas como encontrar a abordagem ideal para a sua realidade? Quanto será que você precisa melhorar… 5%, 60%, 99%, 99,99%? Evite cair em tentativas que sejam facilmente frustradas onde desistimos porque achamos que a meta é impossível. Retornemos ao exemplo da aviação civil, a qualidade é 99,999975% mas não é 100%!
Segundo um artigo chamado “Achieving Software Excellence” com benchmarks internacionais a Qualidade mundial de Software em 2016 variava entre um mínimo de cerca de 85% a um máximo de cerca de 99,65%. Nada mal, mas ainda longe da qualidade obtida pela aviação civil.
Não está contente com seu nível de qualidade?
Espero que este artigo ajude você a definir metas SMART – S (específicas), M (mensuráveis), A (atingíveis), R (relevantes) e T (oportuna) para a melhoria do seu processo de qualidade.
Obtenha grátis a planilha de análise da eficácia dos seus testes “Eficácia de Testes o Funil Ideal”.
Faça o download grátis aqui!
Lembre-se que você sempre pode contar conosco da TMI!
Nossa Consultoria iQPM-Intelligent Quality Process Management faz uma análise (das Forças, Oportunidades, Fraquezas e Ameaças) de todos os sete aspectos fundamentais de seu Processo de Qualidade atual: Cultura (incluído valores, políticas e crenças), Processo, Gestão, Indicadores, Expertise, Recursos e Tecnologia.
Saiba mais em https://tmintelligence.com.br/processmanagementiqpm
Fontes: https://www.poder360.com.br/internacional/mortes-em-acidentes-aereos-caem-pela-metade-em-2019-