GreenbarTestes automatizados na sua empresaRafael Ponte
Quem escreve testes?
http://blog.fragmental.com.br/2007/10/31/programadores-profissionais-                      escrevem-testes-ponto-final/
Você é um programador     profissional?   #provocacaogratuita
Por que testar?Para verificar se o sistema se comporta comodeveria.
Como testar?Testes manuais.Testes automatizados.
Testes automatizados.Trazem mais confiança.Identificam regressões de código.Permitem refatorar com segurança.
Tudo começou com uma      consultoria.
Erros eDesafios             Impacto          Acertos
Erros eDesafios             Impacto          Acertos
Convencer a gerência.Seria um investimento de médio-longo prazo.
Projeto já em andamento.Dificuldade para escrever testes.
Infra?Não tínhamos nada pronto!
Colaboração da equipe.Equipe de bons desenvolvedores, mas sem                  experiência com testes.
Zona de Conforto
Devs. simpatizantes.Teste de integração é teste de “maxu”!
Erros eDesafios             Impacto          Acertos
Por onde começar?           Baby steps.
Testes de UnidadeMelhorando o design das classes aos poucos.
Eclipse já vem com jUnit        Mãos à obra!
SEM mocks.  Modelo, classes utilitárias e deresponsabilidade bem definidas.
COM mocks.Utilizá-los não é tão simples quanto parece.
JMock VS Mockito
Testes de IntegraçãoTeste de “maxu” vai no banco.
Spring Testing + DBUnit
Sujar ou não sujar o banco,       eis a questão.
100% de cobertura.Esta não deveria ser sua meta.
No início era a melhor meta/métrica que      tínhamos.
Getters&SettersUm testezinho a mais não faz mal, né.
Testes mal escritos.Você vai escrevê-los, pode ter certeza disso.
Testes frágeis, poucolegíveis e com assertivas          ruins.
Refatoração Contínua        neles!
Ainda assolados pela pouca legibilidade.
Há 4-5 anos omercado gritava:                   “Antes testes                   mal escritos do                    que nen...
Buscando ajuda no BDD.  Testes são especificações executáveis.
• Nome de métodos mais expressivos• Template Given-When-Then• Nos forçou a pensar mais no  negócio e no que realmente  dev...
TDD.Somente em regras de negócio complexas.
OOP e SOLID PrinciplesSem estes conhecimentos não é tão simples ter              um bom design.
Automatizando.Automatize o máximo que você puder.
Ant + Hudson   Simples e prático.
$ git pull --rebase; ant
Excesso de informaçãoRelatório de testes, Find Bugs, PMD, Checkstyle e                     Coverage
Code Review.Relatório de testes e Coverage são suficientes.
Build do Hudson  quebrando.
Nosso mantra:“Hudson quebrou? Páratudo e conserta.”
Testes de Aceitação.Tudo ia bem, até o dia em que o número detestes cresceu demais.
Selenium/WebDriverPrecisávamos de alguém com experiência.
@handersonbfUm EMO num corpo de um OGRO.                 Selenium/WebDriver            Precisávamos de alguém com experiên...
Testando cenários     importantes.  Começamos do jeito certo.
Test Automation Pyramid        Aceitação - 10%      Integração - 40%    Unidade - 50%
More, more...Testes com granularidade fina demais.
Test Automation Pyramid                Square      Aceitação - 30%      Integração - 30%      Unidade - 40%
Mantê-los se tornou caro.Frágeis, feedback demorado, falsos negativos edifícil rastrear erros.
Nos tornamos mais   criteriosos.
Design das telas mudavaconstantemente.E nem sempre o designer rodava os testes.
Designer disciplinado.E testes de aceitação fora do build principal.
Zona de Conforto DE NOVO!
Testes difíceis de rodar.Executar o build ou levantar o Tomcat era chato.
Facilite a vida da equipe.                Jetty embarcado.
Cucumber.Cliente sem interesse de ler e muito menosescrever as features.
Erros eDesafios             Impacto          Acertos
Qualidade no software.Menor incidência de bugs e correções rápidas.
De   100% para 25%. Melhoramos nossas estimativas.
Fim do Sprint.Menor número de features entregues.
PRODUTIVIDADE.Baixa no início. Melhora durante os Sprints.
Gerência.Satisfeita com a produtividade de alguns     projetos, decepcionada com outros.
Equipe mais madura.Perceberam a importância real dos testes.
CONCLUSÃODepois de quase 2 anos escrevendo testes.
Você só percebe os benefícios dos testes entre 6 meses e 1 ano
Nem tudo são flores.Mas a gerência continua acreditando piamente nostestes automatizados.
Enfim,        VALE A         PENA.
OBRIGADO!      Rafael Ponterponte@triadworks.com.br
Greenbar - Testes automatizados na sua empresa
Greenbar - Testes automatizados na sua empresa
Greenbar - Testes automatizados na sua empresa
Greenbar - Testes automatizados na sua empresa
Greenbar - Testes automatizados na sua empresa
Próximos SlideShares
Carregando em…5
×

Greenbar - Testes automatizados na sua empresa

2.247 visualizações

Publicada em

Experiência de quase 2 anos tentando inserir e manter a cultura de testes automatizados numa empresa. Desafios e as barreiras enfrentadas ao adotar a cultura de testes automatizados nesta empresa, onde acertamos e onde erramos, como a equipe (e isso inclui os gerentes) responderam a mudança e como isso impactou nos sprints e entrega de software.

Publicada em: Tecnologia
2 comentários
6 gostaram
Estatísticas
Notas
Sem downloads
Visualizações
Visualizações totais
2.247
No SlideShare
0
A partir de incorporações
0
Número de incorporações
15
Ações
Compartilhamentos
0
Downloads
57
Comentários
2
Gostaram
6
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Greenbar - Testes automatizados na sua empresa

    1. 1. GreenbarTestes automatizados na sua empresaRafael Ponte
    2. 2. Quem escreve testes?
    3. 3. http://blog.fragmental.com.br/2007/10/31/programadores-profissionais- escrevem-testes-ponto-final/
    4. 4. Você é um programador profissional? #provocacaogratuita
    5. 5. Por que testar?Para verificar se o sistema se comporta comodeveria.
    6. 6. Como testar?Testes manuais.Testes automatizados.
    7. 7. Testes automatizados.Trazem mais confiança.Identificam regressões de código.Permitem refatorar com segurança.
    8. 8. Tudo começou com uma consultoria.
    9. 9. Erros eDesafios Impacto Acertos
    10. 10. Erros eDesafios Impacto Acertos
    11. 11. Convencer a gerência.Seria um investimento de médio-longo prazo.
    12. 12. Projeto já em andamento.Dificuldade para escrever testes.
    13. 13. Infra?Não tínhamos nada pronto!
    14. 14. Colaboração da equipe.Equipe de bons desenvolvedores, mas sem experiência com testes.
    15. 15. Zona de Conforto
    16. 16. Devs. simpatizantes.Teste de integração é teste de “maxu”!
    17. 17. Erros eDesafios Impacto Acertos
    18. 18. Por onde começar? Baby steps.
    19. 19. Testes de UnidadeMelhorando o design das classes aos poucos.
    20. 20. Eclipse já vem com jUnit Mãos à obra!
    21. 21. SEM mocks. Modelo, classes utilitárias e deresponsabilidade bem definidas.
    22. 22. COM mocks.Utilizá-los não é tão simples quanto parece.
    23. 23. JMock VS Mockito
    24. 24. Testes de IntegraçãoTeste de “maxu” vai no banco.
    25. 25. Spring Testing + DBUnit
    26. 26. Sujar ou não sujar o banco, eis a questão.
    27. 27. 100% de cobertura.Esta não deveria ser sua meta.
    28. 28. No início era a melhor meta/métrica que tínhamos.
    29. 29. Getters&SettersUm testezinho a mais não faz mal, né.
    30. 30. Testes mal escritos.Você vai escrevê-los, pode ter certeza disso.
    31. 31. Testes frágeis, poucolegíveis e com assertivas ruins.
    32. 32. Refatoração Contínua neles!
    33. 33. Ainda assolados pela pouca legibilidade.
    34. 34. Há 4-5 anos omercado gritava: “Antes testes mal escritos do que nenhum teste.”
    35. 35. Buscando ajuda no BDD. Testes são especificações executáveis.
    36. 36. • Nome de métodos mais expressivos• Template Given-When-Then• Nos forçou a pensar mais no negócio e no que realmente devemos testar• Maior interação com o cliente
    37. 37. TDD.Somente em regras de negócio complexas.
    38. 38. OOP e SOLID PrinciplesSem estes conhecimentos não é tão simples ter um bom design.
    39. 39. Automatizando.Automatize o máximo que você puder.
    40. 40. Ant + Hudson Simples e prático.
    41. 41. $ git pull --rebase; ant
    42. 42. Excesso de informaçãoRelatório de testes, Find Bugs, PMD, Checkstyle e Coverage
    43. 43. Code Review.Relatório de testes e Coverage são suficientes.
    44. 44. Build do Hudson quebrando.
    45. 45. Nosso mantra:“Hudson quebrou? Páratudo e conserta.”
    46. 46. Testes de Aceitação.Tudo ia bem, até o dia em que o número detestes cresceu demais.
    47. 47. Selenium/WebDriverPrecisávamos de alguém com experiência.
    48. 48. @handersonbfUm EMO num corpo de um OGRO. Selenium/WebDriver Precisávamos de alguém com experiência.
    49. 49. Testando cenários importantes. Começamos do jeito certo.
    50. 50. Test Automation Pyramid Aceitação - 10% Integração - 40% Unidade - 50%
    51. 51. More, more...Testes com granularidade fina demais.
    52. 52. Test Automation Pyramid Square Aceitação - 30% Integração - 30% Unidade - 40%
    53. 53. Mantê-los se tornou caro.Frágeis, feedback demorado, falsos negativos edifícil rastrear erros.
    54. 54. Nos tornamos mais criteriosos.
    55. 55. Design das telas mudavaconstantemente.E nem sempre o designer rodava os testes.
    56. 56. Designer disciplinado.E testes de aceitação fora do build principal.
    57. 57. Zona de Conforto DE NOVO!
    58. 58. Testes difíceis de rodar.Executar o build ou levantar o Tomcat era chato.
    59. 59. Facilite a vida da equipe. Jetty embarcado.
    60. 60. Cucumber.Cliente sem interesse de ler e muito menosescrever as features.
    61. 61. Erros eDesafios Impacto Acertos
    62. 62. Qualidade no software.Menor incidência de bugs e correções rápidas.
    63. 63. De 100% para 25%. Melhoramos nossas estimativas.
    64. 64. Fim do Sprint.Menor número de features entregues.
    65. 65. PRODUTIVIDADE.Baixa no início. Melhora durante os Sprints.
    66. 66. Gerência.Satisfeita com a produtividade de alguns projetos, decepcionada com outros.
    67. 67. Equipe mais madura.Perceberam a importância real dos testes.
    68. 68. CONCLUSÃODepois de quase 2 anos escrevendo testes.
    69. 69. Você só percebe os benefícios dos testes entre 6 meses e 1 ano
    70. 70. Nem tudo são flores.Mas a gerência continua acreditando piamente nostestes automatizados.
    71. 71. Enfim, VALE A PENA.
    72. 72. OBRIGADO! Rafael Ponterponte@triadworks.com.br

    ×