Como escrever uma história de usuário testável.
Uma história de usuário deve expressar uma capacidade e por que ela importa. Evite disfarçar uma tarefa técnica como benefício ao usuário.
Adapte o fluxo à sua tarefa.
Identifique o usuário, a capacidade e a razão de sua importância; depois, acrescente condições de aceitação que tornem o resultado observável. Mantenha a história focada o suficiente para avaliar sua conclusão em um cenário concreto.
- O que você fornece
- Problema do usuário e capacidade desejada.
- O que você recebe
- Histórias centradas no usuário com limites de escopo.
Veja a entrada e o resultado.
Entrada e saída ilustrativas · exemplo didático, não uma execução real do WebAct
Exemplo campo
Catalog manager needs to identify changed supplier prices.
Exemplo completo
As a catalog manager, I want to review changed prices so I can approve updates before importing them.
Carregue esta entrada no prompt e copie para o WebAct para testar a tarefa. Seu resultado pode ser diferente da ilustração.
Decisões e solução de problemas.
Trabalho de manutenção técnica deve ser forçado para uma frase de história de usuário?
Explique seu objetivo e suas restrições reais. Uma tarefa técnica pode ser documentada honestamente sem inventar uma ação do usuário para caber no formato.
Por que a história parece concluída mas continua difícil de testar?
Acrescente o comportamento esperado e limites relevantes. O benefício explica por que o trabalho importa; as condições de aceitação explicam o que significa concluir.
Teste com sua própria fonte.
Substitua o exemplo pelo seu material no prompt. Mantenha os requisitos necessários e copie a tarefa para o WebAct.
Personalizar e copiar a tarefa ↑