SlideShare uma empresa Scribd logo
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 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
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 - 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
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 SILVA
eduardo.b.silva85@gmail.com
https://br.linkedin.com/in/eduardobsilva

Mais conteúdo relacionado

Destaque

Windows 8 e linux
Windows 8 e linuxWindows 8 e linux
Windows 8 e linux
Federico Melluso
 
Evaluation, imp, outline
Evaluation, imp, outlineEvaluation, imp, outline
Evaluation, imp, outline
cseerussell
 
Evaluation p7
Evaluation p7Evaluation p7
Evaluation p7
JacobDMBird
 
Preguntas trampa
Preguntas trampaPreguntas trampa
Preguntas trampa
Jhoana Rodriguez
 
04 Eyewear_Final
04 Eyewear_Final04 Eyewear_Final
04 Eyewear_Final
Paula Story
 
my updated cv 2015
my updated cv 2015my updated cv 2015
my updated cv 2015
nkamogeleng kutu
 
Fisiología del aparato reproductor femenino
Fisiología del aparato reproductor femeninoFisiología del aparato reproductor femenino
Fisiología del aparato reproductor femenino
Jesús González Jarillo
 
baker-tilly-international-2015-global-annual-review
baker-tilly-international-2015-global-annual-reviewbaker-tilly-international-2015-global-annual-review
baker-tilly-international-2015-global-annual-review
Fakhriddin Saydullaev
 

Destaque (8)

Windows 8 e linux
Windows 8 e linuxWindows 8 e linux
Windows 8 e linux
 
Evaluation, imp, outline
Evaluation, imp, outlineEvaluation, imp, outline
Evaluation, imp, outline
 
Evaluation p7
Evaluation p7Evaluation p7
Evaluation p7
 
Preguntas trampa
Preguntas trampaPreguntas trampa
Preguntas trampa
 
04 Eyewear_Final
04 Eyewear_Final04 Eyewear_Final
04 Eyewear_Final
 
my updated cv 2015
my updated cv 2015my updated cv 2015
my updated cv 2015
 
Fisiología del aparato reproductor femenino
Fisiología del aparato reproductor femeninoFisiología del aparato reproductor femenino
Fisiología del aparato reproductor femenino
 
baker-tilly-international-2015-global-annual-review
baker-tilly-international-2015-global-annual-reviewbaker-tilly-international-2015-global-annual-review
baker-tilly-international-2015-global-annual-review
 

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

Convergido: TDD + ATDD + BDD + xUnit Patterns + Dependency Injection
Convergido: TDD + ATDD + BDD + xUnit Patterns + Dependency InjectionConvergido: TDD + ATDD + BDD + xUnit Patterns + Dependency Injection
Convergido: TDD + ATDD + BDD + xUnit Patterns + Dependency Injection
Marco Baccaro
 
Clean Code - Fork In Tuba
Clean Code - Fork In TubaClean Code - Fork In Tuba
Clean Code - Fork In Tuba
Rafael Paz
 
Não há agile sem práticas ágeis
Não há agile sem práticas ágeisNão há agile sem práticas ágeis
Não há agile sem práticas ágeis
Marco Baccaro
 
Verdades e mitos sobre testes que eu gostaria
Verdades e mitos sobre testes que eu gostariaVerdades e mitos sobre testes que eu gostaria
Verdades e mitos sobre testes que eu gostaria
Livia Gabos
 
Testes e mocks: Em Visual Studio com .NET
Testes e mocks: Em Visual Studio com .NETTestes e mocks: Em Visual Studio com .NET
Testes e mocks: Em Visual Studio com .NET
Alessandro Binhara
 
Introdução ao TDD
Introdução ao TDDIntrodução ao TDD
Introdução ao TDD
Thiago Faria de Andrade
 
5 coisas que todo desenvolvedor deveria saber sobre sql server
5 coisas que todo desenvolvedor deveria saber sobre sql server5 coisas que todo desenvolvedor deveria saber sobre sql server
5 coisas que todo desenvolvedor deveria saber sobre sql server
Marcos Freccia
 
Oficina de Teste de Usabilidade
Oficina de Teste de UsabilidadeOficina de Teste de Usabilidade
Oficina de Teste de Usabilidade
UTFPR
 
Agile Testing
Agile TestingAgile Testing
Agile Testing
GTS-CE
 
In tests we trust: começando com TDD, mocks e mais
In tests we trust: começando com TDD, mocks e maisIn tests we trust: começando com TDD, mocks e mais
In tests we trust: começando com TDD, mocks e mais
Ana Paula Gomes
 
1 2 3 - Testando - Automatizando os testes de software
1 2 3 - Testando - Automatizando os testes de software1 2 3 - Testando - Automatizando os testes de software
1 2 3 - Testando - Automatizando os testes de software
Heider Lopes
 
Clean code
Clean codeClean code
Teste sua aplicação antes que ela teste você
Teste sua aplicação antes que ela teste vocêTeste sua aplicação antes que ela teste você
Teste sua aplicação antes que ela teste você
Tiago Link
 
Introdução ao TDD
Introdução ao TDDIntrodução ao TDD
Introdução ao TDD
Breno Martinusso
 
Agile testing
Agile testingAgile testing
Agile testing
Qualister
 
Além do TDD...
Além do TDD...Além do TDD...
Além do TDD...
GTS-CE
 
Test-Driven Development - Introdução ao método de construção de software guia...
Test-Driven Development - Introdução ao método de construção de software guia...Test-Driven Development - Introdução ao método de construção de software guia...
Test-Driven Development - Introdução ao método de construção de software guia...
Thiago Faria de Andrade
 
Tdc2013 - Trilha de Teste -
Tdc2013 - Trilha de Teste - Tdc2013 - Trilha de Teste -
Tdc2013 - Trilha de Teste -
Leonardo Galani
 
Teste de usabilidade
Teste de usabilidadeTeste de usabilidade
Teste de usabilidade
Lourdes Martins
 
Teste de usabilidade
Teste de usabilidadeTeste de usabilidade
Teste de usabilidade
Lourdes Martins
 

Semelhante a Confirmation – O 1/3 Mais Importante da História de Usuário - Eduardo Silva (20)

Convergido: TDD + ATDD + BDD + xUnit Patterns + Dependency Injection
Convergido: TDD + ATDD + BDD + xUnit Patterns + Dependency InjectionConvergido: TDD + ATDD + BDD + xUnit Patterns + Dependency Injection
Convergido: TDD + ATDD + BDD + xUnit Patterns + Dependency Injection
 
Clean Code - Fork In Tuba
Clean Code - Fork In TubaClean Code - Fork In Tuba
Clean Code - Fork In Tuba
 
Não há agile sem práticas ágeis
Não há agile sem práticas ágeisNão há agile sem práticas ágeis
Não há agile sem práticas ágeis
 
Verdades e mitos sobre testes que eu gostaria
Verdades e mitos sobre testes que eu gostariaVerdades e mitos sobre testes que eu gostaria
Verdades e mitos sobre testes que eu gostaria
 
Testes e mocks: Em Visual Studio com .NET
Testes e mocks: Em Visual Studio com .NETTestes e mocks: Em Visual Studio com .NET
Testes e mocks: Em Visual Studio com .NET
 
Introdução ao TDD
Introdução ao TDDIntrodução ao TDD
Introdução ao TDD
 
5 coisas que todo desenvolvedor deveria saber sobre sql server
5 coisas que todo desenvolvedor deveria saber sobre sql server5 coisas que todo desenvolvedor deveria saber sobre sql server
5 coisas que todo desenvolvedor deveria saber sobre sql server
 
Oficina de Teste de Usabilidade
Oficina de Teste de UsabilidadeOficina de Teste de Usabilidade
Oficina de Teste de Usabilidade
 
Agile Testing
Agile TestingAgile Testing
Agile Testing
 
In tests we trust: começando com TDD, mocks e mais
In tests we trust: começando com TDD, mocks e maisIn tests we trust: começando com TDD, mocks e mais
In tests we trust: começando com TDD, mocks e mais
 
1 2 3 - Testando - Automatizando os testes de software
1 2 3 - Testando - Automatizando os testes de software1 2 3 - Testando - Automatizando os testes de software
1 2 3 - Testando - Automatizando os testes de software
 
Clean code
Clean codeClean code
Clean code
 
Teste sua aplicação antes que ela teste você
Teste sua aplicação antes que ela teste vocêTeste sua aplicação antes que ela teste você
Teste sua aplicação antes que ela teste você
 
Introdução ao TDD
Introdução ao TDDIntrodução ao TDD
Introdução ao TDD
 
Agile testing
Agile testingAgile testing
Agile testing
 
Além do TDD...
Além do TDD...Além do TDD...
Além do TDD...
 
Test-Driven Development - Introdução ao método de construção de software guia...
Test-Driven Development - Introdução ao método de construção de software guia...Test-Driven Development - Introdução ao método de construção de software guia...
Test-Driven Development - Introdução ao método de construção de software guia...
 
Tdc2013 - Trilha de Teste -
Tdc2013 - Trilha de Teste - Tdc2013 - Trilha de Teste -
Tdc2013 - Trilha de Teste -
 
Teste de usabilidade
Teste de usabilidadeTeste de usabilidade
Teste de usabilidade
 
Teste de usabilidade
Teste de usabilidadeTeste de usabilidade
Teste de usabilidade
 

Mais de gutssc

5 coisas que aprendemos blockchain
5 coisas que aprendemos blockchain5 coisas que aprendemos blockchain
5 coisas que aprendemos blockchain
gutssc
 
Apresentacao Organização GUTS-SC 2019
Apresentacao Organização GUTS-SC 2019Apresentacao Organização GUTS-SC 2019
Apresentacao Organização GUTS-SC 2019
gutssc
 
4º GUTS-SC - Florianópolis 20/10
4º GUTS-SC - Florianópolis 20/104º GUTS-SC - Florianópolis 20/10
4º GUTS-SC - Florianópolis 20/10
gutssc
 
Automação de testes com a ferramenta Fitnesse - Eliane Somavilla
Automação de testes com a ferramenta Fitnesse - Eliane SomavillaAutomação de testes com a ferramenta Fitnesse - Eliane Somavilla
Automação de testes com a ferramenta Fitnesse - Eliane Somavilla
gutssc
 
Automação Web Utilizando Keywords - Gustavo Moreira
Automação Web Utilizando Keywords - Gustavo MoreiraAutomação Web Utilizando Keywords - Gustavo Moreira
Automação Web Utilizando Keywords - Gustavo Moreira
gutssc
 
Data Driven Quality no Scrum
Data Driven Quality no ScrumData Driven Quality no Scrum
Data Driven Quality no Scrum
gutssc
 
Apps - o que testar e o que não testar
Apps - o que testar e o que não testarApps - o que testar e o que não testar
Apps - o que testar e o que não testar
gutssc
 
Tester - Como e onde atuar - Camila Labes
Tester - Como e onde atuar - Camila LabesTester - Como e onde atuar - Camila Labes
Tester - Como e onde atuar - Camila Labes
gutssc
 
Primeiros passos com protractor - Walmyr Lima
Primeiros passos com protractor - Walmyr LimaPrimeiros passos com protractor - Walmyr Lima
Primeiros passos com protractor - Walmyr Lima
gutssc
 
O Mercado de Teste de Software - Cristiano Caetano
O Mercado de Teste de Software - Cristiano CaetanoO Mercado de Teste de Software - Cristiano Caetano
O Mercado de Teste de Software - Cristiano Caetano
gutssc
 
1º GUTS-SC - Florianópolis 23/01
1º GUTS-SC - Florianópolis 23/011º GUTS-SC - Florianópolis 23/01
1º GUTS-SC - Florianópolis 23/01
gutssc
 

Mais de gutssc (11)

5 coisas que aprendemos blockchain
5 coisas que aprendemos blockchain5 coisas que aprendemos blockchain
5 coisas que aprendemos blockchain
 
Apresentacao Organização GUTS-SC 2019
Apresentacao Organização GUTS-SC 2019Apresentacao Organização GUTS-SC 2019
Apresentacao Organização GUTS-SC 2019
 
4º GUTS-SC - Florianópolis 20/10
4º GUTS-SC - Florianópolis 20/104º GUTS-SC - Florianópolis 20/10
4º GUTS-SC - Florianópolis 20/10
 
Automação de testes com a ferramenta Fitnesse - Eliane Somavilla
Automação de testes com a ferramenta Fitnesse - Eliane SomavillaAutomação de testes com a ferramenta Fitnesse - Eliane Somavilla
Automação de testes com a ferramenta Fitnesse - Eliane Somavilla
 
Automação Web Utilizando Keywords - Gustavo Moreira
Automação Web Utilizando Keywords - Gustavo MoreiraAutomação Web Utilizando Keywords - Gustavo Moreira
Automação Web Utilizando Keywords - Gustavo Moreira
 
Data Driven Quality no Scrum
Data Driven Quality no ScrumData Driven Quality no Scrum
Data Driven Quality no Scrum
 
Apps - o que testar e o que não testar
Apps - o que testar e o que não testarApps - o que testar e o que não testar
Apps - o que testar e o que não testar
 
Tester - Como e onde atuar - Camila Labes
Tester - Como e onde atuar - Camila LabesTester - Como e onde atuar - Camila Labes
Tester - Como e onde atuar - Camila Labes
 
Primeiros passos com protractor - Walmyr Lima
Primeiros passos com protractor - Walmyr LimaPrimeiros passos com protractor - Walmyr Lima
Primeiros passos com protractor - Walmyr Lima
 
O Mercado de Teste de Software - Cristiano Caetano
O Mercado de Teste de Software - Cristiano CaetanoO Mercado de Teste de Software - Cristiano Caetano
O Mercado de Teste de Software - Cristiano Caetano
 
1º GUTS-SC - Florianópolis 23/01
1º GUTS-SC - Florianópolis 23/011º GUTS-SC - Florianópolis 23/01
1º GUTS-SC - Florianópolis 23/01
 

Último

Teoria de redes de computadores redes .doc
Teoria de redes de computadores redes .docTeoria de redes de computadores redes .doc
Teoria de redes de computadores redes .doc
anpproferick
 
Como fui de 0 a lead na gringa em 3 anos.pptx
Como fui de 0 a lead na gringa em 3 anos.pptxComo fui de 0 a lead na gringa em 3 anos.pptx
Como fui de 0 a lead na gringa em 3 anos.pptx
tnrlucas
 
Gestão de dados: sua importância e benefícios
Gestão de dados: sua importância e benefíciosGestão de dados: sua importância e benefícios
Gestão de dados: sua importância e benefícios
Rafael Santos
 
Orientações para utilizar Drone no espaço Brasil
Orientações para utilizar Drone no espaço BrasilOrientações para utilizar Drone no espaço Brasil
Orientações para utilizar Drone no espaço Brasil
EliakimArajo2
 
Por que escolhi o Flutter - Campus Party Piauí.pdf
Por que escolhi o Flutter - Campus Party Piauí.pdfPor que escolhi o Flutter - Campus Party Piauí.pdf
Por que escolhi o Flutter - Campus Party Piauí.pdf
Ian Oliveira
 
PRATICANDO O SCRUM Scrum team, product owner
PRATICANDO O SCRUM Scrum team, product ownerPRATICANDO O SCRUM Scrum team, product owner
PRATICANDO O SCRUM Scrum team, product owner
anpproferick
 
Ferramentas e Técnicas para aplicar no seu dia a dia numa Transformação Digital!
Ferramentas e Técnicas para aplicar no seu dia a dia numa Transformação Digital!Ferramentas e Técnicas para aplicar no seu dia a dia numa Transformação Digital!
Ferramentas e Técnicas para aplicar no seu dia a dia numa Transformação Digital!
Annelise Gripp
 

Último (7)

Teoria de redes de computadores redes .doc
Teoria de redes de computadores redes .docTeoria de redes de computadores redes .doc
Teoria de redes de computadores redes .doc
 
Como fui de 0 a lead na gringa em 3 anos.pptx
Como fui de 0 a lead na gringa em 3 anos.pptxComo fui de 0 a lead na gringa em 3 anos.pptx
Como fui de 0 a lead na gringa em 3 anos.pptx
 
Gestão de dados: sua importância e benefícios
Gestão de dados: sua importância e benefíciosGestão de dados: sua importância e benefícios
Gestão de dados: sua importância e benefícios
 
Orientações para utilizar Drone no espaço Brasil
Orientações para utilizar Drone no espaço BrasilOrientações para utilizar Drone no espaço Brasil
Orientações para utilizar Drone no espaço Brasil
 
Por que escolhi o Flutter - Campus Party Piauí.pdf
Por que escolhi o Flutter - Campus Party Piauí.pdfPor que escolhi o Flutter - Campus Party Piauí.pdf
Por que escolhi o Flutter - Campus Party Piauí.pdf
 
PRATICANDO O SCRUM Scrum team, product owner
PRATICANDO O SCRUM Scrum team, product ownerPRATICANDO O SCRUM Scrum team, product owner
PRATICANDO O SCRUM Scrum team, product owner
 
Ferramentas e Técnicas para aplicar no seu dia a dia numa Transformação Digital!
Ferramentas e Técnicas para aplicar no seu dia a dia numa Transformação Digital!Ferramentas e Técnicas para aplicar no seu dia a dia numa Transformação Digital!
Ferramentas e Técnicas para aplicar no seu dia a dia numa Transformação Digital!
 

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)
  • 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

Notas do Editor

  1. Boa tarde pessoal. Espero que todo mundo ainda esteja animado. Meu nome é Eduardo e hoje trabalho como analista de sistemas.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. “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.
  11. 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.
  12. Utilizando a mesma tela de alteração de senha como exemplo, esses são os testes nesse formato.
  13. É 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.
  14. 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.
  15. 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.
  16. 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.
  17. 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.
  18. 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.
  19. 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.
  20. 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.
  21. 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.