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

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
User has authorization to run transaction MM01 AND
User fill the input screen with material 123 AND
Material 123 do not exist

When
User hits ENTER

Then
Popup should be displayed with different material views

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.

Given
User has authorization to run transaction MM01 AND
User fill the input screen with material 123 AND
Material 123 do not exist

When
User hits ENTER

Then
Popup should be displayed with different material views

But
Error message "Material not created" is displayed

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.

Given
ABAP Wannabe has lots of free time AND
ABAP Wannabe has MiniSAP setup AND
ABAP Wannabe has a decent PC AND
ABAP Wannabe is not lazy to read some stuff AND
(ABAP Wannabe has seen ABAP101's video OR
ABAP Wannabe follows ALL the technical prerequisites)

When
ABAP Wannabe tries to install MiniSAP

Then
MiniSAP should be installed successfully.

Um teste negativo

Given
ABAP Wannabe has lots of free time AND
ABAP Wannabe has MiniSAP setup AND
ABAP Wannabe has a decent PC AND
ABAP Wannabe is not lazy to read some stuff AND
(ABAP Wannabe has not seen ABAP101's video OR
ABAP Wannabe DOES NOT follow ONE technical prerequisites)

When
ABAP Wannabe tries to install MiniSAP

Then
MiniSAP won't be installed successfully.

Gostou do GWT?

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