Confirmation – O 1/3 Mais Importante da História de Usuário - Eduardo Silva
•Download as PPTX, PDF•
0 likes•267 views
Apresentação da palestra no primeiro evento do GUTS-SC. Palestrante https://br.linkedin.com/in/eduardobsilva
Recommended
More Related Content
Viewers also liked
Similar to Confirmation – O 1/3 Mais Importante da História de Usuário - Eduardo Silva
Similar to Confirmation – O 1/3 Mais Importante da História de Usuário - Eduardo Silva (20)
More from gutssc
More from gutssc (11)
Recently uploaded
Recently uploaded (8)
Confirmation – O 1/3 Mais Importante da História de Usuário - Eduardo Silva
- 1. Confirmation – O 1/3 Mais Importante da História de Usuário Eduardo Bruno Silva 2 3 d e j a n e i r o d e 2 0 1 6 GUTS/SC
- 2. Quem? • Formação • Sistemas de Informação (UFSC) • MBA Gestão Empresarial (FGV) • Pós – Engenharia e Projeto de Software (Unisul) • Scrum • CSPO - Certified Scrum Product Owner • CSM – Certified Scrum Master
- 3. Agenda • História de Usuário • Confirmation • Técnicas de escrita • Tips!
- 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)
- 22. SBE - Conceitual • Exemplo
- 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. Tips & Tricks • Escrever da perspectiva do usuário • Escrever antes de iniciar a implementação • Medidas de usabilidade (fácil de usar não é uma medida!) • Como tratar as situações de erro também são critérios de aceite • Testes de performance e estresse devem ser critérios de aceite
- 29. 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
Editor's Notes
- 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.