1.
Automação de testes para
equipes Agile
Alini Gottardi

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

4.
Analista de Testes
Planeja, analisa riscos, estabelece
prioridades de testes, cria os casos de
teste

5.
Arquiteto de Testes
Levanta e instala ferramentas, disponibiliza
e configura ambientes, garante infra-
estrutura

6.
Testador
Executa os casos de teste, documenta a
execução, elabora relatórios, investiga o
sistema em tempo de execução

7.
Automatizador
Cria sistemas que testam sistemas...

8.
Imagine o cenário atual
Equipe metodologia cascata

9.
Vamos modernizar! Vamos ser Ágeis!

10.
Novo cenário Agile/Scrum/Kanban...

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

12.
Gargalo no testador!!!

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.

18.
Exemplo – Teste Executável

19.
Exemplo - Background

20.
Todos os problemas resolvidos!
Será?????

21.
Todos os problemas resolvidos
Não é bem assim!

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)

32.
Pirâmide da Automação
Agile Testing (Janet Gregory e Lisa Crispin)

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

35.
O que automatizar?

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

39.
Scripts Estruturados
Código gerado pelo Record & Play
Manipulado para conter if, métodos e
outra vantagens da linguagem utilizada

40.
Scripts Estruturados

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

42.
Scripts Compartilhados
Abordagem dos scripts estruturados
porém os scripts comuns a vários casos
de teste

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

46.
Scripts Keyword-Driven
Abstrai a automação de casos de teste da
programação de testes
Scripts são chamados por keywords

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

48.
Combinação Keyword-Data-Driven
Reune as duas abordagens, tornando a
automação de testes totalmente
independente de desenvolvimento e
programação

49.
Scripts Keyword-Driven
Possibilidade de criar ferramentas
desktop para automação
Curva de aprendizado um pouco maior
para os testadores

50.
Perguntas?

51.
Obrigada!
Contato: alini.gottardi@gmail.com