O que é história de usuário e critérios de aceitação (exemplos)

Exemplo:

Como usuário do WhatsApp, desejo um ícone de câmera na caixa de gravação do bate-papo para capturar e enviar fotos para que eu possa clicar e compartilhar minhas fotos simultaneamente com todos os meus amigos.

O que é um critério de aceitação?

Um critério de aceitação é um conjunto de condições ou regras de negócios aceitas que a funcionalidade ou recurso deve satisfazer e atender, a fim de ser aceito pelo Dono do Produto / Partes Interessadas.

Essa é uma parte muito importante da conclusão da história do usuário e deve ser estudada pelo Dono do Produto e pelo Analista de Negócios muito meticulosamente, porque perder um único critério pode custar muito. Esta é uma lista numerada ou com marcadores simples.

Seu formato é o seguinte:

' Dada alguma pré-condição quando faço alguma ação, espero o resultado ”.

como eu abro arquivos apk

Exemplo (w.r.t à história de usuário acima):

• Vamos considerar que estou conversando com um amigo e devo conseguir tirar uma foto.
• Quando clico em uma imagem, devo ser capaz de adicionar uma legenda à imagem antes de enviá-la.
• Se houver algum problema ao iniciar a câmera do meu telefone, uma mensagem de erro como ‘A câmera não pôde ser iniciada’. etc., deve ser mostrado em conformidade.

Portanto, a história do usuário define o requisito para qualquer funcionalidade ou recurso, enquanto os critérios de aceitação definem a ‘Definição de pronto’ para a história do usuário ou o requisito.

Como um controle de qualidade, é muito importante entender a história do usuário e seus critérios de aceitação profundamente, sem nenhuma dúvida remanescente no 'início do teste'. Seguindo em frente, vamos entender por que é extremamente importante ir 'fundo' nas histórias de usuários e nos critérios de aceitação.

Explorando profundamente as histórias de usuários

Para começar, vamos primeiro entender a importância de um estudo 'em profundidade' de uma coisa básica e fundamental, ou seja, Histórias de usuários.

Os casos a seguir são minhas próprias experiências reais.

Caso 1:

Antes dos 3 anos, eu estava trabalhando em um projeto de aplicativo móvel e o produto era um aplicativo desenvolvido para o pessoal de entrega.

Você teria visto um entregador vindo ao seu local para fazer a entrega. E eles têm um telefone celular no qual pedem que você dê sua assinatura após a entrega. Esta assinatura reflete no portal dos provedores de serviços de correio como DTDC, FedEx etc.

Vamos imaginar que o aplicativo móvel acabou de ser lançado e seus portais já existem e estão funcionando.

Problema: Para um Sprint, o proprietário do produto tem uma história de usuário para este aplicativo móvel que “Como Administrador do Portal, devo ser capaz de visualizar a assinatura tomada pelo entregador no momento da entrega” . Aqui, o portal (aplicativo da web) é alterado e atualizado de acordo para refletir a assinatura.

Como um controle de qualidade, você deve verificar se a assinatura capturada no aplicativo móvel está refletindo conforme o esperado no portal.

Se você olhar para esta história de usuário, parece simples, mas há um requisito oculto aqui que 'Para entregas históricas, não havia funcionalidade de reflexão de assinatura, então o que deveria acontecer se os caras do portal visualizassem as entregas históricas?' Os dados históricos devem ser eliminados? Devemos permitir falhas ou erros para esses dados?

Claro que não, isso deve ser tratado com gentileza.

Solução: Quando as respectivas tabelas de banco de dados são atualizadas para adicionar uma nova coluna para o local da Assinatura, os dados antigos devem ter um valor NULL ou 0 que deve ser verificado e uma mensagem dizendo 'Não existe assinatura' deve ser exibida.

Isso pode ser considerado uma falta do Dono do Produto ou do Analista de Negócios, mas isso tem que ser feito. Implementar um recurso com sucesso, mas interromper algo junto com ele, não é desejável pelos clientes. Isso precisa ser feito junto com a mesma história de usuário e no mesmo sprint.

Caso # 2

6 anos atrás, eu estava trabalhando em um aplicativo de finanças para planejamento de aposentadoria (sem BA), que era um aplicativo global onde o pessoal de finanças como CA, consultores financeiros poderia usá-lo para diferentes moedas para projetar os planos de investimento, poupança, etc., em um grande período para seus clientes.

Problema: O Product Owner dá a você uma história de usuário que “Como Consultor, desejo visualizar o relatório do meu cliente com base nos dados financeiros fornecidos”.

Aqui, havia 2 requisitos ocultos e eu diria que é uma história incompleta porque:

para) Os relatórios devem considerar a taxa de conversão de moeda diária e não a histórica como no último relatório visualizado e

b) Se a moeda for alterada após fornecer os detalhes financeiros do cliente, os relatórios devem ser exibidos na moeda alterada.

Solução: Levantei essa preocupação diretamente com nosso Product Owner e o informei de que ambos deveriam ser feitos o mais rápido possível. Ele concordou comigo e criou 2 histórias diferentes para os próximos sprints com prioridade.

Remover: Eles foram detectados porque todos nós conhecíamos muito bem os produtos, seu design, estrutura, etc. Esse conhecimento só pode ser alcançado entendendo o produto completamente, entendendo a interoperabilidade dos módulos e estudando completamente a história do usuário, mesmo que seja um 2 liner.

Faça anotações para tornar as coisas mais fáceis e discuta com os BAs e os desenvolvedores sobre o que pensam.

Análise aprofundada dos critérios de aceitação

Compreender os critérios de aceitação e todas as outras condições e regras exaustivamente é ainda mais importante do que compreender uma história de usuário. Porque se um requisito for incompleto ou vago, ele pode ser assumido no próximo sprint, mas se um critério de aceitação for perdido, a própria história do usuário não pode ser liberada.

Acho que todos nós teríamos usado o net banking em algum momento e a maioria de nós o usa todos os dias e eu faço muito download dos meus demonstrativos históricos. Se você observar com atenção, existem certas opções específicas disponíveis para baixá-los.

Existe a opção de selecionar o tipo de arquivo para fazer o download do seu extrato. Existe a opção de escolher se deseja fazer o download apenas dos Créditos / Débito / ambos.

Agora imagine que o Product Owner lhe dá esta história de usuário “Como cliente, quero baixar meu extrato de conta para ver todas as minhas transações feitas em um período específico”.

Com os seguintes critérios de aceitação:

• Considerando que estou na página de download do demonstrativo, devo selecionar o período para o qual desejo fazer o download do demonstrativo.
• Considerando que estou na página de download do extrato histórico, devo selecionar a conta para a qual desejo fazer o download do extrato.
• Considerando que estou na página de download do demonstrativo histórico, não devo fazer o download do demonstrativo em datas ‘Até’ futuras.
• Considerando que estou na página de download de demonstrativos históricos, não devo ter permissão para selecionar a data 'De' 10 anos além do passado.
• Considerando que eu baixei meu extrato, devo conseguir visualizar o arquivo baixado.
• Considerando que estou na Página de Download do Demonstrativo Histórico, devo poder fazer o download do meu demonstrativo nos formatos doc, excel e pdf.

Se você passar por esta aceitação, há 3 coisas faltando aqui:

• Nome e formato do nome do arquivo que será baixado.
• Quais informações (nomes das colunas) devem ser exibidas no arquivo.
• A lista de opções para selecionar que tipo de transação o cliente deseja, ou seja, apenas débitos ou apenas créditos ou ambos.

Tais casos podem acontecer de vez em quando, porém ainda estude bem sobre cada critério de aceitação e tente visualizá-lo com referência à história do usuário. Quanto mais você estudar profundamente sobre as condições e regras de negócios, maior será o seu conhecimento sobre o recurso.

Os bugs encontrados no estágio inicial não custam nada em comparação com o que pode custar no estágio de 'teste'.

Importância de encontrar discrepâncias na história do usuário / critérios de aceitação

É sempre importante fazer um mergulho profundo nas histórias do usuário e nos critérios de aceitação em um estágio inicial, mesmo antes do início do desenvolvimento ou teste.

Porque envolve:

# 1) Perda de tempo:

Se as discrepâncias ou erros na história do usuário / critérios de aceitação forem encontrados durante o desenvolvimento ou o teste, muito retrabalho pode precisar ser feito no tempo restante do sprint.

Não acontece que, mesmo que o Product Owner tenha perdido algumas coisas, ele moverá a história do usuário para o próximo sprint. 95% de chances são de que eles solicitem que a equipe faça a implementação necessária e a libere no mesmo sprint.

Por isso, torna-se um pesadelo para a equipa, uma vez que têm de dedicar mais tempo aos fins-de-semana ou trabalhar até tarde. Isso pode ser evitado estudando e discutindo a história do usuário / critérios de aceitação o mais cedo possível.

# 2) Desperdício de esforços:

Os desenvolvedores e o controle de qualidade precisam revisitar o código implementado e os casos de teste novamente. Atualizar, adicionar e remover conforme o requisito não é uma tarefa fácil. Torna-se muito doloroso porque já existe uma pressão para entregar a tempo.

Em tal situação, há chances de erros no estágio de desenvolvimento ou teste. Se você se deparar com tal situação, vá para ‘DevQA Pairing’. Como cereja no topo do bolo, você pode não receber uma compensação pelo trabalho extra.

Conclusão

A compreensão profunda da história do usuário e dos critérios de aceitação só pode ser alcançada gastando muito tempo estudando-a.

Não existe uma ferramenta ou curso específico disponível no mercado para fazer isso por você, pois tudo se trata de pensamento lógico, experiência e conhecimento sobre o produto.

Participar ativamente de uma reunião de pré-planejamento, conversar com o BA, estudar por conta própria só pode ajudá-lo a conseguir isso. Quanto mais esforços você coloca, mais você aprende e cresce.

Seja o QA ou os desenvolvedores, todos têm que estar na mesma página sobre as histórias de usuário e seus critérios de aceitação, só então as expectativas do cliente podem ser alcançadas com sucesso.

Você tem algo novo para compartilhar conosco sobre suas experiências de trabalho com User Stories? Por favor, expresse seus pensamentos abaixo !!

Leitura recomendada

• MongoDB criar usuário e atribuir funções com exemplos
• Modelo de amostra para relatório de teste de aceitação com exemplos
• Autenticação de usuário no MongoDB
• Parametrização de dados JMeter usando variáveis ​​definidas pelo usuário
• Permissões Unix: Permissões de arquivo no Unix com exemplos
• O que é teste de aceitação (um guia completo)
• O que é o teste de aceitação do usuário (UAT): um guia completo
• Tutorial Python DateTime com exemplos