A prática Behavior Driven Development, BDD, vem ganhando atenção crescente e cada vez mais aplicações práticas. O InfoQ Brasil convidou quatro especialistas das comunidades de desenvolvimento e testes para um painel sobre o tema. Nele, são discutidos aspectos fundamentais da técnica de BDD e seus rumos conceitos, polêmicas e formas de adoção. Os painelistas convidados foram:
- Jorge Diz - Desenvolvedor na Maps S.A. Soluções e serviços;
- Camilo Ribeiro - Consultor de QA Sênior daThoughtWorks;
- Bruno Abreu - Co-fundador da Sofist e One Day Testing;
- Guilherme Motta - Consultor Sênior da ThoughtWorks.
InfoQ Brasil: Qual a sua opinião sobre a utilização de BDD como documentação de um software, ou mesmo uma especificação executável do comportamento? Seria um fator primordial ao sucesso de um projeto?
Jorge Diz: Quando se fala em documentação, precisamos lembrar que ela é apenas um suporte para processos de comunicação. Não é um fim em si mesma, e o fato de documentar não garante que a comunicação aconteça. Pensando em BDD como um formato de documentação, a técnica tem a vantagem de promover a criação de documentos vivos, que podem ser executados contra o que está sendo implementado. Mesmo que não se implementem as chamadas aos serviços do sistema sendo testado, o formato promove um tipo de especificação mais pé-no-chão, que usa exemplos concretos. Ou seja, a filosofia é útil ainda que as especificações não virem testes executáveis.
Camilo Ribeiro: Não vejo como um fator primordial para o sucesso de qualquer projeto por um motivo muito óbvio: Software é desenvolvido sem BDD por muitos anos. Entretanto, um projeto de desenvolvimento de software enfrenta um conjunto de riscos de negócio, e muitos desses riscos estão relacionados ao produto "imaginado" e como será quando estiver pronto. O BDD, quando aliado a técnicas como Especificação por Exemplos, é capaz de reduzir significativamente esse risco, pois torna requisitos antes apresentados e discutidos de forma abstrata, em exemplos reais de utilização. Esse formato de especificação possibilita um aprimoramento da comunicação de todos os envolvidos no projeto (cliente, QAs, desenvolvedores e outros stakeholders).
Além de ajudar na compreensão do que deve ser desenvolvido, o BDD ajuda a manter sempre funcionando a suíte de testes de regressão. E é uma poderosa ferramenta para rastreabilidade dos requisitos para o código-fonte. Isso facilita na localização de defeitos e na evolução do sistema em desenvolvimento, mesmo quando esse sistema é legado. Outra vantagem do BDD é criar uma documentação que é ligada tão diretamente ao comportamento da aplicação, que qualquer mudança nos requisitos implica em mudanças do código e vice-versa; ou seja, tem-se documentação sempre atualizada.
Com as vantagens descritas acima, acredito que o BDD não é um fator primordial de sucesso, mas é algo que mitiga diversos riscos, durante especificação, desenvolvimento, testes, manutenção e entrega da aplicação.
Bruno Abreu: Vejo o BDD como uma forma de organizar e deixar claro para todos o que o sistema deve fazer - o que não deixa de ser uma especificação executável do produto. No entanto, considero o BDD como complemento à documentação do software e não substituto, uma vez que deve haver documentação mínima de base que auxilie a equipe em descrever os cenários esperados.
Acredito que o uso de BDD é catalisador para que os projetos de software tenham sucesso. Equipes muito experientes, em sua grande maioria, sabem muito bem o que fazer e estão comprometidas a ponto de fazer tudo acontecer de forma excepcional. Por outro lado, uma equipe menos experiente tem muito a ganhar, pois o que deve ser feito e os critérios de aceite ficarão muito claros para todos os envolvidos. Toda informação que deixe mais claro o que deve ser realizado ajuda.
Guilherme Motta: O BDD serve como documentação viva do software; nunca se desatualiza e implica que o time tenha o trabalho de manter os testes passando. Não o considero um fator essencial de sucesso para todo e qualquer projeto, porém. O BDD faz sentido para alguns domínios específicos, por sua complexidade ou por seu número elevado de cenários e valores esperados.
Quando os profissionais de negócio e stakeholders (ou product owners) escrevem os cenários, isso facilita o processo de desenvolvimento do software. Utilizar BDD não significa que todas as funcionalidades da aplicação terão testes de aceitação; alguns projetos utilizam BDD com sucesso para uma parte específica do sistema, por ter um maior valor de negócio ou pela sua complexidade.
InfoQ Brasil: O BDD foi inicialmente entendido como uma reação ao TDD; mas evoluiu para se focar no comportamento de sistemas completos. Você nota esta evolução?
Camilo Ribeiro: Totalmente. O BDD se tornou uma poderosa ferramenta para desenvolvimento ágil de software. Ele é documentação e código ao mesmo tempo. E é armazenado e desenvolvido da mesma forma e pelas mesmas pessoas que desenvolvem e mantêm o código fonte. Isso era uma característica do TDD, mas, o BDD não se limita ao universo restrito de design do código-fonte; trabalha com os requisitos de forma que o product owner consiga entender.
Uma prova disso é o livro Specification by Example, que ilustra o uso do BDD como importante ferramenta para a especificação e desenvolvimento de software. Sempre usa exemplos testáveis, descritos na linguagem do product owner, para ajudar a reduzir a distância de comunicação entre os diversos interessados - algo que nem o TDD e nem a documentação extensa, como casos de uso acompanhados de diversos diagramas, conseguem prover.
Guilherme Motta: O BDD se diferencia do TDD por ter o objetivo de mapear em cenários uma ou mais interações com o software e o seu comportamento ou resultado esperado.
Jorge Diz: Na verdade, noto uma evolução contrária. O BDD surgiu como "gabarito" para testes de aceitação automatizados, idealmente elaborados em conjunto com os especialistas no domínio. Mas em muitos casos a técnica acabou sequestrada por desenvolvedores, como um jargão para orientar e tornar mais fluentes os testes de apoio à programação.
É uma repetição do que vem acontecendo há mais de 50 anos. São propostas linguagens, técnicas e ferramentas para tornar mais fácil a especificação de lógica por parte de especialistas no domínio, mas quem toma conta do brinquedo novo é o pessoal de TI: já aconteceu com Cobol, SQL, query-by-example e BPEL. A exceção foram as planilhas de cálculo.
Bruno Abreu: Certamente noto essa evolução. Hoje vejo de forma clara os profissionais comentarem que o TDD trata detalhes de código, enquanto o BDD trata de detalhes do sistema como um todo. Ver esse conceito de forma mais clara na cabeça das pessoas é uma prova dessa evolução.
InfoQ Brasil: Qual o nível de maturidade da comunidade brasileira na utilização do BDD? Estamos preparados para o uso em larga escala?
Jorge Diz: Vejo o uso de BDD muito concentrado na comunidade Ruby. Mas acho que a questão não é se estamos preparados ou não. Para mim é evidente que os formatos que são utilizados hoje para especificação não funcionam nada bem. Um conjunto de cenários seguindo a fórmula "dado que / quando / então" é mais simples e substitui com vantagens os documentos de casos de uso, que em muitos casos mais confundem que comunicam. Também não é necessária a transformação entre modelos para gerar casos de teste, que hoje multiplica as falhas de comunicação, principalmente pelo fato de que normalmente cada artefato é gerado por equipes separadas que não compartilham das mesmas premissas.
Camilo Ribeiro: Acho que estamos preparados tecnicamente, mas não culturalmente. A tecnologia para implementar BDD é gratuita, as práticas são relativamente simples e o ganho é imediato. Portanto qualquer empresa que queira implementar BDD só precisa treinar a equipe de desenvolvimento. Existirão problemas técnicos, mas esses são simples de resolver. O grande problema aqui é cultural.
A maioria das empresas brasileiras ainda tem que aprender o significado do desenvolvimento ágil e entender que usar uma ou duas práticas do Scrum não é suficiente. O BDD vem como uma ferramenta para ajudar empresas que desenvolvem de forma ágil a documentar o seu software, e muitas empresas ainda dependem de casos de uso ou ferramentas de gerenciamento de escopo e requisitos para desenvolver e manter os seus softwares. Na verdade, isso não é algo do Brasil e mesmo em mercados mais avançados como EUA, Austrália e Europa. Muitas empresas ainda não estão praticando Agile e ainda não têm maturidade para desenvolver software usando BDD.
Bruno Abreu: Vejo que o assunto BDD se tornou mais popular na segunda metade do ano passado, na comunidade de testes do Brasil, e ainda vejo que o assunto é novidade para a grande maioria das empresas.
No meu ponto de vista, temos um problema cultural grande nas empresas brasileiras, pois muitas ainda olham para qualidade como algo que não é um compromisso de toda a equipe do projeto. Às vezes, as empresas enxergam de forma positiva e estão dispostas a investir, mas os profissionais não acreditam naquilo - mesmo sem terem ao menos tentado usar e se aprofundar no assunto.
Portanto, sinceramente não creio que estamos preparados para uso em larga escala. Conheço empresas que usam BDD pra valer como parte do ciclo de desenvolvimento, mas são poucas perto da quantidade de empresas de desenvolvimento de software que temos no país.
Guilherme Motta: Acredito que possuímos profissionais com experiência teórica e prática sobre BDD, mas se "larga escala" significa aplicar BDD sempre que apropriado então estamos longe. Vejo profissionais e projetos utilizando BDD apenas para ter na lista de "buzzwords"; e em outros casos, vejo projetos perdendo oportunidades de se beneficiar pelo uso de BDD por falta de entendimento e conhecimento da prática.
InfoQ Brasil: Como você vê a adoção de BDD no mundo corporativo?
Jorge Diz: Ainda muito incipiente. Isso tem muito a ver com a cultura enraizada nas comunidades de cada plataforma. As comunidades Java, .Net e PHP ainda são bastante refratárias quanto a investir no aprendizado de BDD e de especificação baseada em testes, como regra geral. Sem necessariamente seguir BDD, vejo outras formas de especificação fluente de testes de aceitação sendo adotadas. Na empresa onde estou trabalhando atualmente, há uma cultura de utilização de planilhas como especificação executável que me surpreendeu por estar madura em várias equipes de produto. Vejo que também está aumentando no mercado o interesse em FitNesse, uma wiki para especificações executáveis.
Camilo Ribeiro: Como mencionei, BDD é simples de ser implementado. Ler um ou dois livros, criar o fork de dois repositórios no github e fazer alguns testes em um projeto que possa assimilar um pouco mais de risco - isso pode ser suficiente para iniciar o uso do BDD. O segundo passo é mostrar para os interessados, principalmente os não técnicos, o valor que a técnica tem para o negócio.
Uma pessoa de negócios, como o cliente, o analista de requisitos ou o gerente de projetos, precisa ter a visibilidade de que o BDD é uma prática feita por desenvolvedores e QAs para tornar o nosso mundo, cheio de códigos, em algo compreensível para eles - e ao mesmo tempo garantir que todos os requisitos são testáveis, foram testados e continuarão sendo testados para cada mudança até o final do projeto.
Bruno Abreu: Ainda vejo um uso tímido, pois percebo que poucas empresas investem neste tipo de iniciativa. Por outro lado, enxergo um horizonte promissor, pois tenho visto com mais frequência empresas investindo em automatização de testes. Outro fator positivo é o movimento, mesmo que infelizmente e injustamente reprimido, em prol de QAs técnicos - que são peça fundamental para esta mudança cultural nas empresas.
Guilherme Motta: Em uma palavra: parcimônia. O BDD traz benefícios em alguns contextos e em outros não. Tive a oportunidade de trabalhar em um projeto onde o product owner validava os requisitos desejados, executando cenários automatizados de aceitação. Algumas vezes foi possível encontrar cenários que não tinham sido previstos pelo requisito inicial da funcionalidade. Com isso, novos exemplos foram criados para cobrir os novos comportamentos e resultados esperados.
InfoQ Brasil: Em alguns cenários a automação é realizada através da interface gráfica do sistema; em outros através do Controller. Na sua experiência quais são as vantagens e desvantagens dessas abordagens? Você vê outras opções igualmente válidas?
Jorge Diz: A automação através da interface gráfica é atraente por ser mais evidenciável para um cliente não técnico. E inicialmente é bastante divertida, pois parece que com pouco esforço podemos gerar scripts. Mas não pode ser a principal forma de automação, pois não coloca ênfase no aspecto funcional. É fácil cair na armadilha de investir tempo demais para tornar mais robustos os testes de interface com o usuário, tirando tempo de outros testes e atividades importantes relacionadas à qualidade. Outra desvantagem é que, dependendo do ambiente de desenvolvimento utilizado, o esforço até se chegar numa interface web que possa ser testada é muito longo, e isto prejudica a utilização do testes como apoio ao desenvolvimento.
O teste utilizando outras camadas da aplicação, ao contrário, requer que o miolo das funcionalidades seja exposto como serviço. Isto promove um ciclo mais saudável de experimentação da lógica funcional da aplicação, evitando a distração com os detalhes próprios da interface usuário. Os testes tendem a ser mais robustos e funcionam melhor como documentação de regras de negócio.
Camilo Ribeiro: Enquanto os testes de unidade são muito rápidos e isolados, os testes na interface com o usuário (UI) são lentos, mas cobrem cenários do usuário. Acredito que ambos os tipos são importantes e nenhum deles é eficaz sem o outro.
Precisamos desenvolver com testes que nos ajudam a escrever e refatorar nosso código e que nos deem feedback rápido sobre a implementação. Os testes funcionais que navegam pela UI, por outro lado, são testes que normalmente cobrem as dezenas de integrações que o sistema possui; mas normalmente são lentos e em alguns casos podem não ser tão determinísticos quanto os testes de unidade. Além disso, testes de unidade não nos dão feedback sobre o comportamento funcional, mas sim sobre o estado estrutural do sistema.
Em outras palavras, se os testes de unidade estão OK, podemos dizer que não há bugs naquele código, ou podemos ainda refatorar esse código de forma a manter o comportamento dos seus objetos. Mas não podemos dizer que o sistema atende as exigências do nosso product owner. Esses testes são muito importantes para manter a qualidade do código-fonte, mas normalmente não focam no negócio.
Já os testes de UI não conhecem a implementação do código; e normalmente nem sabem de detalhes como a linguagem de programação ou a arquitetura usada ou na solução sob testes. Porém, representam o comportamento do usuário e focam nos testes do negócio, e pouco na parte tecnológica. Não é à toa que várias ferramentas restringem, de forma proposital, os meios de acesso que os desenvolvedores dos testes terão ao usar a ferramenta. Isso evita que, ao usar a ferramenta, o desenvolvedor efetue operações que um usuário não conseguiria.
Bruno Abreu: No meu ponto de vista, automatizar através do controller traz algo sensacional: poder executar os seus cenários de forma rápida. Se os cenários executam rapidamente, pode-se executá-los várias vezes com pouco impacto no projeto. Por outro lado, a complexidade pode ser maior - especialmente se tivermos interfaces mal definidas e pouco testáveis; ou seja, se não houver acesso às informações críticas que permitem saber se o teste deu certo ou não. Vejo aqui um QA técnico tornando isso viável, ajudando o time de desenvolvimento a construir código testável.
A opção de automatizar via interface gráfica é mais fácil, pois há uma série de ferramentas que viabilizam isso. É tudo muito bonito, mas ainda vejo sistemas com baixa testabilidade, mesmo quando falamos de camada de apresentação - principalmente quando queremos fazer algo mais complexo.
Mas a execução via interface gráfica é mais lenta, e dependendo da quantidade de cenários automatizados, a execução frequente é inviável. Um desenvolvedor não vai esperar cinco minutos para executar um conjunto de cinco testes automatizados via interface gráfica; agora, um desenvolvedor provavelmente esperaria um conjunto de 50 ou mais testes serem executados nos mesmos 5 minutos, pois aquela execução dá e ele mais segurança sobre o que fez.
Guilherme Motta: Ambos os tipos de testes possuem vantagens e desvantagens. Quando fazemos a automação através da interface gráfica, estamos optando por um tempo de resposta mais alto; mas estamos incluindo de certa forma "testes de interface" básicos. Quando testamos no nível dos controllers, temos um tempo de resposta mais baixo, mas estamos testando no nível "de código". Essa decisão depende de como o projeto estrutura os seus testes no seu pipeline, no seu servidor de integração contínua.
InfoQ Brasil: Gostaria de fazer mais algum comentário sobre o tema de BDD e a sua adoção?
Guilherme Motta: Para aprender mais sobre BDD, existem diversos projetos open source. Um ótimo exemplo é o projeto Rapid FTR.
Bruno Abreu: Gostaria de incentivar aqueles que não conhecem ou utilizaram BDD a fazer pequenos pilotos nas suas empresas. Encontrem as pessoas estratégicas na equipe, que acreditam em qualidade e façam a coisa acontecer. Precisamos nos mexer. Quanto mais gente estiver comprometida com a qualidade, melhor para todos.
Camilo Ribeiro: O BDD não é nada sobrenatural; não é difícil de implementar nem de aprender, tem uma vasta biblioteca na internet e não é caro. Também não é uma solução para todos os problemas. Mas é uma alternativa interessante aos diversos meios de documentação que usamos normalmente, como casos de uso e histórias de usuário.
Transformar requisitos em testes foi uma grande sacada do Dan North e isso ajuda muito - não só a manter os testes de regressão, mas principalmente a entender o que deve ser desenvolvido e a evitar aqueles requisitos impossíveis de implementar. Além disso facilita o entendimento, uma vez que o BDD simplifica o desenvolvimento de histórias baseadas em exemplos e não em cenários abstratos, como casos de uso. Desenvolver software em forma de comportamentos e exemplos testáveis além se ser mais simples e muito mais intuitivo, é inclusivo - pois pessoas sem o conhecimento técnico podem entender os testes e o comportamento do sistema.
Jorge Diz: Acho que há várias trilhas a serem exploradas em torno da filosofia de especificações executáveis. O BDD é um conjunto de convenções simples, que mostrou as vantagens de especificar através de testes automatizados fluentes. Mas nem sempre essas convenções são as mais adequadas como suporte à comunicação entre os envolvidos num projeto.
Acho que o caminho é desenvolver linguagens como parte do processo de aprendizagem próprio de qualquer projeto de software. Precisamos fazer a ponte do mundo dos especialistas no domínio da aplicação, centrada em exemplos concretos, para o código executável, onde implementamos as abstrações necessárias. Já vimos que não adianta tentar fazer com que os especialistas no domínio virem programadores, por mais simples que possam parecer as ferramentas.
Sobre os participantes
Jorge Diz, aprendiz de tecnologia da informação, desenvolve, testa e tenta entender software há quase três décadas. Com frequência palestra em eventos técnicos e participa da organização de outros, como o TDC. É Mestre em Engenharia Elétrica e Bacharel em Ciência da Computação, ambos pela UNICAMP. Atualmente trabalha como desenvolvedor de produtos para o mercado financeiro na Maps Soluções e Serviços. Seus interesses incluem qualidade de software, dinâmica de equipes de desenvolvimento, e linguagens de domínio.
Camilo Ribeiro é Senior QA Consultant na ThoughtWorks em Porto Alegre. Trabalha e estuda o mundo de desenvolvimento e teste de software desde 2005, e desde 2006 tem se dedicado aos testes de software. Acredita em QAs técnicos, prática Agile. Gosta de automatizar processos e de discutir as melhores soluções com o cliente.
Bruno Abreu, co-fundador da Sofist e One Day Testing, já participou em quase uma centena de projetos dos mais variados tipos na área de testes e qualidade de software. É apaixonado pelo estudo de formas de tornar QA mais eficiente e eficaz, e acredita no trabalho de QAs se tornando cada vez menos manual e repetitivo. É Mestre em Ciência da Computação pela UNICAMP e Bacharel em Ciência da Computação pela UFMG. Acompanha ativamente o curso de especialização em engenharia de software da UNICAMP desde 2005, especificamente nas disciplinas de V&V e Manutenção.
Guilherme Motta trabalhou durante grande parte da sua carreira como consultor em diferentes companhias, com culturas e processos distintos. Nesses projetos, atuou como engenheiro e analista de testes, QA, analista de segurança, desenvolvedor, IS, além de em diversos outros papéis multifuncionais. Atualmente é Consultor Sênior da ThoughtWorks Brasil, advogando o Agile em projetos internacionais e em diversos eventos da comunidade de desenvolvimento.