um guia perfeito para os critérios de aceitação de História do usuário com cenários da vida real:
na indústria de desenvolvimento de Software, a palavra “requisito” define qual é o nosso objetivo, o que os clientes precisam exatamente e o que fará a nossa empresa aumentar o seu negócio.seja uma empresa de produtos que produz produtos de software ou uma empresa de serviços que oferece serviços em vários campos de software, a principal base para todos eles é a exigência e o sucesso é definido pela forma como os requisitos são cumpridos.,
o termo “requisito” tem nomes diferentes em diferentes metodologias de projecto.
na cachoeira, é referido como “documento requisito/Especificação”, em ágil ou SCRUM é referido como “Epic”, “história de usuário”.
no modelo Waterfall, os documentos de requisitos são documentos enormes de 200 ou mais páginas, uma vez que todo o produto é implementado em uma fase. Mas este não é o caso com Agile / SCRUM porque nestas metodologias os requisitos são dados para pequenas funcionalidades ou características como o produto é preparado passo a passo.,
neste artigo, eu tentei o meu melhor para compartilhar todos os meus 4 anos de experiência em trabalhar com histórias de usuário e seus critérios de aceitação relacionados, juntamente com cenários fáceis e simples da vida real para sua melhor compreensão.vamos rever os fundamentos primeiro.
o que é uma história de utilizador?
uma história de usuário é um requisito para qualquer funcionalidade ou recurso que é escrito em uma ou duas linhas e max até 5 linhas. Uma história de usuário é geralmente o requisito mais simples possível e é sobre uma e apenas uma funcionalidade (ou uma característica).,
O mais comumente utilizado o formato padrão para a criação da História de Usuário é mostrado abaixo:
Como <função de usuário/cliente, Eu quero < objetivo a ser alcançado> para que eu possa <razão do objetivo>.
exemplo:
Como um utilizador do WhatsApp, quero um ícone da câmara na caixa de escrita chat para capturar e enviar imagens para que possa clicar e partilhar as minhas imagens 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ócio aceites que a funcionalidade ou característica deve satisfazer e cumprir, a fim de ser aceite pelo proprietário/Partes Interessadas do produto.esta é uma parte muito importante da conclusão da história do Usuário e deve ser estudada pelo proprietário do produto e Analista de negócios muito meticulosamente, porque a falta de um único critério pode custar muito. Esta é uma lista simples numerada ou com pontos.
Seu formato é o seguinte:
“dado algum pré-requisito quando faço alguma ação, então eu espero o resultado”.exemplo (W. R.,t to above user story):
- Let’s consider that i’m chatting with a friend and I should be able to capture a picture.
- Quando eu clicar em uma imagem, eu devo ser capaz de adicionar um título para a imagem antes de enviá-la.
- Se houver algum problema em iniciar a minha câmara de telefone, uma mensagem de erro como ‘Camera não pôde ser iniciada’. etc., deve ser demonstrado em conformidade.
assim, 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 feito” para a história do usuário ou o requisito.,
Como um QA é muito importante entender profundamente a história do Usuário e seus critérios de aceitação, sem que nem mesmo uma única dúvida permaneça no “início dos testes”. Em frente vamos entender por que é extremamente importante cavar ‘fundo’ em histórias de usuários e critérios de aceitação.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 seguintes casos são as minhas próprias experiências reais.,
Case #1:
Before 3 years, I was working on a Mobile Application Project and the product was an application that was designed for the delivery people.
Você teria visto uma pessoa de entrega vindo para o seu lugar para a entrega. E eles têm um telefone celular no qual eles pedem que você dê sua assinatura após a entrega. Esta assinatura reflecte-se no portal dos prestadores de serviços de correio, como a DTDC, a FedEx, etc.
vamos imaginar que o aplicativo móvel é apenas lançado e seus portais já estão existentes e up.,
problema: para um Sprint o proprietário do produto tem uma história de usuário para este aplicativo móvel que “como administrador de Portal, eu deveria ser capaz de ver a assinatura tomada pela pessoa de entrega no momento da entrega”. Aqui o portal (app web) é alterado e atualizado em conformidade para refletir a assinatura.
Como um QA você tem que verificar se a assinatura capturada no aplicativo móvel está refletindo como esperado no portal.,
Se você olhar para esta história de usuário, parece simples, mas há um requisito escondido aqui que ” para entregas históricas, não havia nenhuma funcionalidade de reflexão de assinatura, então o que deve acontecer se os caras do portal vêem entregas históricas?”Os dados históricos devem ser apagados? Devemos permitir falhas ou erros para tais dados?claro que não, isto deve ser tratado graciosamente.,solução
: Quando as tabelas DB respectivas são actualizadas para adicionar uma nova coluna para a localização da Assinatura, os dados antigos devem ter um valor nulo ou 0 que deve ser verificado e deve ser mostrada uma mensagem que indique “não existe assinatura”.
isto pode ser chamado como uma falha do proprietário do produto ou analista de negócios, mas isso tem que ser feito. Implementar uma característica com sucesso, mas quebrar algo junto com ela não é desejável pelos clientes. Isso precisa ser feito junto com a mesma história de usuário e no mesmo sprint.,
Case #2
6 years ago, I was working on a Retirement Planning Finance Application (with no BA) which was a global application where Finance folks like CA, Finance Advisors could use it for different currencies to project the investment plans, savings, etc., durante um grande período para os seus clientes.problema
: O proprietário do Produto lhe dá uma história de usuário que “como consultor, eu quero ver o relatório do meu cliente com base nos detalhes financeiros fornecidos”.,
Aqui foram 2 oculto requisitos e eu diria que é como uma história incompleta, porque:
a] Os relatórios devem considerar a diária taxa de conversão da moeda e não histórico, como no último relatório exibido e
b] Se a moeda é alterado depois de dar financeira do cliente detalhes, os relatórios devem mostrar na nova moeda.solução
: eu levantei essa preocupação diretamente com o nosso proprietário do produto e fiz com que ele soubesse que ambos tinham que ser feitos o mais rápido possível. Ele concordou comigo e criou duas histórias diferentes para os próximos sprints com prioridade.,
Take Away: estes foram capturados porque todos nós estávamos muito bem cientes dos produtos, seu design, estrutura etc. Tal conhecimento só pode ser alcançado através da compreensão completa do produto, da compreensão da interoperacionalidade dos módulos e do estudo minucioso da história do usuário, mesmo que seja um 2 liner.
fazer notas para tornar as coisas mais fáceis e discutir com os BA’s e os desenvolvedores sobre o seu pensamento.,
olhada Em Profundidade Critérios de Aceitação
Compreender os critérios de aceitação e todas as outras condições& regras exaustivamente é ainda mais importante do que subestimar uma história de usuário. Porque se um requisito é incompleto ou vago, ele pode ser retomado no próximo sprint, mas se um critério de aceitação é perdido, então a história do usuário em si não pode ser lançado.acho que todos nós teríamos usado a net banking em algum momento e a maioria de nós a usa todos os dias e eu descarrego muito minhas declarações históricas., Se você observar cuidadosamente, existem certas opções específicas disponíveis para baixá-las.
Existe uma opção para selecionar o tipo de arquivo para baixar a sua declaração. Há uma opção para escolher se você quer baixar apenas os créditos/débito /ambos.
Agora imagine que o proprietário do Produto lhe dá esta história de usuário “como um cliente, eu quero baixar a minha declaração de conta para que eu possa ver todas as minhas transações feitas por um período específico”.,
com os seguintes critérios de aceitação:
- Considerando que estou na página de declaração histórica de Download, eu devo selecionar o período para o qual eu quero baixar a declaração.
- Considerando que eu estou na página de declaração histórica de Download, eu devo selecionar a conta para a qual eu quero baixar a declaração.
- Considerando que eu estou na página de declaração histórica de Download, eu não deveria ser autorizado a baixar a declaração para o futuro ‘até’ data.,Considerando que estou na página da declaração histórica de Download, não devo ser autorizado a selecionar “a partir” data 10 anos mais tarde no passado.tendo em conta que descarrego a minha declaração, devo ser capaz de ver o ficheiro baixado.Considerando que estou na página de declarações históricas de Download, eu deveria ser capaz de baixar minha declaração em formatos doc, excel e pdf.
se passar por esta aceitação, faltam 3 coisas aqui:
- Nome e formato do nome do ficheiro que será transferido.,
- Que informação (nomes de colunas) deve ser apresentada no ficheiro.
- a lista de opções para seleccionar o tipo de transacção que o cliente quer, ou seja, apenas débitos ou apenas créditos ou ambos.
tais casos podem acontecer de vez em quando, no entanto, ainda estudar bem sobre cada critério de aceitação e tentar visualizá-lo com referência à história do Usuário. Quanto mais você estudar profundamente sobre as condições e regras de negócios, mais será o seu conhecimento sobre o recurso.
Bugs encontrados na fase inicial não custam nada comparado com o que pode custar na fase de “teste”.,
importância de encontrar discrepâncias nos critérios de História/aceitação do utilizador
é sempre importante fazer um mergulho profundo nas histórias do utilizador e nos critérios de aceitação numa fase inicial mesmo antes do início do desenvolvimento ou dos testes.
Pois envolve:
#1) Desperdício de Tempo:
Se as discrepâncias ou erros na história de usuário/critérios de aceitação são encontradas quando o desenvolvimento está acontecendo ou testar se está a passar, em seguida, um monte de retrabalho tem que ser feito no restante do tempo de sprint.,
não acontece que, mesmo se o proprietário do produto perdeu algumas coisas, eles vão mover a história do Usuário para o próximo sprint. 95% de chances são de que eles pedem à equipe para fazer a implementação necessária e liberá-lo no mesmo sprint.por isso, torna-se um pesadelo para a equipa, pois têm de passar tempo extra, vir aos fins-de-semana ou trabalhar até tarde. Isto pode ser evitado estudando e discutindo a história do Usuário/critérios de aceitação O MAIS CEDO POSSÍVEL.
# 2) Perda de esforços:
os desenvolvedores e o QA têm que revisitar o código implementado e os casos de teste novamente., Atualizar, adicionar e remover como o requisito por não é uma tarefa fácil. Torna-se demasiado doloroso, pois já existe uma pressão para se cumprir a tempo.em tal situação, há chances de erros na fase de desenvolvimento ou teste. Se você se deparar com tal situação vá para ‘Devqa emparelhamento’. Como uma cereja no topo do bolo, você pode não obter uma compensação para o trabalho extra.
conclusão
compreensão profunda da história do utilizador e os critérios de aceitação só podem ser alcançados se dispusermos de imenso tempo a estudá-la.,
não há nenhuma ferramenta ou curso específico disponível no mercado para fazer isso para você, pois isso é tudo sobre pensamento lógico, experiência e conhecimento sobre o produto.participar activamente em reuniões pré-planeadas, falar com o BA, estudar sozinho, só o pode ajudar a conseguir isso. Quanto mais esforços você colocar, mais você aprende e cresce.
seja o QA ou Desenvolvedores, todo mundo tem que estar na mesma página sobre as histórias do Usuário e seus critérios de aceitação, só então as expectativas do cliente pode ser alcançado com sucesso.,você tem algo novo para compartilhar conosco sobre suas experiências em trabalhar com histórias de Usuários? Por favor, expresse seus pensamentos abaixo!!última actualização: 18 de janeiro de 2021 6: 33 am
Leave a Reply