Antes de começar a trabalhar em uma história de usuário, é muito importante determinar seus critérios de aceitação. Isso pode ser feito quando você detalha o backlog ou planeja o próximo sprint. Algumas equipes realizam reuniões especiais chamadas 3 Amigo (mais sobre elas no último
artigo ), comícios, kick-offs de acordo com especificações ou estudos de reuniões.
Não chame, para a maioria das equipes isso é difícil. A principal dificuldade é que essas reuniões não são estruturadas e seus resultados são incompreensíveis. Eles consomem tempo e são simplesmente chatos. Como resultado, as sessões se tornam irregulares ou completamente abandonadas.
Mas existe uma maneira fácil de tornar essas reuniões curtas e muito produtivas. E esse método é chamado Exemplo de Mapeamento ou Mapeamento de Casos de Teste.
Como isso funciona
Casos de teste específicos (exemplos) são uma ótima maneira de explorar uma área de assunto. Eles podem ser uma boa base para seus testes de aceitação. Quando discutimos casos de teste, surgem outros aspectos que também precisam ser mencionados.
- Regras que resumem casos diferentes ou vice-versa limitam a aplicabilidade do caso de teste.
- Perguntas sobre cenários em que ninguém sabe o que é realmente verdade. Ou hipóteses que apresentamos para avançar de alguma forma no desenvolvimento de requisitos.
- Nova história de usuário que foi revelada durante a discussão.
Exemplo O mapeamento usa um conjunto de cartões em quatro cores diferentes e canetas esferográficas para registrar novas informações enquanto você fala. Durante a reunião, as informações são registradas nos cartões e colocadas no quadro, como na figura acima.
Primeiro, no adesivo amarelo, você precisa escrever
a história em si e colocá-la no topo do quadro. Em seguida, os adesivos azuis indicam cada um dos
critérios ou regras de aceitação que desenvolvemos anteriormente. Colocamos cartões azuis sob amarelo.
Cada regra geralmente pode ser ilustrada com vários
casos de teste . Cada caso de teste possui seu próprio adesivo verde, que é colocado sob a regra correspondente.
Enquanto compilamos um mapa e discutimos casos, podem surgir
perguntas que nenhum dos presentes pode responder. Nós os fixamos em adesivos vermelhos e continuamos a discussão.
A reunião continua até que todos estejam convencidos de que a história é totalmente compreendida ou o tempo alocado para ela terminar.
Feedback instantâneo
No processo de tal conversa, uma representação visual do entendimento atual da história é fácil e rapidamente construída.
- Uma placa coberta com adesivos vermelhos (perguntas) diz que ainda há muito a ser visto.
- Um quadro coberto com adesivos azuis (regras) indica que a história é grande e complexa. Talvez você precise decompor isso. Talvez você precise pegar outro adesivo amarelo (histórias) e colocar parte das histórias na lista de pendências.
- Se uma regra tiver muitos casos de teste, talvez seja muito complicada e você precise destacar várias regras que podem ser descritas em mais detalhes separadamente.
Você pode achar que algumas regras são tão óbvias que não precisam de casos de teste. Por exemplo, se todos entenderem a regra da mesma maneira, não será necessário perder tempo e torturar um número fixo de casos de teste.
Pense por um tempo limitado
Um grupo de vários amigos deve fazer uma história decente em
dez minutos .
Se você não conseguir cumprir o tempo alocado, várias opções são possíveis:
- Você ainda está aprendendo a usar esse método (isso é normal);
- sua história é muito grande (isso definitivamente não é mais bom);
- há muita incerteza em sua história.
O que pode ser feito? Tente dividir a história em várias, ou dê lição de casa ao proprietário do produto, para que mais tarde você retorne a essa história juntos na próxima sessão usando o exemplo de mapeamento, mas com respostas.
Matt Wynne, da Cucumber, convida os participantes da reunião a votarem em 25 minutos se a história está pronta para ser enviada para desenvolvimento. Mesmo que alguns problemas permaneçam não resolvidos, a equipe pode decidir que não há muita incerteza e que pode ser desenvolvida ao longo do caminho.
Benefício
O mapeamento de exemplo ajuda a mudar a escala e se concentrar nas menores partes do comportamento da história. Ao compilar um mapa, você pode selecionar as regras, encontrar a essência do comportamento desejado e adiar o restante para mais tarde. Devido a essa pesquisa aprofundada, o mapeamento de exemplo funciona como um filtro, impedindo que grandes histórias ousadas entrem no sprint e, em seguida, dando surpresas desagradáveis no último minuto. Além disso, essa abordagem economiza tempo e ajuda a manter o envolvimento das pessoas interessadas no processo.
Parece para alguns que 3 amigos devem escrever testes de aceitação
durante esta reunião (por exemplo, scripts para Pepino). Em princípio, em alguns casos, isso pode fazer sentido, mas mais frequentemente essa abordagem apenas distrai o verdadeiro objetivo da conversa.
É claro de onde vem essa opinião: o objetivo óbvio é pegar uma história do usuário, que já possui alguns critérios de aceitação predefinidos, e encontrar casos de teste que podem ser transformados em testes de aceitação.
O objetivo real é alcançar um
entendimento comum do que é necessário para criar uma história. Você pode avançar rapidamente para esse objetivo sem alta tecnologia.
Simplifique a gravação
Portanto, em vez de usar os scripts formais do Gherkin, tente compilar rapidamente uma lista de
casos de
teste usando a convenção de nomenclatura.
Por exemplo:
- onde o cliente esqueceu seu recibo;
- onde o produto foi comprado há 15 dias.
Quando a incerteza está oculta por trás do nome do caso, você deseja instintivamente detalhes e especificações. Mas, mesmo assim, não é necessário aderir à estrutura rígida
.Se o resultado ("então") não for claro, o exemplo não funcionará, mas a questão será.
Desconhecido conhecido
Se a conversa começar a circular, não haverá informações suficientes. Talvez a reunião não tenha a pessoa certa ou você precise fazer alguma pesquisa ou usar o
Spike .
Em vez de ouvir a
opinião de cada participante sobre qual deve ser o resultado do ponto de vista, basta escrever a pergunta no cartão vermelho e seguir em frente. Portanto, o
desconhecido se tornará um
desconhecido conhecido . Este é um grande progresso.
Por experiência, mesmo esse aspecto dos exemplos de mapeamento pode transformar três reuniões de Amigo de chatas em rápidas e produtivas.
Quem deve participar?
O mínimo é o seu 3 amigo: desenvolvedor, testador e proprietário do produto (analista de negócios). Isto é apenas um mínimo. Além disso, você pode convidar alguém da operação, um especialista em UX ou qualquer outra pessoa relacionada à história em discussão. Qualquer pessoa que possa ajudar a encontrar novas perguntas ou transformar perguntas em respostas durante uma conversa será útil.
Enquanto você domina essa técnica, é conveniente encontrar alguém para o papel de facilitador. Sua tarefa formal será garantir que tudo o que é dito seja imediatamente gravado em adesivos. Casos de teste e perguntas são discutidos rapidamente durante a sessão, e é preciso disciplina para escrevê-los em adesivos em tempo hábil para ver o que está sendo dito.
Então, quando escrever no Gherkin?
Não entenda errado, o uso do Gherkin é de grande valor, especialmente nos primeiros dias do projeto, quando você desenvolve um idioma comum. É vital que os cenários sejam expressos para que todos na equipe acreditem neles.
Mas descrever casos de teste dessa maneira requer uma maneira diferente de pensar. É necessário não apenas decidir quais casos se enquadram na área em questão e estabelecer regras gerais para eles.
Para uma equipe que trabalha com uma linguagem de domínio suficientemente madura, é mais lucrativo para o proprietário do produto gastar seu tempo e energia no mapeamento e deixar a tarefa de escrever Gherkin para outros dois amigos. Depois de desenvolverem a especificação Gherkin, o proprietário do produto poderá dar feedback. Fazendo a si mesmo a pergunta: "Eu escreveria assim?" Você pode verificar a eficácia do mapeamento em termos de transferência de conhecimento do produto para seu amigo.
Quantas vezes isso?
Na prática, é recomendável se reunir
todos os dias . Basta selecionar uma história de usuário, dar 25 minutos de atenção e voltar ao trabalho. Se você tentar fazer mais, apenas gaste sua energia.
Mas eu tenho uma equipe distribuída!
Para isso, já criamos soluções, por exemplo, listas de adesivos no Google Keep ou quadros on-line com adesivos coloridos. Você pode usar o mapa mental. O principal é
que você possa trabalhar de forma simples e rápida
para poder se concentrar na conversa .
Algumas dicas finais
É importante distinguir claramente entre
regras e casos de teste antes de usar o mapeamento de exemplo. Há um
exercício divertido para isso.
Lembre-se de que o objetivo final de uma reunião é
descobrir o que você ainda não sabe . Não há perguntas estúpidas, todas elas ajudam a realmente investigar o problema.
Usando essa técnica, você descobrirá que as regras criam linhas naturais de desenvolvimento para sua história. Tente se relacionar com calma com as perguntas, separe-as e deixe-as de lado. Então você pode se concentrar em resolver o problema principal. Você pode complicar e levar ao ideal mais tarde.
Falaremos sobre a prática da 3 Amigo em elaborar os requisitos e criar cartões de caso de teste na conferência QualityConf . Além disso, a lista de relatórios aceitos contém outras abordagens práticas extremamente interessantes para criar um produto de TI de alta qualidade. A conferência QualityConf será realizada pela primeira vez como parte do festival RIT ++ nos dias 27 e 28 de maio, com tempo para participar.