Como criar Critérios de Aceite nas US

Ser um estagiário de QA não é fácil, saber analisar funcionalidades, escrever testes, executar e abrir bugs. Falar sobre todos estes itens chega da um frio na barriga eu sei mais e seu eu te contar que tem gente que além disso ainda tem que fazer trabalho de PO e escrever User Story e Critérios de Aceite do que será desenvolvimento pelo time. Loucura?

Não, porque é isso que meu seguidor passar.

Então meus caros, isso realmente está acontecendo no mercado. Concordo com está abordagem? Depende, e para você entender o meu posicionamento precisamos entender a importância da User story no sistema.

Mas o que são User Story?

Para quem não sabe uma das boas práticas do ágil é a criação da documentação funcional de como o sistema deve funciona. A User Story ou US ela irá descrever o que é a funcionalidade e as regras de negócio que podem vir em formato de critério de aceitação, ao definir erroneamente ou de forma ambiguá pode levar a alguns erros como:

• Testes ineficientes e cobertura inadequada.
• Bugs não detectados e problemas de qualidade.
• Dificuldade de priorização e planejamento.
• Implementação demorada e custosa.
• Desconexão entre a equipe de desenvolvimento e os objetivos do projeto.
• Aumento do risco de retrabalho e insatisfação do cliente.

Vamos implementar!

Não se desespere! Existe um método prático para criar critérios de aceite concisos e focados no valor entregue ao usuário.

Primeiro: Saiba descrever a sua funcionalidade através de uma regra simples:

Eu: descreva a persona que irá utilizar o sistema
Gostaria: descreva a ação que a persona gostaria de realizar no sistema
Porque: justifique o motivo desta implementação

Vamos de exemplo:

Eu como cliente,

Gostaria de poder adicionar produtos ao meu carrinho Porque assim eu posso comprá-los mais tarde.

Segundo: Agora que temos a nossa US descrita, podemos criar nossos Critérios de Aceite para indicar como deve funcionar a adição deste produto ao carrinho.

- O botão "Adicionar ao Carrinho" deve estar presente em todas as páginas de produtos.
- O carrinho deve ser implementado usando a tecnologia XYZ.
-  deve ser armazenado no banco de dados ABC.
-  deve ser compatível com todos os navegadores.
-  deve ser responsivo em todos os dispositivos.
-  deve ter um design atraente.
-  deve ter animações suaves.
-  deve ter um tempo de resposta inferior a 1 segundo.
-  deve ter um limite de 100 produtos.
-  deve ter um sistema de cupons.

O que você acha deles? Bom, ruim?

Pois então, estes critério de aceite são péssimos e você sabe o porque?

• Muito detalhados: Incluem detalhes técnicos e de implementação que não são relevantes para o valor entregue ao usuário.
• Não mensuráveis: Alguns critérios são subjetivos e difíceis de testar (ex: “design atraente”).
• Não focados no valor: Não priorizam o que realmente importa para o usuário (ex: “compatível com todos os navegadores” – qual o impacto disso para o usuário?).

Vamos melhorar eles com apenas uma ação:

• Aplicar a escrita em Gherking

Dado que estou visualizando a página de um produto, 
Quando clico no botão "Adicionar ao Carrinho", 
Então o produto deve ser adicionado ao meu carrinho e uma mensagem de confirmação deve ser exibida.

Dado que adicionei um produto ao meu carrinho, 
quando visualizo a página do carrinho, 
então devo ver o produto listado com o nome, imagem e preço corretos.

Dado que adicionei um produto ao meu carrinho, 
quando altero a quantidade do produto, 
então o valor total do carrinho deve ser atualizado automaticamente.

Dado que adicionei um produto ao meu carrinho, 
quando removo o produto do carrinho, 
então o produto deve ser removido da lista e o valor total do carrinho deve ser atualizado automaticamente.

Conseguem ver a diferença de escrita, entendimento e documentação funcional apenas aplicando uma técnica? Agora nos ganhamos com critérios de aceitação

• Claros e objetivos: Usam linguagem simples e direta.
• Focados no valor: Priorizam o que realmente importa para o usuário (adicionar, visualizar, alterar e remover produtos do carrinho).
• Mensuráveis: Podem ser testados de forma clara e objetiva.
• Concisos: Evitam detalhes técnicos desnecessários.

Ao aplicar apenas está técnica você pode transformar a forma como aborda o desenvolvimento de projetos, resultando em testes mais eficientes, produtos de maior qualidade e maior satisfação do cliente.

E se você quer se aprofundar nesse tema e se destacar como estagiário de QA, eu tenho uma ótima notícia!

No Qualiters Club eu ensino não apenas está técnica de escrita básica em Gherking com conceitos mais avançados além disso também ensino técnica de Storytelling que faz com que você nunca mais fique com aquela pulga atrás da orelha pensando “Será que eu realmente analisei tudo?”, “Será que realmente tudo ficou coberto?”, E sem falar que você terá acesso a conteúdos exclusivos, aulas práticas, suporte personalizado e uma comunidade engajada de profissionais que estão transformando a forma como garantem a qualidade dos projetos.

Não deixe de conferir a qualificação em qualitersclub.com

Mas para quem ficou aqui até o final para saber se um estagiário deveria estar fazendo isso a minha resposta sincera para isso é Não! Ah mais e se eles estiver sendo acompanhado de um PO? Poder até pode, mas não deveria. Eu sinceramente iria sentar com meu gestor e pediria para desenharia um PDI para me tornar um QA Junior em 6 meses a 1 ano, pois por mais que você esteja aprendendo, se destacando no mercado o que é ótimo, foge do que é esperado para um estagiário em QA isso está mais para um estagiário de produto.

E se você quer conferir o vídeo onde eu explico com mais detalhes ele já está disponível no Youtube.