Testes automatizados e 
especificação por exemplo 
Unindo TI e negócio através do BDD
Quem sou eu? 
• Bruno “Codeman” Bemfica 
• Trabalho com TI há 12 anos. 
• CEO/Fundador da Sonne Tech 
• Membro fundador do...
Um pouco de história 
• Até a década de 90, modelos dominantes: 
– PMI + Waterfall (1970 – Winston Royce) 
– RUP (Rational...
Um pouco de história 
Waterfall RUP
Estatísticas de projetos de software 
(fonte: Gartner Group)
Causas dos problemas 
• Desenvolver software é fácil como caminhar 
sobre a água 
• Toda a documentação do projeto costuma...
Causas dos problemas 
• “Uma estimativa é um palpite. Não há 
comprometimento implicado. Nenhuma 
promessa foi feita. Perd...
Causas dos problemas 
• Mudança de requisitos == Mudança de prazos 
• Falta de contato com o cliente == Dúvidas 
• Mudança...
Frequência de uso das funcionalidades de um software 
(Fonte: Standish Group)
Consequências dos problemas 
• Retrabalhoˆ3 
• Ciclos de desenvolvimento cada vez maiores 
• Pressão por entrega: 
– Códig...
Enquanto isso, no desenvolvimento…
Resultado
Enquanto isso, no desenvolvimento…
PMI/Waterfall e RUP 
• RUP é um modelo atrasado de 
desenvolvimento de software que não cabe 
mais no cenário atual 
• Wat...
Como mostramos ao cliente
Como é de verdade
Problemas chave 
• Metodologias ineficientes de gestão 
• Problemas de comunicação business – devs 
• Más práticas de códi...
Uma luz no fim do túnel
Manifesto ágil 
• Criado em 2001, com 17 signatários 
• Processos adaptativos 
• Prioriza entregas e não documentações 
• ...
Kanban
TDD 
• “Criado” por Kent Beck em 2003 
• Código que testa código 
• Diminui (mas não exclui) testes manuais 
• Uso de stub...
Testes automatizados e TDD
STOP!
Vantagens do TDD 
• Reduz intervalo entre inserção e correção de 
bug 
• Reduz tempo gasto em debugging 
• Induz ao refact...
Desvantagens do TDD 
• Difícil de vender 
• Difícil de começar a usar (mudar o 
pensamento) 
• Atingir o estado da arte le...
Problemas anteriores 
• Gestão engessada e focada em papel, não em 
interações e pessoas: √ 
• Código ruim, oriundo de pre...
Especificação por exemplo/BDD 
• Criado também em 2003, por Dan North, como uma 
“resposta” ao TDD 
• Foco maior em negóci...
Problemas em se mudar o jeito de 
fazer software 
• Pessoas não gostam de mudanças 
• Mudanças levam tempo 
• Mudanças tem...
Histórias de usuários 
• Eu, enquanto <papel no sistema>, preciso 
<objetivo>. Para tal, devo <funcionalidade> 
• Pilar fu...
Exemplo 
• Funcionalidade: Eu, enquanto analista de crédito, preciso checar se 
um cliente está com o nome limpo antes de ...
STOP!
Ganhos 
• Testes de funcionalidade, requisitos funcionais e 
especificação se tornam a mesma coisa. 
• Documentação centra...
Dicas para iniciar o processo 
• Evite o nome “ágil/agile” 
• Comece automatizando os testes 
exploratórios/funcionais (en...
Dicas para iniciar o processo 
• Derivar o escopo dos objetivos 
• Olhar o micro, sem esquecer o macro 
• Especificação de...
Dicas para lidar com pessoas reativas 
• Comece implementando uma prática que aumente a 
qualidade e ganhe tempo 
• Cuidad...
Filosofia de vida 
“Qualidade é sobre estar tão preparado para o 
comum que quando o incomum aparece, temos 
tempo para at...
Obrigado! 
• Twitter: @ubuntroll 
• Site: www.brunobemfica.net 
• Email: brunobemfica@gmail.com 
• PS: Não usem PHP!
Perguntas? Comentários? 
Xingamentos? 
• Ligue para o nosso sac: 0800-BDD 
• Código mostrado na palestra: 
https://github....
Bibliografia 
• Specification By Example – Gojko Adzik 
• Bridging the Communication Gap – Gojko Adzik 
• ATDD By Example ...
Testes Automatizados e Especificação Por Exemplo - Unindo TI e Negócio através do BDD
Testes Automatizados e Especificação Por Exemplo - Unindo TI e Negócio através do BDD
Testes Automatizados e Especificação Por Exemplo - Unindo TI e Negócio através do BDD
Testes Automatizados e Especificação Por Exemplo - Unindo TI e Negócio através do BDD
Testes Automatizados e Especificação Por Exemplo - Unindo TI e Negócio através do BDD
Próximos SlideShares
Carregando em…5
×

Testes Automatizados e Especificação Por Exemplo - Unindo TI e Negócio através do BDD

612 visualizações

Publicada em

Palestra sobre TDD e BDD ministrada na UFLA.

Publicada em: Software
0 comentários
3 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
612
No SlideShare
0
A partir de incorporações
0
Número de incorporações
13
Ações
Compartilhamentos
0
Downloads
8
Comentários
0
Gostaram
3
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide
  • - Royce em 1970 formalizou o waterfall como exemplo a NÃO ser seguido
    - RUP é engessado e faz com que algumas pessoas tenham mais trabalho que as outras em algumas fases (empresas perdem dinheiro pagando funcionários ociosos)
  • -Citar “O mítico homem-mês” de Frederick Brooks (1975) ao falar da adição de novos recursos ao projeto
  • - FALAR SOBRE OS PAPÉIS NO SCRUM (SCRUM MASTER, PO E ENGENHEIROS) – DIZER QUE NÃO É REGRA ESSAS RULES - RESOLVIDO O PROBLEMA DE GESTÃO, PROCESSOS ADAPTATIVOS!!
  • TDD é trabalho de preguiçoso. Citar frase sobre preguiçosos do Bill Gates
  • Falar sobre google (Se precisa mudar o código quando o teste quebra, o teste é bom. Se precisa mudar o teste sem mudar o código, ele é ruim)
  • - RESOLVIDO O PROBLEMA TÉCNICO. MAS E O PROBLEMA DE COMUNICAÇÃO???
  • - YAGNI (You Ain’t Gonna Need It)
  • - FALAR SOBRE DOCUMENTAÇÃO ANTIGA (UML, ETC) VS DOCUMENTAÇÃO VIVA
  • - Evitar agile pq já traz uma carga de conceitos/pré-conceitos em cima.
  • E.P.E == Especificação Por Exemplos – Deriving Scope é processo chave, pois objetivos são mensuráveis
    Especificação colaborativa: Nem sempre o cliente tem a solução pro problema e qdo tem, nem sempre é a melhor. Ele não sabe fazer software
    Não esquecer o macro pra não sair viajando e perder tempo em coisas inúteis em especificação
    Apoio da gestão: Chefia sabendo do processo e pagando pra ver
  • DICA: Prática não técnica (especificar as histórias de usuário do jeito que foi mostrado, por exemplo)
    TTM: Time to Market
    Bumerangues: Histórias que vão e voltam do backlog por muito tempo (PO vai se proteger dizendo que a culpa é do processo, não da especificação ruim)
    Documentação: Agile pode usar diagramas UML, especialmente o de domínio
  • - Documentação viva faz os problemas mais corriqueiros irem embora.
  • Testes Automatizados e Especificação Por Exemplo - Unindo TI e Negócio através do BDD

    1. 1. Testes automatizados e especificação por exemplo Unindo TI e negócio através do BDD
    2. 2. Quem sou eu? • Bruno “Codeman” Bemfica • Trabalho com TI há 12 anos. • CEO/Fundador da Sonne Tech • Membro fundador do PyTchê • Já passei por empresas como Groupon, Peixe Urbano e Grupo Pão de Açúcar • Desenvolvo em Python, C# e no que mais der na telha (desde que não seja PHP) • Gosto muito de felinos
    3. 3. Um pouco de história • Até a década de 90, modelos dominantes: – PMI + Waterfall (1970 – Winston Royce) – RUP (Rational) – XGH (eXtreme Go Horse )
    4. 4. Um pouco de história Waterfall RUP
    5. 5. Estatísticas de projetos de software (fonte: Gartner Group)
    6. 6. Causas dos problemas • Desenvolver software é fácil como caminhar sobre a água • Toda a documentação do projeto costuma ser feita no começo • Orçamentos fechados dependem de estimativas precisas • Estimativas dependem de critérios bem definidos
    7. 7. Causas dos problemas • “Uma estimativa é um palpite. Não há comprometimento implicado. Nenhuma promessa foi feita. Perder uma estimativa não é desonra de forma alguma. O motivo pelo qual fazemos estimativas é por que não sabemos quanto tempo algo levará.” MARTIN, Robert C. - O Codificador limpo.
    8. 8. Causas dos problemas • Mudança de requisitos == Mudança de prazos • Falta de contato com o cliente == Dúvidas • Mudanças de requisitos + falta de contato com cliente == retrabalho • Adição de novos recursos ao projeto
    9. 9. Frequência de uso das funcionalidades de um software (Fonte: Standish Group)
    10. 10. Consequências dos problemas • Retrabalhoˆ3 • Ciclos de desenvolvimento cada vez maiores • Pressão por entrega: – Código ruim e POG – Impossibilidade de refactoring – Poucos ou nenhum teste
    11. 11. Enquanto isso, no desenvolvimento…
    12. 12. Resultado
    13. 13. Enquanto isso, no desenvolvimento…
    14. 14. PMI/Waterfall e RUP • RUP é um modelo atrasado de desenvolvimento de software que não cabe mais no cenário atual • Waterfall é inútil e PMI é um excelente método de gestão… Para qualquer coisa que não seja software.
    15. 15. Como mostramos ao cliente
    16. 16. Como é de verdade
    17. 17. Problemas chave • Metodologias ineficientes de gestão • Problemas de comunicação business – devs • Más práticas de código derivadas dos problemas anteriores
    18. 18. Uma luz no fim do túnel
    19. 19. Manifesto ágil • Criado em 2001, com 17 signatários • Processos adaptativos • Prioriza entregas e não documentações • Prioriza colaborações • Responde rápido a mudanças (ciclos curtos) • Gerou N variações (XP, Scrum, FDD, ASD, etc) • Preza por boas práticas de programação
    20. 20. Kanban
    21. 21. TDD • “Criado” por Kent Beck em 2003 • Código que testa código • Diminui (mas não exclui) testes manuais • Uso de stubs e mocks facilita o foco no que interessa
    22. 22. Testes automatizados e TDD
    23. 23. STOP!
    24. 24. Vantagens do TDD • Reduz intervalo entre inserção e correção de bug • Reduz tempo gasto em debugging • Induz ao refactoring de código • Força a uma melhor escrita de código e arquitetura
    25. 25. Desvantagens do TDD • Difícil de vender • Difícil de começar a usar (mudar o pensamento) • Atingir o estado da arte leva tempo • Não testa regra de negócio x especificação
    26. 26. Problemas anteriores • Gestão engessada e focada em papel, não em interações e pessoas: √ • Código ruim, oriundo de pressa e impossibilidade de melhorias em virtude de pressão externa:√ • Comunicação entre a equipe: ?
    27. 27. Especificação por exemplo/BDD • Criado também em 2003, por Dan North, como uma “resposta” ao TDD • Foco maior em negócio do que o TDD • Utiliza linguagem ubíqua para que programadores e humanos se entendam • Testes (d)escritos pela equipe de negócios • Foco em entrada de usuários (ex: telas) e no que realmente é importante a quem usa o sistema (princípio YAGNI)
    28. 28. Problemas em se mudar o jeito de fazer software • Pessoas não gostam de mudanças • Mudanças levam tempo • Mudanças tem custos, muitas vezes bem alto$ • No mundo corporativo, ninguém tem amigos
    29. 29. Histórias de usuários • Eu, enquanto <papel no sistema>, preciso <objetivo>. Para tal, devo <funcionalidade> • Pilar fundamental: Critérios de aceitação
    30. 30. Exemplo • Funcionalidade: Eu, enquanto analista de crédito, preciso checar se um cliente está com o nome limpo antes de liberar um empréstimo. Para tal, preciso inserir que o sistema me avise sobre a situação financeira do cliente ao digitar o CPF dele no cadastro • Cenário: Cliente com nome limpo – Dado um cliente com CPF 789.456.123-00 – Quando o CPF dele não estiver na lista do SPC ou Serasa – Então o sistema deve liberar a aprovação de crédito • Cenário: Cliente com nome sujo – Dado um cliente com CPF 123.456.789-00 – Quando o CPF dele estiver na lista do SPC ou Serasa – Então o sistema deve me avisar e impedir a aprovação de crédito
    31. 31. STOP!
    32. 32. Ganhos • Testes de funcionalidade, requisitos funcionais e especificação se tornam a mesma coisa. • Documentação centralizada junto ao projeto, tornam-se uma coisa só • Documentação direta e reta, sem rodeios • Documentação é sempre atualizada junto ao projeto • Velocidade de entrega aumenta
    33. 33. Dicas para iniciar o processo • Evite o nome “ágil/agile” • Comece automatizando os testes exploratórios/funcionais (ensine Selenium aos testers) • Tenha em mente que a queda de produtividade nos primeiros meses é completamente normal
    34. 34. Dicas para iniciar o processo • Derivar o escopo dos objetivos • Olhar o micro, sem esquecer o macro • Especificação deve ser colaborativa (PO + equipe) • Validar frequentemente e automatizar a especificação (documentação viva) • Comece pelas telas (entrada de usuário – YAGNI) • Certifique-se de ter apoio da gestão
    35. 35. Dicas para lidar com pessoas reativas • Comece implementando uma prática que aumente a qualidade e ganhe tempo • Cuidado para não se queimar por desorganização alheia • Venda o processo como algo que diminui o TTM • Cuidado com os bumerangues • Agile tem documentação sim
    36. 36. Filosofia de vida “Qualidade é sobre estar tão preparado para o comum que quando o incomum aparece, temos tempo para atacá-lo” – ADZIK, Gojko “Não existe problema técnico. Todos os problemas são de natureza humana” – WEISSMANN, Henrique Lobo (www.itexto.com.br)
    37. 37. Obrigado! • Twitter: @ubuntroll • Site: www.brunobemfica.net • Email: brunobemfica@gmail.com • PS: Não usem PHP!
    38. 38. Perguntas? Comentários? Xingamentos? • Ligue para o nosso sac: 0800-BDD • Código mostrado na palestra: https://github.com/BrunoCodeman/PalestraT estes
    39. 39. Bibliografia • Specification By Example – Gojko Adzik • Bridging the Communication Gap – Gojko Adzik • ATDD By Example – Markus Gärtner • Desenvolvimento Guiado por Testes – Kent Beck • Desenvolvimento de Software com Scrum – Mike Cohn • O Codificador Limpo – Robert C. Martin

    ×