Como funcionam os Critérios de Aceitação de uma estória?

Quando terminamos a implementação de uma feature, no universo ágil, não podemos deixar de falar em critérios de aceite.

Critérios de aceitação de uma estória nada mais é que uma lista (tipo um checklist) para verificar se a estória de implementação foi feita de acordo com o que o Product Owner definiu/pediu, atendendo assim os requisitos para a utilização do usuário.

Esses critérios surgem de perguntas que a equipe de desenvolvimento faz ao PO no momento em que a estória está sendo descrita, na busca por obter mais detalhes do que deve ser implementado.

Garantir que o que foi desenvolvido irá realmente gerar valor para o cliente é um desafio, pois precisamos entender verdadeiramente quais são as suas necessidades. Trabalhar com estórias e com Critérios de Aceite bem definidos garante que possamos chegar no melhor possível a ser entregue com o projeto, gerando qualidade e aceitação daquilo que a equipe de desenvolvimento dedicou seu esforço.

Agora, vou deixar abaixo alguns critérios que são utilizados nas estórias de algumas equipes que conheço. As estórias não são fechadas se os criterios não são atendidos.

Critérios de aceite de Qualidade:

• Foram executados os roteiros testes?
• Foi feita a tradução em Inglês?
• Foi feita a tradução em Espanhol?
• Foi feito o link para URL do help?
• Foi criado o json e recurso dos novos menus?
• Foi feito teste com redimensionamento (visão monitor24', visão noteboox, visão tablet, visão celular)?
• Foram implementados os id's dos elementos?
• Foram validadas as rotinas em Chrome, Firefox e Edge?

Até mais! 😀

Quando considerar um projeto pronto na metodologia ágil? Definição de Pronto - DoD (Definition of Done)

Olá meu povo testador!

Conforme mencionado neste post, uma das palestras que participei num encontro de qualidade promovido pela empresa falou a respeito da definição de pronto. Vou desmistificar um pouco sobre a Definição de Pronto dentro da metodologia ágil.

O que é Definição de pronto?

Equipes ágeis maduras desenvolvem projetos seguindo alto padrão de qualidade. Tal rigor é imposto por meio da DoD – Definition of Done, ou Definição de Pronto. A DoD é uma discussão entre Time de Desenvolvimento (o que inclui o testador/QA) e Product Owner de que toda a entrega atenderá os padrões de qualidade estabelecidos por eles mesmos.

Para que serve o DoD?

É uma forma de se buscar a excelência. A discussão aprofunda a compreensão da equipe dos itens do backlog e os requisitos do produto de cada estória da sprint.

Quando uma estória está pronta?

Vida de Programador - nº1438

Toda mudança é difícil, quando você sai do modelo de desenvolvimento tradicional e vai para o ágil a história não é diferente. Posso dizer que eu vivi o quadrinho do Vida de Programador acima. É difícil de um programador de longa data aceitar que o "pronto" não é mais um status por etapa de desenvolvimento e sim "pronto" de tudo. Ainda percebo que é difícil o programador aceitar que ele precisa se preocupar com tudo também.

É importante frisar que, no ágil, a definição de pronto é decidido pela equipe e ocorre por estória. Então temos que o "pronto" pode ser diferente para cada estória dentro da sprint. ;)

Exemplos de definição de pronto:

- Critérios de aceite da estória atendidos.

      Responsável: Time de Desenvolvimento e Product Owner;

- Testes da estória executados conforme planejamento. Todas as subtasks de testes devem estar finalizadas.

      Responsável: QA (Quality Assurance);

- Todos os defeitos não críticos que não podem ser corrigidos dentro dos limites da sprint adicionados ao backlog do produto e priorizados para a próxima sprint.

      Responsável: todo o time;

- Integração de todas as funcionalidades.

      Responsável: todo o time;

- Todos os requisitos funcionais testados, incluindo os testes positivos e negativos, com o número de testes com base no tamanho, complexidade e riscos.

      Responsável: QA;

- Todos os riscos de qualidade cobertos de acordo com a medida acordada de testes.

      Responsável: QA;

- Documentação escrita, avaliada e aprovada.

      Responsável: Product Owner.

Espero que tenham gostado deste post. Qualquer dúvida, perguntem! :D

Referências: 

Definition of Done. Disponível em: <http://www.mindmaster.com.br/definition-of-done/>.

Apostila da certificação CTFL-AT (já falei sobre ela AQUI): Foundation Level Extension Syllabus Agile Tester. Disponível em: <http://www.bstqb.org.br/uploads/docs/syllabus_ctfl_at_2014br.pdf>.