Vamos contextualizar o título.
Conceituação
Hoje o mercado pede automação de teste e as pessoas, obviamente vão em busca do que o mercado pede. Não todas obviamente, mas uma grande parte. Com a ascensão da agilidade na entrega dos softwares hoje em dia, onde muitos tomam como base um produto que é potencialmente entregável em uma variação/período de tempo de 2 a 4 semanas (obviamente não é a regra mas muitas equipes trabalham com essa variação).Ai comece a pensar o seguinte: como eu vou garantir que, a cada variação destas (2 a duas semanas ou 4 a 4 semanas), para um mesmo produto, eu conseguirei garantir a qualidade do que está sendo desenvolvido?
Vamos incluir aqui a automação de teste em todos os níveis, segundo a pirâmide de automação de teste.
Olhando esta variação notamos que há uma grande vantagem em automatizar tudo o que pudermos ao invés de executar testes manualmente, certo? Obviamente sabemos que os testes automatizados não substituem os testes manuais por completo, mas essa é uma linha de raciocínio que não é falsa.
Logo, precisamos nesta variação, automatizar o que for factível para que no final:
- o produto potencialmente entregável funciona como esperado (aspecto implícito de qualidade)
- que, durante as próximas entregas de novas funcionalidades ou alteração de funcionalidades existentes, o tempo não seja desperdiçado na execução do teste manual e que o(s) script(s) de teste executem, onde ganhamos um feedback continuo dos testes
Senso comum
Ótimo Elias, você me convenceu, automatizar é a solução... Então vamos logo automatizar!O que o mercado faz
O termo "mercado" aqui diz respeito ao profissional, seja ele desenvolvedor, tester ou qualquer outro papel, que vai automatizar algo. Também é a minha visão e opinião sobre o mercado.Dado a agilidade na entrega do software o que o mercado faz é entender a funcionalidade e começar a automatizar nos períodos pertinentes.
Só que existem problemas quando "baixamos a cabeça" e começamos a automatizar...
O mercado em si também trabalha muitas vezes de uma forma que não há ganhos em automatizar. Ex: um profissional de teste recebe, para poder automatizar, uma série de documento de requisitos, regras de negócio e casos de uso para automatizá-los. Com isso o foco da automação fica apenas na visão de um único requisito/caso de uso/regra. Isso pode ser extremamente ruim porque a automação dificilmente vai mostrar valor no conjunto da obra.
Não vou comentar aqui sobre testar/automatizar quando não se tem quase documentação porque, neste caso e na minha visão, existe uma grande chance de você conseguir testar e automatizar certo... mas isso é outro post...
Sim, pode ser, mas pare de criar scripts e comece a pensar!
A grande maioria das pessoas que me procuram pedindo ajuda em automação, principalmente automação funcional/UAT é que os scripts param de funcionar e estes não conseguem mais "fazer com que o script passe".
E sabe porque isso acontece? Porque estas pessoas simplesmente "baixaram a cabeça" e começaram a automatizar.
Também há outro problema que é a falta de conhecimento na ferramenta em que se está utilizando.
Vamos pegar um exemplo, e você não vai perder mais 5 min neste post :)
O teste é simples:
Simples não? Porque então não automatizar logo???
Bom, antes de continuar lendo o post tente automatizar na sua ferramenta de automação web preferida.
Provavelmente ele vai falhar quando você executa o terceiro passo, que é clicar no link "Treinamento Agile Testing"
Abaixo vou colocar o trecho de código automatizando com WebDriver + Java, ignorando os devidos imports.
O comportamento que eu vejo é o seguinte:
Agora comparem a descrição do comportamento com os passos que eu descrevi anteriormente. Qual a diferença?
Descrevendo o comportamento da página eu coloquei uma coisa muito importante: que eu espero o efeito de clicar em "Minhas Páginas" acabar para que eu possa clicar no link "Treinamento Agile Testing"
O que faltou então: a espera!
Simples não, mas tem elementos simples que não nos damos conta que fazem nosso script falhar "sem razão".
Adicionando uma espera o script, funcional, fica assim:
Logo quando vemos algo fácil (ou mesmo difícil), por pressão de tempo, por baixa complexidade ou por diversos outros fatores começamos logo a escrever scripts de teste automatizado "sem pensar".
O que eu quero dizer com arquitetura é você fazer as seguintes perguntas:
Existem muitas outras perguntas que podemos fazer, mas isso já te dá uma boa noção do que é pensar em arquitetura para a automação de teste.
Então não é apenas "baixar a cabeça" e criar scripts. Imagine que o software a cada variação/período, tenha mais e mais funcionalidades. Como você vai responder as perguntas acima?
Se você não pensar nestes aspectos vai ser muito, mas muito mais vantajoso executar os testes manualmente porque você perderá muito tempo tentando arrumar/consertar os scripts.
É neste ponto que a maioria dos profissionais falha na nossa área: vendemos automação como sendo algo legal, mas depois nossos pares/colegas/gerentes veem isso como uma coisa difícil de manter e complicada, caindo em descrédito e não enxergando benefícios.
Tudo isso porque não pensamos antes de fazer!!!
Também conheça muito bem da ferramenta que você está utilizando e evite ao máximo record & play.
Uma ferramenta com record & play, muito provavelmente, não terá pontos de sincronização (a espera que fizemos) e você vai esquecer rapidinho de que existe uma sincronização a ser feita.
Todo o teste deve ser sempre baseado em uma hipótese, e quando você cria uma hipótese qual a primeira coisa que fazemos? Estudamos as possibilidades, analisamos comportamentos e depois aplicamos o teste para validar que a hipótese é ou não é verdadeira.
O nosso senso de urgência e conhecimento sempre vai nos dizer para não perder tempo pensando, afinal eu já tenho conhecimento e experiência bastante para fazer isso. Mas a prática real é bem diferente. Estudar comportamentos e pensar antes de qualquer coisa, não só para criar scripts de teste, nos dá uma visão muito melhor do que fazer.
Leitura recomendada: Tester, para de testar!
Só que existem problemas quando "baixamos a cabeça" e começamos a automatizar...
- Nem sempre a funcionalidade que será automatizada é realmente entendida pelo automatizador ou mesmo pela equipe
- A automação, as vezes, é feita sem um conhecimento geral sobre programação com a utilização de ferramentas record & play
- A execução da automação é feita um a um. Ou seja, existem diversos scripts de teste, mas o profissional abre e executa cada um
- Depois de um tempo, o próprio profissional não sabe o que o script faz
- Mesmo com uma série de scripts prontos, um novo bug sempre é encontrado pelo cliente
O mercado em si também trabalha muitas vezes de uma forma que não há ganhos em automatizar. Ex: um profissional de teste recebe, para poder automatizar, uma série de documento de requisitos, regras de negócio e casos de uso para automatizá-los. Com isso o foco da automação fica apenas na visão de um único requisito/caso de uso/regra. Isso pode ser extremamente ruim porque a automação dificilmente vai mostrar valor no conjunto da obra.
Não vou comentar aqui sobre testar/automatizar quando não se tem quase documentação porque, neste caso e na minha visão, existe uma grande chance de você conseguir testar e automatizar certo... mas isso é outro post...
Para de criar scripts e comece a pensar!
OK, temos um curto período de tempo se falarmos em agilidade (lembra das 2 a 4 semanas mágicas que muitos adotam), então começar a automatizar o mais rápido possível é a solução!Sim, pode ser, mas pare de criar scripts e comece a pensar!
A grande maioria das pessoas que me procuram pedindo ajuda em automação, principalmente automação funcional/UAT é que os scripts param de funcionar e estes não conseguem mais "fazer com que o script passe".
E sabe porque isso acontece? Porque estas pessoas simplesmente "baixaram a cabeça" e começaram a automatizar.
Também há outro problema que é a falta de conhecimento na ferramenta em que se está utilizando.
Explicando no lado técnico da coisa
Começando do básico, e um dos exercícios que eu faço muito com meus alunos no meu Treinamento de Selenium/WebDriver, é primeiro olhar como a página funciona num olhar de usuário, não de testador (embora o testador tenha um olhar de usuário, no momento em que ele vai automatizar algo ele olha como olhar de tester).Vamos pegar um exemplo, e você não vai perder mais 5 min neste post :)
O teste é simples:
- Acesse a página http://eliasnogueira.com/arquivos_blog/geral/collapse/
- Clique sobre a 'div preta' "Minhas Páginas"
- Clique sobre o link "Treinamento Agile Testing"
Simples não? Porque então não automatizar logo???
Bom, antes de continuar lendo o post tente automatizar na sua ferramenta de automação web preferida.
Resultado da automação sem pensar no comportamento
Se você automatizar exatamente os passos o teu script falhará! Sim, ele vai falhar!Provavelmente ele vai falhar quando você executa o terceiro passo, que é clicar no link "Treinamento Agile Testing"
Abaixo vou colocar o trecho de código automatizando com WebDriver + Java, ignorando os devidos imports.
WebDriver driver = new FirefoxDriver();
driver.get("http://eliasnogueira.com/arquivos_blog/geral/collapse/");
driver.findElement(By.id("section1")).click();
driver.findElement(By.linkText("Treinamento Agile Testing")).click();
Vamos pensar no comportamento da página
Ao invés de automatizar com um olhar de desenvolvedor ou testador, vamos olhar como um usuário e mais: vamos descrever o comportamento da página.O comportamento que eu vejo é o seguinte:
- Eu acesso a página em questão e ele carrega
- Me mostra algumas informações
- Eu clico em "Minhas Páginas"
- Um efeito é aplicado apresentando três links
- Eu espero o efeito terminar
- Eu clico no link "Treinamento Agile Testing"
Agora comparem a descrição do comportamento com os passos que eu descrevi anteriormente. Qual a diferença?
Descrevendo o comportamento da página eu coloquei uma coisa muito importante: que eu espero o efeito de clicar em "Minhas Páginas" acabar para que eu possa clicar no link "Treinamento Agile Testing"
O que faltou então: a espera!
Simples não, mas tem elementos simples que não nos damos conta que fazem nosso script falhar "sem razão".
Adicionando uma espera o script, funcional, fica assim:
WebDriver driver = new FirefoxDriver();
driver.get("http://eliasnogueira.com/arquivos_blog/geral/collapse/");
driver.findElement(By.id("section1")).click();
By byAgileLink = By.linkText("Treinamento Agile Testing");
WebDriverWait wait = new WebDriverWait(driver, 10);
wait.until(ExpectedConditions.elementToBeClickable(byAgileLink));
driver.findElement(byAgileLink).click();
Porque isso ocorre?
O primeiro problema é a afobação, sim!!!!Logo quando vemos algo fácil (ou mesmo difícil), por pressão de tempo, por baixa complexidade ou por diversos outros fatores começamos logo a escrever scripts de teste automatizado "sem pensar".
O problema do lado da arquitetura
Poucos testers que eu conheço, sim poucos mesmo, pensam em arquitetura para a automação de teste!O que eu quero dizer com arquitetura é você fazer as seguintes perguntas:
- como eu executarei todos os scripts?
- como eu saberei o resultado da execução?
- como qualquer pessoa terá acesso aos scripts e a executá-los?
- como eu irei escalar os scripts? (quando novas funcionalidades entrarem)
- como eu farei a manutenção dos scripts?
- como eu irei informar o ambiente que os scripts serão executados?
Existem muitas outras perguntas que podemos fazer, mas isso já te dá uma boa noção do que é pensar em arquitetura para a automação de teste.
Então não é apenas "baixar a cabeça" e criar scripts. Imagine que o software a cada variação/período, tenha mais e mais funcionalidades. Como você vai responder as perguntas acima?
Se você não pensar nestes aspectos vai ser muito, mas muito mais vantajoso executar os testes manualmente porque você perderá muito tempo tentando arrumar/consertar os scripts.
É neste ponto que a maioria dos profissionais falha na nossa área: vendemos automação como sendo algo legal, mas depois nossos pares/colegas/gerentes veem isso como uma coisa difícil de manter e complicada, caindo em descrédito e não enxergando benefícios.
Tudo isso porque não pensamos antes de fazer!!!
Dica
Sempre, sempre que você for automatizar qualquer funcionalidade que seja, escreva em um bloco de notas ou pense quais são os reais passos que você está executando como um usuário. Depois disso, se você ainda não estiver muito familiarizado com a ferramenta que estás utilizando, tenta substituir cada ponto anotado por comandos. Obviamente terão pontos que não serão comandos, mas isso fará você pensar em tudo o que ocorreu na página e cobrir isso na criação do script.Também conheça muito bem da ferramenta que você está utilizando e evite ao máximo record & play.
Uma ferramenta com record & play, muito provavelmente, não terá pontos de sincronização (a espera que fizemos) e você vai esquecer rapidinho de que existe uma sincronização a ser feita.
Conclusão
Testar coisa é uma tarefa investigativa, então tudo começa com um curiosidade e estudo do comportamento das coisas.Todo o teste deve ser sempre baseado em uma hipótese, e quando você cria uma hipótese qual a primeira coisa que fazemos? Estudamos as possibilidades, analisamos comportamentos e depois aplicamos o teste para validar que a hipótese é ou não é verdadeira.
O nosso senso de urgência e conhecimento sempre vai nos dizer para não perder tempo pensando, afinal eu já tenho conhecimento e experiência bastante para fazer isso. Mas a prática real é bem diferente. Estudar comportamentos e pensar antes de qualquer coisa, não só para criar scripts de teste, nos dá uma visão muito melhor do que fazer.
Leitura recomendada: Tester, para de testar!
