Este artigo é um guia rápido para qualquer um interessado em implementar o ATDD em sua equipe e seus projetos. Ele descreve os benefícios da abordagem ágil com base em minha primeira experiência em uma equipe de desenvolvimento de software corporativo.
A colaboração é um dos núcleos de valor da metodologia ágil. Certa vez estava trabalhando em um projeto grande e então percebi a falta de colaboração entre os desenvolvedores, testers e das pessoas com foco nos negócios. A falta de clareza dos requisitos, requisições frequentes de scope-creep (funcionalidades fora do escopo), falta de visibilidade relacionado à conclusão dos testes e defeitos sendo identificados em etapas avançadas do ciclo de vida do projeto.
Entretanto, o mais importante para mim foi que ninguém fazia ideia sobre nosso framework de automação. Então todos os testes automáticos eram escritos depois que as funcionalidades eram desenvolvidas e prontas para testar. Por causa dessas observações comecei a pesquisar como as pessoas lidam com esses tipos de problemas.
Encontrei o Desenvolvimento Orientado a Testes de Aceitação (ATDD) sendo uma das abordagens utilizadas para mitigar muitas dessas questões. Esta abordagem é utilizada normalmente como sinônimo de Behavior Driven Development (BDD), Story Test Driven Development (SDD) e Specification By Example (SBE).
A principal diferença do ATDD, como oposto das outras abordagens ágeis, é seu foco em fazer desenvolvedores, testers, analistas de negócios, product owners e outros stakeholders colaborarem como uma unidade e criar um entendimento claro do que é necessário ser implementado.
Baseado em minhas próprias experiências, vou compartilhar minhas ideias de como as equipes podem implementar o ATDD em seu próprio projeto.
O contexto
Trabalhei em uma grande empresa que tinha um pensamento de startup, então qualquer ideia inovadora e feedback eram encorajados pela equipe. Rapidamente construímos protótipos para verificar se a ideia poderia melhorar nosso produto ou atingir os objetivos da empresa. Fui líder de testes em uma equipe com 25 membros, que consistia em um Scrum Master, um líder técnico e múltiplos analistas de negócios, designers, desenvolvedores e testers.
Como resultado da cultura de inovação sempre houve desorganização entre a equipe, incluindo mudanças frequentes nas características dos requisitos, indivíduos trabalhando em ambientes separados e equipes o tempo todo com o nível de motivação baixo. Isso foi interessante para mim e então me voluntariei para ajudar a encontrar a solução dessa dor, o que me levou até o ATDD.
Todo meu aprendizado e experiência com o ATDD podem ser categorizados dentro das 3 etapas abaixo.
O ciclo de implementação do ATDD
Criado por Raj Subramanian
Etapa 1 - Treinamento e experimentação
Existem diversos caminhos para abordar tarefas, especialmente quando consideramos as experiências de trabalho do indivíduo em diferentes equipes ágeis, dentro ou fora de sua atual organização.
Para trazer o entendimento comum e compartilhado sobre a equipe e sobre os objetivos da organização, é importante que haja um treinamento apropriado, especialmente quando for relacionado ao ATDD. Neste caso deveriam ser as metas, os objetivos, as expectativas e as informações sobre os resultados que surgirão a partir desta abordagem. Depois do treinamento, é importante começar a implementação em menor escala para testar coisas diferentes e receber um feedback iterativo.
Por exemplo, depois de pesquisar sobre o ATDD, expliquei para os diferentes stakeholders o porquê de precisarmos explorar essa abordagem e quais seriam os benefícios. Explicitei algumas possibilidades positivas como o aumento da colaboração da equipe, maior clareza nos requisitos, identificação de defeitos nos estágios iniciais do ciclo de vida do desenvolvimento de software (SDLC) aumentando a visibilidade e a utilização antecipada da automatização do SDLC, assim como o envolvimento de toda a equipe com o claro entendimento dos critérios de aceitação.
Durante minha conversa com os stakeholders, enfatizei que este trabalho requer experimentação e sem esta etapa poderíamos nunca conhecer seus benefícios. Depois de algumas discussões longas, decidimos separar a equipe original de 25 pessoas em dois times menores: a Equipe A com 12 pessoas, que deveria implementar o ATDD, e a equipe B com 13 pessoas, que deveria continuar os trabalhos como já estavam fazendo.
Planejei um workshop de 2 dias sobre o ATDD para o treinamento da equipe A, determinando quais conceitos faziam sentido no contexto do nosso projeto e como poderíamos nivelar a automação a partir deste processo. Então incluí uma mistura teórica e prática de exercícios no treinamento. Alguns destes exercícios são:
- Como escrever afirmações Gherkin - Given/When/Then (GWT)
- Quais são os atributos chave para uma boa user story?
- Uma demonstração do nosso framework de automação, incluindo tanto como funciona quanto como foi estruturado. Também existem exercícios de como escrever um simples código de testes automatizado como uma equipe. Antes do workshop, eu e um membro da equipe modificamos nosso framework de automação para ser sincronizado com a abordagem ATDD. Utilizamos o plugin Cucumber com Java e o Appium para o nosso framework de automação.
Etapa 2 - Aumentando a visibilidade
Quando o projeto acontece através de múltiplas sprints, é fácil perder o controle dos diferentes processos que devem ser seguidos. Então a chave é criar metas, objetivos e expectativas visíveis para toda a equipe.
Quando começamos a utilizar a ATDD, comecei simplesmente escrevendo cada progresso diário que precisava ser acompanhado no quadro branco posicionado onde nossa equipe tinha suas reuniões diárias, a daily stand-up. Para cada user story, foi adicionado um checklist de itens do que precisava ser feito antes que fosse considerada completa. Trabalhando dessa forma, não houve ambiguidade sobre qual processo do ATDD precisava ser seguido.
Um dos itens do checklist foi a reunião inicial (kick-off meeting), onde cada desenvolvedor, tester e analista de negócios discute os requisitos como uma equipe, identificando quais requisitos poderiam ser automatizados e estabelecendo um critério de aceitação da story em um formato GWT. Outro item da checklist foi o QA-Dev Handoff, onde os desenvolvedores poderiam mostrar ao tester através de uma rápida discussão como os requisitos tinham sido completos e quais unidades de testes foram escritas como parte da story.
Através deste handoff o tester aprendeu quais áreas não estavam coberta pelos testes unitários e desenvolveram um melhor entendimento da funcionalidade implementada, conduzindo melhor a cobertura dos testes. Os itens do checklist às vezes eram óbvios, bons para um entendimento claro da declaração. Incluímos um para garantir que todos os defeitos associados com a história estavam fechados e o outro com a aprovação final pelos analistas de negócios após a visualização da demonstração, garantindo que a funcionalidade estivesse construída de acordo com o conjunto de requisitos e expectativas anteriores.
Também começamos a ter um "Process Hawk", sendo um dos membros da equipe. Poderia ser um scrum master, gerente de projetos ou qualquer um que pudesse garantir que a equipe seguiria o fluxo. No meu caso, outro tester sênior acompanhou o time. Em todas as reuniões, nosso trabalho era relembrar cada integrante para que seguisse o processo ATDD, incluindo as reuniões de stand-up, de planejamento, de retrospectiva e outras reuniões de equipe.
Etapa 3- Feedback e aprendizagem iterativa
Ter um ciclo de feedback constante é crucial para a implementação de qualquer abordagem ágil, incluindo o ATDD. Fazer reuniões retrospectivas semanais ou quinzenais com toda a equipe é um caminho importante para conhecer quais partes do processo estão realmente beneficiando a equipe e quais precisam ser modificados. Como sabemos, alguma coisa que não ajuda a equipe conduz a desperdício de tempo e esforço. Como explica Brian Tracy, autor de Eat That Frog!: 21 Great Ways to Stop Procrastinating and Get More Done in Less Time states, a pior utilização do tempo é fazer algo muito bem, mas que não precisaria ter sido feito.
Na atual era da tecnologia da informação, organizações não podem aceitar o desperdício de tempo e energia em abordagens ineficientes, ao invés disso, elas precisam de um processo efetivo e enxuto. Isso combina com o princípio do livro The Lean Startup chamado validação da aprendizagem: o ciclo Construir, Medir, Aprender.
Com isso em mente, comecei a ter reuniões de 30 minutos todas as quintas com a equipe A para checar como o time estava trabalhando com o novo processo. Este foi um novo caminho para medir quais as mudanças precisavam ser feitas baseada nas reações da equipe. Esta reunião aconteceu separada da reunião de retrospectiva que ocorreu ao final do sprint de duas semanas. Essa abordagem trouxe feedback contínuo da equipe, o que nos permitiu realizar mudanças imediatas e efetivas.
O feedback não foi o único processo de check-in semanal, as reuniões standup também provaram ser fontes de informações muito valiosas. Atualizações individuais dos membros da equipe e discussões relacionadas aos pontos críticos não cobertos do processo, assim estávamos prontos para abordá los imediatamente antes que a equipe fosse afetada pelo restante da equipe.
Resumo
Como resultado seguinte do ciclo de implementação do ATDD, a equipe A passou a enxergar consideráveis diferenças na motivação, colaboração e requisitos das equipes.
Motivação da equipe
Todos começaram trabalhando como uma equipe e se sentindo empoderados. Cada pessoa foi responsável por uma story, do início ao fim. Ele ou ela garantiu que a story tinha todas as informações necessárias para começar o desenvolvimento e testar o trabalho. Os membros da equipe também garantiram que todas as questões relacionadas à story estavam concluídas. Finalmente, a pessoa foi encarregada de demonstrar a story para todos os stakeholders ao final da sprint. Esta sensação de responsabilidade aumentou significamente a motivação da equipe.
Colaboração
Reuniões de kick-off colocam os analistas de negócios, desenvolvedores e testers juntos para desenvolver um entendimento comum da user story. O QA-Dev Handoff que aconteceu antes de publicar o pacote nos servidores de QA ajudaram ambos desenvolvedores e testers a conhecerem qual teste poderia ser concluído como parte da story trazendo maior entendimento sobre as funcionalidades implementadas.
Houve uma visibilidade crescente sobre a automação desde que toda a equipe assumiu as responsabilidades, ao invés de ser uma responsabilidade apenas dos testers. Finalmente, nas reuniões de planejamento toda a equipe discutiu as stories juntos, além disso, geraram mais ideias, questionamentos e discussões. Aumentando a colaboração também direcionava ao aumento da aprendizagem, a equipe decidiu ter sessões de coaching par a par (peer-to-peer) para aprender uns com os outros. Os testers começaram fazendo testes exploratórios pareados e sessões de lunch-n-learn liderados por diferentes membros da equipe para discutir diversos tópicos relacionados à tecnologia. Tudo isso aumentou a colaboração geral da equipe.
Requisitos
Uma das principais dificuldades com nossos processos anteriores eram as mudanças frequentes nos requisitos e o scope creep. Com a abordagem ATDD foi imperativo, uma vez iniciada a story, os requisitos se tornavam bloqueados para mudanças. Qualquer mudança deve ser priorizada em paralelo com as próximas stories e adicionadas à próximo sprint. Isso reduziu a carga de trabalho tanto para o desenvolvedor quanto para o tester, e também preveniu o stakeholder de ter expectativas não realistas das funcionalidades concluídas.
Depois de observar todas as melhorias acima, a equipe B começou a implementar o ATDD também. Como resultado, toda a equipe original utilizou essa abordagem depois da experimentação regular e do feedback.
Conclusão
Recomendo a abordagem ATDD, pois se alinha com o "Shift Left Paradigm" que sugere que o desenvolvimento e os testes deveriam começar o mais cedo possível no SDLC. A visibilidade da automação aumentou quando começamos a escrever testes automatizados no início do SDLC e se transformou em uma colaboração crescente na equipe.
Relembrando, o ATDD não é uma solução definitiva. É uma abordagem ágil que fez mais sentido no contexto dos meus projetos, contudo, existem diversos caminhos para melhorar os processos nas equipes. Utilizei esta abordagem por causa do foco na melhoria dos testes de aceitação, porém, o mais importante é sua ênfase na colaboração. A peça chamada colaboração é parte integral dessa abordagem e acredito que seja também a mais valiosa.
Sobre o autor
Raj Subramanian é um desenvolvedor experiente e apaixonado por testes. Atualmente trabalha como Desenvolvedor Evangelista para a Testim.io, que fornece testes automatizados estáveis e auto-recuperáveis baseado em IA para empresas como Netapp, Swisscom, Wix e Autodesk. Raj também oferece treinamentos e consultoria mobile para diversos clientes. É contribuidor ativo da comunidade de testes, realizando palestras em conferências, escrevendo artigos, blogando, postando vídeos em seu canal do youtube, além de estar diretamente envolvido com diversas atividades relacionadas a testes. Vive atualmente em Chicago e pode ser contactado no email raj@testim.io, no seu website ou twitter. Seus vídeos sobre testes, liderança e produtividade podem ser encontrados aqui.