4. História de Usuário
O que é uma História de Usuário?
Eu, como leitor de livros, gostaria de procurar um livro pelo
nome para poder comprá-lo.
...?
Usuário Desenvolvedor
5. História de Usuário
Representam uma pequena porção de funcionalidade que
representa um incremento de valor de negócio para o
cliente, a ser implementado pelo time de desenvolvimento.
6. História de Usuário
• Princípio do manifesto ágil:
• O método mais eficiente e eficaz de transmitir informações para
e entre uma equipe de desenvolvimento é através de conversa
face a face.
• 3Cs da História de Usuário:
• Card
• Conversation
• Confirmation
7. Confirmation
• Story Tests, Testes de Aceitação, Testes de Confirmação,
Critérios de Aceite
• O que é tudo isso afinal de contas?
• Manifesto Ágil – Passamos a valorizar:
• Indivíduos e interações mais que processos e ferramentas;
• Software em funcionamento mais que documentação
abrangente;
• Ok, mas porque o 1/3 mais importante?
8. Técnicas de Escrita
• Bullet Points
• Testar com...
• Testar se...
• Dado que/Quando/Então
• Especificação por Exemplos – Conceituais
• Especificação por Exemplos - Concretos
9. Bullet Points
• O que é?
• Notação abreviada de texto
• Como abreviação, a conversação se torna extremamente importante
• Quando utilizar?
• Histórias pequenas
• Testes razoavelmente óbvios
• Quando o time provavelmente vai se lembrar de qualquer forma
• Quando não utilizar?
• Testes mais complexos que o time pode não se lembrar somente com uma
descrição curta
• Testes que possuem uma lógica mais complexa
10. Bullet Points
• Exemplos
• Nova senha
• Senha antiga
• Confirmação de senha (deve ser igual a nova senha)
• Nova senha respeita as regras de segurança de senha
11. Testar com... (Test with)
• O que é?
• Descreve rapidamente cenários ou dados para os testes
• A conversação continua muito importante
• Opcional – Começar com “testar com” (test with)
• Opcional – Incluir uma cláusula de validação
• Quando utilizar?
• Histórias pequenas
• Testes simples, quando o comportamento ou o resultado é óbvio
• O time vai se lembrar do comportamento ou resultado do teste
• Ainda vão precisar criar alguns dados diferentes para atingir os diferentes
comportamentos/resultados;
12. Testar com... (Test with)
• Quando não utilizar?
• Testes mais complexos que o time pode não se lembrar
somente com esta cláusula
• Testes onde o comportamento esperado não é óbvio
• Testes onde o comportamento esperado pode variar muito com
diferentes dados
• Testes que possuem uma lógica mais complexa e que pode ser
esquecida
13. Testar com... (Test with)
• Exemplos
• Testar a senha atual com senha correta, incorreta e em branco
• Com cláusula opcional de validação = Validar mensagens de erro
• Testar a senha atual com caracteres especiais
• Testar a confirmação em branco, igual a nova senha e diferente da
nova senha
• Testar com usuários admin, super-usuário e usuários comuns
14. Testar se... (Test that)
• O que é?
• Iniciar a frase com “Testar se...” e descrever o que se deve testar
para verificar se o comportamento do sistema é consistente
com o comportamento esperado;
• Pode exigir mais escrita, mas é mais fácil de lembrar
• Conceitual
• Não utilizar dados específicos
15. Testar se... (Test that)
• Quando utilizar?
• Inicializando no trabalho com critérios de aceite
• Testes simples
• Testes que não se encaixam em nenhuma outra técnica
• Quando não utilizar?
• Com equipes mais experientes que conhecem técnicas melhores
• Testes onde o comportamento esperado depende de muitas
entradas
• Testes que exigem muita lógica
16. Testar se... (Test that)
• Exemplos
• Testar se quando um usuário informa uma senha incorreta, ele
recebe uma mensagem de erro indicando senha incorreta
• Testar se três tentativas de login com a senha incorreta
bloqueiam o acesso do usuário
17. Dado que/Quando/Então
• O que é?
• Teste escrito em três passos:
Dado que <pré-condição do teste>
Quando <evento que inicia o comportamento do sistema>
Então <comportamento esperado/resultados esperados>
• PODE utilizar dados reais, mas não é obrigatório
• Utilizar <E> ou <OU> para incluir mais de um(a)
condição/evento/comportamento/resultado
18. Dado que/Quando/Então
• Quando utilizar?
• Testes com muitas pré-condições
• Testes que exijam configurações importantes ou que podem ser esquecidas
• Testes com gatilhos específicos
• Quando se utiliza Cucumber – facilmente integrável
• Quando não utilizar?
• Testes simples
• Testes com pré-condições simples ou óbvias
• Testes com múltiplas entradas diferentes e muitas saídas diferentes (em um
único teste)
• Testes onde um único Dado que/Quando/Então descreve só um de vários
cenários semelhantes
19. Dado que/Quando/Então
• Exemplo:
• Dado que um usuário informou senha
incorreta duas vezes seguidas
Quando o usuário informa senha incorreta
pela terceira vez
Então o sistema bloqueia o usuário
E o sistema informa ao usuário do bloqueio
• Dado que um usuário administrador
informou senha incorreta duas vezes
seguidas
Quando o usuário informa a senha incorreta
pela terceira vez
Então o sistema notifica o suporte com o
nome do usuário e endereço da base de
dados
20. SBE - Conceitual
• O que é?
• Uma tabela com os principais exemplos (cenários) que
especifica as entradas e saídas
• Similar a uma tabela de decisão
• Na forma conceitual, evitar utilizar dados específicos – utilizar o
conceito dos dados
• Teste focado nas informações determinadas
21. SBE - Conceitual
• Quando utilizar?
• Testes em que o comportamento esperado depende de diversas entradas ou
condições
• Testes em que existem diversos comportamentos
• Testes em que existem diversas entradas diferentes com saídas diferentes
• Qualquer teste em que uma tabela seja útil para:
• Descrever melhor o teste
• Explorar todas as possíveis entradas e saídas
• Quando não utilizar?
• Testes simples
• Testes em que só exista uma pré-condição
• Em testes mais abrangentes/workflow (Ex.: crud)
23. SBE - Conceitual
Senha atual Nova senha Confirmação Resultado
<Em branco> * * Campo não preenchido
Correta <Em branco> * Campo não preenchido
Correta Válida Igual Sucesso
Correta Válida Diferente Senhas diferentes
Correta Inválida * Nova senha inválida
Incorreta <Em branco> * Campo não preenchido
Incorreta Válida Igual Senha atual incorreta
Incorreta Válida Diferente Senha atual incorreta /
Senhas diferentes
Incorreta Inválida * Senha atual incorreta /
Nova senha inválida
24. SBE - Concreto
• O que é?
• Igual ao Conceitual, porém utiliza dados reais de teste
• Quando utilizar?
• Utilizar os dados reais de teste normalmente é mais útil, porém,
é mais fácil escrever esses tipos de teste depois do início da
implementação
25. SBE - Concreto
• Exemplo
• Regras para nova senha:
• Deve ter pelo menos 6 caracteres
• Deve ter pelo menos uma letra e um número
• Não pode ter espaço em branco
• Obs.: A senha atual do usuário é “masteryoda1”
26. SBE - Conceitual
Senha atual Nova senha Confirmação Resultado
<Em branco> <Em branco> <Em branco> Campo não preenchido
<Em branco> hansolo1 hansolo1 Campo não preenchido
<Em branco> leia22 leia21 Campo não preenchido
masteryoda1 <Em branco> <Em branco> Campo não preenchido
masteryoda1 <Em branco> hansolo1 Campo não preenchido
masteryoda1 chewbacca1 chewbacca1 Sucesso
masteryoda1 ackbar10 itsatrap10 Senhas diferentes
masteryoda1 r2d2 r2d2 Nova senha inválida
masteryoda1 !@#$%& lando;lando;lando; Nova senha inválida
masteryoda2 <Em branco> <Em branco> Campo não preenchido / Senha atual incorreta
masteryoda2 <Em branco> darthvader Campo não preenchido / Senha atual incorreta
masteryoda2 223022 223022 Senha atual incorreta
masteryoda2 darth1 darth1<espaço> Senha atual incorreta / Senhas diferentes
masteryoda2 d4rth<espaço> d4rth<espaço> Senha atual incorreta / Nova senha inválida
masteryoda2 darth<espaço>10 1234 Senha atual incorreta / Nova senha inválida
27. Qual técnica utilizar
• A melhor estratégia é utilizar uma mistura de todas
• A maioria dos testes pode ser feita utilizando-se as três
primeiras (~80%)
• Outras técnicas que podem ser utilizadas (com menos
frequência):
• Diagramas de estado
• Fluxogramas
28. Dinâmica de Critérios de Aceite
• Minha equipe ainda não utiliza Confirmation (ou US) –
Como começar?
• Dinâmica!
• Desenhar uma casa sem critérios de confirmação
• O que entregaram:
29.
30. Dinâmica de Critérios de Aceite
• Desenhar novamente, com critérios de aceite:
• A casa deve ter dois andares
• Deve ter uma porta no andar de baixo, no meio da casa
• Em cada lado da porta, deve ter uma janela
• O andar de cima deve ter três janelas espaçadas igualmente
• A casa deve ter uma chaminé
• A casa deve ter uma garagem
• A casa deve ter uma cerca em volta de um jardim
• A cerca deve ter um portão
• Deve existir um caminho entre a porta da casa e o portão
• O jardim deve ter uma árvore
33. Dinâmica de Critérios de Aceite
• O que foi entregue:
T E C H D A Y | R E Q U I S I T O S D E S O F T W A R E
34.
35. Referências
• Martin Fowler - http://martinfowler.com
• Jeff Langr - http://langrsoft.com
• Ron Jeffries - http://ronjeffries.com/
• Mike Cohn - https://www.mountaingoatsoftware.com/blog
• Charles Bradley - http://www.scrumcrazy.com/
• Tom Reynolds – Scrum Alliance Community Member
• Teresa Torres – http://producttalk.org
Boa tarde pessoal. Espero que todo mundo ainda esteja animado.
Meu nome é Eduardo e hoje trabalho como analista de sistemas.
Essa é a agenda da minha palestra aqui no Tech Day.
Vou começar falando um pouco de histórias de usuário, pra nivelar um pouco o conhecimento do pessoal antes de falar dos critérios de aceite.
Depois vou mostrar algumas técnicas de escrita dos critérios de aceite e quando usar ou não usar cada uma dessas técnicas.
E pra finalizar, vou apresentar pra vocês uma dinâmica que organizamos na UNIC pra iniciar a utilização dos critérios de aceite pelos nossos analistas, que deixa claro os benefícios da utilização dos critérios de aceite.
Antes de falar sobre o assunto principal da palestra, temos que revisitar a história de usuário. E ouvindo esse nome, vem a pergunta fundamental. O que é uma História de Usuário?
Isso é uma história de usuário?
Temos um papel, uma ação que deve ser executada e um objetivo a ser atingido por essa ação.
Sem entrar no mérito se essa é uma boa história de usuário, se é INVEST, etc.
Na verdade se eu enviar esse texto como um card pra o desenvolvedor, ele até pode começar a implementar, mas será que o resultado vai ser o que o cliente esperava?
Provavelmente não. O desenvolvedor teria muitas perguntas para fazer antes de realizar essa implementação.
Então esse card, sozinho não é exatamente uma história de usuário.
A história de usuário representa <texto do slide>.
A partir dessa definição de história de usuário, percebam que em nenhum momento se fala em escrever a história de usuário.
Nem sempre é necessário escrevê-la e muito menos documenta-la.
Para que uma história seja implementada pelo time de desenvolvimento, o padrão <papel> <ação> <objetivo> é insuficiente.
Vejamos um dos princípios do manifesto ágil.
Ron Jeffries, um dos assinantes do manifesto ágil, dividiu as histórias em três aspectos críticos: Card, Conversation e Confirmation.
Os Cards servem para identificar as histórias de usuário e lembrar a todo o time do que se trata a história. Ou seja, o card que vimos no slide anterior não é somente 1/3 da história de usuário - o 1/3 menos importante.
O conteúdo da história em si deve ser Comunicado (olha o princípio do manifesto) do PO/Cliente para o time através de conversação: uma troca de ideias, opiniões e sentimentos.
Essa comunicação é principalmente verbal, mas pode ser suplementada com diversos artefatos. Os melhores artefatos são exemplos e os melhores exemplos podem ser executados.
Esses exemplos são o terceiro C da história de usuário: Confirmation.
Na literatura podemos observar diversas nomenclaturas para a mesma coisa.
Bom, o confirmation não é uma técnica para documentação do sistema, nem uma documentação que deve ser mantida.
O confirmation é sim, uma técnica para definir testes, que utiliza a colaboração e a comunicação com objetivo de entregar o valor que o cliente espera.
Resumindo em dois itens do manifesto ágil: 1 e 2.
Porque o 1/3 mais importante? Vamos lá.
Os detalhes trabalhados na conversação são registrados como critérios de aceite.
Não importa o quanto seja conversado nem quanta documentação seja produzida, o importante é estar tão certo quanto o necessário sobre o que deve ser feito.
Essa é a confirmação que precisamos pra a execução do trabalho. No fim das contas, os critérios de aceite são a definição de pronto da história de usuário.
A confirmação é o que possibilita a simplicidade da utilização do card e da conversação nas histórias de usuário.
Quando a iteração de desenvolvimento termina e o cliente vê o resultado dos critérios de aceite, o cliente aprende que o time pode e vai continuar a entregar o que é necessário.
Agora vou mostrar pra vocês algumas formas de escrita para o confirmation da histórias de usuário.
Vou repassar os bullet points, testar com, testar se, TDD – Dado que/Quando/Então, a Especificação por exemplos conceituais e a especificação por exemplos concretos.
A primeira técnica, bullet points, é a mais simples. Bullet points é uma expressão em inglês que quer dizer simplesmente uma notação abreviada de texto.
Essas pequenas frases utilizadas em apresentações já são bullet points.
Sendo uma abreviação, a conversação do PO com o time de desenvolvimento ganha mais importância.
Bullet points devem ser usados principalmente quando as histórias são realmente pequenas, com testes óbvios e quando o time provavelmente vai se lembrar dos testes.
E devem ser evitados quando os testes são mais complexos, quando o time pode não lembrar do teste só com uma pequena descrição.
Testes que possuem lógicas complicadas ou regras complexas também devem ser evitados.
Um exemplo de utilização de bullet points em uma tela de alteração de senha de usuário.
Os bullet points servem para nos lembrar de testar com uma nova senha, diferente da senha antiga. Testar com uma senha igual a senha antiga.
Testar se a confirmação da senha vai funcionar, ou seja, se a confirmação é igual a nova senha.
E testar se a nova senha respeita as regras de segurança de senha, ou seja, se tem letras e números e com um tamanho mínimo de 8 caracteres por exemplo.
“Testar com” – essa técnica originalmente foi escrita no livro do Mike Cohn – User Stories Applied, e em inglês é test with.
Por isso em inglês é mais fácil escrever nesse formato e, por isso, é opcional iniciar a frase com testar com – nem sempre da pra escrever diretamente testar com.
Mas é mais fácil escrever “Testar <o que se quer testar> com <as opções de testes>”, que ainda diz respeito a esta estratégia.
Também pode incluir uma cláusula de validação adicional.
Utilizar em histórias pequenas, testes simples, e quando o time vai se lembrar do comportamento esperado ou do resultado do teste.
Assim como os bullet points, evitar de utilizar quando os testes são mais complexos, onde o comportamento não é óbvio ou pode variar muito com diferentes dados de entrada.
Utilizando a mesma tela de alteração de senha como exemplo, esses são os testes nesse formato.
É quase a forma mais natural de se escrever critérios de aceite caso não seja apresentada nenhuma técnica.
Basicamente é iniciar com “Testar se” e escrever o que deve acontecer para que o comportamento esteja correto.
Pode exigir um pouco mais de escrita do que as demais técnicas, mas é mais fácil de lembrar o teste que deve ser realizado.
Esse tipo de teste tira vantagem se a escrita for totalmente conceitual, evitando a utilização de dados específicos, como valores reais.
A técnica é melhor aproveitada em equipes que estão iniciando o trabalho com histórias de usuário ou testes de histórias.
Ainda é melhor utilizado com testes simples e, por fim, para testes em que nenhuma outra técnica parece adequada.
Evitar de utilizar esse tipo de teste com equipes mais experientes, que podem tirar maior proveito de técnicas melhores ou mais “econômicas”.
Ou testes onde o comportamento do sistema depende de muitas entradas ou possua muitos resultados/saídas, ou que possuem muita lógica envolvida.
Esse tipo de teste é comum e muito usado com BDD. Ele é formado por três partes: Dado que <pré-condições acontecem>, Quando <acontece um determinado evento de gatilho>, Então <acontece um comportamento esperado do sistema e são gerados determinados resultados>
Pode-se utilizar dados reais nesse tipo de teste, mas não é obrigatório.
Em todas as cláusulas é possível adicionar E ou OU para incluir mais de uma condição.
Essa técnica é melhor utilizada quando existem muitas pré-condições ou configurações, com gatilhos específicos e quando se pretende utilizar a ferramenta Cucumber, já que é facilmente integrável a ferramenta.
Evitar utilizar esse formato para testes simples, com pré-condições simples ou para testes com diversas entradas e saídas diferentes, além de quando um único teste desse tipo descreve somente um entre vários cenários semelhantes, já que a quantidade de escrita para cada um dos testes é muito grande.
SBE – Especificação por Exemplo (Specification By Example).
É semelhante a uma tabela de decisão, mostrando os principais cenários de teste com as diversas entradas e saídas.
Na forma conceitual, não devem ser utilizados dados reais, e sim a descrição conceitual dos dados.
Como utiliza uma tabela, o teste se concentra nas informações determinadas pelas pessoas que o escreveram e a generalização dos testes se torna complicada, pois deve ser inferida.
Utilizar este tipo de testes quando o comportamento do sistema depende de diversas condições, ou quando existem diversos comportamentos do sistema ou quando existem diversas entradas que geram diversas saídas.
Além disso, utilizar sempre que uma tabela for útil pra descrever melhor o teste e/ou explorar todas as possíveis entradas e saídas.
Evitar de utilizar para testes simples, ou testes com uma única pré-condição, ou quando o teste for mais abrangente, como por exemplo um CRUD.
Voltando ao exemplo da alteração de senhas, eis a nossa tabela de decisão.
Onde há um asterisco, significa que qualquer valor pode ser utilizado que não fará diferença no resultado final do teste.
Voltando ao exemplo da alteração de senhas, eis a nossa tabela de decisão.
Vejam que dessa vez, foram inseridas as senhas com todos os testes necessários para essa validação.
Resumindo, a melhor estratégia é utilizar uma mistura de todas as técnicas, sempre que necessário.
Porém, seguindo uma proporção de Pareto, acredito que cerca de 80% dos critérios de aceite podem ser escritos utilizando-se as três primeiras técnicas – Bullet Points, Testar com, Testar se.
Essas técnicas apresentadas não são as únicas, mas a ideia delas é oferecer uma direção. Outras técnicas podem ser utilizadas, sempre que necessário.
Algumas outras técnicas documentadas que podem ser utilizadas com menos frequência são Diagramas de estado e Fluxogramas.
A minha equipe ainda não começou a utilizar o Confirmation junto com a História de Usuário (ou nem utiliza a história de usuário), mas eu quero começar. Como faço?
Fizemos uma dinâmica na UNIC que foi muito bem recebida em todas as equipes.
A ideia é juntar os envolvidos e pedir que eles desenhem uma casa. Simplesmente desenhar uma casa, da forma como quiserem.
Depois de todos terminarem de desenhar, verifiquem o desenho de cada um dos participantes e rejeite a casa, dizendo que não é dessa forma que queriam.
Em seguida, peça novamente que desenhem uma casa, com critérios de aceite.
Observem esses 10 critérios de aceite. Na verdade podem ser quaisquer critérios de aceite que você definir, mas o legal é colocar alguns detalhes que quase ninguém vai lembrar de colocar no desenho inicial.
Observem esses 10 critérios de aceite. Na verdade podem ser quaisquer critérios de aceite que você definir, mas o legal é colocar alguns detalhes que quase ninguém vai lembrar de colocar no desenho inicial.
Observem esses 10 critérios de aceite. Na verdade podem ser quaisquer critérios de aceite que você definir, mas o legal é colocar alguns detalhes que quase ninguém vai lembrar de colocar no desenho inicial.
Olhem esse primeiro resultado. Parecido com o que eu esperava certo? Todos os critérios de aceite foram atendidos.
Desenho aprovado!
Agora olhem esse segundo desenho. Muito bom certo?
Eu pedi somente uma casa, ganhei um carro, um jardim com algumas flores. Fiquei muito feliz.
O problema é que eu já estaria feliz somente com a casa com os critérios de aceite que eu defini.
Portanto, o que aconteceu aqui, além de ter superado minhas expectativas, pode ter significado um gasto maior do que o orçamento inicial do projeto.
Ou seja, cuidado para fazer somente o que o cliente pediu.