Este documento apresenta os principais conceitos e práticas para testes de software ágeis, enfatizando a importância das pessoas, os diferentes quadrantes da qualidade e estratégias para o tratamento de bugs no contexto ágil.

1. 1 1
KLEITOR
Testes de software
Gestão e Kaizen
Conheça: clipzen.blog
Lean SS Black Belt certified
Kanban Coach certified
Scrum Coach certified
Lean expert and QA specialist

2. 2 2
Esta apresentação enfatiza a gestão
ágil de teste de software.
emphasize

3. 3 3
A importância das pessoas
Universo ágil de teste
Processo de testes ágeis
Ciclo de vida de testes
Estratégia x planejamento
Gestão do time de teste
Escopo de teste e parada
Quadrantes da qualidade
Tratamento de bug no Ágil

4. 4 4
A importância
das pessoas
no teste

5. 5 5
Testes não
descobrem bugs,
pessoas sim.
A importância
das pessoas

6. 6 6
-Se somos fabulosos testadores, nossas
ferramentas estendem nossas capacidades,
ajudando-nos a ser ainda mais fabulosos.
-Se não somos... ferramentas também
estendem essa capacidade
A importância
das pessoas

7. 7 7
Testes orientados a valor
Estreite a colaboração com seus stakeholders:
• Para gerar Informações de valor
• Para identificar e enquadrar histórias que respondam as
perguntas mais importantes sobre o software
Envolva os stakeholders

8. 8 8
Testes orientados a valor
Use o 3C para mover
o projeto pra frente
Envolva os stakeholders

9. 9 9 9
Tester, vc garante que não
vai mais haver perguntas?
Tipos de Stakeholders
Sem tempo
Sem Foco
Pouco receptivo

10. 10 10
Entreviste os stakeholders
Entreviste para saber o que pensam sobre
o sistema.
Suas perguntas te ajudam a explorar
eficazmente
Lista de possíveis interessados:
• Quem que te encarregou de explorar o sistema
• Suporte técnico de pessoas que têm de responder às questões do
usuário ou do cliente
• Programadores que têm de manter o sistema
• Usuários de negócios que dependem do sistema

11. 11 11
Lista de possíveis interessados:
- Gerentes de produto ou analistas que têm de
elaborar novos requisitos para mudanças no sistema
- Qualquer outra pessoa que influencie o produto de
alguma forma.
- Você pode consultá-los em uma rápida conversa
informal e agendar para mais detalhes.
Entreviste os stakeholders

12. 12 12
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
Feedback do cliente e relatório de teste
Para o que o cliente não liga:
“...Rodaram mais de 9.000 casos de teste com uma taxa de
aprovação de 98%.
• A cobertura do código cobre mais de 85%!
• Stress testado todas as noites.
• Cerca de 5.000 bugs encontrados.
• Mais de 3.000 bugs foram corrigidos!”
De “How We Test Software at Microsoft” book

13. 13 13
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
Feedback do cliente e relatório de teste
Para o que ele liga?
Times: bugs a resolver, requisitos a ajustar
Cliente: problemas resolvidos, necessidades
atendidas

14. 14 14
Teste orientado a valor
O valor de qualquer prática depende do seu
contexto. Existem boas práticas em contexto,
mas não existem melhores práticas. As
pessoas, trabalhando juntas, são a parte mais
importante de qualquer projeto orientado a
contexto.
Com base nos ensinos de James Bach

15. 15 15
Ágil
Orientado a Test First

16. 16 16
Image: https://www.youtube.com/watch?v=cmoDqkh-ss4

17. 17 17
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
Gestão de teste
Eficácia e processo
Um processo procura identificar e reutilizar
elementos comuns de alguma abordagem para
aplica-los a outras tarefas relacionadas. Seu
objetivo dentre outros:
-Fornecer meio eficaz para alcançar resultados
-Obter padrões para o time.

18. 18 1818
Fluxo
de
Teste
Em times ágeis

19. 19 19
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
Escopo de teste no
mundo ágil.
-Qual o escopo do backlog?
-Qual a necessidade do cliente?
-Quais bugs corrigiremos agora?

20. 20 20
“Popular testing tools”

21. 21 21
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
Times ágeis
Estratégia de teste versus
planejamento

22. 22 22
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
Em um projeto ágil, os times não dependem
de documentação pesada para se comunicar...
Os testadores trabalham lado a lado com o
resto do time para que os esforços de teste
sejam visíveis para todos... Portanto, a questão
que colocamos frequentemente é: Ainda existe
necessidade de planos de teste?
Fonte: Agile testing, a practical guide for testers and agile teams, book
Estratégia de teste x planejamento

23. 23 23
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
Planejamento de teste
O poder do planejamento é identificar possíveis problemas e
dependências, que trazem risco à superfície a serem
discutidos e a serem abordados, e pensar sobre a big picture.
Se o seu time decide criar um documento de plano de teste
ou não, o planejamento deve ser feito. Cada projeto é
diferente, então não espere que a mesma solução se adeque a
todos.
Agile testing, a practical guide for testers and agile teams, book

24. 24 24
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
Estratégia de teste
Plano de ação a longo prazo, que descreve uma
abordagem geral de teste. Um documento de estratégia
de teste pode ser usado para dar aos novos
colaboradores uma compreensão de alto nível de como
seus processos de teste funcionam e precisa ser
atualizado apenas quando os processos mudarem.
Baseado em: Agile testing, a practical guide for testers and agile teams, book

25. 25 25
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
Planejamento e níveis de teste
O teste comportamental da interface do usuário é
importante, mas quando é a única ou principal abordagem
para o teste, estamos muito propensos a perder tempo com
testes ineficazes e também perder áreas importantes do
produto
De “How We Test Software at Microsoft” book
Pirâmide de teste

26. 26 26
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
Pirâmide de teste
Mais
testes
Mais
ferramentas
http://steveo1967.blogspot.com.br/2015/10/mewt4-post-1-sigh-its-that-pyramid.html

27. 27 27
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
Planejamento e testabilidade
Testabilidade
Testabilidade é o grau em que o software pode ser testado
completamente e eficazmente. O método mais comum que
um testador pode usar para controlar a capacidade de
teste é simplesmente perguntar: "Como vamos testar
isso?” em todo o ciclo Ágil.
Com base em Developer Testing Building Quality into Software, book

28. 28 28
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
Testabilidade
Dependências de teste
-Funcionalidade depende de outra que
ainda não foi entregue? Indentifique o
quanto antes, use mockups, repriorize, etc
-Testabilidade não é facilmente
percebida? Brainstorm sobre a pirâmide e
quadrantes de teste, etc.

29. 29 29
Quando parar?
Alguns critérios de parada
Baseados em fluidez
-Os testes estão fluindo?
Baseados em cobertura
-O que inda há de importante a descobrir?
-Qual a data da apresentação do produto?
-Já encontrou muitos bugs?

30. 30 30
Planejamento e priorização
Campo
Perfil
Operação
"Acceptance Criteria", Kent McDonald
Prioridade:0
João

31. Quadrantes da qualidade
Em que podem ajudar no planejamento e estratégia?

32. Quadrantes ágeis de Teste: apoiar , desenhar e criticar
Agile Testing: Past , Present and Future, Asheesh Mehdiratta, Sonik Chopra

33. 33
Testes BUSINESS-FACING
Abordam de requisitos de negócio, ajudam a
fornecer o grande cenário e suficiente detalhe para
guiar a codificação. Se baseiam em exemplos e
usam linguagem de alto nível que clientes e times
podem entender.

34. Quadrantes da qualidade
que suportam o produto
34
Face de negócio
O objetivo é fornecer comentários e ajudar o time a
alcançar uma confiança imediata e constante no
software que produz.
Sua ênfase é a obtenção de informações o mais rápido
possível, em paralelo com a implementação em curso.
A coleta ocorre e os defeitos estão sendo encontrados,
essas atividades fazem parte do loop de feedback de
qualidade da equipe.
Agile testing, a practical guide for testers and agile teams, book

35. Quadrantes da qualidade
que criticam o produto
35
Face de negócio
Busca obter informações tais com: "Houve desvio da
especificação? "ou" há algum defeito nele? "
E indo além: Será que os usuários ficarão satisfeitos com o
software? O escopo do software é razoável?
Alguma funcionalidade foi esquecida?
O software funciona rápido o suficiente? O software é
compatível com os regulamentos legais?
Agile testing, a practical guide for testers and agile teams, book

36. 36 3636
BUG no ÁGIL
The BUG is
on the table!!!

37. 37 3737
Bug, defeito, falha
Impedimento, ou um
comportamento que viola as
expectativas do PO, cliente.
mais importante o
significado que o conceito.

38. 38 3838
Resultados aceitos? NÃO?

39. BUG TRACK E REPORT – GESTÃO DE FALHAS
•Visão tradicional: rastrear e manter
registo de falhas para analisar causa raiz
e taxas de defeito.
Ferramentas: Mantis, bugzila, etc.
39
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

40. 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
documentação viva.
•Tente iniciar sem um DTS (defect tracking system). DTS
tem sua utilidade principalmente em times distribuídos.
40
Testes Ágeis: como tratar defeitos?

41. ALGUMAS ALTERNATIVAS DO ÁGIL À GESTÃO DE FALHAS
•Estabeleça um limite máximo de bugs por vez ( métricas) e
os corrija continuamente à medida que os reduz.
•Estabeleça um limite mínimo de correções por período: hora,
dia, semana.
•Dê visibilidade aos bug cards
41
Testes Ágeis: como tratar defeitos?

42. 42 42
Bugs corrigidos assim que eles são encontrados:
-Reduz o custo da correção: menos tempo, menos
contexto e menos memória.
-Menos entorno, menos complexidade de código,
camadas indetectáveis e elementos a serem corrigidos
kaizen

43. 43 43
Coisas muiiito! Muito importantes
Mantenha as coisas simples, possíveis e fluídicas
Tratamento de defeitos é uma dor. A dor aumenta
quanto mais tentamos formalizar um processo para
listá-lo, qualificá-lo, ordená-lo e planejá-lo.
Cuidado com o caos e o desperdício
Defina um fluxo do “feito”
através dos testes.

44. 44 44

45. 45 45
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
Gestão de times de teste no
universo ágil

46. 46 46
Times e testes ágeis
Tester faz parte do time?
Dev e analista testam?
Tester fora do time?

47. 47 47
-Na retrospectiva analise as causas e resolva os
problemas que causam bugs.
- Crie critérios de qualidade para cada etapa à sua
gestão Kanban.
-Se precisar crie uma base de conhecimento das
soluções se isso acelera as próximas correções.
kaizen
Fluxo Contínuo

48. 48 48
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
Gerindo débito técnico
Ponha o débito técnico no seu processo
Kaizen Kata.

49. 49 49
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
Métricas Lean para teste de
software
MÉTRICAS LEAN
LEAD TIME: tempo do todo
CICLE TIME: tempo da atividade
TACK TIME: tempo entre atividades

50. 50 50
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
Métricas Lean para teste de
software
Uma medida básica Lean é o tempo que leva "do
conceito ao dinheiro", a partir do pedido de um
cliente ao software fornecido. Eles chamam essa
medida de lead time. O foco está na capacidade da
equipe "de forma repetida e confiável" entregar
novos negócios de valor. Então a equipe tenta
melhorar continuamente seu processo e reduzir o
tempo de ciclo.
Baseado em: Agile testing, a practical guide for testers and agile teams, book

51. 51 51
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
Métricas Lean para teste de
software
-Quanto tempo demora para consertar um
defeito?
-O que a equipe pode fazer para reduzir essa
latência, a quantidade de tempo que demora?
Esses tipos de métricas incentivam a
colaboração para fazer melhorias

52. 52 52
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
Exercício – parte 1
1- Backlog
No mínimo 5 histórias testáveis para a app whatsapp e
popular o taskboard com elas
2- Criar o plano de teste com base no backlog
-Tempo de brainstorm, exploração, analise de resultado
-Estratégia de priorização do backlog
-Estratégia de comunicação e correção de bugs
-Selecionar técnicas exploratórias e blackbox para os
testes

53. 53 53
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
Exercício – parte 2
3-Execução de teste e análise de resultados
-No mínimo um ciclo de testes ágeis das histórias, não é
obrigatório criar cartas de teste
-Visualização e priorização de correção de bugs
-Simulação da correção de bugs e atividade concluída
-Análise de resultado com o time
-Como base no resultado, discutir quais outros níveis de
teste poderiam ajudar a identificar problemas
-Avaliar o grau de testabilidade do produto: baixo,
médio, alto
4-Melhoria continua
-Faça uma retrospectiva com plano de ação, para
identificar pontos fracos não cobertos no ciclo de testes.

54. 54 54
Imagens
http://blog.commlabindia.com/elearning-design/effective-scenarios-for-elearning
http://vitalflux.com/what-does-agile-team-composition-look-like/
http://www.modernanalyst.com/Resources/Articles/tabid/115/ID/3127/10-Tips-for-Writing-Good-User-Stories.aspx
http://www.mathematics-monster.com/lessons/basics_division.html
http://idreflections.blogspot.com.br/2015/01/the-importance-of-being-agile-in-vuca.html
https://www.youtube.com/watch?v=G4Bo0DcenNM

55. 55 55
Parabéns!!!!!
Seu time conseguiu