Recomendados
Recomendados
Más contenido relacionado
Similar a Testar impossivel jorge diz
Similar a Testar impossivel jorge diz (18)
Testar impossivel jorge diz
- 1. Testar: impossível Jorge Diz Globalcode Agile Brazil 2010 Slide 1
- 2. Palestrrante Jorge Alberto Diz •Mestre e bacharel pela UNICAMP •Programando desde 1983 •Testando desde 1994 •Javeiro •Consultor: testes, metodologia •Criador da Academia de Testes da Globalcode Agile Brazil 2010 Slide 2
- 3. Defina teste de software em até 140 caracteres no post-it Agile Brazil 2010 Slide 3
- 4. O Jorge Diz: Testar é difícil Agile Brazil 2010 Slide 4
- 5. 5 estágios do luto (Kübler-Ross) Negação Revolta Barganha Depressão Aceitação Agile Brazil 2010 Slide 5
- 6. Percepção dos testes Agile Brazil 2010 Slide 6
- 7. Finalidade dos testes Agile Brazil 2010 Slide 7
- 8. Finalidade dos testes •Encontrar defeitos •Definir comportamento esperado •Monitoramento em produção •Conformidade com contratos •Riscos (mitigação / avaliação) •Métricas de qualidade Agile Brazil 2010 Slide 8
- 9. Isto é um elefante ? Agile Brazil 2010 Slide 9
- 10. Isto é um teste ? Agile Brazil 2010 Slide 10
- 11. Comportamento esperado requisitos testes exemplos Agile Brazil 2010 Slide 11
- 12. Especificação por Exemplos ”Exemplos não são uma outra forma de ensinar: são a única forma” Agile Brazil 2010 Slide 12
- 13. Fato Não temos um modelo consensual para teste Agile Brazil 2010 Slide 13
- 14. Modelo V Requisitos Entrega Análise Testes Design Codificação Agile Brazil 2010 Slide 14
- 15. Quadrantes de Marick Negócio Q2: GUI, regras de negócio Q3: Exploratório, (Selenium, FitNesse, usabilidade, aceitação funcional crítica ao produtoproduto suporte ao time à equipe Cucumber) Testes Crítica ao Apoio Q4: Q1: Unitários, componentes Desempenho / segurança Tecnologia Agile Brazil 2010 Slide 15
- 16. Pirâmide de Cohn Pirâmide de Cohn Interface Usuário Regras de Negócio Unidades Agile Brazil 2010 Slide 16
- 17. pirâmide alimentar Agile Brazil 2010 Slide 17
- 18. Pirâmide frágil Pirâmide frágil de testes Interface Usuário Unidades Agile Brazil 2010 Slide 18
- 19. Fluxo de problemas erro defeito falha diagnóstico correção Integração contínua / agile operations Agile Brazil 2010 Slide 19
- 20. Só vemos a casca Agile Brazil 2010 Slide 20
- 21. ...mas não o interior Agile Brazil 2010 Slide 21
- 22. Fato Só acreditamos vendo Agile Brazil 2010 Slide 22
- 23. Dashboards Agile Brazil 2010 Slide 23
- 24. Mitos Agile Brazil 2010 Slide 24
- 25. Mito Todos sabemos o que é teste Agile Brazil 2010 Slide 25
- 26. Mito Todos falamos a mesma língua Agile Brazil 2010 Slide 26
- 27. Mito Inspeções substituem testes Agile Brazil 2010 Slide 27
- 28. Mito Testes substituem inspeções Agile Brazil 2010 Slide 28
- 29. Fato Programação em duplas é a principal forma de inspeção de código em XP Agile Brazil 2010 Slide 29
- 30. Mito Automatizar tudo Agile Brazil 2010 Slide 30
- 31. Fato A maioria dos defeitos é encontrada por teste manual Agile Brazil 2010 Slide 31
- 32. Mito Podemos corrigir todos os defeitos encontrados Agile Brazil 2010 Slide 32
- 33. Fato É mais fácil encontrar defeitos que justificativas para corrigi-los Agile Brazil 2010 Slide 33
- 34. Mito Especialista no domínio escreve especificações Agile Brazil 2010 Slide 34
- 35. Fato Somos mais formais que nosso cliente. Todo formalismo destinado a usuários acabou encampado por nós Agile Brazil 2010 Slide 35
- 36. Mito Desenvolvedores sempre testaram seu código Agile Brazil 2010 Slide 36
- 37. Fato Só recentemente, e só alguns (principalmente a comunidade Ruby) Agile Brazil 2010 Slide 37
- 38. Mito Nossa responsabilidade para na entrega Agile Brazil 2010 Slide 38
- 39. Fato Nossa responsabilidade começa na primeira entrega Agile Brazil 2010 Slide 39
- 40. Kübler-Ross 1 Negação Agile Brazil 2010 Slide 40
- 41. Não necessitamos É tudo legado: já funciona há muito tempo O processo garante a qualidade Isso já deveria funcionar, para quê testar ? Agile Brazil 2010 Slide 41
- 42. Não devemos É perda de tempo: eu sou cobrado para entregar código Isso está fora do nosso escopo O esforço seria melhor investido em inspeções Agile Brazil 2010 Slide 42
- 43. Não podemos Ambiente de testes: isso não vai acontecer aqui Não temos permissão para testar Só dá para passar pelo caminho feliz Agile Brazil 2010 Slide 43
- 44. Não fazemos Melhor deixar na mão da fábrica: eles são especialistas, não nós O cliente não está disposto a testar Agile Brazil 2010 Slide 44
- 45. Kübler-Ross Agile: em que estágio estamos ? Agile Brazil 2010 Slide 45
- 46. Negação Desenvolvedor tem malícia para o teste Agile Brazil 2010 Slide 46
- 47. Negação Todos entendemos mocks Agile Brazil 2010 Slide 47
- 48. Revolta Massas sintéticas não são aceitas pelo cliente Agile Brazil 2010 Slide 48
- 49. Revolta Meu cliente não quer / não sabe escrever testes de aceitação Agile Brazil 2010 Slide 49
- 50. Barganha Mas muito do meu código é legado... Agile Brazil 2010 Slide 50
- 51. Barganha Não consigo testar as partes isoladas Agile Brazil 2010 Slide 51
- 52. Barganha Não consigo testar concorrência Agile Brazil 2010 Slide 52
- 53. Barganha Não consigo testar o banco de dados Agile Brazil 2010 Slide 53
- 54. Barganha Só dá para testar usando a interface usuário Agile Brazil 2010 Slide 54
- 55. Barganha Vamos ajeitar a definição de Pronto Agile Brazil 2010 Slide 55
- 56. Depressão Testes de interface usuário são sempre frágeis e lentos Agile Brazil 2010 Slide 56
- 57. Aceitação Integração contínua compensa Agile Brazil 2010 Slide 57
- 58. Conclusões • Como área, não temos um modelo comum para entender testes • No mercado, a área de testes está tendendo ao modelo de fábrica • Ainda se pensa em testes como consumidores de requisitos • Dificuldades técnicas exigem criatividade • Só acreditamos vendo Agile Brazil 2010 Slide 58
- 59. Contato Email: jorge@globalcode.com.br Email, Gtalk: jorge.a.diz@gmail.com • Twitter: @jorgediz • www.globalcode.com.br Agile Brazil 2010 Slide 59