1) O documento apresenta os papéis e técnicas de automação de testes para equipes ágeis, discutindo como a automação pode ajudar a resolver problemas como falta de tempo para testar e garantir a qualidade ao longo dos sprints. 2) É destacado que nem todos os casos de teste devem ser automatizados e que é importante separar os ambientes de desenvolvimento e teste. 3) A apresentação discute diferentes níveis de automação, desde scripts lineares até abordagens data-driven e keyword-driven, concluindo que a combinação das últimas é a melhor opção
2. Apresentação
Alini Gottardi
Ciência da Computação, Unicsul, 2004
MBA em Teste de Software, Unieuro, 2012
Certificação CBTS, 2013
Desenvolvedora PHP, Tray Sistemas
Coordenadora de Qualidade, Buscapé
Analista de Automação, BM&FBovespa
Analista de Testes Pleno, Clearsale
3. Papéis na Área de Teste
Segundo o livro Base de Conhecimento em
Testes de Software
Analista de Testes
Arquiteto de Testes
Testador
Automatizador
11. Novo cenário Agile/Scrum/Kanban...
3 desenvolvedores
1 Tester multitarefa
O start da equipe é ao mesmo tempo
No primeiro dia de desenvolvimento,
tester já precisa estar trabalhando junto
Mas nem há o que testar, o que fazer???
No segundo sprint é preciso garantir que o
sprint anterior continua funcionando
13. Então vamos automatizar os testes!
Cria-se o teste uma só vez e pode ser
reexecutado N vezes
A cada novo build, podemos executar a
regressão e verificar se não quebrou nada
Um script de teste bem escrito pode ser
uma documentação executável,
diminuindo tempo de escrita
BDD
14. Então vamos automatizar os testes!
Cria-se o teste uma só vez e pode ser
reexecutado N vezes
A cada novo build, podemos executar a
regressão e verificar se não quebrou nada
Um script de teste bem escrito pode ser
uma documentação executável,
diminuindo tempo de escrita
BDD
15. BDD - Futuro da Automação?
Três princípios para BDD
1.Negócio e Tecnologia deveriam “falar”
sobre um sistema da mesma forma;
2.Qualquer sistema deveria ter um valor
identificável e verificável para o
“negócio”;
3.Análise, design e planejamento
precoce tem, sempre, retorno
questionável.
16. Por que BDD funciona?
BDD se apóia no uso de um vocabulário
pequeno e bem específico, o que
minimiza “ruídos” na comunicação de
forma que tanto TI quanto do negócio
estejam alinhados.
A “venda da ideia” para BDD costuma ser
mais fácil do que para TDD. Embora, por
envolver mais gente, seja mais
“trabalhoso” de implantar.
17. Automação Viva
BDD associa os benefícios de uma
documentação formal, escrita e mantida
pelo “negócio”, com testes de unidade que
“demonstram” que essa documentação é
efetivamente válida.
Isso garante que a documentação deixa de
ser um registro estático, que se converte
em algo gradualmente ultrapassado, em um
artefato “vivo” que reflete constantemente o
estado atual de um projeto.
22. Não é bem assim!
Se mal tem tempo de testar, quanto mais
automatizar
Escolha da ferramenta (web, desktop,
webservice)
Know-how da equipe
Complexidade e testabilidade do sistema
Papéis dentro da equipe
Não se perder desenvolvendo um sistema
versus criar testes
23. 1) Se mal tem tempo de testar, quanto
mais automatizar
Time ágil: todos os membros em busca da
qualidade e da entrega
Teste unitário dos desenvolvedores
também é testware!
Testador ajuda o desenvolvedor com a
massa de teste
Se a automação for complexa, ter um
responsável fora da equipe (arquiteto)
24. 2) Não automatizar todos os casos de
teste
Manutenção constante
Fragilidade do script GUI (Grafic User
Interface)
Relevância/prioridade do caso de teste
Falsa sensação de que está tudo coberto
25. 3) Não automatizar incertezas
Metodologia ágil é instável, os requisitos
mudam todos os dias
Evitar:
Módulos com funções ainda a serem
definidas
Testes que não serão reutilizados
Automação leva 3x mais tempo
26. 4) Quando o sistema não é testável
Testes unitários x Sistema em linguagem
procedural
Elementos HTML Inacessíveis (problema
GUI)
Janelas javascript/popup
Funcionalidades transparentes ao usuário
Antes de sair codificando, testador deve
definir seus requisitos de testabilidade
27. 5) Separar os ambientes
Testar no ambientes dos desenvolvedores
não dá certo!
Suja a base
Estraga pré-condições
Solução:
Fechar builds periódicos do dev para
teste
Se houver integração contínua melhor
ainda!
28. 6) Realizar estudo das ferramentas
Quem vai usar a ferramenta, qual o seu
propósito e quais problemas essa
ferramenta irá ajudar a resolver
Que tipo de processo ela irá suportar e
em caso de mudanças no processo, a
ferramenta pode ou não ser adequada
facilmente
Que funcionalidades a ferramenta precisa
ter (e.g. quais relatórios devem ser
extraídos);
29. 6) Realizar estudo das ferramentas
Quem deve ter acesso à ferramenta e que
nível de controle de acesso e administração
é necessário
Que tipo de interface com o usuário é
necessária (e.g. GUI ou linha de comando);
Com quais plataformas a ferramenta
precisa ser compatível;
Qual o orçamento e tempo disponíveis para
aquisição e manutenção;
30. 7) Manutenção sempre
O script fica obsoleto muito rapidamente
com as mudanças do sistema
Se não for sempre executado, acaba no
esquecimento
Dentro do planejamento do sprint prever
as manutenções
31. 8) Automação não é somente GUI
GUI = Grafic User Interface
É a primeira que os testers usam e a
primeira que dá dor de cabeça
Testes GUI devem ser usados pra testar
GUI, Smoke Tests, Tarefas sujeitas a erro
(fórmulas, partes difíceis, bugs
intoleráveis)
33. 9) Não criar sprints cascata
Não esperar dev codificar tudo
Não passar apenas automatizando e
testar só no fim
34. 10) Testadores nem sempre são
programadores
Ótimos testadores podem não saber
programar
Programadores não possuem técnicas de
teste
Utilizar maneiras onde o testador se
preocupe apenas com testes
36. Ferramentas de Automação de
Testes Funcionais
Ferramentas que permitem reproduzir a
execução manual
Possui comandos como clicar, abrir URL,
mover mouse, preencher campos
Para encontrar os objetos utiliza
posicionamento do mouse, identificador
HTML, Xpath, entre outros
Podem ser utilizadas por meio de interface
gráfica ou linha de código
Nossos exemplos utilizam Selenium
37. Técnicas GUI - Scripts Lineares
Sem laços, ciclos ou condições if
Criada por sistemas Record & Play
38. Scripts Lineares
Bom para testes que serão pouco
reaproveitados. Ex: teste de aceitação, pré-
condições
Fácil aprendizado
Massa de dados hard-coded
Script não pode ser compartilhado com
outros
Manutenção difícil
Execução frágil
41. Scripts Estruturados
Uso livre da linguagem de programação,
podendo criar laços, condições, repetições
Separar scripts em módulos para serem
reaproveitados
Massa de dados hard-coded
Desenvolvimento extenso
Dependência entre os scripts
43. Scripts Compartilhados
Mesmas vantagens do estruturado
Melhor reaproveitamento de scripts
Mesmas desvantagens do estruturado
Mais scripts para manutenção e
documentação
44. Scripts Data-Driven
A massa de dados fica fora do script,
armazenada em tabelas HTML, XML ou
CSV
Script acessa o arquivo de massa e
realiza o teste
45. Scripts Data-Driven
A massa pode ser criada por um testador
não desenvolvedor
Manutenção não envolve os dados
Facilita a reutilização de scripts
Arquitetura inicial demora para ser
construída
Exige conhecimentos sólidos de
programação
47. Scripts Keyword-Driven
A suite de testes pode ser criada por um
testador não desenvolvedor
Desenvolvedor não precisa ser expert em
testes
O caso de teste pode ser entendido por
leigos
Mesmas desvantagens do Data-Driven