• Nenhum resultado encontrado

Resumo livro cap08

N/A
N/A
Protected

Academic year: 2021

Share "Resumo livro cap08"

Copied!
15
0
0

Texto

(1)

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

(2)

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.

(3)

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.

(4)

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

(5)

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.

(6)

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.

(7)

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

(8)

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.

(9)

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.

(10)

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.

(11)

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

(12)

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?”

(13)

Testabilidade e Automação

Beneficios da Automação

• Trabalhar a partir de testes = a melhor

forma de codificar que simplificarão os

testes.

• Os testes com foco no negócio (Q2) são

expressados como automatizados.

• Fácil de entender, fácil de executar, e

propiciar comentários rápidos.

• Quando valor significativo ao negócio

precisa ser entregue a cada 30 dias ou

duas semanas, então a informação

precisa ser direta e automática.

• Times experientes poderão codificar com

testes automatizados no nível de

desenvolvimento que no nível do cliente.

Sem ou pouca Automação

• Sem os testes do cliente os

programadores possuem mais dificuldade

em conhecer que testes unitários serão

escritos.

• Times que apenas automatizam testes

relacionados a tecnologia, descobrem que

possuem não bug no código mas não

necessariamente o código faz o que o

cliente deseja.

• Times que não automatizam nenhum teste

(14)

Sumário

• Testes voltados ao négocio dizem ao time o que codificar.

• Pequenas iterações propiciam ao cliente ver e utilizar a aplicação e ajustar os requisitos conforme

necessário.

• Ajudam os clientes a expressarem as condições de satisfação e criar exemplos do que é desejado e

o que não é desejado

• Perguntas abertas, ajudam o cliente a pensar sobre todas as funcionalidades desejadas e prevenir

importantes premissas não reveladas.

• Consenso sobre o comportamento desejado e diferentes visões de diferentes partes do negócio.

• Apoiam o desenvolvimento de ferramentas para expressar condições de satisfação do negócio.

• Pensar em todas as partes da aplicação que uma dada estória afeta, mantendo em mente o

funcionamento geral do sistema.

• Quebrar funcionalidades em pequenas estórias e caminhos gerenciaveis.

• Padrão = “escreva o teste, escreva o código, execute testes e aprenda”.

• Utilize testes e exemplos para mitigar riscos de funcionalidades perdidas ou perda da visão do todo.

• Time consciente de implementar uma aplicação testável.

• Testes automatizados para fácil e rápida análise e coleta de comentários = agregar valor nas

(15)

Referencias

• Agile Testing – A Practical Guide for Testers and Agile Teams

Lisa Crispin and Janet Gregory

• Página de índices Lisa Crispin -

http://lisacrispin.com/

• Página de índices Janet Gregory -

http://janetgregory.ca/

• Transferring Testing Skills -

http://lisacrispin.com/2017/02/17/transferring-testing-skills-2/

• I do not want to tak about bugs -

https://www.stickyminds.com/interview/i-don-t-want-talk-about-bugs-let-s-change-conversation-i

nterview-janet-gregory

Referências

Documentos relacionados

São muitos os problemas ambientais causados pelo crescimento urbano, o poder público não acompanha esse crescimento com investimentos em obras de infraestrutura, são ocupados

Curvas de rarefação (Coleman) estimadas para amostragens de espécies de morcegos em três ambientes separadamente (A) e agrupados (B), no Parque Estadual da Ilha do Cardoso,

autoincriminação”, designadamente através da indicação de exemplos paradigmáticos. Sem prejuízo da relevância da matéria – traduzida, desde logo, no número e

(1983) verificaram que a seleção aos cinco anos foi tão eficiente quanto aos 20 anos para os caracteres de crescimento em P. taeda, principalmente para altura, que foi usada

O objetivo do curso foi oportunizar aos participantes, um contato direto com as plantas nativas do Cerrado para identificação de espécies com potencial

-- A Alléém m ddooss bi bi op opol ol í ím mer eros  os  , moléculas menores como , moléculas menores como lipídios lipídios ,, água água ,, sais

servidores, software, equipamento de rede, etc, clientes da IaaS essencialmente alugam estes recursos como um serviço terceirizado completo...

Este artigo de revisão bibliográfica objetivou discutir o percurso histórico da loucura e do crime para entender como se deu o processo de constituição da unidade de saúde