quinta-feira, 29 de agosto de 2013

Pare de criar scripts de teste e comece a pensar

Sim, PARE!!!
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...
  • 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:
  1. Acesse a página http://eliasnogueira.com/arquivos_blog/geral/collapse/
  2. Clique sobre a 'div preta' "Minhas Páginas"
  3. 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!


segunda-feira, 26 de agosto de 2013

O que aprendemos com teste de software

Eu vi uma pergunta desta no fórum do Software Testing Club e resolvi fazer a mesma coisa, só que no fórum do DFTestes.

Creio que é extremamente importante saber o que meus colegas estão aprendendo  também. Isso nos dá uma visão não só de aprendizado mas também de mercado.

As respostas foram:

Analisando as respostas podemos perceber algumas coisas bem interessantes:
  • Muitos testers estão aprendendo ferramentas de automação. Isso indica que eles já estão preocupados em estar no mesmo fluxo que o mercado que quer uma entrega/repsosta mais rápida 

  • Alguns testers já estão aprendendo sobre itens não funcionais em teste de software, e isso prova que não é somente de teste funcional que se vive de teste de software

  • Que alguns testers estão entrando num contexto ágil, aprendendo coisas além do assunto especifico sobre teste de software


E vocês leitores, o que aprenderam com teste de software?

terça-feira, 6 de agosto de 2013

Formação à distância de Selenium 32h em Setembro/2013(Básico e Avançado)

A Qualister realizará em Setembro a formação à distância de Selenium (32h). Se o aluno quiser, poderá participar somente do módulo Fundamentos (16h) ou somente do módulo Avançado (16h).

Segue abaixo maiores detalhes:

Fundamentos
Carga horária: 16 horas
Valor: 650,00 (por aluno)
Data: 14 de setembro e 21 de setembro
Módulo 1: (8h) – 14 de setembro, sábado das 08:00 às 17:00
Modulo 2: (8h) – 21 de setembro, sábado das 08:00 às 17:00

Avançado
Carga horária: 16 horas
Valor: 650,00 (por aluno)
Data: 28 de setembro e 05 de outubro
Módulo 3: (8h) - 28 de setembro, sábado das 08:00 às 17:00
Módulo 4: (8h) - 05 de outubro, sábado das 08:00 às 17:00

Formação (Fundamentos + Avançado)
Carga horária: 32 horas
Valor: (1.300,00 - 25% de desconto) = 975,00 (por aluno)
Data: 14 de setembro, 21 de setembro, 28 de setembro e 05 de outubro
Módulo 1: (8h) – 14 de setembro, sábado das 08:00 às 17:00
Modulo 2: (8h) – 21 de setembro, sábado das 08:00 às 17:00
Módulo 3: (8h) – 28 de setembro, sábado das 08:00 às 17:00
Módulo 4: (8h) - 05 de outubro, sábado das 08:00 às 17:00

Forma de pagamento: cartão de crédito em até 12x (com juros), boleto ou transferência bancária.

LOCAL
Treinamento à distância. Será realizado no seu computador via Internet utilizando ferramenta de web-conferência.

INFRA-ESTRUTURA
Sistema Operacional: Windows ou MacOS (O GotoMeetting não suporta Linux)
Plugin para acesso ao GoToMeeting através do navegador (no dia do treinamento o participante receberá um link para acesso a sala de conferência)

MINISTRANTE
Elias Nogueira é Arquiteto de Teste de Software com ênfase em Automação de Teste. Possui certificação CSTE pela QAI Brasil e já palestrou em diversos eventos relacionados a Teste de Software. Ativo na comunidade de teste é entusiasta que todo testador precisa ser técnico e pensar "fora da caixa". Ja atuou em diversos projetos de teste em diversos segmentos de mercado como varejo, bancário, comércio eletrônico, geomarketing, mineração de dados. Blogueiro do SemBugs http://sembugs.blogspot.com.br

INCLUI
Certificado em formato digital (PDF) e acesso ao material em formato digital (PDF)

TÓPICOS ABORDADOS
Módulo 1
Este módulo apresenta as principais funcionalidades da ferramenta Selenium IDE totalmente aplicadas em 10 exercícios práticos baseados em dúvidas sobre a ferramenta. Ao final dos exercícios o aluno estará apto a automatizar qualquer página web, inclusive com Ajax (requisições assíncronas).

Ementa
  • Record and Play
  • JavaScript
  • Alertas e Confirmações
  • Popup’s
  • Elementos HTML
  • Expressões Regulares
  • Ajax Loading
  • Ajax AutoComplete
  • Ajax Carrinho de Compras
  • Combo Cidade/Estado

Módulo 2
Este módulo apresenta pontos avançados do Selenium IDE com mais exercicíos de variáveis e como manipulá-las através de javascript. Aprenderemos também a criar comandos customizados através de user-extensions e utilizaremos os principais plugins existentes para o Selenium IDE. Como último conteúdo aprenderemos a criar scripts orientados a massa de dados (data driven). Com o Selenium RC iremos executar todos os testes criados no Selenium IDE em diversos browsers web através de linha de comando, criando uma suite de testes automatizados com execução automática, bem como executar scripts data driven via linha de comando sem precisar de programação.

Ementa
  • Criação de comandos customizados através de user-extensions
  • Criação de scripts data driven sem programação
  • Aprendendo os principais plugins
  • Screenshot tirada automaticamente quando o script falha (ScreenShot on Fail)
  • Evidências de Teste (Tesingt Evidence)
  • Esperas automáticas (Implicity Wait)
  • Visualização das variáveis (Stored Variables)
  • Fluxos de Controle (Flow Control)
  • Executando scripts criados no Selenium IDE em diversos browsers com Selenium RC
  • Executando scripts data driven via linha de comando com Selenium RC

Módulo 3
Sabemos que o Selenium IDE tem diversas funcionalidades, mas muitas vezes fica limitado em sua utilização. Neste módulo aprenderemos a programar utilizando a API do Selenium chamada Webdriver com Java através de exercícios práticos. Aprenderemos porque agora existem classes para cada browser e como executar os testes sem precisar mudar o código, além de usar todo o poder dos frameworks de teste unitário para nos auxiliar nos testes.

Ementa:
  • Interagindo com elemento HTML com Webdriver
  • Automatizando uma paginação
  • Esperas por requisições assíncronas (Ajax)
  • Webdriver + JUnit
  • Webdriver + TestNG
  • Data Driven com Webdriver
  • Automatizando para diversos browsers

Módulo 4
Neste módulo aprenderemos como definir uma arquitetura reutilizável para os testes automatizados utilizando Webdriver e um padrão chamado PageObjetcs, bem como utilizar a massa de dados diretamente de um banco de dados. Também aprenderemos como integrar o Webdriver com o Testlink para apresentar os resultados de execução e também a abertura automática de bugs em conjunto com o Mantis. Além disso também aprenderemos a colocar os scripts dentro de um ambiente de Integração Contínua.

Ementa
  • Arquitetura com Page Objetcs
  • Gerando Evidências em PDF
  • Arquitetura de dados com Webdriver e acessoa banco
  • Integração Testlink + Webdriver
  • Integração Mantis + Webdriver
  • Integração Mantis + Testlink + Webdriver
  • Execução automática de testes em um ambiente de integração contínua com Jenkins

INFORMAÇÕES
treinamento@qualister.com.br
48 3285-5615

LINK DO CURSO
http://www.qualister.com.br/curso-treinamento-formacao-no-mes-de-setembro-formacao-a-distancia-de-selenium-basico-e-avancado