Resumo do Livro
Capítulo 8 – Testes com foco no
negócio
Prof. Dr. Adilson Marques da Cunha
Prof. Dr. Luiz Alberto Vieira Dias
Aluna (Ouvinte): Daniela América da Silva
CE-240/CE-245/CE-229
São José dos Campos
Abril de 2017
hhttp://www.freakingnews.com/Donkey-Astronaut-Pictures-117336.asp
Introdução
•
Objetivo
–Especificar testes que o cliente entenda
•
Sumário
– USs = descrição breve da funcionalidade
desejada. Apoiam o planejamento e a priorização. – Desenvolvimento Cascata = documento bem
completo com todos os detalhes
– Agile = conversa baseada na US. requisitos que propicie desenvolver o código quase que
imediatamente.
– Exemplos que se transformarão em testes para confirmar o que o cliente realmente deseja. Uma linguagem que ambos cliente e equipe de
desenvolvimento entendam. • Teste foco no negócio, • Teste voltado para o cliente, • Teste de aceitação.
Quadrantes de Testes
•
Quadrante 1
–garantem a qualidade interna, maximizam a
produtividade do time, e minimizam atraso
técnico.
•
Quadrante 2
–antes da codificação começar.
–Direcionam o desenvolvimento, em um nível
mais alto.
–Definem e verificam a qualidade externa e nos
ajudam a identificar quando a US está pronta.
–Os testes dos clientes são automatizados e
com a frequência desejada
–Comportamentos não funcionais como
performance, segurança e usabilidade também
devem ser definidos.
O dilema do requisitos
•
Cascata
–meses são investidos no levantamento dos requisitos
•
Agile
–os requisitos podem modificar a cada iteração, descritos como estórias ou grupo de estórias
escritas pelo time do cliente.
–Programadores e testadores ajudam a quebrar as estórias em tamanhos apropriados
–Os times agile podem expandir as estórias até ter a informação suficiente para escrever o
código apropriado.
–Testadores ajudam a criar exemplos e o contexto de cada estória e ajuda o cliente as escrever a
estórias de testes.
–Mesmo que o código resulte em um teste de sucesso, mais testes executados para melhor
entender os requisitos e como as funcionalidades deveriam trabalhar.
–Entregável é realizado a cada pequena iteração e o código poderá ser corrigido na proxima
Requisitos
- Figuras, diagramas, planilhas e protótipos são acessados por pessoas com diferentes experiências e pontos de vista - Ajuda as pessoas da área de negócios a entenderem as características desejadas
- Também ajuda a entender o escopo e todos a compreenderam o que é parte ou não da estória.
Linguagem Comum
- Esta estória está resolvendo o problema ?
- Se sim, que problemas estamos tentando resolver ?
- Nós poderíamos implementar uma solução que não resolve o problema ? - Como a estória adicionará valor ao negócio ?
- Quem são os usuários finais desta funcionalidade ? - Que valor eles extrairão disto ?
- O que os usuários farão logo antes e/ou depois de utilizarem a funcionalidade ? - Como saberemos que já concluímos a estória ?
- Qual a pior coisa que poderia acontecer ? (ajuda a gerar ideias e considerar risco e focar os testes nas área críticas).
- E Qual a melhor coisa que poderia acontecer ? (ajuda a mapear o caminho crítico do sucesso)
Beneficio: Testadores são bons em formular uma variedade de questões porque são conscientes do todo, dos aspectos de negócio e técnico da estória.
Requisitos
- Peça ao cliente para lhe dar exemplos de como a funcionalidade deveria funcionar.
- Os exemplos formarão a base para os testes que poderão ser expressados na linguagem de negócios, e testes que poderão ser executados.
- Alguns clientes se sentem confortáveis em
expressar exemplos utilizando ferramentas de testes. - O teste captura o exemplo em um formato de execução, e encapsula o mesmo cenário preparado pelo cliente.
Requisitos
Requisitos não funcionais estão usualmente no Q3 e Q4, e ainda assim precisamos escrever os testes para ter certeza que estarão prontos.
-Por quanto tempo o sistema precisa estar disponível ? -O que acontece se falhar?
-Se há um middleware, precisaremos considerar que as mensagens serão grandes o suficiente, que precisaremos considerar perdas ?
-O que acontece se não houver trafego por horas ? É preciso alertar alguém?
Membros: analista de negócios, especialistas, programadores e membros do time do cliente, times de suporte a produção - Todos tem um perspectiva única.
Pontos de Vista
http://www.ibccoaching.com.br/wp-content/uploads/2015/07/1-TrabalhoEquipe.jpg
Requisitos
- Acesso limitado aos especialistas do negócio, e em muitos casos os clientes estão em diferentes
localidades.
- Aproximar-se o quanto possível para uma conversa direta e pessoalmente, ou via conferencias, telefone, e-mails, mensagens instantâneas, câmeras e outras ferramentas.
A comunicação
- É responsabilidade do Dono do Produto, não apenas atingir uma clareza, mas tambem agir como representante do cliente na priorização de estórias.
- Entretanto há um afunilamento ao concentrar as informações em uma pessoa.
- Idealmente o time de desenvolvimento deveria estar próximo do time do cliente para aprender sobre o trabalho realizado pelo cliente = melhor chance de produzir um software que suporte estas tarefas.
Requisitos
- Condições de satisfação do negócio - Impactos nas funções existentes - Considerações legais-
- O impacto nos processos agendados regularmente - Referencias para mock-up
-Texto para a Ajuda, e quem proverá - Casos de testes
- Migração de dados - Comunicação interna - Comunicação externa
Testes de Aceitação ajuda na aceitação da estória. O time do cliente precisa falar uma só voz. Se você recebe diferentes requisitos de diferentes partes
interessadas, é preciso voltar atrás e rever a estória até que haja uma lista de condições de satisfação do cliente.
Satisfação
- É fácil perder a visão do todo quando
trabalhando por partes e em um número pequeno de estórias a cada iteração
- Listar todas as partes de um sistema que pode ser afetado por uma estória.
- O time pode checar cada ponto de teste para ver que requisitos e casos de testes serão gerados.
- Ciencia de todos os impactos potenciais de qualquer mudança na regra de negócio. - Dependências = se um novo código tiver intersecção com um funcionalidade existente, a US poderá demorar muito mais que o planejado para ser concluída.
Por Partes
Estórias grandes poderão ser quebradas e
pequenas poderão ser combinadas ou tratadas
como tarefas.
No inicio do projeto, o PO para começa com uma
sessão de Brainstorming. Envolve o PO e os
Stakeholders para explicar as estórias e as Uss
poderão ser quebradas.
O quanto antes construir o caminho end-2-end,
mais cedo testes significativos, feedbacks e
testes automatizados poderão ser realizados
É um processo de escrever o teste, escrever o
código, executar os testes, e aprender. Dessa
forma, você saberá que o seu código satisfaz o
cliente e trabalha de forma apropriada a cada
estágio.
Finalizar uma estória por vez, ajuda a espalhar o
esforço de teste, e não deixa-lo apenas para a
ultima iteração.
Tudo Pronto ?
• Temos os testes definidos com o cliente, e
escrito para garantir os critérios de
satisfação do cliente. Os testes foram
executados e passaram, mas como
sabemos se estamos prontos?
–Neste momento podemos realizar apenas os testes
para garantir que os requisitos foram capturados.
–Os usuários de negócio e o dono do produto, poderão
dizer se todos os requisitos foram entregues.
–Outro objetivo dos testes é identificar áreas de alto
risco e ter certeza que o código foi escrito de forma
sólida.
–Gerenciamento de risco é essencial e os testes tem
Testes mitigam o risco
• Agile = mitiga riscos, priorizando valor ao
negócio através de pequenas entregas testadas,
tendo o cliente envolvido a cada iteração.
• Entretanto ainda precisamos discutir possíveis
eventos e a probabilidade de ocorrência e o
impacto para a organização. O caminho de
sucesso é um bom caminho pois após
completado pode-se trabalhar nos cenários de
riscos – não apenas os casos ruins mas também
os que tem mais chance de ocorrer.
• Atenção para não perder a visão do todo
enquanto navega nos detalhes =
Lembre-se do
objetivo final e do todo.
Pergunte ao Cliente: - “qual o pior cenário?”
Pergunte também ao programador
- “Quais são as condições posteriores a execução deste código?”,
- “O que será persistido no banco?”,
- “Que comportamentos precisarão ser verificados para especificar uma linha de funcionamento bom ou ruim?”
- “A estória utiliza tanto ambiente legado quanto uma nova arquitetura ?”
- “O código interage com outro sistema ou depende de software terceiro ?”
Perguntas
“Houveram testes suficientes para manter o time on
track?”,
“Muito tempo fo perdido pois a estória não foi entendida?”
