Estamos gastando mais tempo implementando testes funcionais do que implementando o próprio sistema, isso é normal?

Basicamente, temos três projetos principais, dois deles são serviços web e o outro é um aplicativo web. Embora eu esteja satisfeito em cobrir o máximo possível de nossos serviços da Web com testes funcionais (todos os três projetos têm seus testes de unidade adequados), os testes funcionais para o aplicativo da Web estão demorando muito tempo para serem implementados. Por muito, quero dizer duas vezes, ou às vezes mais, o tempo necessário para implementar a funcionalidade que está sendo testada com o teste de unidade incluído.

A política do gerente é testar todas as funcionalidades adicionadas, mesmo que não sejam críticas para os negócios (por exemplo, um novo CRUD).

Concordo em testar todas as funcionalidades dos serviços da Web, porque é difícil testá-las manualmente e, também, esses testes são rápidos e não demoram muito para serem implementados.

Então, qual é o valor de gastar mais tempo escrevendo testes funcionais do que escrever código do sistema, teste unitário e corrigir os controles de controle de qualidade? Isso é normal? Não deveríamos escrever testes funcionais apenas para funcionalidades críticas e permitir que o controle de qualidade faça testes de regressão sobre nenhuma funcionalidade crítica?

Nota: não estamos desenvolvendo software médico ou da NASA ou nada tão crítico.

Testes funcionais são muito importantes. Sim, eles levam tempo para escrever, mas se você estiver escrevendo os testes funcionais certos, eles valerão a pena.

Existem algumas boas razões para fazer testes funcionais automatizados em um aplicativo.

• Quando um novo recurso é adicionado ao seu site, você saberá imediatamente se as alterações feitas nesse novo recurso quebram qualquer outra funcionalidade no seu site.
• Está documentado o conhecimento de como o aplicativo é executado e trabalha em conjunto para atingir os requisitos de negócios.
• Quando chegar a hora de atualizar uma biblioteca de terceiros, você pode atualizá-la e executar seu conjunto de testes funcionais para ver se algo quebra. Em vez de ter que passar por todas as páginas, você pode fazer com que um computador faça isso por você e fornecer uma lista de todos os testes que foram interrompidos.
• Teste de carga! Você pode simular milhares de usuários simultâneos, todos acessando o site de uma só vez, e pode ver onde o site diminui e diminui a pressão. Você pode ver como o seu site se comporta muito antes de receber uma ligação tarde da noite informando que o site travou.
• O teste funcional leva tempo para ser feito manualmente. Sim, leva muito tempo para escrever os casos, mas se você tivesse que sentar com um fichário com 500 páginas de testes que precisava concluir antes de poder enviar o produto, desejaria ter os testes automatizados!
• Os documentos de teste ficam desatualizados rapidamente. Quando um novo recurso é adicionado, é necessário atualizar o documento de teste mestre. Se alguém pular alguns testes, de repente, os bugs aparecem nas páginas "concluídas e testadas". Atualmente, trabalho em um ambiente como esse, e posso garantir que é um pesadelo.

No final, sim, leva tempo para escrever esses casos, mas você deve se orgulhar de escrevê-los. É a sua maneira de provar, sem sombra de dúvida, que seu código funciona e funciona com todos os outros recursos existentes. Quando o controle de qualidade chega a você e diz que há um erro, você o corrige e o adiciona ao seu conjunto de testes para mostrar que está corrigido e garantir que isso nunca aconteça novamente.

É a sua rede de segurança. Quando alguém invade um processo armazenado e faz uma pequena alteração para que funcione com seu código, você perceberá que ele quebrou outros três recursos no processo. Você vai pegá-lo naquela noite e não na noite anterior ao prazo!

Quanto a escrever testes funcionais apenas para funções críticas do sistema. Isso não fornecerá uma imagem completa e permitirá que os bugs se infiltrem. Basta que seja adicionado um pequeno recurso que não é crítico para o sistema, mas interage indiretamente com uma função crítica do sistema e você tem o potencial de introduzir um bug.

Mais de duas vezes ... me parece um pouco demais. Você pode analisar os motivos para isso, eles podem incluir:

• mau suporte de ferramenta para criação e manutenção dos testes

• contratos dos serviços da web não é suficientemente descrito no design. Os desenvolvedores precisam elaborar os contratos durante o teste, o que geralmente é um processo de alinhamento demorado.

Converse com seus desenvolvedores.

Supondo que você esteja desenvolvendo sprints, tendo esses testes funcionais se apenas parte do sprint. Isso não é feito sem esses testes. Se você não o tiver, seu tempo para testes de integração após a fase de desenvolvimento poderá dobrar.

Passar mais tempo implementando testes funcionais do que a implementação do próprio sistema é normal?

Absolutamente. Escrever testes realmente bons provavelmente levará a maior parte do tempo em muitas (boas) lojas.
Portanto, uma proporção de 2-1 é boa. Os desenvolvedores menos experientes costumam não levar o tempo todo para os testes.

Existe a lei dos retornos decrescentes. Supondo que você escreva testes para o código mais arriscado primeiro, o valor gerado por outros testes diminui com o tempo.

Os testes de unidade são código, portanto, eles contêm bugs (assim como todos os outros códigos). Corrigir esses bugs leva tempo.

Na minha experiência, os testes de unidade contêm muito mais erros do que o sistema que estão testando, e corrigi-los é um fardo contínuo.

Isso é sobre qualidade.

Se você precisar obter o mercado - desenvolverá seu aplicativo o mais rápido possível. Você pode até não ter testes automáticos =), mas você entregará seu aplicativo ao seu auditivo antes de seus concorrentes.

Mas se você souber que seu auditório não irá embora, fará qualquer coisa para não decepcioná-lo. Todo bilhete de bug derrubará sua reputação. Imagine que um bug remova 50% de sua reputação, o próximo - outros 25% e mais um. Então, pode haver muitos testes?

Se por "é normal" você pergunta se é comum, não, certamente não é. Muitas equipes de desenvolvedores têm práticas de teste ruins (eu pertenço a uma) e até livros de qualidade que li conselhos para gastar quase tanto tempo codificando a funcionalidade quanto os testes. Se, normalmente, você pergunta se é saudável, isso depende, mas duas vezes mais testes do que o necessário são melhores do que nenhum teste.

Não precisa ser crítico . Ao testar uma funcionalidade, você testa algo útil para os usuários finais e é sua responsabilidade saber (e não adivinhar) que está sempre funcionando corretamente. Se você precisar duas vezes mais para esse objetivo, deve ser feito dessa maneira - se possível.

Também é possível que sua política seja muito rígida quanto a testes automatizados, mas é difícil saber sem saber a qualidade que eles desejam, seus recursos e o que mais eles poderiam alocá-la.