Trata sobre como todo o time pode realizar testes ágeis

1. Kleitor Franklint

2. KLEITOR
Entusiasta da Vida,
Qualidade,
Colaborativos,
Ágil,
Teste e
Testes Ágeis.
2
kleitor.franklint@gmail.com
br.linkedin.com/in/kfranklint
99416-0873

3. Um overview do Universo Ágil e de como todo o
time pode melhorar e agregar valor ao produto
com testes ágeis.
3

4. 4
Agile ALM - Jurgen Appelo
Repensando o saber.
Essencialmente todos os modelos estão errados, mas alguns são
úteis
George E. P. Box

5. O que é “Ágil”, Afinal?
 Agil não é metodologia, mas praticas uteis,
principalmente comportamentais
 Agil é adaptativo ao invés de prescritivo
 Agil é orientado a pessoas ao invés de orientado
a processo.
 Maximiza o valor do negócio com processos e
documentação right-sized, just-enough, e just-
in-time
5

6. 6
 Capacidade de rapidamente priorizar o uso de recursos quando
requisitos, tecnologia e conhecimento mudam com o objetivo de
lucrar em um mundo empresarial global turbulento
 Uma resposta muito rápida às mudanças súbitas de mercado e
ameaças emergentes através de interação intensiva com o cliente
com base em: http://davidfrico.com/rico14n.pdf, Lean & Agile Enterprise Frameworks
O que é “Ágil”, Afinal?

7. AGILE - MITOS DOS ÚLTIMOS 20 ANOS
•Métodos ágeis são apenas para desenvolvimento de
software
•Métodos ágeis são apenas para pequenas equipes
colocalizados
•Métodos ágeis não têm nenhuma documentação
•Métodos ágeis não têm requisitos
7

8. MITOS DOS ÚLTIMOS 20 ANOS
8
•Métodos ágeis precisam de arquiteturas de sistema tradicional
•Métodos ágeis não têm gerenciamento de projeto
•Métodos ágeis são indisciplinados e não mensuráveis
•Sistemas construídos usando métodos ágeis são impossíveis de
manter e inseguros
(Bicho papão)

9. Mundo Ágil e produtividade
Um estudo independente feito com amostras de mais de 8.000 projetos mostrou que equipes ágeis
são, em média, 25% mais produtivas do que seus pares da indústria.
http://www.deltamatrix.com/why-are-agile-teams-25-more-productive
9

10. 10
Insanidade é fazer a mesma coisa repetidamente e esperar resultados
diferentes.
Definição de insanidade por Albert Einstein
Repensando o fazer.

11. 11
Mas, não é testador que testa?
rsrs.. Já sei, são aqueles testes que
o pessoal de TI e o cliente fazem
usando o produto pronto.
Não, gente. Essa ideia tá
ultrapassada faz 20 anos!
Não!!! Todo mundo pode melhorar o
produto testando!
Repensando que o time todo pode tornar o produto melhor usando
testes!!
Repensando o que, mesmo?

12. Teste para quê, mesmo?
http://www.deltamatrix.com/why-are-agile-teams-25-more-productive
12
The BUG is on the table!!!

13. “O objetivo dos testes é agregar valor o mais cedo possível ao produto”.
Modelagem projetando, modelagem executando
Modelar comportamento do cliente..E SE..
13
Teste para quê, mesmo?

14. Testes Ágeis: um conceito
14
São Práticas “ágeis” principalmente
comportamentais, aplicadas a Teste de
Software, nas quais o teste faz parte do todo e
o todo faz parte do teste.
Não partidarismos, Sim colaboração.

15. Ciclo de vida de projeto orientado a Alice
Ciclo de vida orientado à incerteza
Requisitos de
negócios
Requisitos
funcionais
desenvolvimento Entrega
Suposições Hipóteses Experimentos Validação
15
Modelagem Orientada a teste,
Pra quê?

16. Quadrantes ágeis de Teste: apoiar , desenhar e criticar
16
Agile Testing: Past , Present and Future, Asheesh Mehdiratta, Sonik Chopra
Qualidade externa – construindo o produto certo
Qualidade interna – construindo certo o produto

17. Testes orientados a valor para
todo o TIME!! 

18. 18
Cê sabe o que teste
exploratório?
Rsrs...Gente esse aí é “ad hoc”,
também conhecido como “testa
aeh!”
Mas, pra quê Teste Exploratório?
Claro!!! Navegar pelo Sistema
buscando bugs!!
Por que usar Exploratórios?
Software perfeito e outras ilusões

19. 19
Não consigo cobrir com
antecedência todas as condições
...e é muita coisa que leva tempo!
configurações, interações, execução,
sumarização... rsrs
...e o conhecimento?! dados,
cenários, configurações... nem se
fala!
...e nem todas condições são úteis
de serem cobertas
Por que usar Exploratórios?
Software perfeito e outras ilusões

20. 20
Teste Exploratório: Características
Gente, desculpa, ainda não entendi o
que é teste exploratório
Essa é fácil!!! Design, execução e
aprendizagem ao mesmo tempo
Deixa comigo!!! Seus elementos são
três..
James Bach’s 2003 paper, “Exploratory Testing Explained.”
“Exploratory testing is simultaneous learning, test design, and test execution.”
É estruturado. Não é “Testa
eah!”
Seu ponto de partida são ideias,
propósitos e missão definidas
Identificar riscos críticos,
necessidades e fatores de qualidade
Porque o objetivo é agregar valor ao
produto Por quê?

21. 21
Por que usar Exploratórios?
Software perfeito e outras ilusões
O que posso explorar?
Pode explorar desde a concepção até pós-
estrega... rsrs
...e o todo o time participa!
Analistas, desenvolvedores,
designers, testers...
...tudo, de requisitos, sistemas a
ambiente

22. 22
TESTECOMSCRIPT X EXPLORATÓRIO

23. 23
Alguns pontos de vista
-Aceitação do cliente como base, seja ele qual for;
-Só como pré-entrega do produto é subutilizar a inteligência produtiva da empresa:
muito gasto pouco ROI
-No Ágil é executado em todo o ciclo de vida do produto
-Aproxima o produto da necessidade do cliente no teste de aceitação final ( UAT )
-Agrega muito valor ao produto
-Gera padrão pra desenvolvedores
Teste de aceitação

24. 24
Sim!!! Em todo o ciclo de vida do
produto
Teste de aceitação
Não!!! Só depois do produto pronto

25. 25
Driving Development with Tests:ATDD and TDD, Elisabeth Hendrickson
Todo o time
explora e
modela
Time explora e
remodela testes
de aceitação
Time apoia e
modela testes
de aceitação
Teste de aceitação: ATDD
Testadores e
desenvolvedores
modelam testes de
aceitação

26. 26
Teste de aceitação com
Modelagem Orientada a Comportamento
Se há cliente então Explorar requisito com Teste de aceitação
Se o cliente puder testar então Explorar requisito com Teste de aceitação
Modele Sistemas desenhando comportamentos
usando exemplos
Modele Sistemas com
BDD (Behavior driven design)
usando
DBE ( design by example).

27. 27
Problema: expressões individualizadas do critério
Specification-By-Example with Gherkin, CHRISTIAN HASSA
Teste de aceitação

28. 28
Teste de aceitação com
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“

29. 29
Quebrando requisitos em cenários que
expressem comportamento através de exemplos
https://pythonhosted.org/behave/philosophy.html
Teste de aceitação com BDD
Given
um cliente menor de idade
When
venda de produto for bebida alcoólica
Then
não vender and informar ao cliente o motivo
Vocabulário comum
Aproveitado desde a concepção até a implementação

30. Desenho interno: Test Unitário
Test Driven Development (TDD)
30
Não é uma técnica para testar código ou detectar bugs
Age como uma ferramenta de apoio ao design do código
Não é para validar todo caminho possível dentro do código, mas para avaliar se o comportamento do
produto é o esperado.

31. 31
http://istqbexamcertification.com/what-are-the-different-agile-testing-methodology-test-driven-development-behavior-driven-development/
- Quando não orientados a Negócio consomem uma enorme quantidade de tempo de manutenção e
pouco ROI.
-Orientados ao valor do negócio com testes de aceitação agregam muito valor a produto.
Testadores criam massa de
dados orientada a teste de
aceitação
Facilitam entrega
contínua
Time especifica unit
tests
Desenho interno: Test Unitário
Test Driven Development (TDD)

32. BUG TRACK E REPORT – GESTÃO DE FALHAS
•Visão tradicional: rastrear e manter registo de falhas
para analisar, por exemplo, causa raiz e taxas de defeito.
Ferramentas: Mantis, bugzila, etc.
32
Testes Ágeis: como tratar defeitos?
•Visão ágil: buscar evitar “bug track tools”, meio sem sentido no Ágil. Filas de
defeitos são filas de retrabalho e desperdício

33. ALGUMAS ALTERNATIVAS DO ÁGIL À GESTÃO DE FALHAS
•Ao invés de registrar a falha, crie um teste que prove sua existência. São bons instrumentos de
comunicação. São ocumentação viva.
•Por que um teste que prove o defeito não pode ser um instrumento da ISO?
•Tente iniciar sem um DTS (defect tracking system). DTS tem sua utilidade principalmente em times
distribuídos.
33
Testes Ágeis: como tratar defeitos?

34. ALGUMAS ALTERNATIVAS DO ÁGIL À GESTÃO DE FALHAS
•Estabeleça um limite máximo de bugs por vez e os corrija o mais rápido possível. Sprints menores
auxiliam nisso. Previna
•Estabeleça um limite mínimo de correções por período: hora, dia, semana.
•Dê visibilidade aos bug cards
34
Testes Ágeis: como tratar defeitos?

35. 35
Automação de testes
Quando
 ... Quer reduzir tempo de execução de testes repetitivos
 ... Precisa de Testes de regressão com constante mudança de código
 ... Casos de teste foram extremamente explorados e a execução precisa ser rápida
 ... Precisa auditar rapidamente a confiabilidade dos testes por testador.
 ... Não precisa testar considerações visuais tais como cor da imagem ou tamanho do fonte.
Mudanças nesse contexto só podem ser detectadas por testes manuais
Fonte da imagem: http://www.precisetestingsolution.com/functional-automation-testing.php
Com base em:
http://www.base36.com/2013/03/automated-vs-manual-testing-the-pros-and-cons-of-each/
https://www.apicasystem.com/blog/automated-testing-vs-manual-testing/

36. 36
Como?
 Por features, histórias,
 Orientados a user-centered ( valor ) sob risco de gastar tempo em automação de algo que não
deveria ser automatizado
 Com ferramentas orientadas a necessidade do projeto
 Treinamento técnico em habilidades técnicas e conhecimentos de programação
 Adicionando risco na automação na estimativa de esforço
Automação de testes

37. 37
Quem participa da automação?
Todos os envolvidos que tomam decisões
- Criar cenários
Todos os que podem colaborar com cenários orientados a valor
- Criar cenários
Testadores e desenvolvedores
- Criar cenários
- Implementar e manter a automação

38. POSSO COLABORAR COM
MAIS RESPOSTAS?
38
kleitor.franklint@gmail.com
br.linkedin.com/in/kfranklint
99416-0873