1 1
KLEITOR FRANKLINT
Automação de teste
Conheça: clipzen.blog
Lean SS Black Belt certified
Kanban Coach certified
Scrum Coach certified
Lean expert and QA specialist
Uma introdução sobre estratégias

2 2
O testador e o desenvolvedor de testes
Testes manuais x automatizados
Record x codificação
Implantação de automação
Escopo de automação
Considerações sobre automação
O universo “D”

3 3
Pontos de vista – sem pretensão de verdade-
sobre como minimizar armadilhas que reduzem o
ROI e promover uma linha mais suave na
implantação e manutenção de testes
automatizados.

4 4 4
Qual o valor da automação?
“I made a lipstick robot”
https://www.youtube.com/watch?v=WcW70-6eQcY

5 5 5
A automação
-Atende a necessidade do cliente?
-Torna o time mais produtivo?

6 6 6
Desenvolvimento orientado a valor como proposta.
Mas… o que é valor?
-Necessidade gera valor!
-Cliente puxa a produção
Plan driven x client driven

Teste continuo+entregas frequentes +
Restropectivas+ muito feedback+
envolva o time+ valores ágeis
7
Como descobrir e validar necessidades?
Ou Ágil , BDD e TDD anêmicos

8IBM Confidential
Testador
e
Desenvolvedor de testes.
Imagem: https://nzdunic.info/2014/07/06/test-infected-developer/

9IBM Confidential
Testes Manuais
X
Testes automatizados
Imagem: http://www.softwaretestingstudio.com/manual-vs-automation-testing-best/

10IBM Confidential
TESTES MANUAIS
Imagem: https://productblog.townscript.com/how-to-choose-between-manual-testing-
and-automated-testing-23a4a306b1

Testes manuais
-Alto custo para funcionalidade rotineiras
-Custo de manutenção alto: custo de
identificação de mudanças, etc
-Risco de perda de qualidade na execução
por causas diversas
-Limitações quanto à integração contínua
-Colaboram para agregar valor: testar x checar
11

Testes manuais
-No universo ágil são granulados pelo ciclo de
entrega contínua: histórias testáveis, testes
exploratórios
-Apoiam enriquecendo cenários para testes
automatizados
-Complexidade aumenta quando há
dependência
-Requerem mais esforço no custo de
manutenção
-Pões em risco a documentação viva
12

Teste automatizado
13
-Colabora com a reusabilidade
-Apoia e possibilita integração contínua
-Se usar TDD já refatora o código
-Curva inicial de aprendizagem não é pequena
-É sobre codificação (de alguma forma)
Imagem: http://blog.qatestlab.com/2012/02/03/the-necessity-of-software-test-
automation/

Teste automatizado
14
-Custo alto nas primeiras etapas
de implantação e manutenção
-Pode frustar e trazer novos problemas
quando não está apoiado por uma
estratégia de implantação e manutenção

Teste automatizado
15
-Inicialmente caro e não faz melhor trabalho
que os testes manuais.
-Requer tecnologia adicional: conhecimento x
recurso x compatibilidade
-Nem todos os testes manuais poderão ser
automatizados
-Só pode verificar resultados de máquina
interpretáveis
-Não um substituto para testes exploratórios

16
-Melhor utilização de recursos humanos
-Tempo de ciclo de teste reduzido
-Custo reduzido de testes, após o custo inicial de
implementação
-Testes reproduzíveis com confiabilidade
-Ampliam cobertura de teste, já que o teste pode
ser feito com mais frequência
Testes automatizados
Quando efetivos

17IBM Confidential
Record e Playback
X
Codificação

18IBM Confidential
Fácil de se quebrar: fragilidades na UI,
sessions, etc.
Não requer programação
Fácil inicialmente de criar
Difícil de manter: coesão x acoplamento
Um pouco de prática com Selenium IDE
Record e Playback

19IBM Confidential
Pensando em implantar
Automação de teste?
-Compreenda a necessidade/requisito de
automação
-Identifique e trate armadilhas
-Promova implementação incremental
-Comece simples e aumente a complexidade
com as habilidades do time

20IBM Confidential
-Identifique o custo do teste manual x automatizado
-Em quanto tempo o reuso cobre os custos operacionais?
-Que fatores impedirão que ele seja reutilizável e de ampla
utilização?
-Ele pode encontrar bugs que não estão diretamente
relacionados ao teste?
Pensando em implantar
Automação de teste?

21
O QUE AUTOMATIZAR?
-Casos de teste de longa duração, repetitivos e não
subjetivos
-Projetos/produtos que têm uma GUI de trabalho
relativamente estável
-Projetos/produtos que irão abranger várias versões
Imagem: http://www.cmbi.com.au/0095_ReportAutomation.html

22
O QUE NÃO
AUTOMATIZAR?
-Testes longos e complicados que requerem
intervenção humana
-Testes que levam muito tempo e difíceis de
assegurar reusabilidade mesmo se
automatizados
-Testes de usabilidade

-Use padrões de desenho que provam alta coesão e minimize
dependências
-Estabilize a app
-Minimize o distúrbio de novas funcionalidades sobre as
existentes;
-Identifique a interface que será testada antes de começar:
será a GUI?
-Escolha a ferramenta e descubra suas limitações
Considerações para
a automação

-Construa mantendo a extensibilidade
-Tenha logs da sua automação
-Arquitetura de automação alinhada com a de software
-Softwares desenhados para testabilidade
Considerações para
a automação

-Separe “o que” do “como”:
Testadores e implementadores
Objetos e arquitetura
-Defina os objetivos de design: manutenibilidade, robustez,
escalabilidade, portabilidade, confiabilidade, framework bem
documentado, etc.
Considerações para
a automação

26
Ferramentas e ambientes de automação funcional
http://codoid.com/functional-automation-testing-services/

27
Ferramentas de automação - performance

28
Ferramentas de automação- Pentest
Imagem: https://www.youtube.com/watch?v=u01xjySPUKA

“D” de design, “D” desenvolvimento
BDD
TDD
ATDD
E os outros “D”?
AMDD
DDT
TDDD
TDDWD
O Universo “D”

30 30
Test Driven Development (TDD)
30Figura: Acceptance Test Driven Development, Naresh Jain
 O que é?
-Neste nível é sobre automação de teste. Criar
(mas não só) testes unitários seguidos do código.
Seu ciclo:
-Criar um teste que reprove, escrever o código
para aprovar, refatorar o código.

31 31 31
Então não é a mesma coisa que um teste unitário?
Não, “testes unitários” focam na lógica do código, TDD foca
no negócio.
Test Driven Development (TDD)

32 32
 Manutenibilidade
-Mais fácil manutenção: menor injeção de dependências
-Melhoria continua do design
- Refatora o código em tempo de desenvolvimento
- Provoca e promove testabilidade
 Orientado a valor
-Valida o código do ponto de vista do negócio
 Facilita a aprendizagem
-Auxilia time a entender o código e aprender mais rapidamente;
-Minimiza intermediários
TDD

33 33 33
 Debug x Test First: reativo x proativo
-Localização do bug mais rápida pela execução da suite de teste
 Entrega e integração contínua
-Produz teste de aceitação, integração e regressão
 Documentação viva
-Mantem a documentação sobre o código atualizada
-Agente estratégico na engenharia de conhecimento
-Basta rodar e aprender
TDD

34 34 34
 Melhora produtividade
-Agente colaborador de produtividade
-Auxilia a promover ritmo sustentável
-Integra o time
 Ferramenta de apoio a comunicação
-Experimentar e ganhar feedback
-Risk First
 Gestão de Falha x TDD
-Modelo proativo, dinâmico e vivo de gerir falhas
TDD

35 35
TDD: Frameworks
35
Natural: NUnit
PHP: PHP Unit
Java: Junit, TestNG

36 36 36
Teste de aceitação com
Fonte da imagem: http://istqbexamcertification.com/what-are-the-different-agile-testing-methodology-test-driven-development-behavior-driven-development/
BDD
-Behavior Driven Development
-Behavior Driven Design
É sobre automação… mas é só?
Não… logo conversamos mais

37 37 37
E no começo só havia desenvolvedores
… e então surgiram analistas, testadores e stakeholders
Quem precisa
de BDD?

38 38 38
Como modelar a necessidade do cliente?
Dois universos…
“informações de valor” e “bug zero”
Quem precisa de BDD?

39 39 39
Quem precisa de BDD?
É sobre modelar a árvore de diferentes
pontos de vista
Não é mais sobre desenvolver sistemas…
é sobre o sistema que o cliente quer
é sobre ser produtivo na produção

40 40 40
BDD critério de aceitação
Desafio: expressões individualizadas do critério
Specification-By-Example with Gherkin, CHRISTIAN HASSA

41 4141
O que é
BDD (Behavior driven design)
• Prática onde a comunicação se faz por um vocabulário comum
encorajando a colaboração entre todo o time.
• Forma de escrever teste de aceitação ( ATDD ) com exemplos
DBE ( design by example).
 Foca nas razões pelas quais o código deve ser criado, e não em
detalhes técnicos
 Em vez do termo "testes" , preferimos “cenário" e
"especificação“

42 42 42
10 anos fazendo BDD
totalmente errado
Liz Keogh
https://www.youtube.com/watch?v=2EM4itu7j7I
O que faz valer à pena?

43 43
BDD em nível de implementação tem
duas partes Visão
viva do
cliente

44 44
BDD: Frameworks
44
Ruby: Cucumber
Java: JBehave, at all
PHP: Behat, at all.

45 45 45
 Melhora a captura da necessidade do cliente
- Ilustra comportamento com exemplos vivos
- Usar exemplos concretos quando se discute requisitos;
- Útil para finanças porque não intrínseco;
- Valida e roda o produto ao mesmo tempo:
Responde: Como modelar a aceitação em tempo de demonstração?
 Melhora a comunicação
- Promove linguagem universal entre times e envolvidos
- Permite Experimentar e ganhar feedback
BDD

46 46 46
 Entrega e integração contínua
 Produz teste de aceitação, integração e testes de regressão
 Gestão de Falha x BDD: mais proativo
 Melhora produtividade:
- quando o processo está maduro
- Produz colaboração: negócio x técnico
 Pode ser orientado a Riscos
 Facilita a aprendizagem ( engenharia do conhecimento)
 Documentação viva (Basta rodar e aprender)
BDD

47 47
Referencias
1- Automation Training, Strategy, Approach & Planning
2- Automated Testing vs Manual Testing, By Bhavin Turakhia
3- Achieving business benefits through automated software testing, By Dr. Mike Bartley, Founder
and CEO
4-Certified Tester Advanced Level Syllabus. Version 2016, International Software Testing
Qualifications Board

48 48
Imagens
1- https://www.eremedia.com/tlnt/hr-strategies-for-dummies-4-elements-that-better-be-part-of-it/
2- http://www.adcet.edu.au/oao/for-academics-and-teachers/teaching-strategies-for-students-with-a-specific-learning-
disability/
3- https://www.theodysseyonline.com/opinions-and-why-yours-is-wrong

49 49
Parabéns!!!!!
Seu time conseguiu