Mão na massa utilizando BDD - Ganhando mais agilidade nas suas especificações de produto

Artigo quentinho saindo do forno pela chef Thayna! Hoje quero compartilhar meus aprendizados utilizando o BDD para ganhar mais agilidade nas minhas especificações de produto!

Cardápio de Produto

3 min

Artigo quentinho saindo do forno pela chef Thayna!

Bom, neste post de hoje não vou entrar muito em detalhes sobre a etimologia da palavra e blablabla do BDD (Behavior Driven Development), pois considero que você já deve estar cansado de ver sobre a teoria em outros blogs.

Por isso hoje quero compartilhar meus aprendizados utilizando o BDD para ganhar mais agilidade nas minhas especificações de produto!

Mão na massa!

Durante minhas especificações, fui notando que vários comportamentos se repetiam nos produtos que eu trabalhava, independente do contexto, ou seja, comportamentos padrões. Por muitas vezes eu fui copiando esses comportamentos de um ipara o outro. Isso mesmo, um CTRL + C e CTRL + V.

Com o tempo fui percebendo que poderia ganhar mais agilidade nesse processo de especificação e também evitar retrabalho, porque eu sempre precisava ficar atualizando os backlogs quando algo no BDD era alterado.

Foi aí que surgiu a ideia de criar uma base de conhecimento com BDDs padrões.

Essa base genérica já foi criada em uma Wiki dentro da própria ferramenta utilizada pelo time de engenharia, o Azure DevOps. O intuito de manter dentro dessa ferramenta era que os desenvolvedores já tinham familiaridade com a sua utilização, então tudo continuava dentro do “seu ambiente” de desenvolvimento.

Foram mapeados os comportamentos que mais se repetiam nos nossos produtos e descritos no formato BDD, mas de uma forma genérica. Alguns exemplos de BDDs genéricos que criamos:

Campos obrigatórios não preenchidos


          
            Dado que o usuário tenha acesso / permissão [NOME_PERMISSÃO]
          
          
                E que está cadastrando ou editando [ALGUMA_COISA]
          
          
                Quando ele não preencher todos os campos obrigatórios
          
          
                Então o botão de salvar ficará desabilitado
          
          
                E os campos obrigatórios ficarão destacados em vermelho desde que já tenha tido foco do cursor

Identificação de alterações ao atualizar página - Opção RECARREGAR


          
            Dado que o usuário tenha acesso / permissão [NOME_PERMISSÃO] 
          
          
            E que está cadastrando ou editando [ALGUMA_COISA] 
          
          
            Quando tiver alterações não salvas 
          
          
            E ele atualizar a página do navegador Então será exibida a dialog do próprio navegador: Título: "Atualizar site?", Mensagem: "É possível que as alterações feitas não sejam salvas.", Opções: "RECARREGAR (ação primária)" e "CANCELAR" 
          
          
            E ele escolher a opção "RECARREGAR" 
          
          
            Então a página será atualizada 
          
          
            E as atualizações serão perdidas

Caracteres especiais no campo data


          
            Dado que o usuário tenha acesso / permissão [NOME_PERMISSÃO] 
          
          
            E que está cadastrando ou editando [ALGUMA_COISA] 
          
          
            Quando ele tentar inserir um caractere diferente de número no campo data 
          
          
            Então o campo não será preenchido Porque só deve aceitar números 
          
          
            E o campo data deve ter a máscara de data

Comportamento de botões do tipo ação primária


          
            Dado que um botão é do tipo ação primária 
          
          
            Quando o usuário abrir uma dialog Então o botão de ação primária estará sempre na posição inferior direita 
          
          
            E pré-selecionado, ou seja, se o usuário apertar a tecla enter, então essa ação acontece

Validação do campo e-mail


          
            Dado que o usuário tenha acesso / permissão [NOME_PERMISSÃO] 
          
          
            E que está cadastrando ou editando [ALGUMA_COISA] 
          
          
            Quando ele tentar inserir um e-mail diferente do formato nome@dominio.tld 
          
          
            Então automaticamente o campo fica destacado em vermelho 
          
          
            E com o texto informativo "E-mail inválido" 
          
          
            Porque só deve aceitar no formato de e-mails

Com esses BDDs genéricos criados, os backlogs começaram a ter apenas a referência desses comportamentos padrões:

Além de agilizar o trabalho de especificação, também tivemos alguns outros benefícios:

Ajudou a deixar claro para o time de engenharia alguns padrões que eram utilizados nos nossos produtos
Ajudou o trabalho do time de QA: facilitou o mapeamento dos casos de testes deixando claro quais os comportamentos e as saídas esperadas
Ajudou a garantir a consistência dos nossos produtos: sempre que um novo formulário é criado dentro das nossas aplicações por exemplo, todos os colaboradores já sabem que esse campo deve ficar destacado quando não for preenchido. Também sabem que sempre que um campo moeda é criado, não deve ser possível adicionar caracteres que não sejam números e etc…

Melhoria contínua, sempre!

E a grande “magia” desse rolê todo não foi a criação de uma base genérica de BDDs em si. O grande segredo (e um desafio também) é manter isso vivo. Seja atualizando-a ou mantendo-a na rotina dos times.

Sempre nas plannings e dailies da vida, aproveitamos para compartilhar com o time que algum BDD foi atualizado ou novos foram criados.

Learn

Support

More Options