Um Guia Rápido de Implementação de ATDD

Este artigo fornece um guia rápido para qualquer pessoa interessada em implementar o ATDD em suas equipes e projetos. Ele delineia os benefícios de seguir esta abordagem Ágil baseada em minha experiência em primeira mão em uma equipe de desenvolvimento de software corporativo.

Colaboração é um dos valores centrais da metodologia Agile. Uma vez, enquanto estava trabalhando em um grande projeto, notei uma falta de colaboração entre desenvolvedores, testadores e indivíduos com visão de negócios; falta de clareza nos requisitos; requisitos de escopo freqüente – criar requisitos; falta de visibilidade em relação aos testes concluídos; e defeitos sendo identificados no final do ciclo de vida do projeto. O mais importante para mim, porém, era que ninguém tinha nenhuma idéia sobre nossa estrutura de automação, então todos os testes de automação foram escritos depois que os recursos foram desenvolvidos e prontos para testes. Devido a estas observações, comecei a pesquisar como as pessoas lidam com este tipo de problemas. Como resultado, encontrei o Acceptance Test Driven Development (ATDD) como uma das abordagens utilizadas para mitigar muitos destes problemas. Ele é frequentemente usado como sinônimo de Desenvolvimento Orientado pelo Comportamento (BDD), Desenvolvimento Orientado por Testes de História (SDD) e Especificação por Exemplo (SBE). A principal distinção do ATDD, em oposição a outras abordagens ágeis, é seu foco em fazer com que desenvolvedores, testadores, empresários, proprietários de produtos e outras partes interessadas colaborem como uma unidade e criem um entendimento claro do que precisa ser implementado.

Baseado em minha própria experiência, vou compartilhar minhas idéias sobre como as equipes podem implementar ATDD em seus próprios projetos.

O Contexto

Trabalhei em uma grande empresa que tinha uma mentalidade de startup, então quaisquer idéias inovadoras e feedback foram encorajados pela equipe. Construímos rapidamente protótipos para ver se uma ideia melhoraria o nosso produto ou ajudaria nos objectivos abrangentes da empresa. Eu era o testador líder de uma equipe de 25 membros, que consistia de um mestre de scrum, um líder técnico e vários analistas de negócios, designers, desenvolvedores e testadores. Como resultado da cultura de inovação, havia frequentemente caos dentro da equipe, incluindo frequentes mudanças nos requisitos de características, indivíduos trabalhando em silos e o moral da equipe sendo sempre baixo. Isto foi preocupante para mim, então me voluntariei para ajudar a encontrar uma resolução para estes pontos de dor, o que me levou ao ATDD.

Todos os meus aprendizados e experiência com ATDD podem ser categorizados em 3 passos abaixo.

O ciclo de implementação do ATDD

Criado por Raj Subramanian

Passo 1 – Treinamento e Experimentação

Existem muitas maneiras de abordar as tarefas, especialmente quando se considera as experiências individuais de trabalhar em diferentes equipes ágeis dentro e fora de suas organizações atuais. A fim de trazer um entendimento comum e compartilhado das metas da equipe e da organização, é importante fornecer o treinamento adequado. Em relação à ATDD especificamente, ela deve incluir metas, objetivos, expectativas e a informação sobre os resultados que virão do uso desta abordagem. Depois do treinamento, é importante começar com uma implementação em pequena escala para tentar coisas diferentes e receber feedback iterativo.

Por exemplo, depois de pesquisar a ATDD, expliquei às diferentes partes interessadas porque precisávamos explorar esta abordagem e quais os benefícios que receberíamos com ela. Destaquei alguns dos possíveis positivos, tais como maior colaboração da equipe, melhor esclarecimento dos requisitos, identificação mais precoce de defeitos dentro do ciclo de vida do desenvolvimento de software (SDLC), maior visibilidade e uso mais precoce da automação no SDLC, bem como o envolvimento de toda a equipe na elaboração de critérios claros de aceitação.

Até minha discussão com as partes interessadas, enfatizei que isso exigiria alguma experimentação, mas sem experimentá-la, nunca poderíamos saber seus benefícios. Após algumas longas discussões, decidimos dividir a equipe original de 25 pessoas em duas equipes menores: A equipa A era composta por 12 pessoas, e implementaria o ATDD. A equipe B tinha as 13 pessoas restantes, e continuaria fazendo o que já estava fazendo.

Eu planejei um workshop de treinamento de 2 dias para a equipe A aprendendo sobre ATDD, determinando quais conceitos faziam sentido no contexto do nosso projeto, e como poderíamos alavancar a automação ao longo deste processo. Incluí uma mistura de exercícios teóricos e práticos no treinamento. Alguns dos exercícios estão abaixo:

• Como escrever declarações Gherkin – Given/When/Then (GWT)
• Quais são os principais atributos de uma boa história de usuário?
• Uma demonstração da nossa estrutura de automação, incluindo tanto como funcionava e como era estruturada. Houve também exercícios sobre como escrever código de teste de automação simples como uma equipe. Antes do workshop, um membro da equipe e eu modificamos nosso framework de automação para estar em sincronia com a abordagem ATDD. Usamos o plugin Cucumber com Java e Appium para o nosso framework de automação.

Source

Passo 2 – Aumentando a Visibilidade

Quando um projeto vive através de vários sprints, é fácil perder de vista os diferentes processos que precisam ser seguidos. Então a chave é tornar as metas, objetivos e expectativas visíveis para toda a equipe.

Quando começamos a usar ATDD, eu comecei simplesmente anotando cada um dos processos diários que precisariam ser seguidos em um quadro branco, que eu coloquei onde nossa equipe tinha suas reuniões diárias de stand-up. A cada história de usuário eu adicionei uma lista de verificação de itens que precisavam ser feitos antes que a história fosse considerada completa. Desta forma, não havia ambiguidade sobre o que os processos ATDD precisavam ser seguidos. Um desses itens da lista de verificação foi uma reunião de lançamento, durante a qual o desenvolvedor, o testador e os empresários discutiram os requisitos como uma equipe, identificaram quais requisitos poderiam ser automatizados e delinearam os critérios de aceitação da história no formato GWT. Outro item da lista de verificação foi o QA-Dev Handoff, onde o desenvolvedor mostraria ao testador, através de uma rápida demonstração ou discussão, como os requisitos tinham sido concluídos e que testes unitários foram escritos como parte da história. Através desta transferência, o testador aprendeu quais áreas não foram cobertas pelos testes unitários e desenvolveu uma melhor compreensão do recurso implementado, levando assim a uma melhor cobertura dos testes. Os itens da lista de verificação às vezes eram óbvios, mas é bom ter dito claramente. Incluímos um para garantir que todos os defeitos associados à história fossem fechados; outro foi a aprovação final por um empresário ao ver uma demonstração, garantindo que o recurso foi construído de acordo com os requisitos e expectativas previamente estabelecidos.

Também começamos a ter um “Falcão do Processo”. Este era um membro individual da equipe; poderia ser um scrum master, um gerente de projeto ou qualquer um que garantisse que a equipe acompanharia o processo. No meu caso, era outro testador sênior dentro da equipe; ele e eu lembramos regularmente a todos para seguir o processo ATDD em todas as reuniões, incluindo standup, planejamento, retrospectiva e outras reuniões de equipe.

Passo 3 – Aprendizagem Iterativa e feedback

A manutenção de um loop de feedback constante é crucial na implementação de qualquer abordagem ágil, incluindo ATDD. Ter reuniões semanais ou bissemanais retrospectivas com toda a equipe é uma forma importante de saber quais partes do processo estão realmente beneficiando a equipe, e quais delas podem precisar ser modificadas. Como já sabemos, algo que não ajuda a equipe leva ao desperdício de tempo e esforço. Como Brian Tracy, autor de Eat That Frog!: 21 Great Ways to Stop Procrastinating and Get More Done in Less Time afirma: “Um dos piores usos do tempo é fazer algo muito bem que não precisa ser feito”

Na era atual da tecnologia da informação, as organizações não podem perder tempo e energia em abordagens ineficazes; ao invés disso, precisamos de processos enxutos e eficazes no lugar. Isto se relaciona com o princípio do Aprendizado Validado: o ciclo Construir, Medir, Aprender.

Com isto em mente, eu comecei a ter reuniões de 30 minutos todas as quintas-feiras com a Equipe A para verificar como a equipe está se saindo com o novo processo. Esta foi uma boa maneira de avaliar que mudanças precisavam ser feitas com base nas reações da equipe. Esta reunião ocorreu separadamente da reunião retrospectiva, que foi no final das duas semanas de sprints. Esta abordagem trouxe um feedback contínuo da equipe, permitindo-nos fazer mudanças imediatas e efetivas. O feedback não foi apenas do check-ins do processo semanal; as reuniões diárias de stand-up também provaram ser uma valiosa fonte de informação. As atualizações e discussões individuais dos membros da equipe descobriram bandeiras vermelhas relacionadas ao processo, e nós pudemos imediatamente endereçá-las antes que afetassem o resto da equipe.

Resumo

Como resultado de seguir o ciclo de implementação ATDD, a equipe A começou a ver diferenças consideráveis no moral da equipe, colaboração e requisitos.

Mor moral da equipe

Todos começaram a trabalhar em equipe e se sentiram capacitados. Cada pessoa tinha uma história do início ao fim. Ele/ela garantiu que a história tivesse toda a informação necessária para começar o trabalho de desenvolvimento e teste. O membro da equipe também garantiu que todos os seguimentos relacionados com a história fossem feitos. Finalmente, a pessoa estava encarregada de demonstrar a história a todos os interessados no final do sprint. Este sentimento de propriedade impulsionou significativamente a moral da equipe.

Colaboração

As reuniões de lançamento reuniram a pessoa de negócios, desenvolvedor e testador, a fim de desenvolver um entendimento comum da história do usuário. O QA-Dev Handoff, que aconteceu antes de empurrar a construção para os servidores de QA, ajudou tanto o desenvolvedor quanto o testador a saber quais testes seriam concluídos como parte da história, e trouxe uma melhor compreensão do recurso implementado. Houve maior visibilidade na automação, uma vez que toda a equipe tomou posse, ao invés de apenas os testadores. Finalmente, nas reuniões de planejamento, toda a equipe discutiu a história em conjunto, gerando assim mais idéias, perguntas e discussões. O aumento da colaboração também levou ao aumento da aprendizagem – a equipe decidiu ter sessões de coaching peer-to-peer para aprender uns com os outros, os testadores começaram a fazer testes exploratórios em pares e sessões de almoço-e-aprendizagem foram organizadas por diferentes membros da equipe para discutir vários tópicos relativos à tecnologia. Tudo isso levou a melhorar a colaboração geral da equipe.

Requisitos

Um dos principais problemas com nossos processos anteriores foi a mudança freqüente de requisitos e o rastejamento do escopo. Com a abordagem ATDD, era imperativo que assim que o desenvolvedor começasse a trabalhar em uma história, os requisitos ficassem bloqueados. Qualquer mudança deve ser priorizada junto com as outras próximas histórias e adicionada aos próximos sprints. Isto reduziu a carga de trabalho tanto dos desenvolvedores quanto dos testadores, e impediu que as partes interessadas tivessem expectativas irrealistas de funcionalidades completas.

Após ver todas as melhorias acima, a equipe B começou a implementar o ATDD também. Como resultado, toda a equipe original usou esta abordagem após experimentação e feedback regulares.

Conclusão

Eu recomendo a abordagem do ATDD, e ela se alinha com o “Shift Left Paradigm” que afirma que o desenvolvimento e os testes devem começar o mais cedo possível no SDLC. Ele trouxe mais visibilidade para a automação quando começamos a escrever testes automatizados no início do SDLC, o que por sua vez aumentou a colaboração dentro da equipe.

Source

Remember, o ATDD não é uma solução “one size fits all”. Foi a abordagem ágil que fez mais sentido no contexto do meu projeto, mas existem várias outras formas de melhorar os processos em equipe. Usei esta abordagem por causa do foco em melhores testes de aceitação, mas mais importante por causa de sua ênfase na colaboração. A peça de colaboração é parte integrante desta abordagem, e acredito ser a mais valiosa.

Sobre o Autor

Raj Subrameyer é um estrategista de carreiras tecnológicas focado em ajudar as pessoas a conseguir o emprego dos seus sonhos e tornar-se líderes de sucesso. Ele é apaixonado por orientar profissionais para maximizar suas oportunidades e descobrir sua zona de genialidade. Ele usa sua experiência na indústria da tecnologia para pesquisar, falar e escrever sobre como podemos abraçar a tecnologia e nos tornarmos cidadãos digitais. Ele é um orador procurado em várias conferências e tem sido apresentado em vários podcasts e publicações, incluindo CEOWORLD Magazine, Authority Magazine, Career Addict, Thrive Global, Addicted2Success e The Good Men Project. Ele também é o autor do novo livro – “Skyrocket Your Career”. As suas áreas de especialização incluem o avanço na carreira, liderança, motivação, produtividade e empreendedorismo. No seu tempo livre, ele adora viajar e desfrutar de cerveja artesanal. Você pode encontrar mais informações sobre como ele serve as pessoas através do seu site.