Os testes de ponta a ponta e de integração valem a pena para coisas não essenciais à missão?

É sabido que os testes de ponta a ponta e de integração são caros. Obviamente, se desenvolvermos aplicativos onde as pessoas podem morrer se as coisas derem errado, é um investimento que vale a pena. No entanto, em aplicativos em que os erros não são o fim do mundo, não seria mais barato pular os testes E2E e os testes de integração por completo e criar um plano de backup se algo der errado? Como é um teste manual de histórias de usuários + testes de unidade + usando uma linguagem de tipo estaticamente suficiente?

Por exemplo, se uma loja da Web perdesse um pedido, eles poderiam enviar o item gratuitamente + outro item como um pedido de desculpas. O usuário final pode ficar ainda mais feliz dessa maneira e a empresa economiza dinheiro em geral.

Acho que minha pergunta é: em geral, quanto custa um teste de integração e um teste E2E e quanto economiza? Existe uma maneira de fazer um cálculo de risco / custo para isso?

Não importa se você implementa o E2E e os testes de integração ou não, você precisa de um plano de backup de qualquer maneira . Nunca espere que um sistema esteja livre de erros apenas porque foi testado.

Portanto, em sua estimativa de custo, você não compara o custo da implementação dos testes E2E com os custos que o seu plano de backup estima em caso de falha, você compara:

• Custos para a realização de testes E2E manualmente (várias vezes, antes de cada nova versão)

vs.

• Custos de construção (e manutenção) de testes E2E automatizados

Caso você possa usar esses testes E2E várias vezes, geralmente haverá várias execuções de teste em que os custos atingem um ponto de equilíbrio. Essa deve ser a métrica que você aplica quando deseja planejar com antecedência quais testes E2E você fará manualmente e que você automatizará.

Observe que pode haver alguns tipos de testes E2E que podem ser implementados facilmente, onde o ROI é imediatamente claro, mas também existem tipos de testes E2E nos quais o desenvolvimento e a manutenção podem ser mais caros do que fazê-los manualmente por um período de vários anos.

Talvez contra-intuitivamente, os testes automatizados possam realmente reduzir o tempo de desenvolvimento versus nenhum teste. Portanto, é uma vitória vencedora.

A ideia é que os testes contribuam em vários níveis

1. Forçar a coleta e especificação rigorosas de requisitos

   Isso causa um enorme impacto na velocidade do desenvolvimento. Sem volta pedindo mais detalhes, sem mal-entendidos, sem recursos desnecessários etc.

2. Os desenvolvedores sabem quando um recurso está completo

   A maioria dos testes é feita por desenvolvedores durante a gravação do código, em vez de testadores verificando um produto acabado. A automação desse teste reduz essa carga de trabalho

3. Erros introduzidos por novos recursos detectados instantaneamente.

   Isso pode facilmente custar um sprint e exigir a reescrita de um recurso inteiro se eles não forem detectados.

4. Ciclo de liberação mais rápida

   Isso significa menos código em andamento, o que significa menos mesclagem, o que significa menos trabalho e menos complexidade para os desenvolvedores

Especialmente se você tiver uma configuração de estrutura de teste, escrever esses testes leva menos tempo do que você economiza nessas eficiências.

Além disso, você economiza tempo de teste manual, além de obter um produto melhor no final.

Minha resposta? Talvez não .

Os testes EOE são bons quando são muito simples. Se você estiver planejando cobrir cenários básicos, poderá obter alguma vantagem com os testes EOE. Mas se você tiver um aplicativo realmente complexo e grande (de missão crítica ou não), esses testes de EOE serão caros de manter e você precisará conhecer seu cenário para avaliar se vale a pena.

Há alguns anos, o Blog de testes do Google discute esse assunto. Só posso concordar com o autor. Um bom teste precisa ser rápido , confiável e isolar falhas , recursos que os testes EOE não são capazes de fornecer a você.

Eu trabalhei em um aplicativo que possui mais de 12 horas de testes de ponta a ponta, cobrindo muitos cenários. Eventualmente, conseguimos distribuir esses testes em diferentes máquinas, controlando o início, a execução e o final dos testes, coletando e mesclando os resultados. O aplicativo testado era um aplicativo monolítico (o que é mais fácil de instalar e executar para testar) e era um pesadelo para manter os testes.

Na maior parte do tempo, mantivemos os testes em vez de capturar bugs de seus resultados. Descobrir a origem de um bug em um teste de ponta a ponta leva muito tempo. Também lidamos com muitos testes "falso-negativos" e pouco tempo para entender o problema e corrigi-lo: problemas de carregamento do Java Applet, elemento esperado não encontrado na página (além de outros problemas sobre a velocidade de automação), mantêm o código de consulta que são usados ​​apenas no teste de memória do banco de dados (porque a consulta original usa código específico do banco de dados) etc.

Tudo isso precisa de pessoas para manter o funcionamento. No final, começamos a excluir alguns testes EOE e substituí-los por muitos testes de unidade / integração.

Portanto, meu conselho conservador é usar a pirâmide de testes do Google:

Como um bom primeiro palpite, o Google geralmente sugere uma divisão 70/20/10: 70% de testes unitários, 20% de testes de integração e 10% de ponta a ponta. A combinação exata será diferente para cada equipe, mas, em geral, deve manter a forma da pirâmide.

Na minha experiência, o teste E2E, independentemente da criticidade do aplicativo, é sempre prudente. Eu sempre penso no pior cenário, se as coisas derem errado, você se sente à vontade diante da gerência e justificando sua abordagem? Caso contrário, você precisará alterar sua abordagem. Muitas organizações minimizam a importância e os recursos alocados para o teste, mas tenha certeza de que, quando as coisas dão errado, todo mundo está procurando alguém para culpar e, se você tomou a decisão de limitar o teste ou deu esse conselho, é você quem está se despedindo linha.

Muitas vezes, o desenvolvimento de software requer um olho na política organizacional.

"É sabido que os testes de ponta a ponta e de integração são caros".

Eu acho que não concordo com essa afirmação.

Em primeiro lugar, os testes E2E são o que importa para os usuários finais e podem ser as opções mais econômicas / de menor custo para testar sistemas complexos. Por exemplo, quando alguém compra um carro, a maioria das pessoas não o retira e começa a testar o carb, a caixa de câmbio e as rodas isoladamente. Em vez disso, eles o levam para um test drive.

Em segundo lugar, em termos de ferramentas, o E2E não tende a desacelerar a evolução interna do produto e dura mais tempo. Se você pensar bem, a superfície funcional real da maioria dos produtos raramente muda tanto, enquanto internamente pode estar sujeita a todos os tipos de desenvolvimentos. Como resultado, uma vez que o ferramental de teste está em funcionamento, geralmente dura muito bem. Como exemplo, se voltarmos à analogia do carro. O mesmo caso de teste "leve para um passeio" funcionaria muito bem no Ford Modelo T e em um Tesla. Como seriam os investimentos em estradas rolantes, túneis de vento, configurações de testes de vazamento etc. Quantos dos testes de componentes internos teriam um ROI tão bom ao longo de sua vida útil?

Onde o teste do E2E tende a ser mais caro / inadequado, porém, está na configuração inicial e se é usado para tentar testar tudo. Pragmaticamente, acho que a melhor maneira de evitar essa armadilha é priorizar as automações dos testes de coisas que:

1. São fáceis de automatizar e dificilmente precisam de muita manutenção para continuar funcionando.
2. Consuma mais tempo para aplicar processos de teste manuais consistentes, adequados e adequados.
3. Risco de fazer você ou seu chefe parecerem idiotas se o produto for lançado com ele quebrado.

Use qualquer forma de teste, incluindo o E2E, que julgue apropriado. Concentre-se naqueles embora.

Você não pode realmente comparar o custo dos testes de integração com o custo de um cenário de melhor caso em que um bug afeta apenas uma única ordem. Um erro lógico teria a mesma probabilidade de afetar um grande número de pedidos. Digamos que um bug significa que nenhum pagamento é capturado - isso pode ter efeitos desastrosos para qualquer empresa.

Você deve perguntar qual é o pior bug que, realisticamente, pode acabar em produção devido à falta de testes E2E. E lembre-se da lei de Murphys.

Suponho que esta pergunta seja sobre aplicativos da web corporativos.

Minha recomendação para coisas médicas críticas:

• Execute testes automatizados para suas APIs de back-end, certificando-se de que o back-end funcione conforme o esperado. Esses testes devem ser escritos pelos desenvolvedores durante a implementação de uma API.
• Não se importe com testes de interface do usuário automatizados, ou seja, faça o teste de front-end manualmente.

Eu acho que a maioria dos testes deve estar no nível da API ou no componente. Não me importo com testes de unidade que executam apenas algumas funções internas.