O que é Teste de Automação (Guia Final para Iniciar Teste de Automação)

Um Guia Completo para iniciar o Teste de Automação no seu projeto:

O que é o Teste de Automação?

Teste de Automatização é uma técnica de teste de Software para testar e comparar o resultado real com o resultado esperado. Isto pode ser alcançado escrevendo scripts de teste ou usando qualquer ferramenta de teste de automação. A automação de testes é usada para automatizar tarefas repetitivas e outras tarefas de teste que são difíceis de executar manualmente.

Você quer iniciar o teste de automação no seu projeto, mas está lutando com os passos mais básicos como mencionado abaixo:

• Como introduzir automação no seu projeto?
• Como selecionar a melhor e mais correta ferramenta de automação?
• Como desenvolver scripts eficazmente?
• Como executar e manter scripts de teste?
• E finalmente quais são as melhores práticas que você precisa seguir para o sucesso dos testes de automação?

Hoje, nós planejamos enriquecer o seu conhecimento com uma série de tutoriais sobre “Como começar com testes de automação”. Esta série de tutoriais de automação irá responder a todas as perguntas acima de forma passo a passo com exemplos simples.

Vamos dar uma olhada na série de tutoriais sobre Iniciando a Automação no Seu Projeto!

Automação de Processo Ponta-a-Ponta:

Tutorial #1: Melhor Guia para Iniciar Automação no Seu Projeto
Tutorial #2: Tipos de Testes Automatizados e Alguns Conceitos Errados
Tutorial #3: 10 Passos para Introduzir Automação no Seu Projeto
Tutorial #4: O Guia de A a Z sobre Seleção da Melhor Ferramenta de Automação
Tutorial #5: Desenvolvimento de Script e Frameworks de Automação
Tutorial #6: Execução e relatório de Automação
Tutorial #7: Melhores Práticas e Estratégias de Automação de Testes

Dicas de Automação:

p>Tutorial #8: 10 Dicas que você deve ler antes de automatizar seu trabalho de teste
Tutorial #9: Como o Planejamento de Testes Difere para Projetos Manuais e de Automação
Tutorial #10: Quando Optar pela Automação?
Tutorial #11: Desafios do Teste de Automação
Tutorial #12: Guia para implementar a Prova de Conceito (POC) em Automação
Tutorial #13: Como selecionar casos de teste corretos para Automação
Tutorial #14: Como traduzir casos de teste manuais em scripts de Automação

Carreira de Automação:

p>Tutorial #15: Dicas para se tornar um melhor Testador de Automação
Tutorial #16: Automação de Testes – É uma Carreira Especializada? Os testadores normais também podem fazer automação?p>Ferramentas de automação popular:p>Tutorial #17: Tutorial de Selênio 31+ Melhor Tutorial de Treinamento de Selênio Grátis

Tutorial #18: Tutorial #18: Tutorial QTP
Tutorial #19: SoapUI Web Services Testing Tool
Tutorial #20: HP LoadRunner for Performance Testing

Automation Frameworks:

Tutorial #21: Por que precisamos de um framework para automação
Tutorial #22: Frameworks de automação mais populares

p>Automação em Agile:p>Tutorial #23: Como implementar automação eficiente no mundo ágilp>Outras ferramentas de automação:p>Tutorial #24: Melhores ferramentas de teste de automação
Tutorial #25: Sikuli GUI Automation Tool
Tutorial #26: PowerShell: Automação da interface gráfica de usuário com PowerShell
Tutorial #27: Katalon Automation Recorder (Selenium IDE Alternative)
Tutorial #28: Ferramenta Geb: Automação do Navegador com a Ferramenta Geb
Tutorial #29: AutoIt: Como lidar com janelas pop-up usando AutoIt
Tutorial #30: Cucumber: Automation Using Cucumber Tool and Selenium
Tutorial #31: Protractor Testing Tool for End-to-end Testing of AngularJS Applications

Teste de Automação Móvel:

p>Tutorial #32: Tutorial Prático do Appium Studio
Tutorial #33: Tutorial Appium para Iniciantes
Tutorial #34: Tutorial Selendroid: Android Mobile Automation Framework
Tutorial #35: Ranorex Tutorial: Uma Poderosa Ferramenta de Teste para Desktop, Web e Móvel

Exemplos de Automação de Domínios Específicos:

p>Tutorial #36: Automação de Aplicações JAVA/J2EEp>Preparação de Entrevista para Trabalhos de Automação:P>Tutorial #37: Perguntas de Entrevista para Testes de Automação
Tutorial #38: Perguntas de Entrevista Seleniump>Vamos explorar o primeiro tutorial da série “The Ultimate Guide to Automation Testing”!!

O que é o Teste de Automação?

Se um software pode fazer qualquer coisa então, por que um software não pode testar um software?

Esta afirmação soa lógica para você?

Se sim, então parabéns, agora você está pensando em Automação de Testes, que é o ponto central que vamos discutir nesta série de tutoriais informativos.

Imagine-se no primeiro dia de seu trabalho como um SQA. Você é apresentado com uma aplicação a ser testada. É uma aplicação ERP que contém 100s de formulários e milhares de relatórios. Você começa seu teste exploratório abrindo um formulário que contém cerca de 50 campos diferentes.

Você tenta inserir dados aleatórios neste formulário que demorou cerca de 20 minutos. Em seguida, você pressiona enviar. Wolla!! É exibida uma mensagem de erro que parece ser uma exceção sem soltar. Você se torna muito feliz. Você anotará orgulhosamente os passos e relatará o bug em seu sistema de gerenciamento de bugs. Grande esforço, você se sente realmente confiante e enérgico. Você continua os testes até o final do dia e encontra mais alguns bugs. “Incrível primeiro dia”, você pensou.

Agora vem no dia seguinte, o desenvolvedor corrigiu o problema e lança uma nova versão da compilação. Você testa a mesma forma com os mesmos passos e descobre que o bug está corrigido. Você marca o bug corrigido. Grande esforço. Você contribuiu para a qualidade do produto ao identificar o bug e como este bug foi corrigido, a qualidade foi melhorada.

Agora chega no terceiro dia, um desenvolvedor lançou novamente uma versão mais nova. Agora você tem que testar novamente esse formulário para ter certeza de que nenhum problema de regressão é encontrado. Os mesmos 20 minutos. Agora você se sente um pouco entediado.

Agora imagine 1 mês a partir de agora, novas versões estão constantemente lançando e a cada lançamento, você tem que testar este formulário longo mais 100 de outros formulários como este, apenas para ter certeza de que não há regressão.

Agora você se sente irritado. Você se sente cansado. Você começa a pular os passos. Você preenche apenas cerca de 50% do total dos campos. Sua precisão não é a mesma, sua energia não é a mesma e definitivamente, seus passos não são os mesmos.

E um dia, o cliente reporta o mesmo bug no mesmo formulário. Você se sente patético. Você se sente pouco confiante agora. Você pensa que não é competente o suficiente. Os gerentes estão questionando sua habilidade.

Eu tenho uma notícia para você; esta é a história de 90% dos testadores manuais por aí. Você não é diferente.

As questões de regressão são as mais dolorosas. Nós somos humanos. E não podemos fazer a mesma coisa com a mesma energia, velocidade e precisão todos os dias. Isto é o que as máquinas fazem. É para isso que a automação é necessária, para repetir os mesmos passos com a mesma velocidade, precisão e energia que foram repetidos na primeira vez.

Espero que você entenda meu ponto de vista!!

automação testando um amigo

Quando tal situação surgir, você deve automatizar o seu caso de teste. A automatização do teste é seu amigo. Ele o ajudará a se concentrar em novas funcionalidades enquanto cuida das regressões. Com a automação, você pode preencher esse formulário em menos de 3 minutos.

O script irá preencher todos os campos e lhe informará o resultado junto com as capturas de tela. Em caso de falha, ele pode apontar o local onde o caso de teste falhou, ajudando assim a reproduzi-lo com facilidade.

Automação – Um método econômico para testes de regressão

Custos de automação são realmente mais altos inicialmente. Inclui o custo da ferramenta, depois o custo do recurso de teste de automação e seu treinamento.

Mas quando os scripts estão prontos, eles podem ser executados centenas de vezes repetidamente com a mesma precisão e bastante rápido. Isto irá poupar muitas horas de testes manuais. Assim o custo diminui gradualmente, e por fim se torna um método econômico para testes de Regressão.

Cenários que requerem Automação

O cenário acima não é o único caso em que você precisará de testes de automação. Existem várias situações, que não podem ser testadas manualmente.

Por exemplo,

1. Comparando duas imagens pixel a pixel.
2. Comparando duas planilhas contendo milhares de linhas e colunas.
3. Testar uma aplicação sob a carga de 100.000 usuários.
4. Benchmarks de desempenho.
5. Testar a aplicação em diferentes navegadores e em diferentes sistemas operacionais em paralelo.

Estas situações requerem e devem ser, testadas por ferramentas.

Então, quando automatizar?

Esta é uma era de metodologia ágil no SDLC, onde o desenvolvimento e testes irão quase em paralelo e é muito difícil decidir quando automatizar.

Considere as seguintes situações antes de entrar em automação

• O produto pode estar em seus estágios primitivos, quando o produto nem sequer tem uma IU, nestes estágios devemos ter uma clara reflexão sobre o que queremos automatizar. Os seguintes pontos devem ser lembrados.
  • Testes não devem ser obsoletos.
  • Como o produto evolui deve ser fácil de pegar os scripts e adicionar a ele.
  • É muito importante não se deixar levar e garantir que os scripts sejam fáceis de depurar.
• Não tente automatizar a IU logo nos estágios iniciais, pois a IU está sujeita a mudanças freqüentes, assim os scripts falharão. Na medida do possível, opte pela automação no nível da API/Não-UI até que o produto se estabilize. A automação da API é fácil de corrigir e depurar.

Como decidir os melhores casos de automação:

Automação é parte integrante de um ciclo de testes e é muito importante decidir o que queremos alcançar com automação antes de decidirmos automatizar.

Os benefícios que a automação parece fornecer são muito atraentes, mas ao mesmo tempo, uma suíte de automação mal organizada pode estragar todo o jogo. Os testadores podem acabar por depurar e corrigir os scripts a maior parte do tempo resultando em perda de tempo de teste.

Esta série explica como uma suíte de automação pode ser tornada eficiente o suficiente para pegar os casos de testes certos e produzir os resultados certos com os scripts de automação que temos.

Também, eu cobri as respostas a perguntas como Quando automatizar, O que automatizar, O que não automatizar e Como estrategizar a automação.

Testes de Automatização Certos

A melhor maneira de lidar com este problema é rapidamente encontrar uma “Estratégia de Automação” que se adeque ao nosso produto.

A idéia é agrupar os casos de teste para que cada grupo nos dê um tipo diferente de resultado. A Ilustração dada abaixo mostra como podemos agrupar nossos casos de teste similares, dependendo do produto/solução que estamos testando.

Deixe-nos agora mergulhar fundo e entender o que cada grupo pode nos ajudar a alcançar:

#1) Fazer um conjunto de testes de todas as funcionalidades básicas Testes positivos. Esta suite deve ser automatizada, e quando esta suite é executada contra qualquer compilação, os resultados são mostrados imediatamente. Qualquer falha de script nesta suíte leva ao defeito S1 ou S2, e essa compilação específica pode ser desqualificada. Portanto, economizamos muito tempo aqui.

Como um passo adicional, podemos adicionar esta suíte de testes automatizados como parte do BVT (Build verification tests) e verificar os scripts de automação de QA no processo de construção do produto. Assim, quando o build estiver pronto, os testadores podem verificar os resultados dos testes de automação e decidir se o build é adequado ou não para a instalação e para o processo de testes posteriores.

Isto claramente atinge os objetivos de automação que são:

• Reduzir o esforço de teste.
• Find Bugs em estágios iniciais.

#2) Em seguida, temos um grupo de testes de fim a fim.

P>Acima de grandes soluções, testar uma funcionalidade de fim a fim detém a chave, especialmente durante os estágios críticos do projeto. Devemos ter alguns scripts de automação que tocam nos testes de solução ponta a ponta também. Quando esta suite for executada, o resultado deve indicar se o produto como um todo está funcionando como esperado ou não.

A suite de testes de automação deve ser indicada se alguma das peças de integração estiver quebrada. Esta suíte não precisa cobrir toda e qualquer pequena funcionalidade/funcionalidade da solução, mas deve cobrir o funcionamento do produto como um todo. Sempre que tivermos um alfa ou um beta ou qualquer outra versão intermediária, tais scripts são úteis e dão algum nível de confiança ao cliente.

Para entender melhor vamos assumir que estamos testando um portal de compras online, como parte dos testes de fim a fim devemos cobrir apenas os passos chave envolvidos.

Como dado abaixo:

• Login do usuário.
• Navegar e selecionar itens.
• Opção de pagamento – isto cobre os testes de fim a fim.
• Backend order management (envolve comunicação com múltiplos parceiros integrados, verificação de estoque, envio de e-mail ao usuário etc) – isto ajudará na integração de testes de peças individuais e também o crux do produto.

Então quando um desses scripts é executado ele dá a confiança de que a solução como um todo está funcionando bem.!

#3) O terceiro conjunto é o recurso/teste baseado em funcionalidade.

Por exemplo, podemos ter a funcionalidade de navegar e selecionar um arquivo, então quando automatizamos isto podemos automatizar casos para incluir a seleção de diferentes tipos de arquivos, tamanhos de arquivos, etc, para que o teste do recurso seja feito. Quando existem quaisquer alterações/adições a essa funcionalidade esta suite pode servir como uma suite de Regressão.

#4) A seguir na lista seriam os testes baseados em UI. Podemos ter outra suite que irá testar funcionalidades puramente baseadas em IU como paginação, limitação de caracteres da caixa de texto, botão de calendário, drop downs, gráficos, imagens e muitas dessas funcionalidades baseadas apenas em IU. A falha destes scripts normalmente não é muito crítica, a menos que a IU esteja completamente em baixo ou certas páginas não apareçam como esperado!

#5) Podemos ter mais um conjunto de testes que são simples, mas muito trabalhosos para serem realizados manualmente. Tediosos mas simples testes são os candidatos ideais para automação, por exemplo, entrar detalhes de 1000 clientes no banco de dados tem uma funcionalidade simples mas extremamente tediosa para ser realizada manualmente, tais testes devem ser automatizados. Caso contrário, na maioria das vezes acabam sendo ignorados e não testados.

O que NÃO Automatizar?

Dados abaixo são poucos testes que não devem ser automatizados.

#1) Testes negativos/ testes de reprovação

Não devemos tentar automatizar testes negativos ou de reprovação, pois para estes testes os testadores precisam pensar analiticamente e os testes negativos não são realmente simples para dar um resultado positivo ou negativo que pode nos ajudar.

Testes negativos precisarão de muita intervenção manual para simular um cenário real de recuperação de desastres. Apenas para exemplificar, estamos testando características como confiabilidade de serviços web – para generalizar aqui o objetivo principal de tais testes seria causar falhas deliberadas e ver como o produto consegue ser confiável.

Simular as falhas acima não é simples, pode envolver a injeção de alguns stubs ou usar algumas ferramentas no meio e automação não é a melhor maneira de ir aqui.

#2) Testes ad hoc

Estes testes podem não ser realmente relevantes para um produto em todos os momentos e isso pode até ser algo que o testador poderia pensar naquela fase do início do projeto, e também o esforço para automatizar um teste ad-hoc tem que ser validado contra a criticidade da característica que os testes tocam.

Por exemplo, um testador que está testando um recurso que lida com compressão/encriptação de dados pode ter feito testes ad-hoc intensos com a variedade de dados, tipos de arquivo, tamanhos de arquivo, dados corrompidos, uma combinação de dados, usando diferentes algoritmos, através de várias plataformas, etc.

Quando planejamos a automação podemos querer priorizar e não fazer uma automação exaustiva de todos os testes ad hoc apenas para esse recurso, e acabar com um pouco de tempo para automatizar os outros recursos-chave.

#3) Testes com pré-configuração massiva

Existem testes que requerem alguns pré-requisitos enormes.

Por exemplo, Podemos ter um produto que se integra com um software de terceiros para algumas das funções, já que o produto se integra com qualquer sistema de filas de mensagens que requer instalação em um sistema, configuração de filas, criação de filas, etc.

O software de terceiros pode ser qualquer coisa e a configuração pode ser complexa por natureza e se tais scripts forem automatizados, então estes serão para sempre dependentes da função/configuração desse software de terceiros.

Pré-requisito incluir:

No momento as coisas podem parecer simples e limpas, já que ambas as configurações laterais estão sendo feitas e tudo está bem. Temos visto em inúmeras ocasiões que quando um projeto entra na fase de manutenção o projeto é movido para outra equipe, e eles acabam depurando tais scripts onde o teste real é muito simples mas o script falha devido a um problema de software de terceiros.

O acima é apenas um exemplo, em geral, fique de olho em testes que têm pré-configurações trabalhosas para um teste simples que se segue.

Simple Example of Test Automation

Quando você está testando um software (na web ou desktop), você normalmente usa um mouse e teclado para realizar seus passos. A ferramenta de automação imita esses mesmos passos usando scripting ou uma linguagem de programação.

Por exemplo, se você estiver testando uma calculadora e o caso de teste é que você tem que adicionar dois números e ver o resultado. The script will perform the same steps by making use of your mouse and keyboard.

The example is shown below.

Manual Test Case Steps:

1. Launch Calculator
2. Press 2
3. Press +
4. Press 3
5. Press =
6. The screen should display 5.
7. Close Calculator.

Automation Script:

//the example is written in MS Coded UI using c# language.public void TestCalculator(){//launch the applicationvar app = ApplicationUnderTest.Launch("C:\\Windows\\System32\\calc.exe");//do all the operationsMouse.Click(button2);Mouse.Click(buttonAdd);Mouse.Click(button3);Mouse.Click(buttonEqual);//evaluate the resultsAssert.AreEqual("5", txtResult.DisplayText,”Calculator is not showing 5);//close the applicationapp.Close();}

The above script is just a duplication of your manual steps. The script is easy to create and easy to understand as well.

What are Assertions?

The second last line of the script needs some more explanation.

Assert.AreEqual(“5”, txtResult.DisplayText,”Calculator is not showing 5);

In every test case, we have some expected or predicted result at the end. In the above script, we have an expectation that “5” should be shown on the screen. The actual outcome is the result that is displayed on the screen. Em cada caso de teste, nós comparamos o resultado esperado com o resultado real.

O mesmo vale para o teste de automação também. A única diferença aqui é que, quando fazemos essa comparação na automação do teste, então ele é chamado de outra coisa em cada ferramenta.

Algumas ferramentas o chamam de “Assertion”, algumas o chamam de “checkpoint” e algumas o chamam de “validation”. Mas basicamente, isto é apenas uma comparação. Se esta comparação falhar, por exemplo, uma tela está mostrando 15 ao invés de 5, então esta asserção/ponto de verificação/validação falha e seu caso de teste é marcado como falhado.

Quando um caso de teste está falhando devido a uma asserção, então isso significa que você detectou um bug através da automação do teste. Você deve relatá-lo ao seu sistema de gerenciamento de bugs como você normalmente faz no teste manual.

No script acima, nós executamos uma asserção na segunda última linha. 5 é o resultado esperado, txtResult. DisplayText é o resultado real e se eles não forem iguais, nos será mostrada uma mensagem de que “Calculator is not showing 5”.

Conclusion

Frequentemente os testadores se deparam com prazos e mandatos para automatizar todos os casos para melhorar as estimativas de testes.

Existem algumas percepções “erradas” comuns sobre automação.

Eles são:

• Podemos automatizar todos os casos de teste.
• Testes automatizados reduzirão enormemente o tempo de teste.
• Não são introduzidos bugs se os scripts de automação estiverem rodando sem problemas.

Deve ficar claro que a automação pode reduzir o tempo de teste somente para certos tipos de testes. Automatizar todos os testes sem qualquer plano ou seqüência levará a scripts massivos que são de manutenção pesada, falham frequentemente e precisam de muita intervenção manual também. Além disso, em produtos em constante evolução os scripts de automação podem ficar obsoletos e precisar de algumas verificações constantes.

Agrupar e automatizar os candidatos certos poupará muito tempo e dará todos os benefícios da automação.

Este excelente tutorial pode ser resumido em apenas 7 pontos.

Testes de Automatização:

• É o teste que é feito programmaticamente.
• Utiliza a ferramenta para controlar a execução dos testes.
• Comparar os resultados esperados com os resultados reais (Assertions).
• Pode automatizar algumas tarefas repetitivas mas necessárias (Por exemplo, seus casos de testes de regressão).
• Pode automatizar algumas tarefas que são difíceis de fazer manualmente (E.g. Carregar cenários de teste).
• Os scripts podem ser executados rápida e repetidamente.
• É rentável a longo prazo.

Aqui, Automação é explicada em termos simples, mas isso não significa que seja sempre simples de fazer. Há desafios, riscos e muitos outros obstáculos envolvidos nela. Há inúmeras maneiras pelas quais a automação de testes pode dar errado, mas se tudo der certo, então os benefícios da automação de testes são realmente enormes.

Próximos desta série:

Nos nossos próximos tutoriais, discutiremos vários aspectos relacionados à automação.

Estes incluem:

1. Tipos de testes automatizados e alguns equívocos.
2. Como introduzir automação na sua organização e evitar armadilhas comuns ao fazer automação de testes.
3. O processo de seleção de ferramentas e comparação de várias ferramentas de automação.
4. Estruturas de Desenvolvimento e Automação de Script com exemplos.
5. Execução e relatórios de Automação de Testes.
6. Best Practices and Strategies of Test Automation.