Os 6 Passos de uma Demo(nstração)

Bom, hoje eu quero falar sobre a importância de uma Demo e seus 6 passos d̶e̶f̶i̶n̶i̶d̶o̶s̶ ̶p̶o̶r̶ ̶m̶i̶m̶ ̶m̶e̶s̶m̶o̶. Esta é uma das armas(processos) mais importantes quando há um QA como stakeholder.

O que podemos muitas vezes observar a partir de um processo incremental, ou modelo cascata(como preferir chamar), é o engessamento no processo. E sim, isso pode ter traços dentro uma suposta metodologia ágil, onde o modelo iterativo deveria reinar.

Poderia descrever melhor para mim Diego???

Claro! O QA no modelo incremental fica ocioso durante muito tempo, ele participa, quando muito, da definição do escopo e no fim do desenvolvimento para validar se de fato cumpriu-se o esperado. Isso é de uma estupidez absurda! Se o stakeholder, que tem o poder de invalidar a task a ponto de duplicar o tempo de desenvolvimento, aparecer somente ao fim do processo é simplesmente um passo de fé e esperança que tudo vá ocorrer bem.

A dica é: COMUNICAÇÃO SEMPRE!

Portanto esses com 6 passos que vou ilustrar, o QA irá aparecer pelo menos em dois momentos em um processo de:

1. To do
2. In Progress
3. Code Review
4. Test
5. Done

Passo 1 — O Diálogo:

• Supõe-se que o desenvolvedor já terminou a tarefa e então o QA é acionado. Neste passo é simplesmente um diálogo do Dev com o QA, o Dev deve(ba dum tss🥁!) explicar a tarefa e qual seu objetivo. Com as nuances da explicação já pode-se perceber se algo foi enfatizado ou denegrido no desenvolvimento.

Para uma boa comunicação é necessário uma certa intimidade com desenvolvedor(Não force a barra! Isso não significa invadir a vida pessoal de ninguém), quanto maior a intimidade maior a comunicação. Aqui a soft skill entra forte! Posso tratar sobre soft skill em outro artigo.

Passo 2 — Validação da Explicação:

Até agora sequer houve contato com o produto em si, como eu disse previamente, COMUNICAÇÃO É A ALMA DO NEGÓCIO.

• Deve-se verificar se a explicação e interpretação do desenvolvedor está de acordo com os critérios de aceitação. Com este passo pode-se validar, não somente, a explicação do dev mas também a própria descrição da tarefa. Afinal o desenvolvedor não tem obrigação de ler a mente do PO e entender o que deveria ser feito se a task estiver mal escrita.

Mas Diego, o que fazer agora que a task está extremamente aberta a diversas interpretações?

• Ora, deve-se levantar uma flag e conversar com o PO responsável o quanto antes, afinal ANTES TARDE DO QUE MAIS TARDE.

Passo 3 — Primeiro Contato com a Funcionalidade:

• Supondo que a explicação esteja de acordo com a descrição, vamos usar dados do primeiro passo(O Diálogo). Se já há uma certa intimidade com o desenvolvedor, tu já terás alguma noção de quais áreas do produto ele está mais confortável. Mas vamos jogar com o que temos, os dados do diálogo. Lembra que citei, que provavelmente tu percebeste no diálogo, que alguma coisa foi enfatizada ou denegrida? Bom, vai de cabeça fazer um teste de regressão naquele pedaço denegrido. Mão na massa!

Passo 4 — Teste de Caixa-Nem-Tão-Preta:

Se ainda não quebrou o fluxo desses passos, hora do teste exploratório da funcionalidade em questão.

• Poxa vida, o desenvolvedor tá ao teu lado! Por quê tu insistes em fazer teste de caixa-preta? Dá um bizu no código com o dev aí! Isso com certeza vai te ajudar a ser mais certeiro na hora de achar um bug.

Passo 5 — Balizando com uma Demo Pré-Aprovada:

Esse passo pode ser desconsiderado quando o produto é desenvolvido para apenas um ambiente.

• Se essa já a segunda demonstração que tu estás testando e portanto já fizeste tens uma Demo Aprovada em outro ambiente desta mesma funcionalidade. Pega ela e usa para balizar o teste nesta demo em progresso. Testando lado a lado, por exemplo, Android/iOS/Mobile Web, vais poupar muito tempo e sprint points, sanando alguns bugs de consistência.

Passo 6 — A Testada Final:

Lembrando que ainda estamos trabalhando com o Dev e a tarefa está em In Progress!

• Ative o mindset de teste exploratório, hora de ser o mais crítico possível. Teste toda a funcionalidade, lembrando que todo bug que tu encontrares agora não será encontrado no último teste antes de ir para Done, como a tarefa ainda está In Progress, o desenvolvedor pode fazer um fix nesse mesmo passo.

Fim — FEITO O CARRETO!

Agora já podemos gerar um pull request e a tarefa pode ser arrastada para Code Review.

Concordou ou discordou, quer me xingar, elogiar, conversar mais a respeito?
Chama lá no LinkedIn (https://www.linkedin.com/in/diegopmoreiraa/ ), comentem, curtam e compartilhem. Manda pro papai, pra mamãe, pro cachorro, grande abraço!