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

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

Agenda

• História de Usuário• Confirmation• Técnicas de escrita• Tips!

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

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.

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

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?

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

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

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

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;

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

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

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

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

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

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

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

Dado que/Quando/Então• Exemplo:

• Dado que um usuário informou senha incorreta duas vezes seguidasQuando o usuário informa senha incorreta pela terceira vezEntão o sistema bloqueia o usuárioE o sistema informa ao usuário do bloqueio

• Dado que um usuário administrador informou senha incorreta duas vezes seguidasQuando o usuário informa a senha incorreta pela terceira vezEntão o sistema notifica o suporte com o nome do usuário e endereço da base de dados

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

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)

SBE - Conceitual

• Exemplo

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

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

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”

SBE - ConceitualSenha 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

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

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

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

OBRIGADO!

EDUARDO BRUNO SILVAeduardo.b.silva85@gmail.comhttps://br.linkedin.com/in/eduardobsilva