Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Confirmation – O 1/3 Mais Importante da História de Usuário - Eduardo Silva

193 views

Published on

Apresentação da palestra no primeiro evento do GUTS-SC. Palestrante https://br.linkedin.com/in/eduardobsilva

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Confirmation – O 1/3 Mais Importante da História de Usuário - Eduardo Silva

  1. 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. 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. 3. Agenda • História de Usuário • Confirmation • Técnicas de escrita • Tips!
  4. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 22. SBE - Conceitual • Exemplo
  23. 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. 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. 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. 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. 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. 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. 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
  30. 30. OBRIGADO! EDUARDO BRUNO SILVA eduardo.b.silva85@gmail.com https://br.linkedin.com/in/eduardobsilva

×