Automação de Testes

Testes Manuais

Os desenvolvedores ágeis enfatizam a importância dos testes automatizados. Com ciclos curtos, o teste de regressão manual é quase impossível. Isso significa que não há nenhum teste manual? Não. Alguns testes manuais ainda são recomendados, embora tais testes diferem dos testes manuais tradicionais baseados em roteiros.

Automatize seus testes manuais

Os grupos de produtos geralmente afirmam que “é impossível automatizar testes relacionados a uma conexão de rede perdida” ou “Você não pode automatizar testes relacionados a falhas de hardware”. Nossa resposta geralmente é “Não, não é” ou “Sim, você pode”.

Elisabeth Hendrickson, autora do mini-livro [Exploratory Testing in an Agile Context, ousa afirmar que:

Eu acho que, se você pode escrever um roteiro manual para um teste, você pode automatizá-lo.

Pode ser difícil automatizar um teste exatamente da mesma maneira como seria realizado manualmente. Por exemplo, é quase impossível remover o cabo de rede automaticamente em uma caso de teste de conexão perdida. Portanto, o teste automatizado geralmente é feito de maneira diferente. Em vez de o cabo ser fisicamente destacado, o teste automatizado instrui o driver a responder como se o cabo tivesse sido removido.

A automação de todos os testes vale a pena? De acordo com Hendrickson:

Se um teste é importante o suficiente para ter um roteiro e ser executado, então é importante o suficiente para ser automatizado.

Por que isso? O desenvolvimento iterativo e incremental implica que o código não está congelado no final da iteração, mas sim pode ser potencialmente alterado a cada iteração. Portanto, o teste de regressão manual significaria re-executar a maior parte do teste manual a cada iteração. Automatizar os testes, portanto, recompensa rapidamente.

Faça alguns testes manuais

A automatização de todos os testes pode não valer a pena ou até mesmo não ser possível. Esses testes podem ser feitos manualmente:

Testes que requerem opinião humana e criatividade - Uma pessoa é necessária para avaliar se a interface parece ser boa - teste de usabilidade. O teste exploratório, por definição, precisa de alguém para decidir o próximo passo para explorar.
Testes que requerem movimentos físicos - Por exemplo, testes com o sistema em diferentes configurações físicas. Estes podem ser automatizados com simulação, mas a configuração real pode ser necessária para o teste final.
Testes caros - Testes de capacidade de retorno no ambiente de produção podem ser muito caros e, portanto, são feitos apenas uma ou duas vezes. Isso prorroga o risco. Estes riscos devem ser abordados antecipadamente com testes mais baratos - por exemplo, testes de capacidade de funcionamento em um ambiente simulado - para que executar o teste caro seja apenas uma verificação final.

Nenhuma falsa dicotomia: tente automatizar todos os testes, mas não se esqueça de fazer os testes manuais quando necessário.

Faça testes exploratórios

Em [Perfect Software and Other Illusions about Testing] (http://www.amazon.com/Perfect-Software-Other-Illusions-Testing/dp/0932633692), Gerald Weinberg menciona: “A Exaustiva Falácia dos Testes, onde é possível testar tudo!”. Não, não é. O número de possíveis cenários a testar é infinito e, portanto, automatizar todos os testes significa esforço de automação infinito. Em vez disso, automatize todos os testes antecipados e passe o tempo de forma tão eficiente quanto possível em testes exploratórios manuais para encontrar casos imprevistos.
Resumo sobre testes exploratórios

O que é o teste exploratório? “Aprendizagem simultânea, design de teste e execução de teste” [[Bach03]] (http://www.satisfice.com/articles/what_is_et.shtml). Isso contrasta com os testes tradicionais com roteiro, onde o design e a execução do caso de teste são separados e etapas seqüenciais - primeiro design e depois execução. Testes exploratórios visam utilizar plenamente a criatividade humana durante a execução do teste, usando feedback e observações, em vez de seguir um roteiro de forma insensata. Em testes exploratórios, o testador está explorando o sistema, aprendendo sobre isso e usando essa informação para tomar decisões de teste de design. É melhor explicado por um exemplo.

Imagine que Gita está testando uma aplicação de modelagem 2D. Primeiro, ela define o objetivo de sua sessão de teste - em testes exploratórios, isso é chamado de missão ou charter. Sua missão é “Explorar a mudança de formas, arrastando os pontos de controle.” Ela desenha forma na tela e cria alguns pontos de controle sobre ela. Ela arranca um deles e observa o que acontece. Com base nessa observação (aprendizagem), ela determina o próximo passo (design) e executa-o (execução). A forma ganha um novo design, embora ela perceba - ao arrastar os pontos de controle - que a forma temporariamente ganhou um design que provavelmente não deveria ter. Portanto, ela continua a arrastá-lo e movê-lo até que ela possa reproduzir a transformação acidental.

No exemplo, não existe um detalhado roteiro ou caso de teste preconcebido, mas sim uma área de foco - um charter. O primeiro passo é observar o sistema, e a próxima ação é determinada a partir dessa observação - este é o design do teste. Todas as técnicas de teste tradicionais e heurísticas são aplicadas durante este passo de design.

Testes Automatizados

Crie testes que podem ser mantidos

“Testes automatizados aumentarão nossa carga de manutenção de testes” é uma objeção comum que ouvimos. A manutenção do teste custará algum esforço, mas algumas técnicas diretas podem minimizar esse custo:

Remover a duplicação dentro e entre os testes
Apagar testes
Não teste através da interface do usuário
Execute testes com freqüência

Remova a duplicação dentro e entre os testes

A duplicação de código causa complexidade, obscuridade e defeitos adicionais, resultando em esforço de manutenção extra. Isso é tão verdadeiro para o código de teste quanto para o código de produção. Evite isso removendo a duplicação.

Testes de workflow são uma causa comum de duplicação. Eles geralmente consistem em um cenário-mãe e vários casos derivados com apenas pequenas variações neles. Quando uma etapa muda, todos esses testes de workflow precisam ser atualizados. Esta duplicação pode ser evitada por testes orientados por dados que se concentram em regras de negócios ou separando a duplicação em bibliotecas de teste.

Nós treinamos uma equipe que cometia um erro comum - adiaram sua automação de testes até o final da iteração. Quatro dias restantes e restaram apenas tarefas de automação. Nas iterações anteriores essas tarefas foram feitas pelo especialista em testes, mas agora tinham que ser feitas por toda a equipe.

Começaram com uma oficina de um dia em que o especialista treinou os outros membros da equipe. Depois disso, eles se dividiram em dois pares e um trio trabalhando em paralelo na automação dos testes. Algo interessante aconteceu: os membros da equipe que tiveram experiência na programação queixaram-se sobre o esforço extra necessário por causa da duplicação nos testes. Anteriormente, nenhum deles tinha notado isso e o especialista em testes - que não tinha muita experiência em programação - nunca se importou. Agora que toda a equipe estava envolvida, eles se importaram e a qualidade dos testes melhorou imensamente.

Exclua testes quando não adiciona valor

Os testes servem para múltiplos propósitos. Eles atuam como requisitos, como verificação, e como uma rede de segurança impedindo a regressão do sistema.

Quando um teste existente já não é necessário - porque é um subconjunto de outro teste - então o exclua. Deixar testes desnecessários não traz nenhum benefício, e ainda aumenta o esforço de manutenção e reduz a velocidade de execução do teste.

Evite testar através da UI

As interfaces de usuário (UIs) tendem a mudar com frequência. Executar seus testes através da UI os torna vulneráveis a essas mudanças - mesmo quando não há mudanças na lógica de teste. Isso aumenta o esforço de manutenção do teste.

Portanto, evite testar através da interface do usuário e, em vez disso, chame a lógica do aplicativo diretamente através de uma API. Outra vantagem de fazer isso é que ele acelera o seu teste, uma vez que o teste através da interface do usuário é lento.

Execute testes com frequência

Há muito tempo, trabalhamos com um grande grupo seguindo desenvolvimento waterfall. O conselho tradicional de automação de testes é selecionar e automatizar apenas os casos mais importantes - com uma equipe de automação separada - após a release. Então eles fizeram. No final da próxima versão, eles executaram os testes e … todos eles falharam. Atualizá-los levaria muito tempo, então eles decidiram fazer todos os testes manualmente.

Executar testes uma ou duas vezes uma versão parece eficiente - menos ciclos de CPU são desperdiçados - mas muita coisa mudou e, portanto, muitos falham e causam um grande lote de trabalhos de manutenção. Alternativamente, o sucesso de testes frequentes - usando um sistema de integração contínua - usa mais ciclos de CPU, mas resulta em menos trabalhos de manutenção, uma vez que o esforço para corrigir falhas de testes é pequeno e direto. Se você possui uma alta carga de manutenção de teste, é provável que você não esteja executando os testes com frequência suficiente.

Trate os não funcionais do mesmo modo que os funcionais

A automação e a execução contínua de testes não funcionais são essenciais. Retardá-los até o fim significa mover um dos maiores riscos para o momento mais crítico. Por exemplo, se o sistema precisar de um determinado nível de desempenho, teste antecipadamente para alcançá-lo cedo e execute o teste de forma contínua, enquanto novas funcionalidades são adicionadas para garantir que o sistema não regrida com seu objetivo de desempenho.

Os não-funcionais são frequentemente tratados exoticamente - as pessoas acreditam que não podem ser especificados e não podem ser testados. Isto é um infortúnio. Em uma oficina de requisitos, os não-funcionais podem ser considerados da mesma forma que os funcionais, e testes de exemplo são criados para esclarecê-los.

Execução contínua de testes de longa duração

Os testes não funcionais frequentemente não podem ser executados no ciclo normal do sistema de integração contínua, pois podem levar muito tempo para executar - um teste de estabilidade pode demorar duas semanas. Alguns grupos de produtos os adiam até perto do lançamento, criando um ciclo de feedback atrasado. Não é uma boa ideia.

Execute os testes de longa duração o tempo todo em um ciclo de sistema de integração contínua mais lento. Trate-os como outros testes. Quando eles falharem, informe todas as pessoas que marcaram o código. Depois que eles passarem, obtenha a compilação mais recente e execute-os imediatamente novamente. Desta forma, o ciclo de feedback é tão curto quanto possível.

Usar virtualização ou recipientes

Para acelerar os testes e manter o investimento em hardware baixo, maximize o uso da virtualização usando [VirtualBox] (https://www.virtualbox.org/) ou [VMWare] (http://www.vmware.com) /). Uma alternativa às máquinas virtuais (que nem sempre são rápidas de construir e fáceis de manter) são contêineres virtuais linux, como [Docker] (http://www.docker.io/)

Evite usar ferramentas comerciais de teste

Uma vez treinamos em uma empresa que criou uma ferramenta comercial de “testes automatizados” - uma ferramenta de teste GUI. O treinamento solicitado? Para aprender a fazer testes automatizados para desenvolver sua ferramenta de teste automatizada …

Uma gama de ferramentas comerciais de testes está disponível. Nós raramente conhecemos pessoas que estão realmente satisfeitas com qualquer uma delas. A maioria é excessivamente complexa e concentra-se mais em relatórios e “gerenciamento” do que na automação de testes robustos. Prefira ferramentas gratuitas e de código aberto - feitas por desenvolvedores que resolvem problemas reais - ao invés de ferramentas comerciais.

Exemplo de ferramentas comuns de automação de testes:

Há muito mais. O descrito acima é apenas uma lista de ferramentas comuns, mas novas ferramentas aparecem o tempo todo.