Given-When-Then-But – Uma maneira simples de documentar qualquer coisa

Você já teve alguma dificuldade para explicar algo para alguém? E na empresa que trabalha? Quando alguém (talvez até seu chefe) te pergunta: “E este problema aqui… o que é?”. Por mais bem articulado que você seja, dependendo da complexidade do problema, explicar com o nível de detalhamento adequado a situação não é trivial. Além da complexidade, a pessoa na qual você se dirige também deveria influenciar sua explicação: ela é um outro ABAPer? E se fosse um chefe, gerente, funcional, usuário ou um biólogo?

O problema é agravado quando você precisa explicar um evento por escrito. Mesmo que você seja um bom escritor, não saberá muito bem quem vai ler o que escreveu. Veja por exemplo a necessidade de documentar algo que é lido por muitas pessoas: um incidente/ ticket/ chamado/ requisição/ solicitação/ mudança/ problema.

Neste post explicaremos uma maneira demasiadamente simples de explicar o que precisa por escrito: seja uma especificação funcional, seja um chamado de ABAP, seja um problema que o usuário está tendo, seja sua resolução… enfim. Vale muito a pena conferir.

BDD

Para quem estava na minha palestra no SITSP, ouviu falar superficialmente sobre BDD. Pois bem, estamos também falando de BDD aqui. Sem se prender ao detalhe do que é isso, BDD usa uma técnica chamada Given-When-Then para documentar novos requisitos e testes. Mas na verdade, o conceito se aplica a qualquer coisa.

Se você tiver curiosidade de saber mais sobre BDD, recomendo a leitura da primeira metade do livro “The Cucumber Book: Behaviour-Driven Development for Testers and Developers (Pragmatic Programmers)” de Matt Wynne e Aslak Hellesoy.

Given-When-Then

Given When Then

O conceito Given-When-Then visa criar um “template” usado em todo e qualquer tipo de documentação escrita. Este template terá sempre 3 palavras já definidas e obviamente nem preciso falar quais são. Veja um exemplo de documentação de requisito escrito neste template:

Given

O Given é a parte que você define o cenário. Qual a situação atual? O que deve existir/acontecer de antemão para que o problema ou o requisito aconteça?

When

When é o “trigger” da situação. Quando o problema é percebido? Quando a nova funcionalidade é chamada?

Then

Obviamente, o Then descreve a consequência do problema ou o resultado esperado do novo requisito

But

Menos usado, o bug serve para descrever bugs. Nestes casos o Then toma a forma de “resultado esperado” enquanto o But do “que realmente ocorreu”. Veja um outro exemplo com o But.

Exemplo de BDD: Intalação do MiniSAP

Como prova que este conceito pode ser largamente aplicado, podemos usar o GWT até para descrever o procedimento de instalação do MiniSAP.

Um teste negativo

Gostou do GWT?

Aplique o Given-When-Then no seu dia a dia (começando hoje) e não esqueça de comentar abaixo.

Fábio Pagoti

Formado em Sistemas de Informação pela Universidade de São Paulo. Comecei no mundo da programação com Java mas logo caí no mundo ABAP. Estagiei na Nestlé por 2 anos e foi lá onde conheci o Furlan. Depois de efetivado fui morar no Canadá por 1 ano onde pude aprender a área de testes em desenvolvimento de software. Hoje sou consultor e instrutor ABAP, amante de projetos Open Source, Wordpress, Data Mining e da esfera SAP. Siga-me no twitter: @fabiopagoti

You may also like...

8 Responses

  1. KAZU says:

    Pagoti comentar agora nunca foi tão simples , valew mano !!

    • Fábio Pagoti says:

      Legal!! Bom saber disso! O conteúdo do blog não é só posts mas também os comentários. Gostaria de incentivar bastante os comentários do pessoal.

      Abraços!

  2. Fawcs says:

    Opa. Utilizei isso uma vez. Queria aplicar TDD numa spec. Peguei a spec inteira e transformei em BDD(não conhecia por esse nome). Acho que foi o primeiro programa que fiz que foi aprovado de primeira 🙂