Equívocos comuns de automação de teste

Neste artigo, examinaremos alguns dos equívocos mais comuns de automação de teste e como eles evitam que as organizações tenham sucesso na automação de teste.

Não é difícil imaginar os benefícios de ter testes automatizados junto com o desenvolvimento de produtos - lançamentos mais rápidos, maior cobertura de teste, execução de teste frequente, feedback mais rápido para a equipe de desenvolvimento, apenas para citar alguns, mas muitas organizações não fizeram a mudança ou estão resistente em investir em automação de testes.



Equívocos de automação de teste

Possivelmente, o aspecto mais difícil e desafiador de qualquer empreendimento de automação de teste é entender as limitações do teste automatizado e definir metas e expectativas realistas para evitar decepções. Com isso em mente, vamos ver alguns dos mal-entendidos e mitos mais comuns sobre a automação de teste:


O teste automatizado é melhor do que o teste manual

Referindo-se à postagem do blog de Michael Bolton Teste vs. Verificação , o teste automatizado não é realmente um teste. É a verificação dos fatos. Quando temos uma compreensão do sistema, podemos impor essa compreensão em formas de verificações e, em seguida, executando as verificações automatizadas, confirmamos nosso entendimento. O teste, por outro lado, é um exercício de investigação onde pretendemos obter novas informações sobre o sistema em teste através da exploração.

O teste exige que um ser humano faça um julgamento sensato sobre a usabilidade do sistema. Podemos detectar anomalias quando não estávamos antecipando. Não devemos ser tolerantes com um ou outro, pois os dois métodos são necessários para obter uma visão da qualidade do aplicativo.


Atingindo testes 100% automatizados

Assim como não há uma maneira prática de alcançar 100% de cobertura de teste (devido às infinitas permutações possíveis), o mesmo se aplica à automação de teste. Podemos aumentar a cobertura de teste executando testes automatizados com mais dados, mais configurações, cobrindo uma grande variedade de sistemas operacionais, navegadores, mas atingir 100% ainda é uma meta irreal. Quando se trata de testes automatizados, mais testes não significam necessariamente melhor qualidade ou melhor confiança. Tudo depende da qualidade do teste. Em vez de buscar cobertura total, concentre-se na área de funcionalidade mais importante, que é crucial para o negócio.

ROI rápido

Ao implementar uma solução de automação de teste, existem outras atividades de desenvolvimento inter-relacionadas além de apenas scripts de casos de teste. Normalmente, é necessário desenvolver uma estrutura que possa oferecer suporte a operações personalizadas que sejam úteis e significativas para o negócio, como seleção de casos de teste, relatórios, orientação por dados, etc.

O desenvolvimento do framework é um projeto por si só, requer desenvolvedores qualificados e leva tempo para ser construído. Mesmo quando uma estrutura totalmente funcional está em vigor, o script de verificações automatizadas inicialmente leva mais tempo do que executar o mesmo teste manualmente. Portanto, quando solicitamos feedback rápido sobre o novo recurso que acabou de ser desenvolvido, verificá-lo manualmente é geralmente mais rápido do que automatizar o teste. No entanto, o ROI é retornado no longo prazo, quando precisamos executar os mesmos testes em intervalos regulares.

Maior taxa de detecção de defeitos por meio de verificações automatizadas

Embora muitas das soluções de automação de teste fornecidas por fornecedores e caseiras sejam muito sofisticadas e altamente capazes de realizar operações complexas, elas nunca serão capazes de competir com a inteligência de um testador humano que pode detectar anomalias inesperadas no aplicativo enquanto explora ou executar um conjunto de testes de script no sistema em teste. Ironicamente, as pessoas esperam que o teste automatizado encontre muitos bugs devido ao suposto aumento da cobertura de teste, mas, na realidade, esse não é o caso.


É verdade que os testes automatizados são bons para detectar problemas de regressão - depois que um novo recurso foi adicionado à base de código existente, precisamos garantir que não quebramos a funcionalidade atual e precisamos dessas informações rapidamente - mas, o número de problemas de regressão, na maioria dos casos, tende a ser muito menor do que a nova funcionalidade que está sendo desenvolvida.

Outro ponto a ter em mente é que as verificações automáticas verificam apenas o que foram programadas para verificar pela pessoa que escreveu o script. Os scripts são tão bons quanto a pessoa que os escreveu. Todas as verificações automatizadas poderiam ser aprovadas, mas as principais falhas podem passar despercebidas, o que pode dar uma falsa impressão da qualidade do produto. Em essência, a verificação pode provar a existência de defeitos, mas não pode provar sua ausência.

Exigimos apenas a automação de teste de unidade

Portanto, se a probabilidade de encontrar defeitos é maior ao testar novos recursos, por que não estamos executando nossos testes automatizados na nova funcionalidade conforme ela está sendo desenvolvida? Bem, este é o caso de equipes que praticam TDD .

Os desenvolvedores escrevem um teste de unidade primeiro, observam-no falhar e, em seguida, escrevem código suficiente para obter a aprovação no teste de unidade e o ciclo é repetido até que a funcionalidade pretendida seja entregue. Em essência, esses testes de unidade automatizados verificam a nova funcionalidade e, com o tempo, formam o pacote de regressão da unidade, que é executado repetidamente conforme a nova funcionalidade é entregue.


Mas, há uma advertência para isso. Embora o TDD seja altamente encorajado e seja uma forte prática de desenvolvimento na construção de qualidade desde o início, os testes de unidade são bons apenas para encontrar erros do programador, não falhas. Existe um aspecto muito mais amplo do teste que ocorre quando todos os componentes são unidos e formam um sistema.

Na verdade, muitas organizações têm a maioria de suas verificações automatizadas na camada de IU do sistema. No entanto, o script de verificações automatizadas para a IU ou sistema, enquanto os recursos estão sendo desenvolvidos, é, na melhor das hipóteses, uma tarefa assustadora, pois a nova funcionalidade tende a ser volátil (sujeita a muitas mudanças) durante o desenvolvimento. Além disso, a funcionalidade esperada pode não ser conhecida até mais tarde, portanto, não é recomendável perder tempo automatizando uma funcionalidade em mudança.

Exigimos apenas a automação da IU do sistema

Existem valores na execução de verificações automatizadas na IU e no nível do sistema. Podemos ver o que o usuário experimenta ao interagir com o aplicativo; podemos testar fluxos ponta a ponta e 3rdintegração partidária quando não poderíamos testar de outra forma; também podemos demonstrar os testes para clientes e usuários finais para que eles possam ter uma ideia da cobertura do teste. No entanto, contar apenas com as verificações automatizadas na camada da interface do usuário tem seus próprios problemas.

A IU está mudando constantemente para aprimorar o design visual e a usabilidade, e a falha nas verificações automatizadas devido às mudanças na IU e não na funcionalidade pode dar uma falsa impressão do estado do aplicativo.


As verificações automatizadas da IU também são muito mais lentas na velocidade de execução do que na unidade ou camada de API e, por causa disso, o ciclo de feedback para a equipe é lento. Pode levar algumas horas até que um defeito seja detectado e relatado aos desenvolvedores. E quando algo dá errado, a análise da causa raiz demora mais porque não é facilmente aparente onde está o bug.

É importante compreender o contexto de cada teste e em qual camada o teste deve ser automatizado. A automação de teste deve fazer parte da atividade de desenvolvimento, portanto, toda a equipe é responsável pela automação de teste, com os desenvolvedores escrevendo a execução de testes de unidade, os Desenvolvedores de software em teste escrevendo a execução e mantendo os testes de aceitação na API e / ou UI.

Perdendo a fé e a confiança na automação de testes

Este último não é um mito sobre a automação de teste, mas um efeito colateral quando a automação de teste dá errado. Você passa muitas horas desenvolvendo uma solução de automação de teste perfeita, usando as melhores ferramentas e melhores práticas, mas se as verificações automatizadas não ajudarem a equipe, não adianta.

Se a equipe não tiver visibilidade ou conhecimento sobre o que é automatizado e em execução, eles lançam com medo do desconhecido ou duplicam seus esforços de teste de regressão. Se as verificações automáticas forem instáveis, lentas e fornecerem resultados intermitentes, isso pode confundir a equipe mais do que fornecer uma rede de segurança e um reforço de confiança.


Não tenha medo de remover verificações automatizadas que estão sempre falhando ou fornecem resultados inconsistentes. Em vez disso, busque um conjunto de testes limpo e confiável que possa fornecer indicações corretas sobre a integridade do aplicativo.



Conclusão

Automação de teste é um investimento de longo prazo. Levará tempo e experiência no desenvolvimento e manutenção de estruturas de automação de teste e scripts automatizados. A automação de teste não é um esforço único em que você entrega uma solução e a deixa funcionar. Necessita de monitoramento e atualização constantes.

Em vez de ter como objetivo substituir o controle de qualidade manual ou esperar que as verificações automatizadas encontrem muitos defeitos, devemos abraçar as vantagens que isso traz para a equipe, como liberar o tempo do controle de qualidade para mais testes exploratórios onde as chances de revelar defeitos são maximizadas, ou usar o sistema automatizado scripts para criar dados de teste que podem ser usados ​​para teste manual.

Compreender as limitações e definir expectativas realistas é importante para superar esses mitos de automação de teste.