Quais são as desvantagens do teste automatizado?

48

Há 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, então certamente deve haver algumas razões válidas para não fazer testes automatizados. O que são eles?

Aqui estão alguns que eu criei:

  • 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.)
  • Análise complexa necessária quando um teste com falha é encontrado - este teste está 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 querendo ser convencido a fazê-lo. Eu estou olhando para entender quais são as desvantagens, então quando eu vou para a minha empresa para defender isso, eu não pareço estar jogando a próxima bala de prata imaginária.

Além disso, estou explicitamente não procurando alguém para contestar meus exemplos acima. Eu estou tomando como verdade que há deve ser algumas desvantagens (tudo tem trade-offs) e eu quero entender o que elas são.

    
por RationalGeek 27.10.2011 / 14:56
fonte

11 respostas

26

Você praticamente cravou os mais importantes. Eu tenho algumas adições menores, além da desvantagem de testes realmente sucedidos - quando você realmente não quer (veja abaixo).

  • Tempo de desenvolvimento: Com o desenvolvimento orientado a testes, isso já é calculado em 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 é só o seu próprio time. Em um projeto maior, você pode ter uma equipe de testes separada que escreve testes para verificar as interfaces entre o produto de sua equipe e o de outras. Então, muito mais pessoas precisam ter mais conhecimento.

  • Necessidades de ferramentas: você está no lugar certo. Não há muito a acrescentar a isto.

  • Testes falhados: 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 quais dessas razões realmente se aplicam ao seu teste com falha.

    • falhou devido a um erro real. (apenas por completude, pois isso é naturalmente vantajoso)
    • falhou porque seu código de teste foi escrito com um bug tradicional.
    • falhou, porque seu código de teste foi escrito 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 chega perto do que Adam respondeu. Se você alterar alguma coisa no código do seu produto, mas o teste não der conta de nada, isso dará a você essa "falsa sensação de segurança".

    Um aspecto importante dos testes sem falhas é que uma alteração de requisitos pode levar o comportamento anterior a se tornar inválido. Se você tiver rastreabilidade decente, a alteração do requisito deve ser compatível com seu código de teste e você sabe que não pode mais confiar nesse teste. É claro que manter essa rastreabilidade é outra desvantagem. E se você não fizer isso, você acaba com um teste que não falha, mas na verdade verifica se o seu produto funciona erroneamente . Em algum lugar na estrada isso vai te atingir .. geralmente quando / onde você menos espera.

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

por 27.10.2011 / 15:15
fonte
28

Tendo começado a testar testes automatizados em nossa equipe, a maior desvantagem que já vi é que é muito difícil se inscrever em códigos herdados que não foram projetados com testes automatizados em mente. Sem dúvida, 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 a entrada no curto prazo, o que significa que teremos que ser muito seletivos na introdução automatizada testes unitários 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.

    
por 27.10.2011 / 16:38
fonte
20

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

    
por 27.10.2011 / 21:10
fonte
15

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

  • Tempo necessário para configurar o teste em um aplicativo corporativo complexo.
  • Lidando com testes antigos que falham incorretamente, em outras palavras, o sistema evoluiu e agora os testes estão errados.
  • Falsa confiança de cobertura de teste incompleta ou desconhecida.

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

O tempo que leva para criar o teste às vezes é 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 exigem contexto.

É claro, minha perspectiva é de um aplicativo mais antigo que os testes de unidade.

    
por 27.10.2011 / 15:05
fonte
9

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 fazer qualquer coisa e isso inclui testar adequadamente os requisitos.

Além disso, os testes automatizados também podem incluir os próprios erros , o que leva a questão a se os testes de unidade precisam ser testados por si mesmos , portanto, não necessariamente alcançando nada.

    
por 28.10.2011 / 16:22
fonte
4

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

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

Algumas das desvantagens acima geralmente subtraem o benefício obtido com os scripts automatizados. Embora o teste de automação tenha vantagens e benefícios, ele é amplamente adaptado em todo o mundo.

    
por 28.10.2011 / 08:16
fonte
3

Recentemente, perguntei a uma pergunta sobre testes no desenvolvimento de jogos - esta é BTW como eu sabia sobre isso. As respostas apontaram algumas desvantagens curiosas e específicas:

  1. É caro quando o seu código deve ser altamente acoplado .
  2. É difícil fazer isso quando você precisa estar ciente das várias plataformas de hardware, quando deve analisar a saída para o usuário e o código resultado só faz sentido em um contexto mais amplo .
  3. O teste da interface do usuário e da experiência do usuário é muito difícil .
  4. E, notavelmente, os testes automatizados podem ser mais caros e menos eficazes do que um grupo de 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, muito enxuta e orientada ao 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 simplesmente negligenciou a construção de uma equipe de QA - não tínhamos testadores. Com tanta frequência, os clientes encontraram bugs triviais usando alguns sistemas, mesmo com uma cobertura de teste de > 95%. Então eu adicionaria outro ponto:

  • Testes automatizados podem fazer com que você sinta que o controle de qualidade e os testes 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 escala) para os testes dois. Achei 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 escrevendo uma documentação pesada e facilmente desatualizada. (Claro, isso não se aplica para APIs, mas apenas para implementação interna.) O teste sofre um pouco do mesmo problema: pode ser muito lento para gravar quando comparado com o código testado. OTOH, é um problema menor porque os testes avisam que estão desatualizados, enquanto a sua documentação permanecerá em silêncio enquanto você não reler muito

Finalmente, um problema que encontro às vezes: testes automatizados podem depender de ferramentas, e essas ferramentas podem estar mal escritas. Eu comecei um projeto usando o XUL há algum tempo e, cara, isso é doloroso para escrever testes de unidade para essa plataforma. Eu 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 do teste automatizado. Isso economizou muito trabalho e dor de cabeça e eu sempre recomendo isso por padrão. Eu julgo que essas desvantagens são apenas meros detalhes quando comparadas aos benefícios do teste automatizado. (É importante sempre proclamar sua fé depois de comentar heresias para evitar o auto da fé.)

    
por 22.12.2011 / 14:18
fonte
2

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

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

Fiz parte de esforços de QA automatizados, nos quais demorei meio dia para executar os testes, porque os testes eram lentos. Se você não for cuidadoso ao escrever seus testes, sua suíte de testes também poderá sair dessa maneira. Isso não soa como um grande negócio até que você esteja administrando esse momento, "Oh, acabei de dar um conserto, mas levarei 4 horas para provar a correção".

  • Fragilidade de alguns métodos de escrita de teste

Alguns métodos de teste (como a automação da interface do usuário) parecem quebrar sempre que você se virar. Especialmente doloroso se o seu script, por exemplo, trava o processo de teste porque está esperando que apareça um botão - mas o botão foi renomeado.

Essas são duas coisas que você pode resolver, 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 execuções de teste em máquinas / CPUs). Da mesma forma, alguns cuidados podem ser tomados para tentar evitar métodos frágeis de escrever testes.

    
por 22.12.2011 / 20:08
fonte
2

Eu quero adicionar mais uma falsa sensação de segurança.

Além de conjuntos de problemas muito pequenos e bem definidos, não é possível criar testes abrangentes. Pode haver e frequentemente ainda haverá bugs no nosso software que os testes automatizados simplesmente não testam. Quando os testes automatizados passam, muitas vezes assumimos que não há erros no código.

    
por 22.12.2011 / 15:37
fonte
0

É difícil convencer o gestor / capitalista de risco

  • testautomation aumenta o custo inicial.
  • testautomation aumenta o tempo de lançamento no mercado.
  • o benefício do testautomation vem no meio e no logterm. concorrência acirrada se concentra mais em benefícios de curto prazo.

veja Teste de unidade impulsionada pelo mercado para obter detalhes.

    
por 06.04.2012 / 19:27
fonte
-1

Uma das principais desvantagens pode ser superada usando testes de auto-aprendizagem. Nessa 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 (mostra diferenças entre o resultado esperado antigo e o novo resultado real - atualização esperada se pressionar y). Esse modo de aprendizado de testes precisa ser usado com cautela, portanto, o comportamento de bugs não é aprendido como sendo aceitável.

    
por 03.03.2013 / 16:53
fonte