Quais são as desvantagens do teste automatizado?

Existem várias perguntas neste site que fornecem muitas informações sobre os benefícios que podem ser obtidos com os testes automatizados. Mas não vi nada que representasse o outro lado da moeda: quais são as desvantagens? Tudo na vida é uma troca e não há balas de prata; portanto, certamente deve haver algumas razões válidas para não fazer testes automatizados. O que eles são?

Aqui estão algumas que eu inventei:

• Requer mais tempo inicial do desenvolvedor para um determinado recurso
• Requer um nível de habilidade mais alto dos membros da equipe
• Aumentar as necessidades de ferramentas (test runners, frameworks, etc.)
• É necessária uma análise complexa quando um teste falha é obsoleto devido à minha alteração ou está me dizendo que cometi um erro?

Editar
Devo dizer que sou um grande defensor dos testes automatizados e não estou convencido de fazê-lo. Estou procurando entender quais são as desvantagens, quando vou à minha empresa defender isso, não pareço jogar a próxima bala de prata imaginária.

Além disso, estou explicitamente não procurando alguém para disputar meus exemplos acima. Estou convencido de que deve haver algumas desvantagens (tudo tem vantagens e desvantagens) e quero entender quais são elas.

Você praticamente acertou os mais importantes. Tenho algumas pequenas adições, além da desvantagem de testes realmente bem-sucedidos - quando você realmente não deseja que eles façam (veja abaixo).

• Tempo de desenvolvimento: com o desenvolvimento orientado a testes, isso já é calculado para testes de unidade, mas você ainda precisa de testes de integração e de sistema, que também podem precisar de código de automação. O código escrito uma vez é geralmente testado em vários estágios posteriores.

• Nível de habilidade: é claro, as ferramentas precisam ser suportadas. Mas não é apenas sua própria equipe. Em um projeto maior, você pode ter uma equipe de teste separada que escreve testes para verificar as interfaces entre o produto da sua equipe e as de outras pessoas. Muitas pessoas precisam ter mais conhecimento.

• Necessidades de ferramentas: você está lá. Não há muito a acrescentar a isso.

• Testes com falha: Este é o verdadeiro bugger (para mim de qualquer maneira). Há várias razões diferentes, cada uma das quais pode ser vista como uma desvantagem. E a maior desvantagem é o tempo necessário para decidir qual desses motivos realmente se aplica ao seu teste reprovado.

  • falhou devido a um erro real. (apenas para completar, pois isso é obviamente vantajoso)
  • falhou, porque seu código de teste foi gravado com um bug tradicional.
  • falhou, porque seu código de teste foi gravado para uma versão mais antiga do seu produto e não é mais compatível
  • falhou, porque os requisitos foram alterados e o comportamento testado agora é considerado 'correto'

• Testes sem falhas: também são uma desvantagem e podem ser bastante ruins. Isso acontece principalmente quando você muda as coisas e se aproxima do que Adam respondeu. Se você alterar algo no código do seu produto, mas o teste não for responsável por isso, ele fornecerá essa "falsa sensação de segurança".

  Um aspecto importante dos testes sem falhas é que uma mudança de requisitos pode levar o comportamento anterior a se tornar inválido. Se você tiver uma rastreabilidade decente, a alteração do requisito deverá corresponder ao seu código de teste e você sabe que não pode mais confiar nesse teste. Obviamente, manter essa rastreabilidade é mais uma desvantagem. E se não o fizer, você acaba com um teste que não falha, mas na verdade verifica se o seu produto funciona incorretamente . Em algum lugar no futuro, isso o atingirá ... geralmente quando / onde você menos espera.

• Custos adicionais de implantação: você não executa apenas testes de unidade como desenvolvedor em sua própria máquina. Com testes automatizados, você deseja executá-los em confirmações de outras pessoas em algum local central para descobrir quando alguém interrompeu seu trabalho. Isso é bom, mas também precisa ser configurado e mantido.

Depois de começar a tentar testes automatizados em nossa equipe, a maior desvantagem que vi é que é muito difícil aplicar um código legado que não foi projetado com o teste automatizado em mente. Sem dúvida, isso melhoraria nosso código a longo prazo, mas o nível de refatoração necessário para testes automatizados, mantendo nossa sanidade, é uma barreira muito alta para entrada no curto prazo, o que significa que teremos de ser muito seletivo quanto à introdução de automação automatizada. testes de unidade para cumprir nossos compromissos de curto prazo. Em outras palavras, é muito mais difícil pagar os cartões de crédito quando você já está com dívidas técnicas.

Talvez a desvantagem mais importante seja ... testes são códigos de produção . Todo teste que você escreve adiciona código à sua base de código que precisa ser mantida e suportada. Não fazer isso leva a testes nos quais você não acredita nos resultados, então você não tem outra escolha. Não me interpretem mal - sou um grande defensor dos testes automatizados. Mas tudo tem um custo, e este é um grande problema.

Eu não diria que essas são desvantagens inteiramente aplicáveis, mas as poucas que eu mais acertei são:

• Tempo gasto para configurar o teste em um aplicativo corporativo complexo.
• Manipulando testes antigos que falham incorretamente, em outras palavras, o sistema evoluiu e agora os testes estão errados.
• Falsa confiança da cobertura do teste irregular ou desconhecida.

A cobertura de teste irregular pode levar a uma falsa sensação de segurança. Se você faz um refator e usa os testes para provar sua validade, o que provou que seus testes são capazes de provar isso?

Às vezes, o tempo que leva para criar o teste é um problema para nós. Nosso teste automatizado não inclui apenas testes de unidade, mas também usa testes de caso. Estes tendem a ser mais amplos e requerem contexto.

Obviamente, minha perspectiva é de um aplicativo mais antigo que seus testes de unidade.

Eu diria que o principal problema com eles é que eles podem fornecer uma falsa sensação de segurança . Só porque você tem testes de unidade, isso não significa que eles estejam realmente fazendo alguma coisa e isso inclui o teste adequado dos requisitos.

Além disso, os testes automatizados também podem incluir bugs , o que coloca a questão de saber se os testes de unidade precisam ser testados, para que não sejam necessariamente alcançados.

Embora o teste de automação tenha muitas vantagens, ele também tem suas próprias desvantagens. Algumas das desvantagens são:

• É necessário ter proficiência para escrever os scripts de teste de automação.
• A depuração do script de teste é o principal problema. Se algum erro estiver presente no script de teste, às vezes poderá levar a consequências mortais.
• A manutenção do teste é cara no caso de métodos de reprodução. Mesmo que ocorra uma pequena alteração na GUI, o script de teste deve ser gravado ou substituído por um novo script de teste.
• A manutenção dos arquivos de dados de teste é difícil, se o script de teste testar mais telas.

Algumas das desvantagens acima costumam subtrair os benefícios obtidos com os scripts automatizados. Embora o teste de automação possua profissionais e especialistas, ele é amplamente adaptado em todo o mundo.

Recentemente, fiz uma pergunta sobre testes no desenvolvimento de jogos - é assim que eu sabia sobre esse. As respostas apontaram algumas desvantagens curiosas e específicas:

1. É caro fazer isso quando seu código deve ser altamente acoplado .
2. É difícil fazer isso quando você precisa conhecer as várias plataformas de hardware, quando você deve analisar a saída para o usuário e o resultado do código só faz sentido em um contexto mais amplo .
3. Teste de interface do usuário e UX é muito difícil .
4. E, notavelmente, os testes automatizados podem ser mais caros e menos eficazes do que vários testadores beta de baixo custo (ou gratuitos) .

O quarto ponto me faz lembrar de alguma experiência minha. Trabalhei em uma empresa gerenciada pelo Scrum, enxuta e orientada para XP, onde os testes de unidade eram altamente recomendados. No entanto, em seu caminho para um estilo mais enxuto e menos burocrático, a empresa negligenciou a construção de uma equipe de controle de qualidade - não tínhamos testadores. Com tanta frequência, os clientes encontraram bugs triviais usando alguns sistemas, mesmo com cobertura de teste> 95%. Então, eu acrescentaria outro ponto:

• Testes automatizados podem fazer você sentir que o controle de qualidade e o teste não são importantes.

Além disso, eu estava pensando naqueles dias sobre documentação e cogitei uma hipótese que pode ser válida (em menor grau) para os testes dois. Eu apenas senti que o código evolui tão rapidamente que é muito difícil criar uma documentação que siga essa velocidade, por isso é mais valioso gastar tempo tornando o código legível do que escrever uma documentação pesada e facilmente desatualizada. (Obviamente, isso não se aplica às APIs, mas apenas à implementação interna.) O teste sofre um pouco com o mesmo problema: pode ser muito lento para escrever quando comparado com o código testado. OTOH, é um problema menor porque os testes avisam que estão desatualizados, enquanto sua documentação permanecerá silenciosa enquanto você não a reler com muito, muito cuidado .

Finalmente, um problema que às vezes encontro: o teste automatizado pode depender de ferramentas, e essas ferramentas podem ser mal escritas. Comecei um projeto usando o XUL há algum tempo e, cara, isso é doloroso para escrever testes de unidade para essa plataforma. Iniciei outro aplicativo usando Objective-C, Cocoa e Xcode 3 e o modelo de teste nele era basicamente um monte de soluções alternativas.

Tenho outras experiências sobre as desvantagens do teste automatizado, mas a maioria delas está listada em outras respostas. No entanto, sou um defensor veemente dos testes automatizados. Isso economizou muito trabalho e dor de cabeça e eu sempre o recomendo por padrão. Eu acho que essas desvantagens são apenas meros detalhes quando comparados aos benefícios dos testes automatizados. (É importante sempre proclamar sua fé depois de comentar as heresias para evitar o auto da fé.)

Dois que não são mencionados são:

• Duração do relógio que pode demorar para executar um grande conjunto de testes

Participei dos esforços automatizados de controle de qualidade em que demorou meio dia para executar os testes, porque os testes eram lentos. Se você não for cuidadoso ao escrever seus testes, seu conjunto de testes também poderá ser assim. Isso não parece grande coisa até você gerenciar agora, "Ah, acabei de cometer uma correção, mas vai demorar 4 horas para provar a correção".

• Fragilidade de alguns métodos de escrita de teste

Alguns métodos de teste (como automatizar a interface do usuário) parecem quebrar sempre que você se vira. Especialmente doloroso se o seu script, por exemplo, interromper o processo de teste porque está aguardando a exibição de um botão - mas o botão foi renomeado.

Você pode contornar essas duas coisas, com boas práticas de teste: encontre maneiras de manter seu conjunto de testes rápido (mesmo se você tiver que fazer truques como distribuir testes em máquinas / CPUs). Da mesma forma, alguns cuidados podem ser tomados para tentar evitar métodos frágeis de escrever testes.

Quero acrescentar mais uma, uma falsa sensação de segurança.

Além de conjuntos de problemas bem pequenos e bem definidos, não é possível criar testes abrangentes. Pode e sempre haverá erros em nosso software que os testes automatizados simplesmente não testam. Quando os testes automatizados passam, com muita frequência assumimos que não há bugs no código.

É difícil convencer o gestor / capitalista de risco

• a automação automatizada aumenta o custo inicial.
• a automação de processos aumenta o tempo de colocação no mercado.
• o benefício da automação automatizada ocorre a médio e longo prazo. a concorrência feroz se concentra mais nos benefícios de curto prazo.

consulte Teste de unidade orientado ao mercado para obter detalhes.

Uma das principais desvantagens pode ser superada usando testes de autoaprendizagem. Nesta situação, os resultados esperados são todos armazenados como dados e atualizáveis ​​com revisão mínima pelo usuário do conjunto de testes no modo de autoaprendizagem (a exibição difere entre o resultado esperado antigo e o novo resultado real - atualização esperada se pressionar y). Esse modo de aprendizado de teste precisa ser usado com cautela, para que o comportamento do buggy não seja considerado aceitável.