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 PyTchê

• Já passei por empresas como Groupon, PeixeUrbano e Grupo Pão de Açúcar

• Desenvolvo em Python, C# e no que mais der natelha (desde que não seja PHP)

• Gosto muito de felinos

Um pouco de história

• Até a década de 90, modelos dominantes:

– PMI + Waterfall (1970 – Winston Royce)

– RUP (Rational)

– XGH (eXtreme Go Horse )

Um pouco de história

Waterfall RUP

Estatísticas de projetos de software(fonte: Gartner Group)

Causas dos problemas

• Desenvolver software é fácil como caminharsobre a água

• Toda a documentação do projeto costuma serfeita no começo

• Orçamentos fechados dependem de estimativas precisas

• Estimativas dependem de critérios bemdefinidos

Causas dos problemas

• “Uma estimativa é um palpite. Não hácomprometimento implicado. Nenhumapromessa foi feita. Perder uma estimativanão é desonra de forma alguma. O motivopelo qual fazemos estimativas é por que nãosabemos quanto tempo algo levará.”MARTIN, Robert C. - O Codificador limpo.

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 contatocom cliente == retrabalho

• Adição de novos recursos ao projeto

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ódigo ruim e POG

– Impossibilidade de refactoring

– Poucos ou nenhum teste

Enquanto isso, no desenvolvimento…

Resultado

Enquanto isso, no desenvolvimento…

PMI/Waterfall e RUP

• RUP é um modelo atrasado de desenvolvimento de software que não cabemais no cenário atual

• Waterfall é inútil e PMI é um excelentemétodo de gestão… Para qualquer coisa quenão seja software.

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ódigo derivadas dos problemas anteriores

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

• 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

Kanban

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 queinteressa

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 refactoring de código

• Força a uma melhor escrita de código e arquitetura

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

Problemas anteriores

• Gestão engessada e focada em papel, não eminterações e pessoas: √

• Código ruim, oriundo de pressa e impossibilidade de melhorias em virtude de pressão externa:√

• Comunicação entre a equipe: ?

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)

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

Histórias de usuários

• Eu, enquanto <papel no sistema>, preciso<objetivo>. Para tal, devo <funcionalidade>

• Pilar fundamental: Critérios de aceitação

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çãofinanceira 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

STOP!

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

Dicas para iniciar o processo

• Evite o nome “ágil/agile”

• Comece automatizando os testes exploratórios/funcionais (ensine Selenium aostesters)

• Tenha em mente que a queda de produtividade nos primeiros meses écompletamente normal

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

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çãoalheia

• Venda o processo como algo que diminui o TTM

• Cuidado com os bumerangues

• Agile tem documentação sim

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 osproblemas são de natureza humana” –

WEISSMANN, Henrique Lobo (www.itexto.com.br)

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.com/BrunoCodeman/PalestraTestes

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