Agile Testing - A Practical Guide For Testers and Agile Teams (Lisa Crispin and Janet Gregory) - 281-573

Machine Translated by Google
Capítulo 12
SUMÁRIO DE
QUADRANTES DE TESTE
Código de teste A Equipe e o Processo

Documentação O sistema explicado
Relatório de resultados de testes A aplicação
Resumo do quadrante: Testes unitários

Dirigindo
Testando em um Real
Desenvolvimento
Testes de aptidão
Projeto Ágil
Teste Exploratório
Testando feeds de dados Automação Funcional
Testes ponta a ponta Criticando o Automação Serviços web

Produto
UAT Estrutura de teste incorporada
Testes de confiabilidade
No Capítulo 6, apresentamos os quadrantes de teste e, nos capítulos seguintes,

falamos sobre como usar os conceitos em seu projeto ágil. Neste capítulo,
reuniremos tudo isso com um exemplo de equipe ágil que utilizou testes de
todos os quatro quadrantes.
REVISÃO DOS QUADRANTES DE TESTE Acabamos

de passar cinco capítulos falando sobre cada um dos quadrantes (veja a Figura
12-1) e exemplos de ferramentas que você pode usar para os diferentes tipos de teste.
O próximo truque é saber quais testes seu projeto precisa e quando realizá-los.
Neste capítulo, apresentaremos um exemplo real de um projeto ágil que usou
testes de todos os quatro quadrantes de testes ágeis.
241
produt
Crítica
242 CAPÍTULO 12 RESUMO DOS QUADRANTES DE TESTE
Quadrantes de testes ágeis
Automatizado
Voltado para negócios Manual
& Manual
do
Testes Funcionais Teste Exploratório
Exemplos Cenários
Testes de história Testando usabilidade

Protótipos UAT (teste de aceitação do usuário)
Simulações Alpha Beta
2º trimestre 3º trimestre
odneapiioupqA
e
a
Testes unitários Teste de desempenho e carga

Testes de Componentes Teste de segurança
Teste de “ilidade”
Automatizado Ferramentas
Voltado para a tecnologia
Figura 12-1 Quadrantes de Teste Ágil
UM EXEMPLO DE TESTE DE SISTEMA
A história a seguir é sobre o sucesso de uma organização ao testar todo o seu sistema usando
uma variedade de ferramentas locais e de código aberto. Janet trabalhou com essa equipe e
Paul Rogers foi o principal arquiteto de testes. Esta é a história de Paulo.
A Aplicação O sistema
resolve o problema de monitoramento remoto de poços de produção de petróleo e gás. A

solução combina um dispositivo de monitoramento remoto que pode transmitir dados e receber
ajustes de uma estação central de monitoramento usando um protocolo próprio através de
um canal de comunicação via satélite.
A Figura 12-2 mostra a arquitetura do sistema de Monitoramento Remoto de Dados. Os

dispositivos de medição nos poços de petróleo, Unidades Terminais Remotas (RTU), utilizam um va-
UM EXEMPLO DE TESTE DE SISTEMA 243
Site
Satélite
Satélite
UTR H/W
Modem
Cliente
Rede TCP
Ponte
Terceiros
Aplicativo
Dados na fila JMS
Pontes de rede
Serviços web
Rede
Roteamento e Dados Dados Apresentação e Servidor
distribuição de mensagens Em processamento Gerenciamento Navegação
Servidor de aplicação Usuário administrador
Servidor DB
Usuário básico
Base de dados Entrega de mensagens
Centro
E-mail, Fax, Foto
Figura 12-2 Arquitetura do sistema de monitoramento remoto de dados
variedade de protocolos para se comunicar com o dispositivo de medição. Esses dados de

cada UTR são transmitidos via satélite para servidores localizados na sede do cliente. Em
seguida, ele é disponibilizado aos usuários por meio de uma interface web. Um sistema de
notificação, via e-mail, fax ou telefone, está disponível quando uma determinada leitura está
fora dos limites operacionais normais. Um feed Java Message Service (JMS) e serviços
web também estão disponíveis para ajudar na integração com outros aplicativos dos clientes.
O aplicativo de software era um enorme sistema legado que tinha poucos testes unitários.
A equipe estava reconstruindo lentamente o aplicativo com novas tecnologias.
A Equipe e o Processo
A equipe consistia de quatro programadores de software, dois programadores de firmware,

três a quatro testadores, um engenheiro de produto e um gerente externo. O cliente “real”
estava em outro país. A equipe de desenvolvimento usa XP
práticas, incluindo programação em pares e TDD. A equipe do cliente usou

o sistema de rastreamento de defeitos para o backlog, mas a maior parte da visibilidade do
histórias era através de fichas. Cartões de história foram usados durante a iteração
reuniões de planejamento e o quadro de tarefas acompanhava o progresso.
Scrum foi usado como mecanismo de relatório externo para a organização e

os clientes. A equipe fez iterações de duas semanas e lançou o produto
aproximadamente a cada quatro meses. Isso variou dependendo da funcionalidade sendo
desenvolvido. Foram realizadas retrospectivas como parte de cada sessão de planejamento de iteração e
foram tomadas medidas sobre os três principais itens prioritários discutidos.
A integração contínua através do CruiseControl forneceu construções constantes para

os testadores e as demonstrações realizadas no final de cada iteração. Cada
testador tinha um ambiente local para testar a aplicação web, mas havia
três ambientes de teste disponíveis para o sistema. A primeira foi testar novos
histórias e foi atualizado conforme necessário com a versão mais recente. O segundo foi
para testar problemas relatados pelo cliente, porque teve a última versão lançada para
os clientes. O terceiro ambiente era um ambiente de teste totalmente independente
que estava disponível para testar implantações completas, links de comunicação e o
firmware e hardware. Foi neste ambiente que rodamos nossa carga e
testes de confiabilidade.
TESTES QUE CONDUZEM O DESENVOLVIMENTO
Os testes que direcionaram o desenvolvimento incluíram testes de unidade e testes de aceitação.
Testes unitários
Os testes unitários são testes voltados para a tecnologia que oferecem suporte à programação. Aqueles que
O Capítulo
7, “Testes são desenvolvidos como parte do desenvolvimento orientado a testes não apenas ajudam o programador
voltados para a a entender a história corretamente, mas também ajudam a projetar o sistema.
tecnologia que
dão suporte à
Os programadores do projeto Monitoramento Remoto de Dados compraram o Test
equipe”, explica
mais sobre testes unitários e Desenvolvimento
TDD. Orientado (TDD) e programação em pares de todo o coração. Tudo novo
a funcionalidade foi desenvolvida e testada usando programação em pares. Todas as histórias
entregues aos testadores foram suportados por testes unitários, e muito poucos bugs foram
encontrado após a codificação ser concluída. Os bugs encontrados foram geralmente
relacionados com a integração.
No entanto, quando a equipe começou, o sistema legado tinha poucos testes unitários para
apoiar a refatoração. À medida que as mudanças no processo foram implementadas, os desenvolvedores
AUTOMAÇÃO 245
decidiu começar a resolver o problema. Cada vez que eles tocavam em um pedaço de código
no sistema legado, eles adicionaram testes unitários e refatoraram o código conforme necessário.
Gradualmente, o sistema legado tornou-se mais estável e foi capaz de resistir a grandes refatorações
quando necessário. Experimentamos o poder de
testes unitários!
Testes de aptidão
O engenheiro de produto (o representante do cliente) assumiu a responsabilidade pela criação do
testes de aptidão. Esses testes variaram em formato dependendo da história real.
Embora tenha lutado no início, o engenheiro de produto ficou muito bom em dar
os testes para os programadores antes de começarem a codificar. A equipe criou um
modelo de teste, que evoluiu ao longo do tempo, que atendeu às necessidades dos programadores e
as necessidades dos testadores.
Os testes às vezes eram escritos informalmente, mas incluíam dados, configuração necessária se não
fosse imediatamente óbvio, variações diferentes que eram
crítica para a história e alguns exemplos. A equipe descobriu que os exemplos ajudaram
esclarecer as expectativas para muitas das histórias.
A equipe de teste automatizou os testes de aceitação o mais rápido possível, geralmente no

mesmo tempo em que as histórias estavam sendo desenvolvidas. Claro, o engenheiro de produto
estava disponível para responder a quaisquer perguntas que surgissem durante o desenvolvimento.
Esses testes de aceitação serviram a três propósitos. Eles eram testes voltados para negócios
Consulte o Capítulo 8,
que apoiaram o desenvolvimento porque foram entregues à equipe antes da codificação
“Relacionado aos negócios
Testes que apoiam a equipe”, iniciado. Em segundo lugar, eles foram usados pela equipe de teste como base para automação
para saber mais sobre isso alimentou o conjunto de regressão e forneceu ideias futuras para testes exploratórios. O terceiro
como conduzir o
objetivo foi confirmar se a implementação atendeu às necessidades
desenvolvimento com
do cliente. O engenheiro de produto fez esta verificação da solução.
testes de aceitação.
AUTOMAÇÃO
A automação envolveu a estrutura de testes funcionais, serviços web e testes incorporados.
A estrutura de teste funcional automatizado

Ruby foi utilizado com Watir como ferramenta de escolha para a automação funcional
estrutura. Foi determinado ter o máximo de flexibilidade e oportunidade
para personalização necessária para o sistema em teste.
O código de teste automatizado incluía três camadas distintas, mostradas na Figura 12-3.
A camada mais baixa, Camada 1, incluía Watir e outras classes, como loggers
que gravou nos arquivos de log.
A segunda camada, Camada 2, era a camada de acesso à página, onde as classes que continham
código para acessar páginas da web individuais. Por exemplo, no pedido em
test (AUT) havia uma página de login, uma página de criação de usuário e uma página de edição de usuário.
Classes escritas em Ruby continham código que poderia executar certas funções em
o AUT, como uma classe que faz login no aplicativo, uma classe para editar um usuário e um
classe para atribuir direitos de acesso a um usuário. Essas classes não continham dados. Por exemplo, a
classe log-in não sabia com qual nome de usuário fazer login.
A terceira e superior camada, Camada 3, era a camada de teste e continha os dados

necessário para realizar um teste. Ele chamou de classes da Camada 2, que por sua vez foram chamadas
Camada 1.
Por exemplo, o teste real chamaria LogIn e passaria Janet como o nome de usuário
e Passw0rd como senha. Isso significava que você poderia alimentar muitos
conjuntos de dados facilmente.
Login ('Janet', 'Senha')
Camada 3 – Camada de Teste
Camada 2 – Camada de acesso à página
Camada 1 – Controlador IE (Watir)
Figura 12-3 Camadas de teste funcional

AUTOMAÇÃO 247
A Camada 2 também sabia como lidar com as mensagens de erro geradas pelo aplicativo. Por
exemplo, quando um nome de usuário inválido foi inserido na página de login,
a classe de login detectou a mensagem de erro e depois devolveu o problema
aos testes na Camada 3.
Isso significa que as mesmas classes da Camada 2 podem ser usadas para testes de caminho feliz
e para testes negativos. No caso negativo, a Camada 3 esperaria que a Camada 2
retornaria uma falha e verificaria se o teste falhou pelo motivo correto, acessando as mensagens de
erro que a Camada Dois extraiu do navegador.
Os testes funcionais usaram Ruby com Watir para controlar o DOM no

navegador e poderia acessar quase todos os objetos da página. O automatizado
o conjunto de testes foi executado em compilações noturnas para fornecer feedback consistente à equipe sobre
comportamento de aplicativo de alto nível. Isso foi um salva-vidas, pois a equipe continuou a
construir os testes de unidade. Essa arquitetura acomodou com eficiência os testes voltados para o
negócio que dão suporte à equipe.
Serviços web
Os serviços da Web eram usados pelos clientes para fazer interface com alguns de seus outros
aplicativos. O grupo de desenvolvimento usou Ruby para escrever um cliente para testar cada serviço
eles desenvolveram. Para esses testes, o framework de testes unitários do Ruby, Test::Unit, foi
usado.
Os testes de serviços web foram ampliados pela equipe de teste para cobrir mais de
1.000 casos de teste diferentes e levaram apenas alguns minutos para serem executados. Eles deram ao time
uma quantidade incrível de cobertura em um curto período de tempo.
A equipe demonstrou o cliente de teste aos clientes, que decidiram usar

isso também. No entanto, os clientes decidiram posteriormente que não funcionava para
eles, então eles começaram a escrever seus próprios testes, embora de uma forma muito mais ad hoc
moda usando Ruby.
Eles usaram IRB, a interface interativa fornecida por Ruby, e alimentaram valores em
um método exploratório. Proporcionou ao cliente um ambiente interativo para
descobrir o que funcionou e o que não funcionou. Também permitiu que eles se familiarizassem com
Ruby e como estávamos testando, e isso deu a eles muito mais confiança
nossos testes. Grande parte do teste de aceitação do usuário foi feito usando IRB.
Três inclinações diferentes nos testes de serviços da web serviram a três propósitos diferentes. Os
programadores o usaram para ajudar a testar seus clientes e impulsionar seu desenvolvimento. Os
testadores usaram-no para criticar o produto de uma forma automatizada muito eficiente.
maneira, e os clientes puderam testar os serviços da web entregues a

usando o IRB.
Teste incorporado
Além da interface web, o sistema RDM consistia em um pequeno dispositivo embarcado que se
comunicava com equipamentos de medição utilizando vários
protocolos. Utilizando Ruby, vários testes foram desenvolvidos para testar parte de sua interface
administrativa. Essa interface era um sistema de linha de comando semelhante ao FTP.
Esses testes baseados em dados foram contidos em uma planilha Excel. Um rubi
script leria comandos do Excel usando a interface OLE e enviaria
para o dispositivo incorporado. O script então compararia a resposta
do aparelho com o resultado esperado, também realizado na planilha. Erros
foram destacados em vermelho. Esses testes automatizados levaram aproximadamente uma hora
para ser executado, enquanto fazer os mesmos testes manualmente levaria oito horas.
Embora isso tenha fornecido muita cobertura de teste, na verdade não testou o motivo pelo qual
foi utilizado um dispositivo que era para ler dados das UTRs. Um simulador foi escrito
em Ruby com uma GUI FOX (FXRuby). Isso permitiu que dados simulados fossem inseridos no
dispositivo. Como o simulador podia ser controlado remotamente, ele foi incorporado em testes
automatizados que exercitaram a capacidade do dispositivo embarcado de
ler dados, responder a condições de erro e gerar alarmes quando a entrada
os dados excederam um limite predeterminado.
Os testes incorporados são altamente técnicos, mas com o poder fornecido pelo
simulador, toda a equipe pôde participar dos testes do aparelho. O
O simulador foi escrito para dar suporte aos testes da equipe de teste, mas o programador do
firmware achou-o valioso e também o usou para ajudar em seus esforços de desenvolvimento.
Esse foi um efeito colateral inesperado e positivo. Quadrante 2
testes que apoiam a equipe podem incorporar uma variedade de tecnologias, pois
fiz neste projeto.
CRÍTICA DO PRODUTO COM

TESTES DE NEGÓCIOS
Os testes voltados para as empresas que criticam o produto são descritos nesta seção.
Teste Exploratório
Os testes automatizados eram simples e fáceis de usar por todos da equipe.
Scripts de teste individuais podem ser executados para configurar condições específicas, permitindo
CRÍTICA DO PRODUTO COM TESTES DE NEGÓCIOS 249
testes exploratórios efetivos sejam feitos sem gastar muito tempo

Testes exploratórios,
inserindo dados manualmente. Isso funcionou para todas as três estruturas de teste: funcional,
testes de usabilidade
serviços web e incorporado.
e outros
Os testes do quadrante
3 são discutidos em
A equipe realizou testes exploratórios para complementar o teste automatizado
Capítulo 10,
suítes e obtenha a melhor cobertura possível. Essa interação humana com o
“Visado para negócios
Testes que criticam
o sistema encontrou problemas que a automação não encontrou.
o produto."
O teste de usabilidade não era um requisito crítico para o sistema, mas os testadores
observei para que a interface fizesse sentido e fluísse suavemente. Os testadores
usou testes exploratórios extensivamente para criticar o produto. O engenheiro de produto também
utilizou testes exploratórios para os testes de verificação de sua solução.
Testando feeds de dados
Conforme mostrado na Figura 12-2, os dados do sistema estão disponíveis em um JMS

fila, bem como o navegador da web. Para testar a fila JMS, o desenvolvimento
grupo escreveu um proxy Java. Ele se conectou a uma fila e imprimiu qualquer entrada
dados para o console. Eles também escreveram um cliente Ruby que recebeu esses dados através de um
pipe, que estava então disponível no sistema de teste automatizado Ruby.
Os e-mails foram enviados automaticamente quando foram encontradas condições de alarme.

Os e-mails de alarme continham e-mails de texto simples e e-mails com anexos. Os anexos MIME
continham dados úteis para testes, então um Ruby
cliente de e-mail que suportava anexos foi escrito.
Os testes ponta a ponta
O quadrante 3 inclui testes funcionais ponta a ponta que demonstram o comportamento desejado de
cada parte do sistema. Desde o início, ficou evidente
que a operação correta de todo o sistema de monitoramento remoto de dados poderia
só será determinado quando todos os componentes forem usados. Depois que o simulador, os testes
de dispositivos incorporados, os testes de serviços da Web e os testes de aplicativos foram escritos, ele
foi uma questão relativamente simples combiná-los para produzir um teste automatizado
de todo o sistema. Mais uma vez, foram utilizadas planilhas Excel para realização da prova
dados e classes Ruby foram escritas para acessar os dados e resultados esperados.
Os testes ponta a ponta foram complicados pela resposta imprevisível do

caminho de transmissão por satélite. Um valor de tempo limite predefinido foi definido e se o teste
o valor real não correspondesse ao valor esperado, o teste iria circular até
correspondido ou o tempo limite foi atingido. Quando o tempo limite expirou, o teste foi
considerado fracassado. A maioria dos problemas de transmissão foram encontrados e eliminados
Por aqui. Teria sido altamente improvável que eles tivessem sido encontrados
com testes manuais, porque eram problemas esporádicos.
Como testes ponta a ponta como esses podem ser frágeis, eles podem não ser mantidos tão
parte do conjunto de regressão automatizada. Se todos os componentes do sistema
são bem cobertos com testes de regressão automatizados, testes automatizados de ponta a ponta
pode não ser necessário. No entanto, devido à natureza deste sistema, não foi
possível fazer um teste completo sem automação.
Testes de aceitação do usuário
O Teste de Aceitação do Usuário (UAT) é a crítica final do produto por parte do cliente, que
deveria estar envolvido no projeto desde o início. Nisso
Por exemplo, o verdadeiro cliente estava na França, a milhares de quilômetros da equipe de
desenvolvimento. A equipe teve que ser inventiva para ter um UAT bem-sucedido. O
cliente veio trabalhar com os membros da equipe algumas vezes durante o
ano e assim pude interagir com a equipe um pouco mais facilmente do que se eles tivessem
nunca conheci.
Depois que a equipe introduziu o desenvolvimento ágil, Janet foi à França para facilitar o primeiro
UAT nas instalações do cliente. Funcionou bastante bem e o lançamento
foi aceito depois que alguns problemas críticos foram corrigidos. A equipe aprendeu muito com
essa experiência.
A segunda aprovação do UAT foi feita internamente. Para se preparar, a equipe trabalhou
com o cliente para desenvolver um conjunto de testes que o cliente poderia realizar para verificar
novas funcionalidades. O cliente pôde testar o aplicativo durante todo o ciclo de desenvolvimento,
portanto o UAT não produziu nenhum problema. O cliente
veio, fez os testes e assinou em um dia.
Não podemos enfatizar suficientemente a importância de trabalhar com o cliente. Até

embora o engenheiro de produto fosse o representante do cliente, era crucial
tenha um contato direto com o cliente real. A relação que foi construída
ao longo do tempo foi fundamental para o sucesso do projeto. Janet acredita firmemente que
o UAT teve sucesso porque o cliente sabia o que a equipe estava fazendo
pelo caminho.
Confiabilidade
A confiabilidade, uma das “ilidades” abordadas pelos testes do Quadrante 4, foi um fator crítico
fator do sistema porque ele estava monitorando locais remotos que muitas vezes eram
DOCUMENTAÇÃO 251
inacessível, especialmente no inverno. O simulador desenvolvido para testar o sistema embarcado

foi montado em um ambiente separado e foi executado
durante semanas medindo a estabilidade (mais uma “ilidade”) de todo o sistema. Correções no
Testes que criticam o
produto”, para saber projeto do sistema podem ser planejadas e codificadas como
mais sobre os testes Quad- necessário. Este é um bom exemplo de por que você não deve esperar até o final do
rant 4, como
projeto para fazer os testes voltados para a tecnologia que criticam o produto.
testes de confiabilidade.
DOCUMENTAÇÃO
A abordagem adotada para a documentação é apresentada nesta seção.
Documentando o código de teste

Durante o desenvolvimento, ficou claro que um sistema de documentação formal
era necessário para o código de teste. A solução mais simples foi usar o RDoc, similar
para Javadoc, mas para Ruby. RDoc extraiu comentários marcados da fonte
código e páginas da web geradas com detalhes de arquivos, classes e métodos. O
os documentos eram gerados todas as noites usando um arquivo em lote e estavam disponíveis
para a equipe completa. Foi fácil descobrir quais equipamentos de teste foram criados.
A documentação do código de teste ajudou a documentar os testes e fazer

ficou mais fácil descobrir o que estávamos testando e o que os testes fizeram. Era muito poderoso e
fácil de usar.
Relatando os resultados do teste

Embora testes abrangentes estivessem sendo realizados, havia poucas evidências disso fora da
equipe de teste. Os logs gerados durante a automação
os testes forneciam boas informações para detectar problemas, mas não eram adequados para um
público mais amplo.
Capítulo 16, “Acertar
the Ground Running”,
Para aumentar a visibilidade dos testes realizados, a equipe de testes desenvolveu um
dá mais exemplos de
como as equipes relatam sistema de registro e relatórios usando Apache, PHP e mySQL. Quando um teste
os resultados dos testes. executado, ele registrou o resultado no banco de dados. Um projeto permitido de front-end da web
partes interessadas para determinar quais testes foram executados, a taxa de aprovação/reprovação e
outra informação.
Capítulo 18, “Codificação
e Teste,”
Também acreditávamos em tornar o nosso progresso visível (bom ou mau) tanto quanto
também discute o uso de
grandes gráficos
possível. Para esse fim criamos tabelas e gráficos ao longo do caminho e publicamos
visíveis. -los nas áreas comuns. A Figura 12-4 mostra alguns dos gráficos que criamos.
Figura 12-4 Grandes gráficos visíveis usados pela equipe do projeto do sistema de monitoramento remoto
USANDO OS QUADRANTES DE TESTE ÁGIL

Este exemplo demonstra como as práticas de teste de todos os quatro testes ágeis
quadrantes são combinados durante a vida de um projeto de desenvolvimento complexo para
alcançar uma entrega bem-sucedida. A experiência desta equipa ilustra muitos dos
os princípios que temos enfatizado. Toda a equipe, incluindo programadores, testadores,
proxy do cliente e o próprio cliente, contribuiu para
esforços para resolver problemas de automação. Eles experimentaram diferentes
abordagens. Eles combinaram suas ferramentas locais e de código aberto de diferentes
maneiras para realizar testes em todos os níveis, desde o nível de unidade até o de ponta a ponta.
testes de sistema e UAT. O sucesso do projeto demonstra o sucesso
da abordagem de teste.
Ao planejar cada épico, lançamento ou iteração, trabalhe com a equipe do cliente para
compreender as prioridades do negócio e analisar riscos. Use os quadrantes para
ajudar a identificar todos os diferentes tipos de testes que serão necessários e quando
eles deveriam ser executados. O desempenho é o critério mais importante? É o
RESUMO 253
maior prioridade a capacidade de interface com outros sistemas? A usabilidade é talvez o aspecto mais
importante?
Invista em uma arquitetura de teste que acomode a complexidade do sistema

sob teste. Planeje obter os recursos e conhecimentos necessários no momento certo
para testes especializados. Para cada tipo de teste, sua equipe deve trabalhar em conjunto para
escolha ferramentas que resolvam seus problemas de teste. Use retrospectivas para avaliar continuamente
se sua equipe tem os recursos necessários para ter sucesso e
se todos os testes necessários estão sendo especificados a tempo de servir ao seu propósito,
e automatizado adequadamente.
Os testes ponta a ponta parecem impossíveis de fazer? Sua equipe está achando difícil
escrever testes unitários? Como fez a equipe de Janet, faça com que todos experimentem diferentes
abordagens e ferramentas. Os quadrantes fornecem uma estrutura para um brainstorming produtivo sobre
maneiras criativas de realizar os testes que permitirão ao
equipe agrega valor ao negócio.
RESUMO
Neste capítulo, descrevemos um projeto real que utilizou testes de todos os quatro métodos ágeis.
quadrantes de teste para superar desafios de teste difíceis. Usamos exemplos
deste projeto para mostrar como as equipes podem ter sucesso com todos os tipos de testes.
Algumas lições importantes do projeto Sistema de Monitoramento Remoto de Dados são:
Toda a equipe deve escolher ou criar ferramentas que resolvam cada problema de teste.
Combinações de ferramentas de negócios comuns, como planilhas e scripts de testes

personalizados, podem ser necessárias para realizar tarefas complexas.
testes.
Invista tempo na construção da arquitetura de teste certa que funcione para todos os
membros da equipe.
Encontre maneiras de manter os clientes envolvidos em todos os tipos de testes, mesmo que
estejam em locais remotos.
Relate os resultados dos testes de uma forma que mantenha todas as partes interessadas
informadas sobre a iteração e o progresso do projeto.
Não esqueça de documentar. . . mas apenas o que é útil.
Pense em todos os quatro quadrantes de testes ao longo de seus ciclos de desenvolvimento.
Use as lições aprendidas durante os testes para criticar o produto e impulsionar o desenvolvimento
nas iterações subsequentes.
Esta página foi intencionalmente deixada em branco

Parte IV
AUTOMAÇÃO
A automação de testes é uma prática ágil central. Projetos ágeis dependem de automação.
Uma automação suficientemente boa libera a equipe para entregar código de alta qualidade com
frequência. Ele fornece uma estrutura que permite à equipe maximizar sua velocidade enquanto
mantendo um alto padrão. Controle de código-fonte, compilações automatizadas e testes
suítes, implantação, monitoramento e uma variedade de scripts e ferramentas eliminam
tédio, garantem a confiabilidade e permitem que a equipe faça sempre o seu melhor trabalho.
A automação também é um tópico vasto. Inclui tarefas como escrever shell simples
scripts, configurando propriedades de sessão e criando testes automatizados robustos.
A variedade e o número de ferramentas automatizadas parecem crescer exponencialmente à medida que
aprenda sobre melhores maneiras de produzir software. Felizmente, o número de livros excelentes que
ensinam maneiras de automatizar parece crescer com a mesma rapidez.
Este livro enfoca o papel do testador no desenvolvimento ágil. Como a automação é fundamental para
o desenvolvimento ágil bem-sucedido, precisamos conversar sobre isso, mas
não consigo começar a cobrir todos os aspectos do assunto. O que queremos explicar é
por que você, como testador, deve adotar a automação e como você e sua equipe
pode superar os muitos obstáculos que podem dificultar seus esforços de automação.
Esta seção descreve como você pode aplicar valores, princípios e práticas ágeis para desenvolver uma
estratégia de automação prática, superar barreiras e obter força na automação de testes.

Capítulo 13
POR QUE QUEREMOS

AUTOMATIZAR TESTES E
O QUE NOS DETENDE
O teste manual demora muito
Reduza tarefas de teste propensas a erros
Libere tempo para fazer o melhor trabalho
Internet Segura
Razões para
Automatizar
Forneça feedback com antecedência e frequência
Testes e exemplos que a codificação de unidade pode fazer mais
Os testes fornecem documentação
ROI/Investimento
Por que automatizar?
Lista de Bret
Atitude – Por que devemos automatizar?
Cultura Nós podemos

Corcunda de dor
Superar
Abordagem de toda a equipe barreiras? Investimento inicial
Obstáculos para
Observe
Código em fluxo
Código legado
Temer
Velhos hábitos
Por que automatizamos os testes, o processo de construção, a implantação e outras tarefas?

As equipes ágeis se concentram em ter sempre software funcional, o que lhes permite lançar
software pronto para produção com a frequência necessária. Alcançar esse objetivo
requer testes constantes. Neste capítulo, examinamos os motivos pelos quais queremos
automatizar e os desafios que dificultam o avanço da automação.
257
258 CAPÍTULO 13 POR QUE QUEREMOS AUTOMATIZAR OS TESTES E O QUE NOS RETÉIA
POR QUE AUTOMATIZAR?
Existem vários motivos para automatizar, além de dizermos que você precisa ter
automação para ter sucesso usando ágil. Nossa lista inclui o seguinte:
O teste manual demora muito.

Os processos manuais são propensos a erros.
A automação libera as pessoas para fazerem seu melhor trabalho.
Os testes de regressão automatizados fornecem uma rede de segurança.
Os testes automatizados fornecem feedback com antecedência e frequência.
Testes e exemplos que orientam a codificação podem fazer mais.

Os testes fornecem documentação.
A automação pode ser um bom retorno do investimento.
Vamos explorar cada um deles com um pouco mais de detalhes.
O teste manual demora muito

A razão mais básica pela qual uma equipe deseja automatizar é que simplesmente é preciso muito
muito tempo para concluir todos os testes necessários manualmente. Como sua aplicação
fica cada vez maior, o tempo para testar tudo fica cada vez mais longo,
às vezes exponencialmente, dependendo da complexidade do AUT (aplicativo em teste).
As equipes ágeis são capazes de entregar software pronto para produção no final de cada
iteração curta, tendo software pronto para produção todos os dias. Executando um
conjunto completo de testes de regressão aprovados pelo menos diariamente é uma prática indispensável,
e você não pode fazer isso com testes de regressão manuais. Se você não tiver nenhuma automação
agora, terá que fazer o teste de regressão manualmente, mas não deixe isso parar
você comece a automatizá-lo.
Se você executar seu teste de regressão manualmente, levará cada vez mais tempo
testando todos os dias, todas as iterações. Para que os testes acompanhem o ritmo da codificação, ou os
programadores precisam reservar um tempo para ajudar nos testes de regressão manual ou a equipe
precisa contratar mais testadores. Inevitavelmente, tanto a técnica
a dívida e a frustração crescerão.
Se o código não precisar passar por um conjunto de testes automatizados de regressão em nível de
unidade, os testadores provavelmente gastarão muito do seu tempo pesquisando, tentando reproduzir e
relatar esses bugs simples, e menos tempo encontrando.
bugs potencialmente graves no nível do sistema. Além disso, como a equipe não está desenvolvendo o
teste primeiro, é mais provável que o design do código seja menos testável e
pode não fornecer a funcionalidade desejada pela empresa.
POR QUE AUTOMATIZAR? 259
Testar manualmente vários cenários diferentes pode levar muito tempo, especialmente se você estiver
digitando entradas em uma interface de usuário. Configurando dados para uma variedade
de cenários complexos pode ser uma tarefa árdua se você não tiver
maneira de acelerar isso. Como resultado, apenas um número limitado de cenários pode ser
testado e defeitos importantes podem ser perdidos.
Processos manuais são propensos a erros
Os testes manuais ficam repetitivos, especialmente se você estiver seguindo testes com script,
e os testes manuais tornam-se enfadonhos muito rapidamente. É muito fácil cometer erros
e ignorar até mesmo bugs simples. Etapas e até testes inteiros serão ignorados. Se
a equipe enfrenta um prazo apertado, há a tentação de economizar e o
o resultado é um problema perdido.
Como o teste manual é lento, você ainda poderá testar à meia-noite no

último dia da iteração. Quantos bugs você notará então?
Construções automatizadas, implantação, controle de versão e monitoramento também são importantes

um longo caminho para mitigar riscos e tornar seu processo de desenvolvimento mais
consistente. Automatizar esses testes com script elimina a possibilidade de erros,
porque cada teste é feito exatamente da mesma maneira todas as vezes.
O ditado “construa uma vez, implemente para muitos” é o sonho de qualquer testador que se torna
realidade. A automação dos processos de construção e implantação permite saber exatamente o que
você está testando em qualquer ambiente.
A automação libera as pessoas para fazerem seu melhor trabalho
Escrever o código test-first ajuda os programadores a entender os requisitos e projetar o código de

acordo. Fazer compilações contínuas executam todos os testes de unidade e
os testes de regressão funcional significam mais tempo para fazer explorações interessantes
testando. Automatizar a configuração para testes exploratórios significa ainda mais tempo para
investigar partes potencialmente fracas do sistema. Porque você não gastou
tempo executando scripts manuais tediosos, você terá energia para fazer um bom trabalho,
pensando em diferentes cenários e aprendendo mais sobre como a aplicação
funciona.
Se estivermos pensando constantemente em como automatizar testes para uma correção ou um novo recurso, é
mais provável que pensemos em testabilidade e em um design de qualidade, em vez de em um projeto de qualidade.
hack rápido que pode ser frágil. Isso significa código melhor e testes melhores.
A automação de testes pode realmente ajudar na consistência do aplicativo.

A história de Janete
Jason (um de meus colegas testadores) e eu estávamos trabalhando em alguns scripts de
automação de GUI usando Ruby e Watir e adicionando constantes para nomes de botões para os
testes. Rapidamente percebemos que os botões em cada página não tinham nomes consistentes.
Conseguimos alterá-los e resolver esses problemas de consistência muito rapidamente, além de ter
Consulte o Capítulo
9, “Kit de uma maneira fácil de aplicar as convenções de nomenclatura.
ferramentas para negócios
—Janet
Testes que apoiam a
equipe”, Capítulo 12,
“Resumo dos quadrantes
de testes” e Capítulo
14, “Uma estratégia ágil Livros como Pragmatic Project Automation [2004] podem orientá-lo na automatização
de automação de testes”, das tarefas diárias de desenvolvimento e liberar sua equipe para atividades importantes
para obter mais
como testes exploratórios.
informações sobre Ruby e
Watir.
Oferecendo melhor trabalho aos testadores
Chris McMahon descreveu os benefícios que obteve devido à automação de testes de

regressão em uma postagem na lista de discussão de testes ágeis em novembro de 2007:
Nossa automação de testes de regressão de UI cresceu 500% desde abril [de 2007].
Isto nos permite concentrar a atenção de seres humanos reais em testes mais
interessantes.
Chris continuou explicando: “Agora que temos muita automação, temos tempo livre
para realmente pensar sobre o que os testes humanos precisam fazer. Para qualquer
teste que não seja trivial, praticamente institucionalizamos uma sessão de
brainstorming de ideias de teste antes de iniciar a execução.” Normalmente, Chris e
seus colegas de equipe formam pares com dois testadores ou um testador e um desenvolvedor.
Às vezes, um testador gera ideias e as analisa por meio de um mapa mental, uma página
wiki ou uma lista nas notas de lançamento. Chris observou: “Quase sempre temos
boas ideias de testes por meio de pares que não teriam sido encontradas por nenhum
dos indivíduos de forma independente”.
Referindo-se aos lançamentos frequentes de recursos significativos, Chris diz:

“Graças à boa automação de testes, temos tempo para investir para garantir que todo o
produto seja atraente e funcional para pessoas reais. Sem a automação, testar este
produto seria enfadonho e estúpido. Do jeito que está, nós, testadores, temos um
trabalho significativo e interessante a fazer para cada versão.”
Concordamos com Chris que a parte mais interessante da automação de testes é a maneira
como ela expande nossa capacidade de melhorar o produto por meio de testes exploratórios
inovadores.
Os projetos têm sucesso quando boas pessoas são livres para fazer o seu melhor trabalho. Automatizar os
testes adequadamente faz com que isso aconteça. Testes de regressão automatizados que
detectar alterações nas funcionalidades existentes e fornecer feedback imediato são
um componente primário disso.
Testes de regressão automatizados fornecem uma rede de segurança
A maioria dos profissionais que estão no ramo de software há alguns anos sabe
a sensação de pavor quando se deparam com a correção de um bug ou a implementação de um
novo recurso em código mal projetado que não é coberto por testes automatizados.
Aperte uma extremidade do balão aqui e outra parte ficará saliente. Será que
quebrar?
Saber que o código tem cobertura suficiente por testes de regressão automatizados dá
uma grande sensação de confiança. Claro, uma mudança pode produzir um efeito inesperado, mas
saberemos disso em questão de minutos se for no nível da unidade.
ou horas se estiver em um nível funcional superior. Fazer a mudança testar primeiro significa
pensando sobre a mudança de comportamento antes de escrever o código e escrever um
teste para verificá-lo, o que aumenta essa confiança.
Recentemente, conversei com um dos testadores da minha equipe que questionou o valor dos testes
automatizados. Minha primeira resposta foi “É uma rede de segurança” para a equipe.
No entanto, ele desafiou essa premissa. Não nos tornamos dependentes apenas dos testes em vez de corrigir
a causa raiz do problema?
Isso me fez pensar um pouco mais sobre minha resposta. Ele estava certo em certo sentido; se nos tornarmos
complacentes com nossos desafios de teste e dependermos apenas de testes automatizados para encontrar
nossos problemas e, em seguida, corrigi-los o suficiente para que o teste seja aprovado, estaremos prestando
um péssimo serviço a nós mesmos.
No entanto, se usarmos os testes para identificar áreas problemáticas e corrigi-las da maneira certa ou refatorar
conforme necessário, estaremos usando a rede de segurança da automação da maneira certa. A automação é
fundamental para o sucesso de um projeto ágil, especialmente à medida que o tamanho da aplicação cresce.
—Janet
Quando não possuem um conjunto automatizado de testes que atue como rede de segurança, o
os programadores podem começar a ver os próprios testadores como uma rede de segurança. É fácil
imaginar que o processo de pensamento de Joe Programmer é assim: “Eu deveria
volte e adicione alguns testes de unidade automatizados para formatEmployeeInfo, mas eu
saiba que Susie Tester verificará todas as páginas onde for usado manualmente.
Ela verá se alguma coisa está errada, então eu estaria apenas duplicando o esforço dela.”
É bom que um programador tenha tanta consideração pelos talentos do testador, mas Joe está
caindo em uma ladeira escorregadia. Se ele não automatizar esses testes unitários, quais outros
testes ele poderá pular? Susie estará muito ocupada examinando todas essas páginas.
As equipes que possuem boa cobertura de testes de regressão automatizados podem fazer
alterações no código sem medo. Eles não precisam se perguntar: “Se eu alterar este módulo
formatEmployeeInfo, quebrarei alguma coisa na interface do usuário?”
Os testes dirão imediatamente se quebraram alguma coisa ou não. Eles podem ir muito mais rápido
do que equipes que dependem exclusivamente de testes manuais.
Testes automatizados fornecem feedback antecipadamente e com
frequência Depois que um teste automatizado para uma parte da funcionalidade é aprovado, ele
deve continuar a ser aprovado até que a funcionalidade seja alterada intencionalmente. Quando
planejamos mudanças na aplicação, alteramos os testes para acomodá-las. Quando um teste
automatizado falha inesperadamente, um defeito de regressão pode ter sido introduzido por uma
alteração no código. Executar um conjunto automatizado de testes sempre que um novo código é
verificado ajuda a garantir que bugs de regressão sejam detectados rapidamente. Feedback rápido
significa que a mudança ainda está fresca na mente de alguns programadores, então a solução
de problemas será mais rápida do que se o bug não fosse encontrado até alguma fase de testes,
semanas depois. Falhar rápido significa que os bugs são mais baratos de corrigir.
Testes automatizados são executados regularmente e geralmente atuam como detectores de

alterações. Eles permitem à equipe a oportunidade de saber o que mudou desde a última construção.
Por exemplo, houve algum efeito colateral negativo na última compilação? Se o seu conjunto de
automação tiver cobertura suficiente, ele poderá identificar facilmente efeitos de longo alcance que
os testadores manuais nunca poderão esperar encontrar.
Na maioria das vezes, se os testes de regressão não forem automatizados, eles não serão
executados em todas as iterações, muito menos todos os dias. O problema surge muito rapidamente
durante o final do jogo, quando a equipe precisa completar todos os testes de regressão.
Bugs que seriam detectados no início são encontrados no final do jogo. Muitos dos benefícios dos
testes precoces são perdidos.
Testes e exemplos que impulsionam a codificação podem fazer mais
No Capítulo 7, “Testes voltados para a tecnologia que apoiam a equipe”, falamos sobre o uso de
testes e exemplos para orientar a codificação. Já falamos sobre como é importante conduzir a
codificação com testes de unidade e de cliente. Queremos também salientar que se estes testes
forem automatizados, tornar-se-ão valiosos por uma razão diferente. Eles se tornam a base para
um conjunto de regressões muito forte.
A história de Lisa
Depois que minha equipe dominou testes de unidade, refatoração, integração contínua e outras
práticas voltadas para a tecnologia, conseguimos detectar bugs de regressão e funcionalidades
implementadas incorretamente durante o desenvolvimento.
É claro que isso não significava que nossos problemas estivessem completamente resolvidos; às
vezes ainda ignoramos ou entendemos mal os requisitos. No entanto, ter uma estrutura de
automação implementada nos permitiu começar a focar em fazer um trabalho melhor de captura de
requisitos em testes iniciais. Também tivemos mais tempo para testes exploratórios.
Com o tempo, nossa taxa de defeitos diminuiu drasticamente, enquanto a satisfação de nossos
clientes com o valor comercial entregue aumentou.
—Lisa
TDD e SDD (desenvolvimento orientado a testes de história) mantêm as equipes pensando primeiro nos
A bibliografia contém um
artigo de Jennitta Andrea testes. Durante as reuniões de planejamento, eles conversam sobre os testes e a melhor forma de
[2008] sobre etiqueta de faça-os. Eles projetam o código para fazer os testes passarem, de modo que a testabilidade nunca seja um
equipe para TDD. problema. O conjunto de testes automatizados cresce junto com a base de código, fornecendo uma
rede de segurança para refatoração constante. É importante que toda a equipe pratique TDD e escreva
testes unitários consistentemente, ou a rede de segurança terá falhas.
A equipe também não acumula muita dívida técnica e sua velocidade é

tende a ser estável ou mesmo a aumentar ao longo do tempo. Essa é uma das razões pelas quais
os gerentes de negócios devem ficar felizes em permitir que as equipes de software reservem um tempo para
implementar boas práticas corretamente.
Os testes são uma ótima documentação
Na Parte III, explicamos como as equipes ágeis usam exemplos e testes para orientar o desenvolvimento.
Quando testes que ilustram exemplos de comportamento desejado são automatizados, eles se tornam
documentação “viva” de como o sistema realmente funciona.
funciona. É bom ter documentação narrativa sobre como funciona uma funcionalidade, mas ninguém pode
contestar um teste executável que mostra em
vermelho e verde como o código opera em um determinado conjunto de entradas.
É difícil manter a documentação estática atualizada, mas se não atualizarmos nossos

testes automatizados quando o sistema muda, os testes falham. Precisamos consertá-los
para manter nosso processo de construção “verde”. Isso significa que os testes automatizados são sempre
uma imagem precisa de como nosso código funciona. Essa é apenas uma das maneiras pelas quais nosso
o investimento em automação compensa.
ROI e retorno
Todas as razões apresentadas contribuem para os resultados financeiros e para o retorno da
automação. A automação fornece consistência a um projeto e dá
a oportunidade da equipe testar de forma diferente e ampliar os limites da aplicação. Automação
significa tempo extra para testadores e membros da equipe se concentrarem em colocar o produto
certo no mercado em tempo hábil.
Um componente importante do retorno da automação de testes é a forma como os defeitos são

fixo. Equipes que dependem de testes manuais tendem a encontrar bugs muito depois do código
contendo o bug está escrito. Eles entram no modo de consertar o “bug de
o dia”, em vez de olhar para a causa raiz do bug e redesenhar o
código de acordo. Quando os programadores executam o conjunto de testes automatizados em seus
própria sandbox, os testes de regressão automatizados encontram os bugs antes que o código seja
verificado, então há tempo para corrigir o design. Esse é um retorno muito maior e é como você
reduz a dívida técnica e desenvolve um código sólido.
BARREIRAS À AUTOMAÇÃO – COISAS QUE

ENTRE NO CAMINHO
Em 2001, Bret Pettichord [2001] listou sete problemas que afetam a automação. Eles ainda são
aplicáveis, mas são destinados a equipes que não incorporam a automação como parte de seu
desenvolvimento. E claro, porque
você está fazendo ágil, você está fazendo isso, certo?
Gostaríamos de pensar que todos incluíram tarefas de automação como parte

de cada história, mas a realidade é que você provavelmente não estaria lendo isso
seção se você tivesse tudo sob controle. Incluímos a lista de Bret para mostrar o que
problemas que você provavelmente terá se não incluir a automação como parte do
entregas diárias do projeto.
Lista de Bret
A lista de problemas de automação de Bret é assim:
Usar apenas o tempo livre para automação de testes não dá o foco necessário.
Faltam objetivos claros.

Há falta de experiência.
A rotatividade é alta, porque você perde qualquer experiência que possa ter.
Uma reação ao desespero é muitas vezes a razão pela qual a automação é escolhida
e, nesse caso, pode ser mais um desejo do que uma proposta realista.
BARREIRAS À AUTOMAÇÃO – COISAS QUE Atrapalham 265
Pode haver relutância em pensar em testes; a diversão está na automação, não nos testes.
Concentrar-se na solução do problema tecnológico pode fazer com que você perca de vista
se o resultado atende às necessidades do teste.
Achamos que existem alguns outros problemas que as equipes enfrentam ao tentar
automatizar. Mesmo que tentemos incluir a automação nas entregas do nosso projeto,
existem outras barreiras para o sucesso. Na próxima seção, apresentamos nossa lista de
obstáculos para uma automação de testes bem-sucedida.
Nossa lista
Nossa lista de barreiras para uma automação de testes bem-sucedida é baseada nas experiências
tivemos com nossas próprias equipes ágeis, bem como com as de outras equipes que conhecemos.
Atitude dos programadores

A “corcunda da dor”
Investimento inicial
Código que está sempre em fluxo

Sistemas legados
Temer
Velhos hábitos
Atitude dos programadores – “Por que automatizar?”
Programadores acostumados a trabalhar em um ambiente tradicional, onde

alguma equipe de controle de qualidade separada e invisível faz todos os testes, pode nem mesmo dar
automação de testes funcionais muita reflexão. Alguns programadores não se preocupam
testar muito porque eles têm a equipe de controle de qualidade como uma rede de segurança para detectar
bugs antes do lançamento. Longos ciclos de desenvolvimento em cascata tornam os testes ainda mais
remotos para os programadores. No momento em que os testadores invisíveis estão fazendo seu trabalho, o
os programadores passaram para a próxima versão. Defeitos entram em uma fila para
ser consertados mais tarde com grandes custos, e ninguém é responsável por tê-los produzido. Até mesmo
os programadores que adotaram o desenvolvimento orientado a testes
e estão acostumados a automatizar testes em nível de unidade podem não pensar em como
testes de aceitação além do nível de unidade são realizados.
Certa vez, entrei para uma equipe XP de programadores qualificados que praticavam desenvolvimento orientado
A história de Lisa
a testes e que tinham um conjunto razoável de testes unitários em execução em um processo de construção
automatizado. Eles nunca haviam automatizado nenhum teste voltado para os negócios, então um dia
comecei uma discussão sobre quais ferramentas eles poderiam usar para automatizar testes de regressão
funcionais voltados para os negócios. Os programadores queriam saber por que precisávamos automatizar esses testes.
No final da primeira iteração, quando todos estavam executando os testes de aceitação

manualmente, indiquei que haveria todos esses testes para serem feitos novamente na
próxima iteração como testes de regressão, além dos testes para todas as novas histórias .
Na terceira iteração, haveria três vezes mais testes. Para um testador, parece
ridiculamente óbvio, mas às vezes os programadores precisam fazer testes manuais
antes de entenderem a necessidade de automatizá-los.
—Lisa
A educação é a chave para fazer com que os programadores e o restante da equipe entendam
a importância da automação.
A “corcunda da dor” (a curva de aprendizado)

É difícil aprender a automação de testes, especialmente aprender como fazê-lo de uma forma que
produz um bom retorno sobre os recursos nele investidos. Um termo que ouvimos
Brian Marick usa para descrever a fase inicial de automação que os desenvolvedores
(incluindo os testadores) que precisam superar é o “corcunda da dor” (ver Figura 13-1).
Esta frase refere-se à luta que a maioria das equipes enfrenta ao adotar
automação.
Freqüentemente, espera-se que novas equipes adotem práticas como TDD e refatoração, que
são difíceis de aprender. Sem um bom treinamento, há muito tempo para
dominar novas habilidades e um forte apoio gerencial, eles são facilmente desencorajados
Figura 13-1 Ponto problemático da curva de aprendizado da automação

envelhecido. Se eles tiverem obstáculos extras para aprender, como ter que trabalhar com
código legado mal projetado, pode parecer impossível obter força
automação de testes.
Minha equipe na ePlan Services originalmente tentou escrever testes unitários para um sistema legado que definitivamente
A história de Lisa
não foi escrito pensando em testes. Eles acharam que essa era uma tarefa difícil, se não impossível, então decidiram
codificar todas as novas histórias em uma arquitetura nova e testável. Curiosamente, cerca de um ano depois, eles
descobriram que não era tão difícil escrever testes unitários para o código antigo. O problema era que eles não
sabiam escrever testes unitários e era mais fácil aprender em uma arquitetura bem projetada.
Escrever testes em nível de unidade tornou-se simplesmente uma parte natural da escrita de código.
—Lisa
A dor pode ocorrer porque você está construindo seu domínio específico
estrutura de teste ou aprendendo sua nova ferramenta de teste funcional. Você pode querer
traga um especialista para ajudá-lo a configurar corretamente.
Você sabe que sua equipe superou o “obstáculo” quando a automação se torna,
se não for fácil, pelo menos um processo natural e arraigado. Lisa trabalhou em três
equipes que adotaram com sucesso o TDD e a automação de testes funcionais. Cada
Ao mesmo tempo, a equipe precisava de muito tempo, treinamento, comprometimento e incentivo
para obter força nas práticas.
Investimento inicial
Mesmo com toda a equipe trabalhando no problema, a automação requer um
grande investimento, que pode não render imediatamente. Leva tempo e pesquisa para decidir
quais estruturas de teste usar e se devem ser construídas
internamente ou use ferramentas produzidas externamente. Novos hardware e software são

provavelmente necessário. Os membros da equipe podem demorar um pouco para aprender como
use equipamentos de teste automatizados.
Muitas pessoas experimentaram esforços de automação de testes que não valeram a pena.
A organização deles pode ter adquirido uma ferramenta de captura e reprodução de fornecedor,
entreguei-o à equipe de controle de qualidade e esperava que ele resolvesse todos os problemas de
automação. Essas ferramentas geralmente ficam em uma prateleira acumulando poeira. Pode ter havido
milhares de linhas de scripts de teste de GUI gerados, sem sobrar ninguém que saiba
o que eles fazem, ou os scripts de teste que são impossíveis de manter não são mais
útil.
Entrei em uma organização como novo gerente de controle de qualidade. Uma das minhas tarefas era
avaliar os scripts de testes automatizados atuais e aumentar a cobertura dos testes. Uma ferramenta de
fornecedor foi adquirida alguns anos antes e os testadores que desenvolveram o conjunto inicial não
estavam mais na organização. Um dos novos testadores contratados estava tentando aprender a
ferramenta e adicionando testes ao conjunto.
A primeira coisa que fiz foi pedir a esse testador para fazer uma avaliação do conjunto de testes para ver
qual era realmente a cobertura. Ela passou uma semana apenas tentando entender como as provas eram
organizadas. Comecei a fuçar também e descobri que os testes existentes eram muito mal projetados e
tinham muito pouco valor.
Paramos de adicionar mais testes e, em vez disso, passamos um pouco de tempo entendendo qual era o
objetivo de nossa automação de testes. No final das contas, a ferramenta do fornecedor não conseguiu
fazer o que realmente precisávamos, então cancelamos as licenças e encontramos uma ferramenta de
código aberto que atendesse às nossas necessidades.
Ainda tivemos que gastar tempo aprendendo a nova ferramenta de código aberto, mas esse investimento
teria sido feito se tivéssemos continuado com a ferramenta original do fornecedor, porque ninguém na
equipe sabia como usar a ferramenta original.
—Janet
As habilidades de design de teste têm um enorme impacto sobre se a automação compensa ou não
ausente. Práticas inadequadas produzem testes difíceis de entender e manter,
e pode produzir resultados difíceis de interpretar ou falsas falhas que levam tempo para serem
pesquisar. Equipes com treinamento e habilidades inadequadas podem decidir o retorno
em seu investimento em automação não vale seu tempo.
Boas práticas de design de testes produzem testes simples, bem projetados, continuamente refatorados
e de fácil manutenção. Bibliotecas de módulos de teste e objetos são construídas
tempo e agilize a automação de novos testes. Veja o Capítulo 14 para algumas dicas
e diretrizes para design de teste para automação.
Sabemos que não é fácil capturar métricas. Por exemplo, tentar capturar o
tempo necessário para escrever e manter testes automatizados versus o tempo necessário para
executar os mesmos testes de regressão manualmente é quase impossível. Da mesma forma, tentando
capturar quanto custa corrigir defeitos minutos após a introdução
eles versus quanto custa encontrar e corrigir problemas após o final do
a iteração também é bastante difícil. Muitas equipes não se esforçam para rastrear isso
Informação. Sem números mostrando que automatizar exige menos esforço
e agrega mais valor, é mais difícil para as equipes convencer a gestão de que
vale a pena investir em automação. A falta de métricas que demonstrem o retorno sobre o investimento
da automação também torna mais difícil mudar uma situação.

hábitos da equipe.
Código que está sempre em fluxo
Automatizar testes por meio da interface do usuário é complicado, porque as UIs tendem a
mudam frequentemente durante o desenvolvimento. Essa é uma das razões pelas quais esse registro simples
e as técnicas de reprodução raramente são uma boa escolha para um projeto ágil.
Se a equipe estiver lutando para produzir um bom design no negócio subjacente

lógica e acesso ao banco de dados, e grandes retrabalhos são feitos com frequência, pode ser
difícil de acompanhar, mesmo com testes automatizados por trás da GUI no nível da API. Se
Se pouca atenção for dada aos testes durante o projeto do sistema, pode ser difícil e caro encontrar uma
maneira de automatizar os testes. Os programadores e
os testadores precisam trabalhar juntos para obter um aplicativo testável.
Embora o código e a implementação reais, como a GUI, tendam a mudar

No Capítulo 14, “Uma
frequentemente no desenvolvimento ágil, a intenção do código raramente muda. Organizar o código de teste
Estratégia Ágil de
Automação de Testes,” pela intenção da aplicação, e não pela sua implementação,
veremos maneiras de permite que você acompanhe o desenvolvimento.
organizar testes
automatizados.
Código legado
Em nossa experiência, é muito mais fácil obter tração na automação se você estiver escrevendo
um código totalmente novo em uma arquitetura projetada com testes em mente. Escrita
testar códigos existentes que tenham poucos ou nenhum teste é, na melhor das hipóteses, uma tarefa assustadora. Parece
praticamente impossível para uma equipe novata em agilidade e novata em automação de testes.
Às vezes é um beco sem saída. Você deseja automatizar testes para poder refatorar
parte do código legado, mas o código legado não foi projetado para ser testado, então
é difícil automatizar testes mesmo em nível de unidade.
Se sua equipe enfrenta esse tipo de desafio e não dispõe de tempo suficiente para
Se você fizer um brainstorming sobre como lidar com isso, será difícil começar a automatizar testes de
maneira eficaz. O Capítulo 14 apresenta estratégias para abordar estas questões.
Temer
A automação de testes é assustadora para quem nunca a dominou e até para alguns
quem têm. Os programadores podem ser bons em escrever código de produção, mas
pode não ter muita experiência em escrever testes automatizados. Os testadores não podem
têm uma sólida experiência em programação e não confiam em seu potencial
habilidades de automação de testes.
Os testadores que não são de programação muitas vezes recebem a mensagem de que
nada a oferecer no mundo ágil. Acreditamos no contrário. Nenhum testador individual
precisa se preocupar em como fazer a automação. É um problema de equipe e

geralmente há muitos programadores na equipe que podem ajudar. O truque
é abraçar o aprendizado de novas ideias. Viva um dia de cada vez.
Velhos hábitos
Quando as iterações não ocorrem sem problemas e a equipe não consegue concluir todos os
as tarefas de programação e teste ao final de uma iteração, os membros da equipe
pode entrar em pânico. Observamos que quando as pessoas entram em pânico, elas caem
em velhos hábitos confortáveis, mesmo que esses hábitos nunca tenham produzido bons resultados.
Portanto, podemos dizer: “Devemos entregar no dia 1º de fevereiro.

nessa data, não temos tempo para automatizar nenhum teste. Teremos que fazer o que for
testes manuais podem ser feitos nesse período de tempo e esperar o melhor. Nós
sempre podemos automatizar os testes posteriormente.”
Este é o caminho para a perdição. Alguns testes manuais podem ser feitos, mas talvez não
os importantes testes exploratórios manuais que teriam encontrado o bug que
custou à empresa centenas de milhares de dólares em vendas perdidas. Então, como não terminamos
nossas tarefas de automação de testes, essas tarefas são transferidas
para a próxima iteração, reduzindo a quantidade de valor comercial que podemos entregar.
À medida que as iterações avançam, a situação continua a deteriorar-se.
PODEMOS SUPERAR ESSAS BARREIRAS ?

A abordagem ágil de toda a equipe é a base para superar os desafios de automação. Os
Consulte o
Capítulo 3, programadores que são novos no Agile provavelmente estão acostumados a serem recompensados
“Desafios Culturais”, pela entrega de código, seja ele cheio de bugs ou não, desde que eles
para obter algumas cumprir prazos. O desenvolvimento orientado a testes é mais orientado para o design
ideias sobre como
do que testes, então os testes voltados para os negócios ainda podem não entrar em sua consciência.
fazer mudanças
na cultura da equipe É preciso liderança e comprometimento da equipe com a qualidade para que todos pensem sobre
para facilitar práticas ágeis. como escrever, usar e executar testes voltados para a tecnologia e para os negócios. Envolver toda
a equipe na automação de testes pode ser uma
desafio cultural.
No próximo capítulo, mostraremos como usar valores e princípios ágeis para superar alguns dos
problemas descritos neste capítulo.
RESUMO 271
RESUMO
Neste capítulo, analisamos alguns fatores importantes relacionados à automação de testes:
Precisamos de automação para fornecer uma rede de segurança, fornecer feedback essencial,
manter o débito técnico ao mínimo e ajudar a impulsionar a codificação.
Medo, falta de conhecimento, experiências anteriores negativas com automação, código em
rápida mudança e código legado estão entre as barreiras comuns à automação.
Automatizar testes de regressão, executá-los em um processo de construção automatizado

e corrigir as causas principais dos defeitos reduz o débito técnico e permite o crescimento de
código sólido.
Automatizar testes de regressão e tarefas manuais tediosas libera a equipe para trabalhos
mais importantes, como testes exploratórios.
Equipes com testes automatizados e processos de construção automatizados desfrutam de
uma velocidade mais estável.
Sem testes de regressão automatizados, o escopo dos testes de regressão manuais
continuará a crescer e, eventualmente, poderá ser simplesmente ignorado.
A cultura e o histórico da equipe podem tornar mais difícil para os programadores priorizar a
automação de testes voltados para os negócios do que a codificação de novos recursos.
Usar princípios e valores ágeis ajuda toda a equipe a superar barreiras à automação de testes.

Capítulo 14
UM TESTE ÁGIL
ESTRATÉGIA DE AUTOMAÇÃO
Pirâmide de Teste
Automação
Categorias de teste Quadrantes
Organizando testes Gerenciando

Automatizado
Organizando resultados de testes Testes Integração contínua,
Compila e implanta
Testes unitários e de componentes

Implementando
API ou serviços da Web
Automação
Por trás da GUI
O que pode
GUI
Automatizamos?
Identificando Requisitos
Carregar
Uma ferramenta de cada vez Avaliando
Automação Comparações
Escolhendo ferramentas Ferramentas
Tarefas repetitivas
Ferramentas ágeis
Criação ou configuração de dados
Desenvolvendo
uma automação
Estratégia
Ferramentas de geração de dados
Usabilidade
Evite acesso ao banco de dados Fornecimento
Dados para Exploratório
O que não deveríamos
Quando o acesso ao banco de dados é inevitável
Testes
automatizar? Testes que nunca falharão
Entenda suas necessidades
Testes únicos
Mantenha simples
O que pode ser difícil
Feedback Iterativo de automatizar?
Abordagem de toda a equipe Aplicar Ágil

Princípios para
Reserve um tempo para fazer certo O que mais dói?
Automação
Aprender fazendo Desenvolvendo Abordagem Multicamadas
uma estratégia – por

Aplicando práticas de codificação ágil Projeto e manutenção de testes
onde começamos?
Escolhendo as ferramentas certas
273
274 CAPÍTULO 14 UMA ESTRATÉGIA DE AUTOMAÇÃO DE TESTE ÁGIL
À medida que exploramos cada um dos quadrantes de testes ágeis na Parte III, demos exemplos de
ferramentas que podem ajudar o sucesso desses diferentes esforços de testes. Muitas dessas
ferramentas são para automatizar testes. Conforme descrevemos no capítulo anterior, as equipes
enfrentam muitos obstáculos em sua busca por uma automação de testes bem-sucedida. Ferramentas
melhores ficam disponíveis o tempo todo, mas o truque é escolher as ferramentas certas e aprender
a usá-las de maneira eficaz. A automação de testes requer investimentos cuidadosos e melhorias
incrementais. Neste capítulo, explicamos como você pode aplicar valores e princípios ágeis para obter
impulso ao iniciar ou melhorar seus esforços de automação.
UMA ABORDAGEM ÁGIL PARA A AUTOMAÇÃO DE TESTE
Aqui está você, lendo este capítulo sobre como fazer sua estratégia de automação de testes funcionar,
talvez esperando por aquela solução mágica ou por uma resposta para todas as suas dúvidas.
questões. Odiamos desapontá-lo, mas precisamos dizer logo de cara:
Não há bala de prata. Não existe uma resposta que funcione para todas as equipes.
Não desanime, porque temos algumas ideias para ajudá-lo a começar.
Primeiro, sugerimos abordar seus problemas de automação como faria com qualquer
problema. Defina o problema que você está tentando resolver. Para ajudá-lo a descobrir isso
fora, primeiro falamos sobre alguns fundamentos da automação de testes e reintroduzimos alguns
termos.
Categorias de testes de automação
Na Parte III, apresentamos os Quadrantes de Teste Ágil e falamos sobre cada

quadrante e a finalidade dos testes em cada quadrante. Nesta seção, nós
olhe para os quadrantes sob uma luz diferente. Vamos olhar cuidadosamente para os quadrantes
(veja a Figura 14-1).
Você pode ver que rotulamos os dois quadrantes que apoiam a equipe (Q1 e
Q2) como usar automação. No Quadrante 4, as ferramentas utilizadas para criticar o
produto do ponto de vista tecnológico também geralmente requer ferramentas automatizadas.
No Capítulo 9, “Kit de ferramentas para testes voltados para negócios que apoiam a equipe”, nós
discutimos algumas das ferramentas que podem ser usadas para automatizar
testes na busca por apoiar a equipe. Na verdade, o único quadrante que não é
rotulado como usando automação é o Quadrante 3 – os testes voltados para os negócios que criticam o
produto. No entanto, como discutimos no Capítulo 10, “Recursos voltados para os negócios
Testes que criticam o produto”, as ferramentas podem ser úteis para alguns desses testes.
Por exemplo, a automação pode ajudar a configurar dados de teste e cenários de usuário, além de
analisar atividades registradas.
produt
Crítica
UMA ABORDAGEM ÁGIL PARA A AUTOMAÇÃO DE TESTE 275
Quadrantes de testes ágeis
Automatizado
Voltado para negócios Manual
& Manual
do
Testes Funcionais Teste Exploratório
Exemplos Cenários
Testes de história Testando usabilidade

Protótipos UAT (teste de aceitação do usuário)
Simulações Alpha Beta
odneapiioupqA
e
a
Testes unitários Teste de desempenho e carga

Testes de Componentes Teste de segurança
Teste de “ilidade”
Automatizado Ferramentas
Voltado para a tecnologia
Figura 14-1 Quadrantes de Teste Ágil
Use os quadrantes para ajudá-lo a identificar os diferentes tipos de ferramentas de automação

necessárias para cada projeto, até mesmo para cada iteração. Achamos útil examinar cada
“Testes voltados para
os negócios que dão suporte
quadrante e fazer uma lista de verificação de quais ferramentas podem ser necessárias. Digamos
à equipe”, para obter que estamos prestes a redesenhar uma IU. Observamos o quadrante 1. Como ele pode ser
mais informações sobre
codificado primeiro para teste? Sabemos como testar nossa camada de apresentação?
os testes do Mágico de Oz.
Precisamos de uma nova ferramenta para ajudar com isso? Agora vamos para o quadrante 2.
Precisaremos fazer alguns protótipos; devemos apenas usar papel ou devemos planejar uma
atividade do tipo Mágico de Oz? Que ferramenta usaremos para criar testes executáveis voltados
para os negócios para orientar o desenvolvimento? Temos scripts de teste de regressão que
precisarão ser atualizados ou substituídos? Sabemos que uma de nossas atividades do Quadrante
3 será o teste de usabilidade. Isso requer algum planejamento prévio. Talvez queiramos
ferramentas que ajudem a rastrear as atividades dos usuários para que possamos analisá-las
mais detalhadamente. Pensando no Quadrante 4, percebemos que temos scripts de teste de
carga que usam a UI antiga, então temos que reservar tempo para atualizá-los para a nova.
Como enfatizamos na Parte III, “Usando os quadrantes de testes ágeis”, a ordem

dos quadrantes não está relacionado à ordem em que fazemos os testes. Como nós
fazemos nosso checklist de ferramentas necessárias para cada tipo de teste, pensamos em quando
queremos testar para sabermos quando ter nossas ferramentas de automação prontas. Por exemplo,
uma equipe que projeta uma nova arquitetura planejaria fazer um pico e executar
teste de escalabilidade contra ele o mais rápido possível. Eles precisarão gastar tempo
durante a primeira iteração do projeto, encontrar e implementar uma ferramenta de teste de desempenho.
Os quadrantes nos ajudam a descobrir quais ferramentas podemos precisar, mas com tantas
diferentes opções de automação em diferentes níveis, uma estratégia de onde fazer
quais tipos de testes e como organizá-los é essencial. Para entregar valor
de forma rápida e frequente, nossos esforços de automação precisam de um alto ROI. A pirâmide de teste
nos ajuda a otimizar nosso investimento em testes.
Pirâmide de Automação de Testes
A Figura 14-2 ilustra a “pirâmide de automação de testes”. Gostamos da versão

que Mike Cohn apresentou, que mostra a camada de base composta de
testes de unidade e componentes voltados para a tecnologia. Reconhecemos que muitas equipes
vai lutar com essa ideia, porque parece o oposto do que muitos
as equipes têm atualmente. Muitas equipes de teste aprenderam o modelo “V” de
testes, onde atividades como testes de componentes, sistemas e versões são
feito em sequência após as atividades de codificação. Outras equipes possuem uma pirâmide invertida,
com a maioria dos testes na camada funcional ou de apresentação.
A pirâmide ágil de automação de testes mostra três camadas diferentes de automação

testes. A camada mais baixa é a base que sustenta todo o resto. É principalmente
composto por testes de unidade e testes de componentes robustos, o ambiente voltado para a tecnologia
testes que apoiam a equipe. Esta camada representa a maior parte do processo automatizado
testes. Geralmente são escritos na mesma linguagem do sistema em teste,
usando a família de ferramentas xUnit. Depois que uma equipe domina a arte do TDD,
esses testes são de longe os mais rápidos e menos caros de escrever. Eles providenciam
o feedback mais rápido também, o que os torna altamente valiosos. Eles têm, de longe, o maior ROI de
qualquer tipo de teste.
No desenvolvimento ágil, tentamos enviar o máximo de testes possível para esta camada.
Embora os testes voltados para os negócios tendam a ocorrer em um dos níveis mais altos, nós os
“Testes voltados
para a tecnologia que implementamos no nível da unidade quando faz sentido. Se eles testarem os clientes
apoiam a equipe” não precisam ser capazes de ler e podem ser codificados muito mais rapidamente, pois
para obter mais
testes unitários, é uma boa opção. Outros tipos de testes voltados para a tecnologia, como
informações sobre testes
unitários e de componentes.
testes de desempenho também podem ser possíveis no nível da unidade.
UMA ABORDAGEM ÁGIL PARA A AUTOMAÇÃO DE TESTE 277
Manual
Testes
GUI
Testes
Testes de aptidão
(Camada API)
Testes unitários/testes de componentes
Figura 14-2 Pirâmide de automação de teste
A camada intermediária da pirâmide é a camada que inclui a maioria dos testes automatizados voltados para
os negócios, escritos para apoiar a equipe. Esses são os testes funcionais que verificam se estamos
"Visado para negócios
Testes que apoiam a “construindo a coisa certa”. Os testes neste
equipe", para saber camada pode incluir testes de “história”, testes de “aceitação” e testes que cobrem
mais sobre
conjuntos de funcionalidades do que a camada de teste de unidade. Esses testes operam na API
voltado para negócios
nível ou “por trás da GUI”, testando a funcionalidade diretamente, sem passar
testes que apoiam a
equipe. através da GUI. Escrevemos casos de teste que configuram entradas e fixtures que alimentam
as entradas no código de produção, aceite as saídas e compare-as
aos resultados esperados. Como esses testes ignoram a camada de apresentação, eles são
menos dispendioso para escrever e manter do que testes que usam a interface.
Tentamos escrevê-los em uma linguagem específica de domínio que os clientes possam

entender, então eles exigem mais trabalho do que testes em nível de unidade. Eles também geralmente
executado mais lentamente, porque cada teste cobre mais terreno do que um teste de unidade e
pode acessar o banco de dados ou outros componentes. O feedback que eles fornecem é
não tão rápido quanto os testes em nível de unidade, mas ainda é muito mais rápido do que poderíamos obter
operando através da interface do usuário. Portanto, seu ROI não é tão alto quanto
os testes que formam a base da pirâmide, mas é mais alto que a camada superior.
Fit e FitNesse são exemplos de ferramentas utilizadas para a camada intermediária da pirâmide.
Nós temos mais
sobre esses testes
Equipamentos de teste desenvolvidos internamente que usam planilhas ou outros meios de negócios
no Capítulo 8, para definir casos de teste também são comuns.

Testes que apoiam a
A camada superior representa o que deveria ser o menor esforço de automação, porque os testes
equipe” e
geralmente fornecem o ROI mais baixo. Esses testes são os
Capítulo 9, “Kit de
ferramentas para negócios feito através da GUI, aqueles que realmente operam e manipulam o
Testes que apoiam a camada de apresentação. Eles são escritos depois que o código é concluído e também
equipe”, onde discutimos
geralmente escrito para criticar o produto e ir diretamente para o conjunto de regressão.
as questões voltadas
para o negócio
testes que apoiam a Esses testes são tradicionalmente mais caros de escrever, embora existam novos
equipe e o ferramentas que ajudam a reduzir o investimento necessário. Porque os componentes do
ferramentas que efetivamente
a interface do usuário tende a ser alterada com frequência, esses testes são muito mais frágeis
capturar ativamente
esses testes.
do que testes que funcionam em nível funcional ou de unidade. Por exemplo, apenas renomeando
Elementos HTML podem causar falha em um script de teste. Operando através do usuário
interface também retarda esses testes, em comparação com testes nos níveis mais baixos de
a pirâmide que opera diretamente no código de produção. Os testes no topo
camada fornece feedback importante, mas um conjunto de testes de GUI pode levar horas
para ser executado, em vez dos poucos minutos necessários para conjuntos de testes em nível de unidade. Nós
deseja minimizar o número de testes nesta camada, então eles devem formar apenas
a ponta da pirâmide.
Não importa quantos testes automatizados eles tenham, a maioria dos sistemas também precisa de
atividades de teste manuais, como testes exploratórios e testes de aceitação do usuário.
Não queremos esquecê-los, por isso os ilustramos com a pequena nuvem em
a ponta da pirâmide. A maior parte dos nossos testes de regressão deve ser automatizada
ou nossos testes manuais também não nos proporcionarão um bom retorno do investimento.
Patrick Wilson-Welsh [2008] acrescenta uma dimensão descritiva à pirâmide de automação de testes
com uma metáfora dos “três porquinhos”. A base inferior
camada é feita de tijolos. Os testes são sólidos e não vulneráveis ao ataque
e o sopro do Lobo Mau. A camada intermediária é feita de palitos. Eles
precisa ser reorganizado com mais frequência do que a camada de tijolo para permanecer forte. Os testes em
a camada superior é feita de palha. É difícil fazê-los permanecer no lugar, e o
o lobo pode facilmente explodi-los. Se tivermos muitos testes feitos de
palha, vamos gastar muito tempo colocando-os de volta em forma.
A maioria das novas equipes ágeis não começa com esse formato de pirâmide – geralmente ela é
invertida, um resquício de projetos anteriores. Ferramentas de teste de GUI geralmente são mais fáceis de usar
aprendem, então as equipes começam com muitos testes em sua camada “palha” superior. Como nós
mencionado no capítulo anterior, o “corcunda de dor” que a maioria dos programadores tem que superar
para dominar a automação de testes unitários significa que a equipe
O QUE PODEMOS AUTOMATIZAR ? 279
pode começar com apenas alguns tijolos. Os equipamentos que automatizam funções
Consulte a bibliografia para
testes na camada intermediária são fáceis de escrever se o sistema for projetado com aqueles
obter um link para a
discussão de Patrick testes em mente, para que os gravetos possam se acumular mais rápido que os tijolos. À medida que as
Wilson-Welsh sobre “inverter
equipes dominam o TDD e a automação de testes unitários, a camada inferior começa a crescer. Quando eles
a pirâmide de testes”
ganhar força, uma equipe que usa TDD construirá rapidamente a base de tijolos
a pirâmide de teste.
lado direito para cima.
A pirâmide de testes é um bom lugar para começar a ver como a automação de testes
pode ajudar uma equipe ágil. Os programadores tendem a se concentrar na base da pirâmide e precisam
de muito tempo e treinamento para superar o “corcunda”.
dor” e chegar ao ponto onde o TDD é natural e rápido. Em tradicional
equipes, os testadores geralmente não têm escolha a não ser automatizar os testes no nível da GUI.
A abordagem de equipe inteira usada por equipes ágeis significa que os testadores se unem
programadores e ajudá-los a melhorar a escrita de testes, o que, por sua vez, solidifica a camada de base
da pirâmide. Como os testes impulsionam o desenvolvimento, toda a equipe está sempre projetando para
máxima testabilidade, e o
pirâmide pode crescer até a forma correta.
Os programadores se unem aos testadores para automatizar testes de nível funcional, preenchendo
a camada intermediária. Por exemplo, um testador e um cliente podem preparar um arquivo de 400 linhas
planilha de casos de teste para uma aplicação de serviços web. O programador pode
ajude a descobrir uma maneira de automatizar esses testes. Diferentes membros da equipe podem
ter experiência em áreas como geração de dados de teste ou uso de ferramentas como macros Excel, e
todo esse conhecimento se espalha pela equipe. Trabalhando em conjunto, a equipe encontra as melhores
combinações de ferramentas, casos de teste e dados de teste.
Envolver os programadores na busca de maneiras econômicas de automatizar o

testes de GUI de nível superior têm vários benefícios. Esses esforços podem dar aos programadores uma
melhor compreensão do “quadro geral” do sistema e os testadores podem aprender
como criar testes de GUI mais flexíveis e menos parecidos com palha.
Quanto mais uma equipe puder trabalhar junta e compartilhar conhecimento, mais forte será o
equipe, o aplicativo e os testes se tornarão. O Lobo Mau não vai
ter uma chance. Vamos começar analisando que tipo de testes podemos automatizar
e então naquilo que nem deveríamos tentar.
O QUE PODEMOS AUTOMATIZAR ?

A maioria dos tipos de teste que você pode imaginar se beneficia da automação. Unidade manual
testes não ajudam muito na prevenção de falhas de regressão, porque a execução de um
conjunto de testes manuais antes de cada check-in simplesmente não é prático. Você também não pode
projetar o código primeiro, testando-o por meio de testes unitários manuais. Quando os programadores
não conseguem executar testes rapidamente com o toque de um botão, eles podem não estar motivados
o suficiente para executar testes. Poderíamos testar manualmente que diferentes unidades de código
funcionam juntos corretamente, mas os testes automatizados de componentes são uma rede de segurança
muito mais eficaz.
O teste exploratório manual é uma forma eficaz de encontrar defeitos funcionais, mas
se não tivermos testes de regressão automatizados suficientes voltados para os negócios, provavelmente
gastaremos todo o nosso tempo tentando loucamente acompanhar a regressão manual
testando. Vamos falar sobre todos os diferentes tipos de testes que podem ser feitos
bem com automação.
Para executar testes automatizados, você precisa de algum tipo de estrutura automatizada que
permite que os programadores verifiquem o código com frequência, executem testes nesse código e criem
arquivos implantáveis. Vamos considerar isso primeiro.
Integração, construção e implantação contínuas

Qualquer tarefa tediosa ou repetitiva envolvida no desenvolvimento de software é candidata
para automação. Já falamos sobre a importância de uma construção automatizada
“Testes voltados para
a tecnologia que apoiam a processo. Você não pode construir sua pirâmide de testes automatizados sem isso. Seu
equipe”. a equipe precisa do feedback imediato dos testes em nível de unidade para permanecer no caminho certo.
para obter exemplos de
Receber e-mails de compilação automatizados listando todas as alterações verificadas é uma grande ajuda
ferramentas de automação
de construção.
para testadores porque eles sabem quando uma compilação está pronta para teste sem precisar
incomodar os programadores.
Perigo: aguardando a construção de terça-feira
Num ambiente tradicional, é normal que os testadores esperem por uma compilação
estável, mesmo que isso signifique esperar até a próxima terça-feira. Em um ambiente ágil,
se os testadores não acompanharem os desenvolvedores, as histórias serão testadas no
final do jogo. Se os desenvolvedores não receberem feedback, como sugestões e bugs,
os testadores podem perder credibilidade junto aos desenvolvedores. Bugs não serão
descobertos até que os desenvolvedores já estejam em outra história e não queiram ser
interrompidos para corrigi-los até mais tarde.
Os bugs se acumulam e a automação sofre porque não pode ser concluída. A velocidade
é afetada porque uma história não pode ser marcada como “concluída” até ser testada.
Isso torna mais difícil planejar a próxima iteração. No final do ciclo de lançamento, o
teste da sua história chega ao final do jogo e você pode não ter um lançamento bem-
sucedido. No mínimo, você terá uma liberação estressante.
Um processo de implantação automatizado também acelera os testes e reduz erros.

Na verdade, no dia em que Janet estava editando este capítulo, ela estragou a implantação
porque era um processo manual. Era muito simples, mas ela era nova no
projeto e movi o arquivo para o lugar errado. Implementar um processo de implantação automatizado estava
na lista de coisas que Janet precisava fazer imediatamente.
A equipe de Lisa implementou sua integração contínua e estrutura de construção
primeira coisa, e achei bastante fácil e rápido de fazer, embora exija cuidados e alimentação contínuos. Outras
equipes, especialmente aquelas com equipes grandes e complexas
sistemas, enfrentam obstáculos muito maiores.
Conversamos com equipes que tiveram tempos de construção de duas horas ou mais. Esse
significava que um programador teria que esperar duas horas após o check-in
código para obter a validação de que seu check-in não quebrou nenhuma funcionalidade preexistente. É muito
tempo para esperar.
A maioria das equipes ágeis encontra uma construção contínua que dura mais de oito a dez minutos para
ser inviável. Mesmo 15 minutos é muito tempo para esperar por feedback, porque os check-ins começarão a
se acumular e os testadores esperarão muito tempo para obter
a melhor e mais recente construção. Você pode imaginar como os desenvolvedores trabalham com
uma construção que leva duas horas à medida que se aproxima do final de uma iteração ou
ciclo de lançamento? Se quebrarem alguma funcionalidade, terão que esperar mais dois
horas para saber se eles haviam consertado ou não.
Muitas vezes, compilações longas são o resultado de acessar o banco de dados ou tentar
teste através da interface. Milhares de testes executados em uma grande base de código podem sobrecarregar
os recursos da máquina que executa a compilação. Faça um perfil de seus testes e veja onde está o gargalo.
Por exemplo, se for o
acesso ao banco de dados que está causando a maioria dos problemas, tente simular o
banco de dados real e use um banco de dados na memória. Configure o processo de construção para distribuir
testes em diversas máquinas. Veja se um software diferente poderia
ajudar a gerenciar melhor os recursos. Traga especialistas de fora da sua equipe para ajudar
se necessário.
A chave para acelerar um processo contínuo de integração e construção é levar em conta

um pequeno passo de cada vez. Introduza as alterações uma de cada vez para que você possa
meça cada sucesso separadamente e saiba que você está no caminho certo. Para iniciar
com, você pode querer simplesmente remover os testes mais caros (em termos de tempo)
para ser executado todas as noites, em vez de em todas as construções.
Um processo rápido de integração e construção contínua proporciona o maior ROI

de qualquer esforço de automação. É a primeira coisa que toda equipe precisa automatizar.
Quando estiver implementado, a equipe terá uma maneira de obter feedback rápido dos testes
Veja a bibliografia
automatizados. A seguir, veremos os diferentes tipos de testes que devem ser automatizados.
para links para
automação de construção
ferramentas e livros
com mais
Testes unitários e de componentes
informações sobre
Não podemos enfatizar demais a importância de automatizar os testes unitários. Se seu
como melhorar o
programadores estão usando TDD como mecanismo para escrever seus testes, então eles
processo de construção.
não estão apenas criando um ótimo conjunto de regressões, mas também os estão usando para projetar
código robusto e de alta qualidade. Se sua equipe não estiver automatizando testes unitários, é
Capítulo 7,
as chances de sucesso a longo prazo são mínimas. Faça automação de testes em nível de unidade e
"Tecnologia-
integração contínua sua primeira prioridade.
Enfrentando testes que
Apoiar o
Equipe”, detalha
alguns Teste de API ou serviços da Web
das ferramentas que
pode ser usado.
Testar uma API ou aplicativo de serviços da web é mais fácil usando alguma forma de automação.
Janet esteve em equipes que usaram Ruby com sucesso para ler em um
planilha com todas as permutações e combinações de variáveis de entrada
e compare os resultados com os resultados esperados armazenados nas planilhas. Esses testes
baseados em dados são fáceis de escrever e manter.
Um cliente da Janet usou o recurso IRB (Interactive Ruby Shell) do Ruby para
testar os serviços da web para testes de aceitação. A equipe estava disposta a compartilhar
scripts com a equipe do cliente, mas os testadores de negócios preferiram assistir
veja o que aconteceria se as entradas fossem alteradas na hora. A execução de testes de forma
interativa e semiautomática permitiu isso.
Testando por trás da GUI
Testar por trás da GUI é mais fácil de automatizar do que testar a própria GUI. Porque os testes não
são afetados por alterações na camada de apresentação e trabalho
9, “Kit de

em códigos de lógica de negócios mais estáveis, eles são mais estáveis. Ferramentas para este tipo de
Testes que apoiam a testes normalmente permitem escrever testes em um formato declarativo, usando tabelas
equipe”, para ou planilhas. Os fixtures que fazem com que o código de produção opere no
exemplos de
testar entradas e retornar os resultados geralmente pode ser escrito rapidamente. Isto é um
ferramentas específicas.
área principal para escrever testes voltados para negócios, compreensíveis tanto para clientes quanto
para desenvolvedores que impulsionam o desenvolvimento.
Testando a GUI
Mesmo uma GUI fina com pouca ou nenhuma lógica de negócios precisa ser testada. O rápido
O ritmo de desenvolvimento ágil, entregando novas funcionalidades a cada iteração, exige alguns testes
de regressão automatizados no nível da GUI para a maioria dos projetos.
A seleção de ferramentas é fundamental para uma automação bem-sucedida da GUI. Os scripts automatizados
precisam ser flexíveis e fáceis de manter. Janet usou Ruby e Watir muito
com sucesso quando a estrutura foi desenvolvida usando boas práticas de codificação,
como se fosse um aplicativo de produção. Tempo foi investido no desenvolvimento do
bibliotecas para que não houvesse muito retrabalho ou duplicação no código, e
as mudanças necessárias poderiam ser feitas em um só lugar. Tornar o código fácil de manter aumentou o
ROI nesses testes.
Um ponto sobre testabilidade aqui: certifique-se de que os programadores nomeiem seus objetos ou
Consulte o Capítulo 9, “Kit
atribuam IDs a eles. Se eles dependem de identificadores gerados pelo sistema, então
de ferramentas para
Voltado para negócios toda vez que um novo objeto é adicionado à página, os IDs serão alterados, exigindo
Testes que apoiam a alterações nos testes.
equipe”, para exemplos
de estruturas de teste de
Mantenha os testes apenas na interface real. Verifique coisas como ter certeza de que
GUI.
os botões realmente funcionam e fazem o que deveriam. Não tente tentar testar
funcionalidade de negócios. Outros tipos de testes que podem ser facilmente automatizados são
verificadores de links. Não há necessidade de alguém passar manualmente por cada
link em cada página para garantir que eles acessem a página certa. Procure os frutos mais fáceis de
alcançar, automatize as coisas que são simples de automatizar primeiro e
você terá mais tempo para os desafios maiores.
Testes de carga
Alguns tipos de testes não podem ser realizados sem automação. Testes de carga manuais
geralmente não são viáveis ou precisos, embora todos nós já tenhamos tentado isso uma vez ou
“Criticando o produto
usando testes outro. O teste de desempenho requer ferramentas de monitoramento e uma forma de
voltados para a conduzir ações no sistema em teste. Você não pode gerar um ataque de grande volume para verificar se um
tecnologia”, para obter
site pode ser hackeado ou se pode lidar com uma carga grande
exemplos de ferramentas
sem alguma estrutura de ferramenta.
de automação de teste
de carga.
Comparações
Verificar visualmente a saída de um arquivo ASCII por um processo do sistema é muito mais fácil se
Leia mais sobre
você primeiro analisa o arquivo e o exibe em um formato legível. Um roteiro para
ferramentas de
gerenciamento de código- comparar os arquivos de saída para garantir que nenhuma alteração não intencional foi feita é uma
fonte e IDEs no Capítulo muito mais rápido e preciso do que tentar compará-los manualmente. Arquivo
7, “Testes voltados
existem muitas ferramentas de comparação, desde o diff gratuito até ferramentas proprietárias
para a tecnologia que
como WinDiff. Ferramentas de gerenciamento de código-fonte e IDEs têm seus próprios
dão suporte à
equipe”. ferramentas de comparação integradas. Esses são itens essenciais na caixa de ferramentas de todo testador.
Não se esqueça de criar scripts para comparar tabelas de banco de dados ao fazer testes em seu data
warehouse ou projetos de migração de dados.
Tarefas repetitivas
À medida que trabalhamos com nossos clientes para entender melhor o negócio e aprender
o que é valioso para eles, poderemos ver oportunidades para automatizar alguns dos
suas tarefas. A empresa de Lisa precisava enviar vários formulários com uma carta de apresentação para
todos os seus clientes. Os programadores podiam não apenas gerar os formulários, mas também
também poderia concatená-los com a carta de apresentação e agilizar bastante o
esforço de correspondência. O colega testador de Lisa, Mike Busse, escreveu uma macro de planilha para
fazer cálculos complexos para alocar fundos que os administradores do plano de aposentadoria vinham
fazendo manualmente. Muitas listas de verificação manuais podem ser substituídas
com um script automatizado. A automação não serve apenas para testes.
Criação ou configuração de dados
Outra área útil para automação é a criação ou configuração de dados. Se você configura seus dados
constantemente, automatize o processo. Muitas vezes precisamos repetir
algo várias vezes para poder recriar um bug. Se isso puder ser automatizado, você terá a garantia de
obter os mesmos resultados todas as vezes.
Muitos de nossos esquemas de teste, incluindo aqueles usados para conjuntos de regressão
A história de Lisa
automatizados, usam dados canônicos. Esses dados canônicos ou “semente” foram originalmente
retirados da produção. Algumas tabelas no banco de dados, como tabelas de pesquisa, não mudam,
portanto nunca precisam ser atualizadas com uma nova cópia. Outras tabelas, como aquelas que
contêm informações sobre planos de aposentadoria, funcionários e transações, precisam começar do
zero sempre que um conjunto de regressões for executado.
Nosso desenvolvedor de banco de dados escreveu um procedimento armazenado para atualizar cada
esquema de teste do esquema “semente”. Nós, testadores, podemos especificar as tabelas que queremos
atualizar em uma tabela especial chamada REFRESH_TABLE_LIST. Temos um destino ant para
cada esquema de teste para executar o procedimento armazenado que atualiza os dados. As
compilações automatizadas usam esse alvo, mas nós mesmos o usamos sempre que queremos limpar
nosso esquema de teste e começar de novo.
Muitos de nossos testes de regressão criam seus próprios dados sobre os dados “sementes”. Nossos
testes Watir criam todos os dados necessários e incluem lógica que os torna executáveis novamente,
independentemente dos dados presentes. Por exemplo, o script que testa um funcionário que solicita um
empréstimo do seu plano de aposentadoria primeiro cancela quaisquer empréstimos existentes para que
um novo possa ser contratado.
Os testes FitNesse que testam a camada de banco de dados também criam seus próprios dados.
Usamos um esquema especial onde removemos a maioria das restrições, portanto não precisamos
adicionar todas as colunas de todas as tabelas. Os testes adicionam apenas os dados pertinentes à
funcionalidade que está sendo testada. Cada teste destrói os dados que criou, de forma que os testes
subsequentes não sejam afetados e cada teste seja independente e reexecutável.
—Lisa
O QUE NÃO DEVEMOS AUTOMATIZAR ? 285
Limpar os dados de teste é tão importante quanto gerá-los. Sua criação de dados
O kit de ferramentas deve incluir maneiras de destruir os dados de teste para que não afetem um
teste diferente ou impedir a repetição do mesmo teste.
Examinamos as principais áreas onde a automação é necessária ou pelo menos útil.

Nossa opinião é que sempre que você precisar fazer um teste ou algum teste relacionado
atividade, primeiro decida se ela pode ser auxiliada pela automação. Em alguns casos,
a automação não será apropriada. Vejamos alguns deles.
O QUE NÃO DEVEMOS AUTOMATIZAR ?

Alguns testes precisam de olhos, ouvidos e inteligência humanos. Usabilidade e testes exploratórios
são dois que se enquadram nessa categoria. Outros testes que podem não justificar o investimento
em automação são os testes pontuais e que nunca falharão.
Testando usabilidade
O teste real de usabilidade exige que alguém realmente use o software. A automação pode ser útil na
Discutimos algumas
configuração de cenários para posterior análise da usabilidade. Observar os usuários em ação,
ferramentas de registro e
monitoramento no informando-os sobre suas experiências e
Capítulo 10, julgar os resultados é tarefa de quem entende que os aspectos de usabilidade do software não podem
“Recursos voltados para negócios”.
ser automatizados. Registrar ações do usuário é útil para
produto.” Testando usabilidade.
A história de Janete Avaliamos diversas ferramentas GUI, mas decidimos usar Ruby com Watir. Mantivemos
nossos testes limitados apenas às funções da GUI. Um de nossos testes foi verificar
se as mensagens de validação corretas estavam sendo exibidas na tela. Eu estava
executando os testes e por acaso estava olhando para a tela porque não tinha visto
esse teste específico criado por um dos outros testadores. Meus olhos captaram
algo estranho, mas o teste passou, então repeti novamente. Um dos programadores
adicionou um “$” à tela e a mensagem de erro foi exibida deslocada por causa disso.
A mensagem correta foi exibida, mas não no lugar certo. Neste caso, o valor em
observar a execução dos testes foi enorme porque estávamos nos preparando para
o lançamento em breve e provavelmente não teríamos detectado esse problema específico.
—Janet
É possível automatizar testes que garantem que a GUI nunca mude, mas você
precisa se perguntar se vale a pena o custo. Você realmente se importa com o fato de um botão ter
mudado de posição em um pixel? Os resultados justificam o esforço? Nós
não acho que você deva automatizar os testes de “aparência”, porque um sistema automatizado
O script só pode procurar o que você diz para ver. A automação perderia o visual
problemas que saltariam para um ser humano.
Teste Exploratório
Da mesma forma, os testes exploratórios podem ser acelerados com scripts para criar testes
dados e passar por algumas etapas de configuração, mas requer um testador qualificado para projetar
Testes que criticam o e executar os testes. Um dos principais objetivos dos testes exploratórios é aprender
produto”, para obter mais mais sobre o produto fazendo e, em seguida, use essas informações para melhorar
informações sobre testes
desenvolvimento futuro. Scripts automatizados não farão isso por você. No entanto, como
exploratórios e ferramentas
que podem facilitá-los. como dissemos antes, você não terá tempo para testes exploratórios sem muita
outros testes automatizados.
Testes que nunca falharão
Ouvimos um argumento de que testes que nunca falharão não precisam ser automatizados. Se um
requisito é tão óbvio que só existe uma maneira de implementá-lo
e nenhum programador jamais olhará para esse código mais tarde sem saber exatamente o que ele
deve fazer, as chances de alguém introduzir um defeito nele
código são quase nada. Digamos que temos um formulário com campos de endereço. Nós
precisa de um teste de regressão automatizado para verificar se a segunda linha de endereço
não é necessário? Depois de verificarmos isso manualmente, qual é a probabilidade de alguém
irá acidentalmente alterá-lo para um campo obrigatório mais tarde? Mesmo que alguém o fizesse, seria
não seria um evento catastrófico. Alguém notaria isso e as pessoas
poderia contornar isso facilmente até que fosse consertado.
Então, novamente, seria fácil incluir um teste. E truques de programador

como erros de copiar/colar acontecem o tempo todo. Se você se sentir confortável com isso
o teste manual único faz o trabalho e reduz o risco de falhas futuras
não justifica automatizar testes de regressão, não os automatize. Se sua decisão estiver errada, você
terá outra chance de automatizá-la
mais tarde. Se você não tem certeza e não é muito difícil automatizar, vá em frente.
Se você estiver testando um sistema crítico para a vida, mesmo um risco muito pequeno de regressão
o fracasso é demais. Use a análise de risco para ajudar a decidir quais testes devem ser
“Codificação e testes”,
automatizado.
para obter mais
informações sobre análise

de risco e como ela se
Testes únicos
relaciona com testes.
Na maioria das vezes, executar manualmente um teste único é suficiente. Se automatizar um teste
não tem recompensa, por que fazer isso? Às vezes vale a pena fazer a automação por um
teste único.
O QUE PODE SER DIFÍCIL DE AUTOMATIZAR? 287
Recentemente, fizemos uma história para exibir uma caixa de diálogo com uma mensagem de aviso ao postar
A história de Lisa
uma folha de pagamento, mas a mensagem só deve aparecer durante as duas primeiras semanas de janeiro.
Automatizar um teste para essa funcionalidade exigiria alguma forma de simular que a data atual estava
entre 1º e 15 de janeiro. Isso não é muito difícil de fazer, mas as consequências de uma falha eram bastante
triviais, e tínhamos mais histórias críticas para contar. entregar essa iteração. Automatizar esse teste naquela
época simplesmente não funcionou
tinham valor suficiente para justificar o custo e o fator de risco era baixo. Decidimos testá-lo manualmente.
Há outros casos em que fazer um teste único parece ser o mais intuitivo, mas a automação é uma escolha
melhor. Hospedamos sites para diferentes parceiros de negócios e cada um deles tem conteúdo, aparência e
comportamento exclusivos. Os valores no banco de dados orientam o comportamento e o conteúdo corretos
para cada marca. Alguns dos dados, como tabelas de taxas baseadas em valores de ativos e números
de participantes, são altamente complexos. É muito mais fácil e preciso verificar esses dados usando
testes FitNesse. Temos um conjunto de fixtures que nos permitem especificar chaves para a “marca” parceira
que queremos testar. Podemos facilmente inserir os resultados esperados apropriados nas planilhas que a
equipe de desenvolvimento de negócios cria para cada novo parceiro.
Esses testes não fazem parte do nosso conjunto de regressão. Eles são usados apenas uma vez para validar
a nova marca.
—Lisa
Pode valer a pena automatizar tarefas tediosas, mesmo que você não as faça com frequência.
Pese o custo da automação em relação à quantidade de tempo valioso consumido pelos
fazendo o teste manualmente. Se for fácil de fazer manualmente e automatizar não
seja rápido, apenas mantenha o manual.
O QUE PODE SER DIFÍCIL DE AUTOMATIZAR?

Quando o código não é escrito test-first, ou pelo menos com a automação de testes em mente,
é muito mais difícil automatizar. Os sistemas mais antigos tendem a cair nesta categoria,
mas sem dúvida há muitos códigos novos com as mesmas características não testáveis.
ainda sendo produzido.
Se você se deparar com o trabalho em um código existente que ainda não possui testes automatizados,
você terá uma batalha difícil, mas vencível. Código legado
pode ter E/S, acesso a banco de dados, bem como lógica de negócios e código de apresentação
entrelaçados. Pode não estar claro onde conectar o código para automatizar um
teste. Como você começa a automatizar testes em tal sistema? Você certamente
não posso planejar automatizar tudo abaixo da GUI, porque grande parte do
a lógica está na camada de apresentação.
Existem pelo menos algumas abordagens diferentes que funcionam bem. O

“corcunda de dor” sobre a qual falamos no Capítulo 13, “Por que queremos automatizar
Testes e o que nos impede”, é intimidante, mas pode ser superado e
então a automação de testes se tornará muito mais fácil. Trabalho de Michael Feathers
Effectively With Legacy Code [2004] explica como construir um equipamento de teste
em torno de bases de código existentes e refatorá-las para acomodar a automação.
Mesmo com código legado, você pode escrever testes para se proteger contra a introdução
novos problemas. Esta abordagem pode funcionar mesmo em sistemas que não possuem estrutura
ou não são orientados a objetos.
A equipe de Lisa decidiu adotar uma abordagem diferente, mas igualmente eficaz. O time
Capítulo 7,
os membros começaram a “estrangular” o código legado escrevendo todos os novos recursos em um
“Testes
voltados para a nova arquitetura amigável para testes. Eles estão substituindo gradualmente todo o código antigo
tecnologia que apoiam a equipe”,
com código escrito test-first. Quando eles trabalham em código antigo para corrigir bugs ou em
entra em mais
nos casos em que o código antigo precisa ser atualizado, eles simplesmente adicionam testes unitários para todos
detalhes sobre
do código que eles mudam. Um conjunto de testes de fumaça GUI cobre as funções críticas
diferentes
abordagens ágeis do restante do sistema legado que não possui testes unitários.
para código legado.
Como acontece com qualquer projeto de automação, aborde o código difícil de automatizar
peça de cada vez e aborde primeiro as áreas de maior risco. Resolva a testabilidade
problema e encontrar uma maneira de escrever testes em nível de unidade. O esforço valerá a pena.
DESENVOLVENDO UMA ESTRATÉGIA DE AUTOMAÇÃO – ONDE

VAMOS COMEÇAR ?
Uma abordagem simples e passo a passo parece incompatível com uma automação
estratégia, mas nos testes ágeis tentamos entender o problema primeiro. Decidindo
onde e como começar com a automação requer um pouco de reflexão e discussão. À medida que sua
equipe analisa os desafios de teste, você precisará considerar onde
automação é apropriada. Antes de começar a procurar uma ferramenta de automação específica, você
desejará identificar seus requisitos.
Você precisa entender qual problema está tentando resolver. O que você está
tentando automatizar? Por exemplo, se você não tiver nenhum tipo de automação de teste,
e você começa comprando uma ferramenta de teste comercial cara pensando que ela automatizará todos
os seus testes funcionais, você pode estar começando no lugar errado.
Sugerimos que você comece do início. Procure seu maior ganho. O maior
o melhor custo-benefício são definitivamente os testes de unidade que os programadores podem fazer. Em
vez de começar no topo da pirâmide de teste, você pode querer começar no
parte inferior, certificando-se de que o básico esteja no lugar. Você também precisa considerar
DESENVOLVENDO UMA ESTRATÉGIA DE AUTOMAÇÃO – POR ONDE COMEÇAMOS ? 289
os diferentes tipos de testes que você precisa automatizar e quando você precisará
tenha ferramentas prontas para usar.
Nesta seção, presumimos que você automatizou os testes unitários e de componentes do

Quadrante 1 e está procurando automatizar seus testes voltados para os negócios em
Quadrantes 2 e 3, ou seus testes voltados para a tecnologia do Quadrante 4 que criticam
o produto. Ajudaremos você a projetar uma boa estratégia para construir seus recursos de
automação.
Pense nas habilidades e experiência de sua equipe. Quem precisa da automação e por quê? Que
objetivos você está tentando alcançar? Entendendo alguns
esses problemas podem afetar sua escolha de ferramentas e o esforço que você despende.
Há uma seção sobre avaliação de ferramentas no final deste capítulo.
A automação é assustadora, especialmente se você está começando do zero, então onde podemos
começar?
Onde dói mais?

Para descobrir onde concentrar seus esforços de automação em seguida, pergunte à sua equipe,
“Qual é a maior área de dor?” ou, para algumas equipes, “Qual é o maior
área de tédio?” Você consegue implantar o código para testá-lo? Fazer
os membros da equipe se sentem confiantes em alterar o código ou não têm qualquer
rede de segurança de testes automatizados? Talvez os membros da sua equipe sejam mais
avançados, dominem o TDD e tenham um conjunto completo de testes unitários. Mas eles não
tem uma boa estrutura para especificar testes voltados para negócios ou não consegue
uma maneira de automatizá-los. Talvez você tenha alguns testes de GUI, mas
eles são extremamente lentos e custam muito para manter.
Perigo: tentar testar tudo manualmente

Se você gasta todo o seu tempo testando novamente recursos que já testou antes, sem
chegar a novos recursos e precisa adicionar mais e mais testes, você está sofrendo de
uma grave falta de automação de testes. Esse perigo significa que os testadores não têm
tempo para participar de discussões de design e implementação, bugs de regressão podem
passar despercebidos, os testes não conseguem mais acompanhar o desenvolvimento e os
testadores ficam presos em uma rotina. Os desenvolvedores não estão envolvidos nos testes
voltados para os negócios e os testadores não têm tempo para descobrir uma maneira melhor
de resolver os problemas de teste.
Sua equipe pode resolver isso desenvolvendo uma estratégia de automação, conforme
descrevemos neste capítulo. A equipe começa a projetar visando testabilidade e escolhe e
implementa ferramentas de automação apropriadas. Os testadores têm a oportunidade de
desenvolver suas habilidades técnicas.
Onde quer que dói mais, é aí que você deve iniciar seus esforços de automação.
Por exemplo, se sua equipe está lutando para entregar código implantável, você
precisa implementar um processo de construção automatizado. Nada é pior do que ficar mexendo os
Capítulo 18, “Codificação polegares enquanto espera o teste de algum código.
e Teste,”
tem mais informações
Mas, se o desempenho colocar a existência da sua organização em perigo, os testes de desempenho
sobre uma abordagem
simples para análise de devem ser a principal prioridade. É voltar a entender o que
risco. problema que você está tentando resolver. A análise de risco é sua amiga aqui.
Trabalhei em um sistema legado que tentava resolver alguns problemas de qualidade, bem como
adicionar novos recursos para nosso principal cliente. Não havia nenhuma unidade automatizada ou
testes funcionais para o aplicativo existente, mas precisávamos refatorar o código para resolver os
problemas de qualidade. Os membros da equipe decidiram abordar uma peça de cada vez. Ao
escolherem uma parte da funcionalidade para refatorar, os programadores escreveram testes de
unidade, garantiram que eles fossem aprovados e então reescreveram o código até que os
testes fossem aprovados novamente. No final da refatoração, eles tinham um código testável e bem
escrito e os testes que os acompanhavam. Os testadores escreveram os testes funcionais de nível
superior ao mesmo tempo. Em um ano, a maior parte do código legado de baixa qualidade foi
reescrito, e a equipe conseguiu uma boa cobertura de testes apenas abordando um pedaço de
cada vez.
—Janet
A automação de testes não valerá a pena a menos que outras boas práticas de desenvolvimento estejam em vigor
lugar. A integração contínua executando um conjunto robusto de testes unitários é o primeiro passo
para automatizar outros testes. O código que é continuamente refatorado para manutenção e bom design
ajudará a aumentar o ROI da automação. A refatoração não pode acontecer sem uma boa cobertura de
testes unitários. Esses desenvolvimentos
práticas também precisam ser aplicadas aos scripts de testes funcionais automatizados.
Abordagem Multicamadas
Embora recomendemos dominar uma ferramenta de cada vez, não espere muito
de qualquer ferramenta. Use a ferramenta certa para cada necessidade. A ferramenta que funciona melhor
para testes unitários pode ou não ser apropriado para automatizar testes funcionais.
Os testes de GUI, carga, desempenho e segurança podem exigir, cada um, um
ferramenta ou ferramentas.
O conceito de pirâmide de testes de Mike Cohn (veja a Figura 14-2) ajudou nossas equipes a colocar
seus esforços de automação onde eles fazem o melhor. Queremos maximizar
os testes que apresentam o melhor ROI. Se a arquitetura do sistema for projetada para capacidade de
teste, a automação de testes será menos dispendiosa, especialmente no nível da unidade.
Os testes que passam pela interface do usuário geralmente apresentam o ROI mais baixo, porque
sua manutenção é cara, mas precisamos deles. Eles compõem o pequeno
ponta da nossa pirâmide Podemos optar por automatizar alguns desses testes, mas o
a maioria dos testes de GUI são definidos em termos de negócios e provavelmente é melhor deixá-los
como testes de interação humana (ou seja, testes manuais).
A camada intermediária representa os testes funcionais que trabalham diretamente com o código de
produção, sem uma GUI ou outra camada intermediária. Embora não sejam tão baratos para
automatizar quanto os testes em nível de unidade e forneçam feedback um pouco mais lentamente,
as ferramentas certas permitem que eles tenham um bom ROI. O facto de estes testes poderem ser
escrito em uma linguagem que os especialistas em negócios entendem que agrega valor.
Existem muitas camadas diferentes no aplicativo que podem ser testadas de forma independente.
Em seu livro xUnit Test Patterns [2007], Gerard Meszaros refere-se a isso
como o padrão de teste de camada. Ele adverte que ao tentar testar todas as camadas
da aplicação separadamente, ainda temos que verificar se as camadas estão enganchadas
configurado corretamente e isso pode exigir pelo menos um teste da lógica de negócios
através da camada de apresentação.
A história de Lisa À medida que minha equipe construía nossa estrutura de automação passo a passo, reunimos um
arsenal de ferramentas. Depois de implementar uma estrutura de construção contínua com Ant e
CruiseControl, dominamos o JUnit para testes unitários. Sabíamos que a automação de testes
unitários é a maneira mais rápida e barata de automatizar e fornece o feedback mais rápido aos
programadores.
Nosso sistema legado não tinha testes automatizados, então construímos um conjunto de testes de
regressão GUI com Canoo WebTest. Isso proporcionou um bom retorno porque os scripts do
WebTest foram especificados, não programados. Eles foram rápidos de escrever e fáceis de manter.
Depois que o JUnit e o WebTest foram implementados, experimentamos o FitNesse e descobrimos

que ele funcionava bem para testes funcionais por trás da GUI. Descobrimos que a automação
com FitNesse é relativamente rápida. Embora os testes FitNesse sejam significativamente mais
caros para produzir e manter do que os testes unitários, seu valor em impulsionar o
desenvolvimento e promover a colaboração entre clientes, programadores e testadores manteve o
ROI alto.
Todas essas ferramentas foram fáceis de aprender, implementar e integrar ao processo de construção
e forneceram feedback contínuo sobre nossos problemas de regressão. Essas foram considerações
importantes quando decidimos sobre nossa estratégia de automação de testes.
—Lisa
Ao avaliar o retorno dos seus esforços de automação, considere aspectos menos tangíveis, como se
a ferramenta promoveu a colaboração entre os
equipes técnicas e de clientes. A principal razão para escrever testes é ajudar

orientar o desenvolvimento. Se o processo de escrever seus testes de aceitação automatizados
resulta em uma compreensão completa dos requisitos de negócios, isso é suficiente
de retorno, mesmo que os testes nunca encontrem um único bug de regressão posteriormente.
Pense em design e manutenção de testes

Pense em todos os scripts de teste manuais que você escreveu na vida. Não
você apenas gostaria que tudo isso tivesse sido automatizado? Sua vida não teria
foi muito mais fácil? Acreditamos que todos os testes com script devem ser automatizados. Vamos
comece a converter esses testes manuais com script.
Depois de começar, pode ser muito fácil automatizar os testes. Por exemplo, quando
Se você tiver um acessório FitNesse funcionando, adicionar mais casos de teste requer pouco esforço.
Isso é ótimo quando você tem muitas permutações diferentes para testar. Você vai
provavelmente testará mais condições do que você faria se todos os seus testes fossem feitos
manualmente. Quando os membros da equipe de Lisa reescreveram o sistema de empréstimos de seu plano
de aposentadoria, eles puderam testar centenas de possibilidades diferentes de processamento de
pagamentos de empréstimos por meio de testes FitNesse. O que acontece quando três pagamentos do empréstimo são
processado no mesmo dia? Se alguém não fizer nenhum pagamento por três
meses e depois envia um grande pagamento, os juros são calculados e aplicados corretamente? Foi
fácil escrever testes automatizados para descobrir.
Essa é uma grande vantagem, mas tem um lado negativo. Agora a equipe tem dezenas, ou
até centenas de casos de teste para manter. E se as regras sobre cálculo
o valor dos juros para o pagamento de um empréstimo mudará daqui a um ano? Esse
pode exigir a atualização de todos os testes. Se sua ferramenta de teste não acomodar facilmente
alterações em testes existentes, seu grande conjunto de testes automatizados pode
se transformar em uma dor de cabeça.
Os testes ponta a ponta são particularmente difíceis de automatizar porque têm a capacidade
maior potencial para precisar de manutenção à medida que as regras de negócios mudam. Como nós
equilibrar a necessidade de automação com o custo?
Projeto de teste
Lembre-se de começar com a fatia fina ou fio de aço do recurso que você está testando. Aborde a
Capítulo 8,
automação da mesma forma que os programadores abordam a codificação. Pegue um
Testes que apoiam a pequena unidade da rosca de aço funcionando e depois passar para a próxima. Depois
equipe”, explica mais você cobriu toda a fatia fina, volte e dê volume.
sobre fatias finas.
Escolha seu padrão de teste com atenção. Automatize todos os casos de teste que você
Consulte o Capítulo 9, “Kit
de ferramentas para
precisa, mas não mais, e automatize-os no nível mais baixo possível. Limite
Voltado para negócios o escopo de cada caso de teste para uma condição de teste ou uma regra de negócios. Entenda o
Testes que apoiam a objetivo do teste. Evite dependências entre testes, pois elas
equipe”, para obter
aumentar rapidamente a complexidade e as despesas de manutenção.
mais informações sobre
design de teste eficaz.
Considere opções
Como mencionamos antes, quanto mais baixo for o nível em que você automatiza um teste,
melhor será o ROI. Empurre a automação de testes o mais abaixo possível na pirâmide.
Se você tiver uma boa cobertura em seus testes de unidade e integração de código, você não
precisa automatizar tantos testes funcionais. Com cobertura sólida na parte inferior
níveis, pode ser suficiente fazer testes ponta a ponta manualmente para verificar o comportamento do
sistema. Use a análise de risco para ajudá-lo a decidir.
Interface de usuário
A interface do usuário precisa ser testada. Em algumas situações, a automação de testes
no nível da GUI é fundamental. Talvez sua equipe esteja usando controles GUI de terceiros e você não
tenha certeza de como eles se comportarão. Se sua análise de risco e ROI
suporta muita automação no nível da GUI, faça o investimento.
Se você automatizar nos níveis mais altos, não exagere e automatize todos os caminhos possíveis
através do sistema. Você não precisa manter todos os testes automatizados criados durante a fase de
desenvolvimento no conjunto de regressão;
considere as compensações do tempo de construção e a chance de encontrar defeitos. Concentre seu
esforços para cobrir todos os caminhos importantes através do código na unidade, código
integração e níveis funcionais. Você terá um retorno muito melhor.
Encontrar um equilíbrio
Encontrar um equilíbrio não é um princípio ágil, é apenas bom senso. Você precisa de um
solução boa o suficiente no momento, mas não precisa ser perfeita. Será que o
ferramenta fornece os resultados que você precisa agora? Fornece um retorno adequado sobre os
recursos necessários para usá-lo para automação? Se sim, vá em frente e use
isso e reserve um tempo mais tarde para procurar alternativas. Você pode melhorar sua estrutura de
automação ao longo do tempo. O fator mais importante é se suas ferramentas de automação se adequam
à sua situação específica no momento.
Não deslize para o outro lado e pense: “OK, podemos gerar vários scripts
com esta ferramenta de registro, faça nossos testes imediatos e refatore os scripts
mais tarde para torná-los sustentáveis.” Embora você não precise continuar procurando
a solução de automação perfeitamente ideal, você precisa de uma solução que não
aumente a dívida técnica da sua equipe. Encontre um equilíbrio entre “Ele encontra os bugs
precisamos saber e não custa muito para manter” e “Isso é
a solução mais elegante e legal que podemos encontrar.”
Escolhendo as ferramentas certas
É legal termos tantas ferramentas disponíveis para nos ajudar a resolver nossa automação
problemas. Não busque mais sofisticação do que você precisa. Colegas de trabalho de Lisa
descobriram que uma planilha que recupera dados do banco de dados e realiza cálculos
independentemente do sistema é uma ferramenta poderosa, tanto para
impulsionar o desenvolvimento e verificar os cálculos da aplicação.
Geralmente minimizamos a automação de testes na camada GUI, mas há situações em que

mais automação GUI é apropriada. Se o usuário fizer uma alteração
em X, o que mais muda? Alguns problemas só se manifestam na GUI
nível. Lisa testou uma correção de bug que resolveu um problema de back-end quando os
participantes do plano de aposentadoria solicitaram uma distribuição de dinheiro de suas contas.
A mudança foi cercada por testes unitários, mas foi uma regressão da GUI
teste que falhou quando o formulário de distribuição não apareceu mediante solicitação.
Ninguém previu que uma mudança de back-end poderia afetar a GUI, então eles
provavelmente não teria se preocupado em testá-lo manualmente. É por isso que você precisa
Testes de regressão GUI também.
Já falamos sobre algumas desvantagens das ferramentas de gravação/reprodução, mas elas são
apropriado na situação certa. Você pode estar usando uma ferramenta de gravação/reprodução
por um bom motivo: talvez seu código legado já tenha um conjunto de ferramentas automatizadas
testes criados nessa ferramenta, sua equipe tem muita experiência na ferramenta ou seu
a administração deseja que você o use por qualquer motivo. Você pode usar gravado
scripts como ponto de partida, depois divida os scripts em módulos, substitua os dados
codificados por parâmetros quando apropriado e monte os testes usando o
módulos como blocos de construção. Mesmo que você não tenha muita experiência em
programação, não é difícil identificar os blocos de script que devem estar em um módulo. O
login, por exemplo, é uma escolha óbvia.
A gravação/reprodução também pode ser apropriada para sistemas legados que são projetados
de tal forma que dificultam os testes unitários e os testes manuais.
do zero é muito caro. É possível construir uma capacidade de gravação e reprodução
no aplicativo, mesmo um aplicativo legado. Com o design certo e o
uso de algum formato legível para a interação gravada, é até
possível construir testes de reprodução antes que o código seja construído.
Automação de testes de GUI: da Idade das Trevas à

automação bem-sucedida em um ambiente ágil
Pierre Veragen, líder de SQA da iLevel by Weyerhaeuser, explica como sua equipe usou uma
ferramenta que fornecia recursos de gravação/reprodução e script de forma produtiva em um
ambiente em cascata e, em seguida, aproveitou-a quando a empresa adotou o desenvolvimento
ágil.
Na época do desenvolvimento em cascata, em 2000, começamos a fazer automação de

testes de GUI usando uma abordagem de reprodução de gravação. Rapidamente
acumulamos dezenas de milhares de linhas de scripts gravados que não atendiam às nossas
necessidades de teste. Quando assumi o cargo, 18 meses depois, rapidamente me convenci
de que a abordagem de reprodução de discos era para os dinossauros.
Quando tivemos a oportunidade de obter uma nova ferramenta de automação de testes no

final de 2003, avaliamos cuidadosamente as ferramentas com estes critérios em mente:
capacidade de registro para nos ajudar a entender a linguagem de script e a capacidade de
construir uma biblioteca orientada a objetos para cobrir a maioria das nossas necessidades,
incluindo relatórios de testes. Na época, o TestPartner da CompuWare atendeu a todos os
nossos requisitos.
Começamos a usar o TestPartner em um aplicativo CAD com engenharia altamente complexo,

construído em Visual Basic 6, ainda usando um processo em cascata. Antes de começarmos
a automatizar os testes, nossos lançamentos foram rapidamente seguidos por um ou mais
patches. Concentramos nossos esforços de automação na verificação dos cálculos de
engenharia por meio da GUI e, posteriormente, na posição real dos detalhes do CAD. Esses
testes incluíram centenas de milhares de pontos de verificação individuais, que nunca
poderiam ter sido feitos manualmente. Dentro de um ano, tendo adicionado um conjunto
sólido de testes manuais de interação do usuário, além de nossos testes automatizados,
estávamos lançando um software robusto sem os habituais patches de acompanhamento.
Ficamos confiantes em nossa combinação de testes manuais e automatizados, que não
incluíam uma única linha de scripts gravados.
Em 2004, nosso grupo mudou para Visual Basic .NET. Passei vários meses adaptando
nossa biblioteca TestPartner para ativar controles .NET. Em 2006, adotamos uma
metodologia Ágil. Com base nas lições aprendidas anteriormente no mundo não ágil,
alcançamos resultados surpreendentes com a automação de testes. No final de 2006, os
membros da equipe conseguiram produzir scripts de teste de GUI e componentes de biblioteca
de fácil manutenção após apenas alguns dias de treinamento. Ao mesmo tempo, a
equipe adotou testes unitários com NUnit e testes de aceitação de usuários com FitNesse.
No momento em que este livro foi escrito, os problemas eram detectados em todos os três
níveis de nossos testes automatizados: Unidade, FitNesse e GUI. Os problemas
encontrados em cada um dos três níveis de teste são de natureza diferente. Como tudo é
automatizado e acionado automaticamente, os problemas são detectados muito
rapidamente, no verdadeiro estilo Agile. Cada parte de nossa automação de testes agrega valor.
Algumas pessoas acham que os recursos seriam mais bem gastos em arquitetura e design,
de modo que a automação de testes de GUI não é necessária. Em nosso grupo de
desenvolvimento, cada equipe tomou sua própria decisão sobre automatizar os testes de
GUI.
Caso você decida usar a automação de testes de GUI, aqui vão alguns conselhos: Fique
longe de scripts gravados, invista em capacidade de manutenção e minimize os testes de
GUI necessários com uma boa arquitetura do aplicativo. Pela minha experiência, investir em
boas práticas de automação de testes de GUI sempre valerá a pena.
O conselho de Pierre reflete bem como as boas práticas de desenvolvimento, especialmente

aquelas seguidas em projetos de desenvolvimento ágil, se aplicam ao desenvolvimento de
testes automatizados, bem como ao desenvolvimento de código de produção.
Gravação e reprodução integradas

xUnidade
Gerard Meszaros, treinador ágil e autor de [2007], descreve Teste Padrões
uma situação em que a abordagem
mais simples acabou sendo registrar/
reprodução. Mencionamos desvantagens das ferramentas de gravação/reprodução, mas se você
projetar seu código para suportá-las, elas podem ser a melhor abordagem.
Pediram-me para ajudar uma equipe que estava portando um aplicativo “sensível à
segurança” do OS2 para o Windows. A empresa estava muito preocupada com o tempo que
levaria para testar novamente o sistema portado e com a probabilidade de a equipe perder
bugs importantes. O sistema foi projetado para oferecer ao usuário apenas escolhas
válidas que não comprometam a segurança. Eles consideraram usar uma ferramenta de
gravação de testes para gravar testes no sistema antigo e reproduzi-los no novo sistema, mas
não havia ferramentas de gravação de testes disponíveis para OS2 e Windows que
pudessem lidar com janelas desenhadas usando caracteres ASCII. Depois de revisar a
arquitetura do sistema, determinamos que escrever testes xUnit não seria uma maneira
econômica de testar o sistema porque grande parte da lógica de negócios estava incorporada
na lógica da interface do usuário, e refatorar o código para separá-los seria ser muito
arriscado e demorado. Em vez disso, propusemos construir um recurso de teste de
gravação e reprodução diretamente no sistema antes de portá-lo.
Embora o resto do projeto tenha sido orientado por marcos, desenvolvemos o mecanismo de
teste integrado de uma forma muito ágil. Cada tela exigia pelo menos um novo gancho e às
vezes vários. Começamos com as telas mais utilizadas, adicionando os ganchos
necessários para registrar as
ações e as respostas do sistema a elas em um arquivo XML. Também adicionamos
ganchos para reproduzir o XML e determinar os resultados do teste.
Inicialmente, concentramos nossos esforços em comprovar o conceito, fisgando apenas
as telas que precisávamos gravar e depois reproduzir um teste simples, mas realista.
Depois que todos estavam convencidos de que a abordagem funcionaria, priorizamos as
telas em relação ao benefício que ela traria. Implementamos os ganchos um por um até
que pudéssemos automatizar uma parte significativa dos testes. Também construímos
uma folha de estilo XSLT que formataria o XML de maneira semelhante ao Fit, com
células verdes indicando resultados aceitáveis e células vermelhas indicando uma
etapa de teste com falha.
Enquanto isso, o cliente identificava os cenários de teste que precisavam de

casos de teste. À medida que terminávamos telas suficientes para gravar um teste
específico, o cliente faria um “teste de aceitação” de nossos ganchos gravando e
reproduzindo (ainda no OS2) o(s) teste(s) que estavam aguardando por esses ganchos.
Quando todos os ganchos estivessem no lugar, poderíamos prosseguir e portar o
código, incluindo os ganchos de teste, do OS2 para o Windows. Depois de verificar a
reprodução bem-sucedida no OS2, o cliente moveria os arquivos de teste XML
para o Windows e execute-os na versão portada do código.
O cliente achou isso muito fácil de fazer e conseguiu gravar um grande número de
testes em um período de tempo relativamente curto. Como os testes registravam
ações e respostas em termos comerciais, os testes foram bastante fáceis de entender.
O cliente adorou o recurso e ainda elogia quanto esforço economizou e quanto mais
confiança tem no produto. “Isso não apenas economizou dezenas de anos de esforço de
testes, mas também descobriu bugs ocultos e desconhecidos no sistema legado, que
considerávamos o padrão ouro.”
Na história de Gerard, a equipe trabalhou em conjunto para adaptar a testabilidade a um

sistema que não foi projetado para testabilidade. Eles deram aos seus clientes uma maneira
de capturar seus cenários de teste em uma plataforma e reproduzi-los em ambas as
plataformas para verificar a portabilidade bem-sucedida. Este é um excelente exemplo da
abordagem de toda a equipe. Quando todos na equipe colaboram em uma solução de
automação de testes, há uma chance muito maior de sucesso.
Algumas equipes ágeis obtêm valor de ferramentas de teste comerciais ou de código aberto, enquanto
Veja mais
outros preferem uma abordagem totalmente personalizada. Muitos testadores acham que vale a pena
exemplos de
ferramentas para testes escrever scripts simples em uma linguagem de script como Ruby, ou um shell, para automatizar
voltados para tarefas rotineiras, mas necessárias, gerar dados de teste ou conduzir outras ferramentas. Livros
negócios no Capítulo 9, como Everyday Scripting with Ruby for Teams, Testers, and You fornecem um roteiro para essa
“Kit de ferramentas
abordagem. Se você é um testador sem uma sólida experiência em programação, recomendamos
para testes voltados
para negócios
que você compre um livro, encontre um tutorial on-line ou faça um
que dão suporte à equipe”. aula sobre uma linguagem de script e veja como pode ser fácil escrever scripts úteis.
O que estamos tentando dizer é que você pode usar muitas ferramentas diferentes. Olhe para
o problema que você está tentando resolver e decidir em equipe o mais fácil e mais fácil
maneira eficaz de resolvê-lo. De vez em quando, dê um passo atrás e dê uma olhada nas ferramentas
você está usando. Todos na equipe estão felizes com eles? Você está perdendo problemas porque
não tem as ferramentas certas? Reserve tempo para explorar novas ferramentas
e veja se eles podem preencher lacunas ou substituir uma ferramenta que não está valendo a pena.
Se sua equipe é novata no desenvolvimento ágil ou está trabalhando em um projeto totalmente novo,
você pode se deparar com a escolha de ferramentas e a configuração de ambientes de teste
durante as primeiras iterações, quando você também pode estar trabalhando em histórias de alto
risco. Não espere conseguir agregar muito valor ao negócio se ainda estiver criando sua
infraestrutura de teste. Planeje com bastante tempo a avaliação de ferramentas, configuração
desenvolver processos de construção e experimentar diferentes abordagens de teste.
APLICANDO PRINCÍPIOS ÁGEIS À AUTOMAÇÃO DE TESTE
Cada equipe, cada projeto e cada organização tem uma situação única com
desafios únicos de automação. Cada um tem sua própria cultura, história, recursos,
pressões de negócios, produtos e experiência. Não importa qual seja a sua equipe
situação, você pode usar os princípios e valores ágeis discutidos no Capítulo 2
para ajudá-lo a encontrar soluções. Conceitos como coragem, feedback, simplicidade,
comunicação, melhoria contínua e resposta às mudanças não são
apenas ideias ágeis – são qualidades comuns a todas as equipes de sucesso.
Mantenha simples
A máxima ágil de “faça a coisa mais simples que possa funcionar” aplica-se a
testes, bem como código. Mantenha o design do teste simples, mantenha o escopo mínimo e
use a ferramenta mais simples que fará o trabalho.
A simplicidade é um valor ágil fundamental por um bom motivo. O melhor lugar para começar é o
abordagem mais simples que você pode imaginar. No entanto, fazer a coisa mais simples não
significa fazer a coisa mais fácil. Envolve realmente pensar sobre o que você precisa
agora e dando passos de bebê para chegar lá. Mantendo as coisas simples, se você fizer isso
fizer uma escolha errada, você não se desviará muito do caminho antes de perceber o erro de
seus caminhos.
É fácil se envolver em uma tarefa e fugir do básico para algum desafio intrigante. Avalie o ROI de
cada tarefa de automação antes de executá-la.
A automação é divertida (quando você supera a parte assustadora de começar). Isso é
tentador tentar algo difícil só porque você pode. Como todos os outros aspectos dos testes em um
projeto de desenvolvimento ágil, a única maneira de acompanhar é
faça apenas o mínimo necessário.
Use a ferramenta mais simples que você puder usar. Lembre-se da pirâmide de teste. Se um
o teste voltado para o cliente pode ser mais facilmente automatizado no nível da unidade, faça-o
APLICANDO PRINCÍPIOS ÁGEIS À AUTOMAÇÃO DE TESTE 299
lá. Lisa às vezes escreve casos de teste no FitNesse, apenas para descobrir que os
programadores podem automatizá-los muito mais rápido como testes JUnit. Por outro lado, às vezes
os programadores usam FitNesse para TDD em vez de JUnit, porque o código
eles estão escrevendo pode ser testado em um dos formatos de fixação FitNesse.
Feedback Iterativo
Iterações curtas nos permitem experimentar várias abordagens de automação,
avaliar os resultados e mudar de rumo tão rapidamente quanto necessário. Comprometa-se
com um esforço de automação, como desenvolver uma estrutura de teste internamente ou
implementar uma ferramenta de código aberto por pelo menos algumas iterações. Após cada iteração,
veja o que está funcionando e o que não está funcionando. Pense em ideias para superar
problemas e tente-os na próxima iteração. Se não for a solução certa, tente
outra coisa por algumas iterações. Não seja sugado por um atoleiro onde
você colocou tantos recursos em uma ferramenta e tem tantos testes que a utilizam,
que você sente que não pode trocar de ferramenta. Entre as muitas ferramentas comerciais e de código
aberto, além da capacidade dos programadores de escrever ferramentas de teste desenvolvidas internamente,
não há razão para se contentar com menos do que a ferramenta ideal.
Uma das minhas primeiras equipes XP lutou para encontrar uma boa maneira de automatizar testes
A história de Lisa
de aceitação voltados para o cliente para um aplicativo Web baseado em Java. Isso aconteceu quando
havia muito menos opções de ferramentas para equipes ágeis. Primeiro, tentamos uma ferramenta de
código aberto que simulava um navegador, mas faltavam os recursos que precisávamos. Simplesmente não foi
bastante robusto o suficiente. Discutimos isso na próxima retrospectiva.
Decidimos tentar usar a ferramenta de teste de unidade para testar a GUI nas próximas duas iterações.
Ao nos comprometermos com duas iterações, sentimos que estávamos nos dando tempo suficiente
para testar a ferramenta, mas não tanto tempo que teríamos investido muito se não fosse a solução
certa. Os clientes acharam os testes de unidade difíceis de ler e havia lógica na GUI que não
pudemos testar com esta ferramenta.
Após outra discussão durante nossa retrospectiva, nos comprometemos com duas iterações de uso de
uma ferramenta de teste de GUI de fornecedor que eu havia usado extensivamente em projetos anteriores.
Os programadores Java acharam o processo lento porque a ferramenta usava uma linguagem de script
proprietária, mas funcionava bem o suficiente para realizar a automação mínima necessária. Depois
de duas iterações, decidimos que não era o ideal, mas na época não havia muitas outras opções e
era a melhor que tínhamos.
Em retrospectiva, deveríamos ter continuado procurando uma opção melhor. Talvez pudéssemos ter
desenvolvido nosso próprio equipamento de teste. Conseguimos automatizar cerca de 60% dos testes de
regressão acima do nível da unidade usando a ferramenta do fornecedor, o que parecia ótimo na
época. Se tivéssemos nos esforçado um pouco mais, poderíamos ter feito muito melhor.
—Lisa
Use iterações a seu favor. Eles facilitam uma abordagem passo a passo. Se seu
a ideia for um fracasso, você saberá rapidamente e terá a chance de tentar uma diferente.
Não tenha medo de continuar procurando, mas não continue procurando a solução perfeita se
uma que você tentar tiver um desempenho adequado.
Abordagem de toda a equipe
O desenvolvimento ágil não funciona sem automação. Felizmente, a abordagem de equipe inteira,
que exploramos no Capítulo 1, significa que uma gama mais ampla de
habilidades e recursos estão disponíveis para encontrar e implementar uma automação útil
estratégia. Atacar o problema em equipe significa que é mais provável que o código
ser projetado para testabilidade. Programadores, testadores e outros membros da equipe
colaborará para automatizar testes, trazendo vários pontos de vista e conjuntos de habilidades
ao esforço.
A abordagem de toda a equipe ajuda a superar a barreira do medo. Tarefas de automação

pode ser opressor para começar. Saber que existem outras pessoas com habilidades e
experiências diferentes para ajudar nos dá coragem. Ser capaz de pedir e
receber ajuda nos dá confiança de que podemos alcançar uma cobertura adequada com
nossos testes automatizados.
Minha equipe atual se comprometeu a automatizar testes de regressão em todos os níveis onde isso
A história de Lisa
fizesse sentido. Aqui estão alguns exemplos de onde pedi ajuda para ter sucesso com a automação.
No início, quando não tínhamos nenhum teste automatizado e os desenvolvedores estavam tentando
dominar o desenvolvimento orientado a testes, optamos pelo Canoo WebTest para os testes de
fumaça da GUI. Eu precisava de um pouco de ajuda para entender como configurar o WebTest para ser
executado em nosso ambiente e precisava de muita ajuda para executar os testes do processo de
construção automatizado. Pedi ajuda ao nosso administrador de sistema (que também era um dos
programadores). Rapidamente obtivemos um conjunto de testes em execução na compilação.
Mais tarde, eu realmente queria experimentar o FitNesse para testes funcionais por trás da GUI. Tive que
ser paciente enquanto os programadores ainda estavam ganhando força com os testes unitários
automatizados. A equipe concordou em experimentar a ferramenta, mas foi difícil encontrar tempo para
começar a usá-la. Escolhi uma história que parecia adequada aos testes FitNesse e perguntei ao
programador que estava trabalhando na história se eu poderia fazer parceria com ele para tentar alguns testes FitNesse
Ele concordou e automatizamos alguns testes no FitNesse. O programador achou fácil e valeu a pena e
deu um bom relatório ao resto da equipe.
Depois disso, não foi difícil abordar cada programador, sugerir a criação de testes FitNesse para a história
em que ele estava trabalhando e deixá-lo ver os resultados. Os testes do FitNesse encontraram casos
de teste nos quais o programador não havia pensado e perceberam o benefício imediatamente. Quando
todos na equipe tiveram alguma experiência com a ferramenta, eles não apenas ficaram felizes em
automatizar os testes, mas também começaram a projetar o código de uma forma que tornasse mais fácil
escrever acessórios FitNesse.
Quando nosso especialista em Ruby, que projetou a maior parte de nosso conjunto de testes
Watir, deixou a empresa, fiquei bastante preocupado em manter nosso enorme conjunto de
testes, bem como em ser capaz de codificar novos. Meu conhecimento em Ruby não era tão
bom quanto o dele (além disso, tínhamos apenas um testador, então o tempo era um
problema). Cada programador da equipe saiu, comprou um livro sobre Ruby e ajudou quando
tive problemas para atualizar scripts para funcionarem quando o código mudava. Um programador
até escreveu um novo roteiro para testar uma nova história quando eu não tinha tempo para
essa tarefa. Quando contratamos um novo testador, ele e eu conseguimos cuidar e alimentar os
scripts Watir, de modo que os programadores não precisassem mais assumir essas tarefas.
Eu sei que posso pedir ajuda aos colegas de equipe com problemas de automação, e toda a
equipe vê a automação como uma prioridade, por isso os programadores sempre pensam na
testabilidade ao projetar o código. Este é um exemplo da abordagem de toda a equipe no trabalho.
—Lisa
Testes especializados voltados para a tecnologia, como testes de segurança ou de carga, podem
O Capítulo
exigir a contratação de especialistas de fora da equipe. Algumas empresas possuem equipes
11, “Criticando
o produto especializadas que estão disponíveis como recursos compartilhados para equipes de produto. Até
usando testes ao mesmo tempo que aproveitam esses recursos, as equipes ágeis ainda devem assumir a
voltados para a responsabilidade de garantir que todos os tipos de testes sejam realizados. Eles também podem ser
tecnologia”, fala
surpreso ao descobrir que os membros da equipe podem ter as habilidades necessárias se tomarem uma decisão
sobre testes voltados
para a tecnologia abordagem criativa.
como esses e
diferentes abordagens para Algumas
lidar com organizações
eles. têm equipes de testes independentes que fazem testes de pós-desenvolvimento
testando. Eles podem estar testando para garantir que o software se integre a outros sistemas ou
conduzindo outros testes especializados, como testes de desempenho em larga escala.
testando. As equipes de desenvolvimento devem trabalhar em estreita colaboração com essas outras
equipes, usando o feedback de todos os esforços de teste para melhorar o design do código e facilitar
automação.
Reservando um tempo para fazer certo
Resolver problemas e implementar boas soluções leva tempo. Devemos ajudar

nossa administração entende que sem tempo suficiente para fazer as coisas da maneira certa
Dessa forma, nossa dívida técnica aumentará e nossa velocidade diminuirá. Implementando
soluções da maneira “certa” levam tempo no início, mas economizarão tempo no longo prazo
prazo. Considere o tempo que leva para debater ideias, soluções,
treinamento e para aprendizado no trabalho.
A administração da sua organização está compreensivelmente interessada em produzir

resultados o mais rápido possível. Se a gerência estiver relutante em dar tempo à equipe
para implementar a automação, explique claramente as compensações. Entregar alguns recursos no
curto prazo sem testes de regressão automatizados para garantir que eles
continuar trabalhando terá um grande custo no futuro. À medida que sua equipe acumula
dívida técnica, você terá menos capacidade de entregar o gerenciamento de valor de negócios
precisa. Trabalhe para chegar a um acordo. Por exemplo, corte o escopo de um recurso
mas mantenha o valor essencial e use a automação para entregar e manter um
produto melhor.
Sempre temos prazos e sempre nos sentimos pressionados pelo tempo. A tentação de
simplesmente voltar a fazer as coisas como sempre fizemos, como executar testes de
regressão manualmente e esperar pelo melhor, está sempre presente, embora
sabemos que isso não funciona. Nunca há tempo suficiente para voltar e consertar
coisas. Durante sua próxima reunião de planejamento, reserve um tempo para fazer
progresso em seus esforços de automação.
Nossa equipe se concentra em reservar tempo para um bom design, um forte conjunto de testes
A história de Lisa
automatizados e tempo suficiente para testes exploratórios. Qualidade, e não velocidade, sempre
foi nosso objetivo. Nossos problemas de produção custam muito para serem resolvidos, então
toda a empresa está disposta a dedicar algum tempo para evitá-los. Às vezes não escolhemos o
design certo e não temos medo de arrancá-lo e substituí-lo quando percebemos.
Naturalmente, existem compensações comerciais e a empresa decide se deve prosseguir com os

riscos conhecidos. Trabalhamos para explicar todos os riscos com clareza e dar exemplos de
cenários potenciais.
Aqui estão alguns exemplos recentes de como reservar um tempo para fazer as coisas certas.
Iniciamos um tema para fazer grandes alterações nos extratos de contas dos planos de
aposentadoria. Um dos programadores, Vince Palumbo, assumiu a tarefa de coletar dados adicionais
a serem utilizados nos depoimentos. Ele decidiu escrever testes unitários robustos para a
funcionalidade de coleta de dados, mesmo que isso significasse que a história teria que continuar na
próxima iteração. Escrever os testes unitários exigia muito tempo e esforço e, mesmo com os testes,
o código era extremamente complexo e difícil de fazer. Algumas iterações depois, outra programadora,
Nanda Lankala-palli, pegou outra história relacionada à coleta de dados e ficou agradavelmente
surpresa ao encontrar novos testes unitários. Ele foi capaz de fazer alterações rapidamente e o
esforço de teste foi bastante reduzido porque os testes de unidade estavam em vigor.
Mais tarde, descobrimos que havíamos perdido um caso extremo em que alguns cálculos para
a alteração no valor da conta estavam incorretos. A combinação de testes unitários automatizados e
muitos testes exploratórios não foram suficientes para capturar todos os cenários. Ainda assim, ter
os testes significava que Vince poderia escrever seu código corrigido primeiro e se sentir mais
confiante de que o código agora estava correto.
Outro exemplo recente dizia respeito ao processamento de cheques recebidos. A empresa queria
reduzir o processo de duas etapas para uma etapa, o que significava que o dinheiro seria investido
nas contas do plano de aposentadoria dois dias antes do que seria possível. O processo existente
foi todo escrito em código legado, sem testes unitários.
Discutimos se deveríamos reescrever o processamento na nova arquitetura. Nosso proprietário
do produto estava preocupado com o tempo que isso poderia levar. Nós sentimos
levaria tanto tempo para alterar o código existente quanto para reescrevê-lo
completamente, porque o código antigo era difícil de entender e não tinha nenhum teste
de unidade. Decidimos reescrever, o que não apenas reduziu o risco de problemas
nesta funcionalidade crítica, mas também nos deu a oportunidade de fornecer alguns
recursos extras com um pequeno custo extra. Até agora, esta estratégia provou valer a pena.
—Lisa
Permita-se ter sucesso. Trabalhe em um ritmo sustentável. Aproveite o tempo para refatorar conforme
você avança ou você acabará em uma bagunça. Como testadores, sempre
tem muitas tarefas diferentes para fazer. Se você estiver aprendendo uma nova ferramenta ou tentando
automatizar novos testes, não faça multitarefas. Encontre um grande bloco de tempo e foco. Isso é
difícil, mas mudar de marcha constantemente é mais difícil.
Se as partes interessadas da empresa estiverem impacientes para que sua equipe “simplesmente faça
isso”, analise o problema com elas. Quais são os riscos? Quanto custará uma produção
custo do problema? Quais são os benefícios de lançar um hack rápido? Quanto
dívida técnica isso adicionará? Qual é o retorno do investimento a longo prazo de um
design sólido suportado por testes automatizados? Como cada abordagem afetará
rentabilidade da empresa e satisfação do cliente? E o intangível
custos, como o efeito que a realização de um trabalho de baixa qualidade tem sobre o moral da equipe?
Às vezes o negócio vai dar certo, mas apostamos que você normalmente encontrará
esse investimento inicial compensa.
Aprender fazendo
Todo mundo aprende de maneiras diferentes, mas quando você decide como vai
para automatizar um teste, entre e comece a fazê-lo. Em scripts diários com Ruby
for Teams, Testers, and You [2007], Brian Marick aconselha aprender a programar
escrevendo um programa. Cometer erros! Quanto mais problemas você tiver, mais
mais você aprenderá. Conseguir que alguém se junte a você ajudará a acelerar o aprendizado, mesmo
que nenhum de vocês esteja familiarizado com a ferramenta ou o idioma.
Se você não tem ninguém com quem fazer dupla, fale com o “patinho de borracha”: Imagine
você está descrevendo o problema para um colega de trabalho. O processo de explicação pode
muitas vezes fazem com que a causa do problema apareça. Simplesmente lendo um teste
em voz alta para si mesmo pode ajudá-lo a encontrar seus pontos fracos.
Aplicar práticas de codificação ágil a testes

Os testes são tão valiosos quanto o código de produção. Na verdade, o código de produção não é
muito sem testes para apoiá-lo. Trate seus testes da mesma forma que você trata todos
código. Mantenha-o na mesma ferramenta de controle de código-fonte do seu código de produção.
Você sempre deve ser capaz de identificar as versões dos scripts de teste que acompanham um
versão específica do código.
Emparelhamento, refatoração, design simples, design modular e orientado a objetos, bom

padrões, mantendo os testes tão independentes quanto possível - todas as qualidades de um bom
código também são qualidades de bons testes automatizados. O desenvolvimento ágil às vezes é
percebido pelos desinformados como caótico ou negligente, quando na verdade é altamente
disciplinado. Realize suas tarefas de automação com a maior disciplina, procedendo em pequenos
passos, verificando cada passo que dá certo. Se você estiver programando scripts automatizados,
escreva-os primeiro para teste, como qualquer programador ágil
escreveria código de produção. Tenha a simplicidade em mente, no entanto. Não escreva
scripts de teste sofisticados com muita lógica, a menos que haja um bom ROI. Esses testes precisam
testes e custam mais para manter. Especifique testes quando puder, em vez de codificar
e sempre opte pela abordagem mais simples possível.
Não podemos enfatizar o suficiente: a automação de testes é um esforço de equipe. A variação

a experiência, as habilidades e as perspectivas de diferentes membros da equipe podem trabalhar em
conjunto para encontrar a melhor abordagem para a automação. Inovar – seja criativo. Faça o que
funciona para sua situação específica, não importa qual seja o “comum”.
sabedoria”, diz.
As ferramentas de automação são apenas uma peça do quebra-cabeça. Ambientes de teste e teste
os dados são componentes essenciais. Vejamos os dados de teste a seguir.
FORNECIMENTO DE DADOS PARA TESTES
Não importa qual ferramenta usamos para automatizar os testes, os testes precisam de dados para serem processados.
Idealmente, eles precisam de dados realistas que correspondam aos dados de produção. No entanto, os
bancos de dados de produção geralmente contêm muitos e muitos dados e podem ser
altamente complexo. Além disso, o acesso ao banco de dados retarda exponencialmente os testes. Igual a
grande parte dos testes ágeis é um ato de equilíbrio.
Ferramentas de geração de dados
Enquanto escrevemos este livro, existem diversas ferramentas interessantes disponíveis para gerar testes
dados para todos os tipos de campos de entrada e condições de contorno. Código aberto e
ferramentas comerciais como Data Generator, databene benerator, testgen,
Datatect e Turbo Data estão disponíveis para gerar arquivos simples ou gerar dados
diretamente para tabelas de banco de dados. Essas ferramentas podem gerar enormes variedades de
diferentes tipos de dados, como nomes e endereços.
FORNECIMENTO DE DADOS PARA TESTES 305
Também é bastante fácil gerar dados de teste com um script caseiro, usando um
linguagem de script como Ruby ou Python, uma ferramenta como Fit ou FitNesse, ou um
script de shell.
Nossos scripts Watir criam entradas de dados de teste aleatórias, tanto para garantir que sejam
A história de Lisa
reexecutáveis (é improvável que criem um funcionário com o mesmo SSN duas vezes) quanto para
fornecer uma variedade de dados e cenários. O script que cria novos planos de aposentadoria produz
planos com cerca de 200 combinações diferentes de opções. O script que testa a contratação de um
empréstimo gera aleatoriamente a frequência, o motivo e o prazo do empréstimo e verifica se o pagamento
esperado está correto.
Temos scripts utilitários para criar arquivos separados por vírgula para testar uploads.
Por exemplo, existem vários locais no sistema que carregam arquivos de censo com informações de novos
funcionários. Se eu precisar de um arquivo de teste com 1.000 novos funcionários com alocações aleatórias
de investimentos para um plano de aposentadoria, posso simplesmente executar o script e especificar o
número de funcionários, os fundos mútuos em que estão investindo e o nome do arquivo. Cada registro
terá um Número de Seguro Social gerado aleatoriamente, nome, endereço, beneficiários, valores de
diferimento de salário e alocações de fundos de investimento. Aqui está um trecho do código para gerar
os cálculos de investimento.
# 33% das vezes maximiza o número de fundos escolhidos, 33% das vezes
# selecione um único fundo e 33% das vezes selecione entre 2 a 4 fundos
fund_hash = caso rand(3)
quando 0: a.get_random_allocations(@fund_list.clone)
quando 1: a.get_random_allocations(@fund_list.clone, 1)
quando 2: a.min_percent = 8;
a.get_random_allocations(@fund_list.clone, rand(3) + 2)
fim
emp['fund_allocations'] = fund_hash_to_string(fund_hash)
Scripts como esses têm usos duplos, tanto como testes de regressão que cobrem vários cenários diferentes
quanto como ferramentas de teste exploratório que criam dados de teste e constroem cenários de teste.
Eles não são difíceis de aprender a escrever (veja a seção “Aprender fazendo“
anteriormente neste capítulo).
—Lisa
Scripts e ferramentas para gerar dados de teste não precisam ser complexos. Por exemplo,
PerlClip simplesmente gera texto na área de transferência do Windows para que possa ser colado
onde for necessário. Vale a pena tentar qualquer solução que elimine o tédio suficiente para
permitir que você descubra possíveis problemas sobre o aplicativo. "O mais simples
coisa que poderia funcionar” definitivamente se aplica à criação de dados para testes.
Você deseja manter seus testes o mais simples e rápidos possível.
Evite acesso ao banco de dados
Sua primeira escolha para teste deve tentar ter testes que possam ser executados completamente
em memória. Eles ainda precisarão configurar e desmontar os dados de teste, mas o
os dados não serão armazenados em um banco de dados. Cada teste é independente e é executado tão rapidamente quanto
qualquer teste poderia. O acesso ao banco de dados significa que a E/S e os discos são
inerentemente lentos. Cada leitura no banco de dados retarda a execução do teste. Se o seu objetivo é dar rápido
feedback para a equipe, então você deseja que seus testes sejam executados o mais rápido possível.
Um objeto falso, como um banco de dados na memória, permite que o teste faça o que for necessário
fazer e ainda dar feedback instantâneo.
Um de nossos processos de construção executa apenas testes em nível de unidade e tentamos

A história de Lisa
manter seu tempo de execução inferior a oito minutos, para obter feedback ideal. Os testes substituem
objetos falsos pelo banco de dados real na maioria dos casos. Os testes que realmente testam
a camada de banco de dados, como a persistência de dados no banco de dados, usam um pequeno
Compreensivo esquema com dados canônicos originalmente copiados do banco de dados de produção. Os dados são
explicações e exemplos realistas, mas a pequena quantidade torna o acesso mais rápido.
de vários tipos de testes
duplos podem ser No nível de teste funcional, nossos equipamentos de teste FitNesse criam dados na memória sempre
encontrados em . que possível. Esses testes são executados rapidamente e os resultados aparecem quase
Consulte a xUnidade Teste instantaneamente. Quando precisamos testar a camada de banco de dados, ou se precisarmos testar
Padrões bibliografia
código legado que não é acessível independentemente da camada de banco de dados, geralmente
para obter mais escrevemos testes FitNesse que configuram e desmontam seus próprios dados usando um dispositivo
informações sobre isso e
de dados desenvolvido internamente. Esses testes são necessários, mas são lentos e sua manutenção
ferramentas para trabalhar
é cara, por isso os mantemos no mínimo necessário para nos dar confiança.
com stubs de teste e
com objetos simulados e
Queremos que nossa versão que executa testes voltados para os negócios forneça feedback dentro
falsos. de algumas horas para nos manter produtivos.
—Lisa
Ferramentas como DbFit e

NdbUnit podem simplificar
Como é tão difícil obter força na automação de testes, seria fácil
os testes de banco de
diga “OK, temos alguns testes e eles levam horas para serem executados, mas é melhor
dados e permitir o
desenvolvimento de do que nenhum teste.” O acesso ao banco de dados é um dos principais contribuintes para testes lentos. Continue
banco de dados orientado dando pequenos passos para falsificar o banco de dados sempre que puder e teste o máximo de lógica possível.
a testes; consulte a
possível sem envolver o banco de dados. Se isso for difícil, reavalie seu
bibliografia para obter mais
recursos.
arquitetura do sistema e ver se ela pode ser melhor organizada para teste.
Se você estiver testando lógica de negócios, algoritmos ou cálculos em código, estará interessado
no comportamento do próprio código, dadas determinadas entradas; você não se importa
de onde vêm os dados, desde que representem dados reais com precisão. Se este
Se for o caso, construa dados de teste que façam parte do teste e possam ser acessados na
memória e deixe o código de produção operar a partir deles. Simular acesso ao banco de dados
e objetos, e concentre-se no propósito do teste. Não só os testes serão executados
mais rápido, mas serão mais fáceis de escrever e manter.
Ao gerar dados para um teste, use valores que reflitam a intenção do teste,
sempre que possível. A menos que você esteja completamente confiante de que cada teste é independente,
gere valores de teste exclusivos para cada teste. Por exemplo, use carimbos de data/hora
como parte dos valores do campo. Dados exclusivos são outra rede de segurança para impedir que os testes
infectando uns aos outros com dados perdidos. Quando você precisa de grandes quantidades de dados,
tente gerar os dados aleatoriamente, mas sempre limpe-os no final do teste
para que não sangre no próximo teste. Reconhecemos que às vezes você
precisa testar tipos de dados muito específicos. Nestes casos, gerados aleatoriamente
dados iriam anular o propósito do teste. Mas você pode usar o suficiente
randomização para garantir que cada teste tenha entradas exclusivas.
Quando o acesso ao banco de dados é inevitável ou até mesmo desejável
Se o sistema em teste depende muito do banco de dados, isso naturalmente terá que ser
testado. Se o código que você está testando lê e/ou grava no banco de dados, pelo menos
em algum momento você precisará testar isso e provavelmente desejará pelo menos alguns testes de
regressão que verifiquem a camada de código do banco de dados.
Dados de configuração/ desmontagem para cada teste
Nossa abordagem preferida é fazer com que cada teste adicione os dados necessários a um teste
esquema, operar nos dados, verificar os resultados no banco de dados e, em seguida, excluir todos os
dados de teste para que o teste possa ser executado novamente sem impactar outros testes subsequentes.
Isto apoia a ideia de que os testes são independentes uns dos outros.
Usamos um acessório de dados genérico que permite que a pessoa que escreve o teste especifique
A história de Lisa
a tabela do banco de dados, as colunas e os valores das colunas para adicionar dados. Outro
dispositivo genérico de pesquisa de dados nos permite inserir um nome de tabela e uma cláusula SQL
where para verificar os dados persistidos reais. Também podemos usar o acessório de dados genérico
para excluir dados usando o nome da tabela e um valor-chave. A Figura 14-3 mostra um exemplo
de tabela que usa um data fixture para construir dados de teste no banco de dados. Ele preenche a tabela
Figura 14-3 Exemplo de tabela usando um acessório de dados para construir dados de
teste no banco de dados
“todos os fundos” com as colunas e valores especificados. É fácil para aqueles que escrevem
casos de teste preencher as tabelas com todos os dados de que precisamos.
Observe que os esquemas que usamos para esses testes têm a maioria de suas restrições
removidas, portanto, só precisamos preencher as tabelas e colunas pertinentes à funcionalidade
que está sendo testada. Isso também torna a manutenção um pouco mais fácil. A desvantagem é
que o teste é um pouco menos realista, mas os testes que utilizam outras ferramentas verificam a
funcionalidade em um ambiente realista.
A desvantagem de criar dados de teste dessa maneira é que sempre que uma alteração é feita no
banco de dados, como uma nova coluna com um valor obrigatório, todos os dados fixos
tabelas nos testes que preenchem essa tabela terão que ser alteradas. Esses testes podem ser
complicados de escrever e manter, por isso só os usamos quando for absolutamente necessário.
Tentamos projetar os testes para manter os custos de manutenção baixos. Por exemplo, o conjunto
de dados na Figura 14-3 está em uma biblioteca “include” e pode ser incluído nos testes que
precisam dele. Digamos que adicionamos uma nova coluna, “fund_category”. Precisamos apenas
adicioná-lo a esta tabela “include”, em vez de em 20 testes diferentes que o utilizam.
—Lisa
Dados Canônicos
Outra alternativa é ter esquemas de teste que possam ser atualizados rapidamente com
dados de um banco de dados canônico ou inicial. A ideia é que esses dados de sementes sejam uma amostra
representativa dos dados reais de produção. Por ser uma pequena quantidade de dados,
pode ser reconstruído rapidamente sempre que um conjunto de testes de regressão precisar ser executado.
Essa abordagem também aumenta o tempo necessário para executar testes, mas são apenas alguns
minutos no início do conjunto de regressão, em vez de reservar um tempo de cada
teste individual. Os testes ainda serão mais lentos que os testes que não acessam o banco de dados, mas serão
mais rápidos que os testes que precisam preencher laboriosamente cada

coluna em cada tabela.
Os dados canônicos têm muitos usos. Testadores e programadores podem ter seus próprios
esquema de teste para atualizar à vontade. Eles podem conduzir tanto manuais quanto automatizados
testes sem pisar nos testes de ninguém. Se os dados forem cuidadosamente escolhidos,
os dados serão mais realistas do que a quantidade limitada de dados que cada teste pode
construir para si mesmo.
Claro que, como acontece com praticamente tudo, há uma desvantagem. Dados canônicos
pode ser difícil acompanhar. Quando você precisar de novos cenários de teste, deverá identificar os dados de
produção que funcionarão ou criar os dados necessários e adicioná-los
para o esquema inicial. Você tem que limpar os dados, mascarar a identificação de pessoas reais
características, tornando-o inócuo por razões de segurança. Cada vez que você adiciona
uma tabela ou coluna no banco de dados de produção, você deverá atualizar seus esquemas de
teste adequadamente. Talvez seja necessário avançar os dados sensíveis à data todos os anos ou
fazer outra manutenção em grande escala. Você deve selecionar cuidadosamente quais tabelas
devem ser atualizadas e quais tabelas não precisam ser atualizadas, como tabelas de pesquisa.
Se você precisar adicionar dados para aumentar a cobertura do teste, a atualização demorará mais
para ser feita, aumentando o tempo do processo de construção que a aciona. Como enfatizamos, é
importante que suas compilações automatizadas forneçam feedback em tempo hábil, para que
atualizações cada vez mais longas do banco de dados prolonguem seu ciclo de feedback. Você
também perde a independência do teste com dados canônicos; portanto, se um teste falhar, outros
poderão seguir o exemplo.
Os membros da equipe de Lisa executam seus conjuntos de testes de GUI e alguns de seus testes
de regressão funcional em esquemas atualizados a cada execução com dados canônicos. Em raras
ocasiões, os testes falham inesperadamente devido a uma atualização incorreta dos dados iniciais.
Decidir se deve “rolar” os dados para frente, de modo que, por exemplo, as linhas de 2008 se tornem
as linhas de 2009, pode ser uma dor de cabeça. Até agora, o ROI do uso de dados canônicos tem
sido aceitável para a equipe. A equipe atual de Janet também usa dados iniciais para testes de
“camada intermediária” em compilações locais. Funciona bem para feedback rápido durante o ciclo
de desenvolvimento. No entanto, o ambiente de teste e os ambientes de preparação usam uma
cópia migrada dos dados de produção. A desvantagem é que os testes de regressão só podem ser
executados em cópias locais da compilação. O risco é baixo porque eles praticam “construir uma
vez, implantar para muitos”.
Dados semelhantes aos da produção
A capacidade de testar um sistema que seja o mais parecido possível com a produção é essencial
para a maioria das equipes de desenvolvimento de software. No entanto, executar um conjunto de
testes de regressão automatizados em uma cópia de um banco de dados de produção provavelmente
seria executado muito lentamente para ser um feedback útil. Além disso, você não poderia realmente
depender de nenhum dado permanecer estável ao trazer novas cópias para se manter atualizado.
Geralmente, quando se trata de testes funcionais ou de ponta a ponta, um clone do banco de dados
de produção é mais útil para testes exploratórios manuais.
Os testes de estresse, desempenho e carga, que exigem muita automação, precisam de um

ambiente que simule de perto a produção para fornecer resultados que possam ser traduzidos em
operações reais. Usabilidade, segurança e confiabilidade são outros exemplos de testes que
necessitam de um sistema semelhante ao de produção, embora possam não envolver muita
automação.
Sempre há uma compensação; seu banco de dados de produção pode ser enorme, por isso é caro
e lento, mas fornece os dados de teste mais precisos disponíveis. Se a sua organização puder
adquirir hardware e software para armazenar várias cópias de dados de produção para fins de teste,
isso é ideal. As pequenas empresas podem
têm restrições de recursos que podem limitar a quantidade de dados que podem ser
armazenados em ambientes de teste e preparação. Neste caso, você precisará decidir
quantos dados de teste você pode suportar e planejar como copiar dados relevantes o suficiente
dados para tornar o teste representativo do que é usado na “vida real”. Ou você pode
considere fazer o investimento em hardware, que está ficando mais barato
todos os dias, para apoiar um ambiente de estilo de produção real. Caso contrário, seu
os resultados dos testes podem ser enganosos. Como mencionamos com os dados canônicos,
pode ser necessário limpar os dados antes de usá-los.
Migração de dados
A migração de dados precisa ser testada em um banco de dados real. Os scripts de atualização
do banco de dados precisam ser executados em dados reais e na última versão conhecida do
esquema do banco de dados.
Testando uma migração de banco de dados
Paul Rogers, arquiteto de testes de automação, conta esta história de teste de uma
migração de banco de dados reveladora [2008]:
Ontem mesmo, executei uma migração Rails em meu banco de dados de teste.
Os desenvolvedores escreveram, testaram e verificaram usando seus bancos de
dados de desenvolvimento. Meu banco de dados de teste era provavelmente 20.000
vezes maior. A migração para eles levou segundos. Para mim, bem, parei depois de
três horas, provavelmente 10% concluído. Os programadores precisavam de refazer
a sua estratégia de migração.
Duvido que isso tivesse aparecido em um banco de dados na memória, então, para
mim, um banco de dados real neste caso foi definitivamente a escolha certa. Na
verdade, é provável que isso contribua para coisas que precisamos considerar
antes do lançamento, como quanto tempo leva uma implantação ou quanto tempo
leva a atualização do banco de dados. Podemos então usar isso para estimar
quanto tempo de inatividade precisaremos para a atualização real.
Este é outro exemplo de como devemos encontrar um equilíbrio entre testes que fornecem
feedback rápido e testes que refletem de forma realista eventos que podem ocorrer na
produção.
Entenda suas necessidades
Se você entender o propósito de seus testes, poderá avaliar melhor seu

precisa. Por exemplo, se você não precisar testar procedimentos armazenados ou consultas SQL
diretamente para obter velocidade, considere ferramentas como bancos de dados na memória, que
funcionam como bancos de dados reais, mas aceleram bastante seus testes. Quando você precisa
para simular o ambiente de produção real, faça uma cópia de todo o
AVALIANDO FERRAMENTAS DE AUTOMAÇÃO 311
banco de dados de produção, se necessário. O objetivo é o feedback rápido, portanto, equilibre o

teste de cenários realistas com a localização de defeitos da maneira mais eficiente possível.
AVALIANDO FERRAMENTAS DE AUTOMAÇÃO
O primeiro passo para escolher uma ferramenta de automação é fazer uma lista de tudo
a ferramenta precisa fazer por você. Vamos considerar como você pode decidir sobre seu teste
requisitos da ferramenta.
Identificando requisitos para sua ferramenta de automação

Depois de decidir sobre o próximo desafio de automação a ser enfrentado, pense no seu
necessidades da ferramenta. Quais ferramentas você já possui? Se precisar de outros adicionais, você
provavelmente deseja algo que se integre bem aos seus testes existentes e
infraestrutura de desenvolvimento. Você precisa de uma ferramenta para integrar facilmente ao
processo de construção contínuo? O seu hardware existente suportará a automação que você precisa
fazer? Configurando um segundo processo de construção para executar testes funcionais
pode exigir maquinário adicional.
Quem usará a ferramenta de teste que você pretende implementar? Os não-programadores

escreverão casos de teste? Seus programadores querem uma ferramenta que eles
se sente confortável com também? Você distribuiu membros da equipe que
precisa colaborar?
Quem automatizará e manterá os testes? As habilidades já em seu

equipe são importantes. Quanto tempo você tem para instalar uma ferramenta e
Aprenda como usá-lo? Se seu aplicativo for escrito em Java, uma ferramenta que use Java
para scripts pode ser o mais apropriado. Os membros da equipe têm experiência com ferramentas
específicas? Existe uma equipe de teste separada com experiência em um
determinada ferramenta? Se você está iniciando a transição para o desenvolvimento ágil e já tem
uma equipe de automatizadores de testes, pode fazer sentido aproveitar a experiência deles e
continuar usando as ferramentas que eles conhecem.
Os requisitos da sua ferramenta dependem do seu ambiente de desenvolvimento. Se

você está testando um aplicativo da web e a ferramenta escolhida não oferece suporte a SSL
ou AJAX, você pode ter um problema. Nem toda ferramenta de teste pode testar serviços da web
formulários. O teste de sistema embarcado pode precisar de ferramentas diferentes novamente. O
o estudo de caso no Capítulo 12, “Resumo dos quadrantes de teste”, mostra uma maneira
usar Ruby para testar um aplicativo incorporado.
Claro, o tipo de teste que você está automatizando é fundamental. Os testes de segurança
provavelmente precisam de ferramentas altamente especializadas. Existem muitos softwares de código aberto e
ferramentas do fornecedor para desempenho, para que o trabalho de selecionar uma não seja cansativo.
Ao dominar um desafio, você estará melhor preparado para o próximo. Levou
equipe de Lisa alguns anos para desenvolver conjuntos robustos de testes de regressão no
unidade, integração e níveis funcionais. O teste de desempenho foi o próximo
área de dor. As lições aprendidas com os esforços anteriores de automação ajudaram
eles fazem um trabalho melhor na identificação de requisitos para uma ferramenta de teste, como facilidade
de relatórios de resultados, compatibilidade com estruturas existentes e scripts
linguagem.
Escreva uma lista de verificação que capture todos os requisitos de sua ferramenta. Alguns deles
podem entrar em conflito ou se contradizerem - “A ferramenta precisa ser fácil
suficiente para que os clientes possam especificar testes” ou “Os testes devem ser fáceis de
automatizar." Anote-os para encontrar o equilíbrio certo. Então comece
fazendo sua pesquisa.
Uma ferramenta de cada vez
Você precisará de ferramentas diferentes para atender a propósitos diferentes. Implementar novas
ferramentas e aprender a melhor maneira de usá-las pode ser cansativo
muito rapidamente. Experimente uma ferramenta de cada vez, abordando a área de maior dor.
Dê tempo suficiente para um julgamento justo e avalie os resultados. Se estiver funcionando para
você, domine essa ferramenta antes de passar para a próxima área de dor e a próxima
ferramenta. A multitarefa pode funcionar em algumas situações, mas as novas tecnologias exigem atenção
total.
Quando você escolher uma ferramenta para atender a uma necessidade específica, dê um passo para trás
e veja o que mais você precisa. Qual é o próximo desafio de automação enfrentado
seu time? A ferramenta que você acabou de selecionar para outra finalidade funcionará para esse propósito?
também precisa ou precisa iniciar um novo processo seletivo?
Se você decidiu procurar ferramentas fora de sua organização, a primeira

A bibliografia
O passo é encontrar tempo para experimentar. Comece com alguma pesquisa básica: Internet
contém sites que
auxiliam na pesquisas, artigos e outras publicações sobre ferramentas e listas de discussão são
busca e bons lugares para ter ideias. Compile uma lista de ferramentas a serem consideradas. Se sua equipe usa
avaliação de ferramentas.uma ferramenta wiki ou fórum on-line, poste informações sobre as ferramentas e inicie uma discussão
sobre prós e contras.
Reserve tempo para avaliar ferramentas. Algumas equipes têm um “sprint de engenharia” ou
“refatorar iteração” a cada poucos meses onde, em vez de entregar histórias
priorizados pela empresa, eles começam a trabalhar na redução do débito técnico, na atualização de
versões de ferramentas e na experimentação de novas ferramentas. Se sua equipe não tiver
ainda assim, peça à sua administração para obtê-los. Reduzindo sua tecnologia
dívida legal e o estabelecimento de uma boa infraestrutura de testes melhorarão seu

velocidade no futuro e tempo livre para testes exploratórios. Se você nunca teve
hora de tornar o código mais fácil de manter ou atualizar ferramentas, a dívida técnica
diminua sua velocidade até que ela pare.
Quando você tiver uma lista de ferramentas que podem atender às suas necessidades, restrinja o
possibilidades até uma ou duas, aprenda como usar cada uma bem o suficiente para
experimente e faça um pico: experimente um cenário simples, mas representativo, que você possa
jogar fora. Avalie os resultados em relação aos requisitos. Use retrospectivas
considerar prós e contras.
Quais recursos você precisa para implementar e usar a ferramenta? Que impacto
a ferramenta terá na produtividade e velocidade da equipe? Quais são os riscos
pose? O que isso permitirá que você faça a longo prazo que não pode fazer agora?
Escolha seu melhor candidato e comprometa-se a experimentá-lo por algum período de tempo.
tempo suficiente para obter alguma competência com ele. Certifique-se de testar todas as suas
funcionalidades de missão crítica. Por exemplo, se sua aplicação usa muito Ajax,
certifique-se de que você pode automatizar testes usando a ferramenta. Em retrospectivas, veja
o que funcionou e o que não funcionou. Esteja aberto à ideia de que pode não estar certo
e que você tem que jogá-lo fora e começar de novo. Não sinta que você tem que manter
continue com a ferramenta porque você já investiu muito nela.
Todos sabemos que não existe uma “bala de prata” que possa resolver toda a sua automação
problemas. Reduza suas expectativas e abra sua mente. Soluções criativas
confiar tanto na arte quanto na ciência.
Ao realizar a pesquisa da ferramenta de teste de desempenho, recorremos a uma lista de discussão

A história de Lisa
de testes ágeis para obter sugestões. Muitas pessoas ofereceram suas experiências e algumas
até se ofereceram para ajudar no aprendizado e na implementação de uma ferramenta.
Procuramos uma ferramenta que usasse Java para scripts, tivesse uma curva de aprendizado
O Capítulo 11, mínima e apresentasse os resultados em um formato gráfico útil. Listamos as ferramentas e
“Criticando o produto
seus prós e contras no wiki da equipe. Orçamos tempo para testes. O colega de trabalho de Lisa,
usando testes
Mike Busse, testou os dois principais candidatos e mostrou os destaques para o restante da equipe.
voltados para a
Uma ferramenta foi escolhida por consenso da equipe e provou ser adequada.
tecnologia”, mostra
um exemplo dos resultados —Lisa
produzidos pela ferramenta
de teste de desempenho
escolhida, JMeter.
Escolhendo ferramentas
Temos a sorte de ter uma gama já vasta e um conjunto cada vez maior de ferramentas para
escolha entre: ferramentas locais, de código aberto, de fornecedores ou uma combinação de
qualquer, são todas alternativas viáveis. Com tantas opções, o truque é saber
onde procurar e encontrar tempo para experimentar as ferramentas e ver se elas atendem às suas
necessidades. Como não podemos prever o futuro, pode ser difícil avaliar o ROI de
cada solução potencial, mas uma abordagem iterativa para avaliá-las ajuda
vá para o caminho certo.
Você deve cultivar o seu próprio?
Seu aplicativo apresenta desafios de teste únicos, como

software ou integração com sistemas externos? Os membros da equipe têm
habilidades, tempo e inclinação para escrever sua própria estrutura de teste ou construir uma
em cima de uma ferramenta de código aberto existente? Nesse caso, ferramentas de teste desenvolvidas internamente podem ser
o melhor ajuste.
Um resultado feliz (ou talvez um grande fator de sucesso) do desenvolvimento ágil é

que muitos programadores estão “infectados por testes”. As ferramentas de desenvolvimento atuais e
linguagens tornam as estruturas de automação mais fáceis de construir. Ruby, Groovy, Trilhos,
e muitas linguagens e estruturas se prestam à automação. As ferramentas de código aberto existentes,
como Fit e HtmlUnit, podem ser aproveitadas, com estruturas personalizadas construídas sobre elas.
As ferramentas caseiras têm muitas vantagens. Eles são definitivamente amigáveis ao programador. Se
sua equipe estiver escrevendo suas próprias estruturas de automação, eles estarão
precisamente personalizado para as necessidades de suas equipes de desenvolvimento e de clientes,
e integrado ao seu processo de construção existente e outras infraestruturas —
e você pode torná-los tão fáceis de executar e interpretar os resultados quanto precisar.
Cultivado em casa não significa grátis, é claro. Uma equipe pequena pode não ter o
largura de banda para escrever e dar suporte a ferramentas, bem como desenvolver código de produção. A
grande organização com requisitos únicos pode ser capaz de montar um
equipe de especialistas em automação que podem colaborar com testadores, clientes,
programadores e outros. Se suas necessidades são tão únicas que nenhuma ferramenta existente
os apoia, o cultivo local pode ser a sua única opção.
Ferramentas de código aberto
Muitas equipes que escreveram suas próprias ferramentas as disponibilizaram generosamente

para a comunidade de código aberto. Como essas ferramentas foram escritas por programadores
infectados por testes cujas necessidades não foram atendidas pelas ferramentas dos fornecedores, elas são
geralmente leve e apropriado para desenvolvimento ágil. Muitos desses
as ferramentas são desenvolvidas primeiro para teste, e você pode baixar o conjunto de testes junto com
o código-fonte, tornando a customização mais fácil e segura. Estas ferramentas têm um
amplo apelo, com recursos úteis tanto para programadores quanto para testadores. O
o preço está certo, embora seja importante lembrar que o preço de compra é
apenas uma fração do custo de qualquer ferramenta.
Nem todas as ferramentas de código aberto estão bem documentadas e o treinamento pode ser um problema.
No entanto, vemos seminários e tutoriais sobre a utilização destas ferramentas em muitas conferências e
reuniões de grupos de utilizadores. Algumas ferramentas de código aberto têm excelente usuário
manuais e ainda disponibilizam tutoriais online e aulas agendadas.
Se você está considerando uma solução de código aberto, procure um desenvolvedor ativo
“Kit de ferramentas para
e comunidade de usuários. Existe uma lista de discussão com muita largura de banda? São novos
Voltado para negócios recursos lançados com frequência? Existe uma maneira de relatar bugs e alguém corrige
Testes que apoiam a eles? Algumas dessas ferramentas têm melhor suporte e resposta mais rápida a bugs
equipe”, para saber
do que as ferramentas do fornecedor. Por que? As pessoas que os escrevem também os usam, e
mais sobre open
teste de origem automático
eles precisam desses recursos para testar seus próprios produtos.
ferramentas de informação.
Ferramentas do fornecedor
As ferramentas comerciais são percebidas como uma aposta segura. É difícil criticar alguém por
selecionando uma ferramenta bem conhecida que já existe há anos. É provável que eles
vêm com manuais, suporte e treinamento. Para testadores ou outros usuários que
não tiver formação técnica, o arranque inicial poderá ser mais rápido. Alguns são
bastante robusto e rico em recursos. Sua empresa pode já possuir um e ter
uma equipe de especialistas que sabem utilizá-lo.
Embora estejam mudando com o tempo, as ferramentas dos fornecedores são historicamente hostis aos
programadores. Eles tendem a usar linguagens de script proprietárias que
os programadores não querem perder tempo aprendendo. Eles também tendem a ser pesados. Os scripts de
teste podem ser frágeis, facilmente quebrados por pequenas alterações no
aplicação e de manutenção cara. A maioria dessas ferramentas está gravando
scripts para reprodução posterior. Os scripts de gravação/reprodução são notoriamente
caro do ponto de vista da manutenção.
Elisabeth Hendrickson [2008] aponta que ferramentas especializadas como essas

Veja a bibliografia para
pode criar a necessidade de especialistas em automação de testes. Silos como estes podem funcionar
uma discussão
completa por contra equipes ágeis. Precisamos de ferramentas que facilitem o teste primeiro, em vez do teste por último
Elisabeth desenvolvimento. As ferramentas de teste não devem impedir a mudança.
Hendrickson
nesse assunto.
Se você já tem pessoas especialistas em uma ferramenta de fornecedor e usa uma ferramenta que
pode ser usado apenas por um subconjunto da equipe de desenvolvimento ou por uma equipe separada
desde o desenvolvimento, uma ferramenta de fornecedor pode fazer muito sentido. Os dois primeiros XP de Lisa
as equipes usaram uma ferramenta de fornecedor com algum grau de sucesso.
No momento em que este livro foi escrito, melhores ferramentas de teste funcional e IDEs estavam surgindo.
Eles facilitam as tarefas de manutenção de testes com recursos como pesquisa/substituição global. Torção
é um exemplo de ferramenta implementada como uma coleção de plug-ins para o Eclipse
IDE, para que possa aproveitar os poderosos recursos de edição e refatoração.
Ferramentas ágeis
Elisabeth Hendrickson [2008] lista algumas características de testes ágeis eficazes
Parte III, “Usando
ferramentas de automação. Essas ferramentas devem:
quadrantes de testes ágeis”
e particularmente o
Capítulo 9, “Kit de Apoie o início imediato do esforço de automação de testes, usando uma abordagem
ferramentas para testes de teste primeiro
voltados para negócios
Separe a essência do teste dos detalhes da implementação
que dão suporte à
equipe”, contém Apoiar e incentivar boas práticas de programação para a parte do código da
exemplos de automação de testes
ferramentas de
Suporte à escrita de código de automação de testes usando linguagens reais,
automação de testes que funcionam bem em projetos ágeis.
com IDEs reais
Promova a colaboração
IMPLEMENTANDO AUTOMAÇÃO
Ao avaliar as ferramentas, pense na rapidez com que sua principal necessidade de automação
deve ser atendida. Onde você obterá suporte para ajudar
Implementá-lo? De que treinamento a equipe precisa e quanto tempo será
disponível para se dedicar a isso? Com que rapidez você precisa desenvolver essa ferramenta?
Tenha todas essas restrições em mente ao analisar as ferramentas. Você pode

terá que se contentar com uma ferramenta menos robusta do que você realmente deseja para obter recursos vitais
automação acontecendo no curto prazo. Lembre-se de que nada é permanente.
Você pode desenvolver seu esforço de automação passo a passo. Muitas equipes experimentam
tentativas malsucedidas antes de encontrar a combinação certa de ferramentas, habilidades,
e infraestrutura.
Selênio no trabalho
Joe Yakich, engenheiro de software com experiência em automação de testes, descreve como
uma equipe com a qual trabalhou implementou um esforço de automação de testes com Sele-nium,
uma ferramenta de automação de testes de código aberto.
A empresa de software para a qual trabalhei — vamos chamá-la de XYZ Corp — teve um
problema. O produto, um aplicativo baseado na Web de nível empresarial, era uma
oferta poderosa e madura. Os projetos de desenvolvimento foram gerenciados usando
IMPLEMENTANDO AUTOMAÇÃO 317
Agile e Scrum, e um grupo talentoso de engenheiros produziram novos recursos

rapidamente. A empresa crescia de forma constante.
Então qual foi o problema? XYZ estava enfrentando um futuro em que os esforços de teste de
software talvez não conseguissem acompanhar o esforço de desenvolvimento.
Problemas de qualidade de software podem retardar a adoção do produto ou, pior ainda,
ainda - faz com que os clientes existentes procurem outro lugar.
A automação de testes parecia uma forma óbvia de mitigar esses riscos, e a XYZ estava
plenamente ciente disso. Na verdade, eles já haviam tentado criar um conjunto de automação
de testes duas vezes antes e falharam.
Na terceira vez, XYZ optou por usar Selenium RC, impulsionado pela linguagem de
programação Ruby. Selenium RC – RC significa “Controle Remoto” – é uma ferramenta
para automação de testes. Selenium RC consiste em um componente de servidor e
bibliotecas de cliente. O componente do servidor Java atua como um proxy HTTP, fazendo
com que o Selenium Core JavaScript pareça originar-se do servidor web do aplicativo em
teste (AUT). O servidor pode iniciar e parar sessões do navegador (os navegadores suportados
incluem quase todos os navegadores modernos, incluindo Internet Explorer, Firefox e Safari)
e interpretar comandos para interagir com elementos como botões, links e campos de
entrada.
As bibliotecas cliente permitem que scripts de teste sejam escritos em Java, .NET, Perl,
Python e Ruby.
Nossa equipe escolheu Ruby porque é uma linguagem puramente orientada a objetos,
dinâmica e interpretada, com uma sintaxe elegante, expressiva e concisamente poderosa.
Mais importante ainda, Ruby é uma ferramenta ideal para a criação de uma Linguagem
Específica de Domínio (DSL). Ruby é maleável o suficiente para que o programador escolha
primeiro a estrutura e a sintaxe da DSL e depois crie uma implementação, em oposição a uma
linguagem mais rígida que pode impor restrições a essa liberdade. Um dos nossos objetivos
era criar uma estrutura de automação – uma DSL – que escondesse detalhes complexos.
Queríamos poder dizer coisas como
editor.save
em nossos testes em vez de
s.click("//tabela[@class='edit']/tbody/tr[0]//img[@src='save.gif']")
O primeiro não é apenas mais legível, mas também muito mais fácil de manter. A expressão
XPath neste último pode ser colocada em um método de biblioteca para ser chamada conforme
necessário. Usar uma DSL que emprega os substantivos e verbos do aplicativo permite que
um engenheiro que escreve um teste se concentre no teste, e não na complexidade subjacente
da interação com os controles na tela.
XYZ criou uma equipe de automação para construir a estrutura e os testes. A criação da
estrutura em si foi uma tarefa demorada e tecnicamente desafiadora.
tarefa. Algumas das próprias classes da estrutura eram complicadas o suficiente para
garantir seus próprios testes unitários. Depois que uma quantidade suficiente de estrutura de
teste foi construída, começamos a trabalhar nos testes reais da aplicação, usando a biblioteca
Ruby RSpec. O próprio RSpec é uma DSL para especificações de teste. Um de seus pontos
fortes é o uso de declarações declarativas simples para descrever comportamentos e expectativas.
Poderíamos, por exemplo, escrever um teste usando a instrução
“Um usuário deve poder acessarpara

os dados no editor clicando
salvar um Salvar"
preenchendo o corpo do teste com chamadas para a estrutura de teste baseada em Selenium que
criamos.
Quase um ano depois, automatizamos quase dois mil casos de teste.

Embora a maior parte da aplicação fosse coberta pela automação, outras partes da aplicação
exigiam testes manuais – fomos forçados a fazer escolhas e priorizar nossos esforços. Todas as
semanas, o conjunto de testes demorava mais para ser executado do que na semana anterior;
agora levamos quase seis horas para ser concluído e começamos a pensar em executar testes
em paralelo. Ainda não conseguimos expandir nossos testes em todos os navegadores
suportados pelo aplicativo. O entusiasmo gerado pela automação diminuiu um pouco e achamos
necessário gerenciar cuidadosamente as expectativas, tanto com a alta administração quanto com
outros engenheiros. Apesar destes problemas, o Selenium foi uma vitória clara, pois se não
tivéssemos investido pesadamente na automação de testes, os testes na XYZ exigiriam a
contratação de um exército de engenheiros de teste (o que teria sido proibitivamente caro, mesmo
que tivéssemos conseguido encontrar candidatos qualificados suficientes). .
Nem tudo pode ser automatizado, por razões orçamentais ou técnicas. Além disso, os testes
exploratórios são inestimáveis e não devem ser negligenciados. Deve-se notar, no entanto, que
essas desvantagens são compartilhadas por todas as outras ferramentas de automação
de testes disponíveis atualmente, e a maioria das outras ferramentas de automação que podem
rivalizar com as proezas de automação do Selenium são produtos comerciais que não podem
igualar seu preço: grátis.
Boas práticas de desenvolvimento são fundamentais para qualquer esforço de automação. Use uma
abordagem orientada a objetos. À medida que você constrói sua biblioteca de objetos de teste, adicionar
novos testes fica mais fácil. Uma linguagem específica de domínio ajuda a tornar os testes voltados para
os negócios compreensíveis para os clientes, ao mesmo tempo que reduz os custos de gravação e
manutenção de scripts de teste automatizados.
Um bom design orientado a objetos não é a única chave para construir um conjunto de testes
automatizados sustentáveis que compensam. Você também precisa executar os testes com frequência
o suficiente para obter o feedback que sua equipe precisa. Quaisquer ferramentas que escolhermos devem
ser integrado ao nosso processo de construção. Resultados fáceis de interpretar devem surgir
para nós automaticamente.
GERENCIANDO TESTES AUTOMATIZADOS 319
As ferramentas que escolhemos devem funcionar em nossas plataformas e devem ser

compartilhadas e funcionar bem com nossas outras ferramentas. Temos que ajustá-los
continuamente para ajudar com nossos problemas atuais. A construção está quebrando todos os
dias? Talvez precisemos conectar nossos resultados a um semáforo real para conscientizar a equipe sobre se
Um teste voltado para negócios falhou? Deve ficar claro exatamente o que falhou e onde. Não
temos tempo extra para isolar problemas.
Estas preocupações são uma parte essencial do quadro, mas ainda são apenas uma parte do
quadro. Precisamos de ferramentas que nos ajudem a criar ambientes de teste que imitem a
produção. Precisamos de maneiras de manter esses ambientes de teste independentes, não
afetados pelas mudanças que os programadores possam estar fazendo.
Construir uma infraestrutura de teste pode ser um grande investimento, mas é um investimento
que nossa equipe ágil precisa fazer para dar um salto na automação de testes. Hardware,
software e ferramentas precisam ser identificados e implementados. Dependendo dos recursos
da sua empresa, este pode ser um projeto de longo prazo. Pense em maneiras de lidar com a
situação no curto prazo, enquanto planeja como montar a infraestrutura que você realmente
precisa para minimizar riscos, maximizar a velocidade e entregar o melhor produto possível.
GERENCIANDO TESTES AUTOMATIZADOS
Digamos que precisamos de uma maneira de encontrar o teste que verifica um cenário específico,
de entender o que cada teste faz e de saber que parte do aplicativo ele verifica. Talvez precisemos
satisfazer um requisito de auditoria para rastreabilidade de cada requisito até seu código e testes.
Os testes automatizados precisam ser mantidos e controlados da mesma forma que o código-
fonte de produção. Ao marcar seu código de produção para lançamento, os testes que verificaram
essa funcionalidade precisam fazer parte da tag.
Aqui está um exemplo em que isso é útil. Acabamos de encontrar um problema no código em
desenvolvimento. É um problema novo ou está oculto no código há algum tempo e de alguma
forma não foi percebido no teste? Podemos implantar a tag que está em produção, tentar
reproduzir o problema e investigar por que os testes não detectaram o problema. A equipe de
Lisa recentemente teve uma situação em que o conjunto de regressão perdeu um bug porque
faltava uma restrição de banco de dados no esquema de teste. Esse tipo de problema é difícil de
identificar se você não estiver vinculando as versões do código de teste às versões do código de
produção.
Organizando testes
Muitas ferramentas vêm com seus próprios meios de organização. Por exemplo, Fit-Nesse vem
com seu próprio wiki, com uma organização hierárquica e recursos integrados.
controle de versão. No momento em que este livro foi escrito, FitNesse estava começando a fornecer suporte para
ferramentas de controle de código-fonte, como o Subversion. Scripts escritos em outras ferramentas de teste,
como Watir e Canoo WebTest, podem e devem ser mantidos dentro do
mesmo sistema de controle de código-fonte do código de produção, assim como os testes de unidade.
Organizando testes com o projeto em teste

Perguntamos a alguns especialistas em testes ágeis como eles gerenciam os testes. Dierk König,
fundador e gerente de projetos do Canoo WebTest, explicou como suas equipes gerenciaram seus
testes automatizados para satisfazer as necessidades das equipes de desenvolvimento e dos clientes.
Sempre organizamos nossos testes junto com o projeto em teste. Ou seja, as fontes de teste
são armazenadas junto com as fontes do projeto exatamente no mesmo repositório, utilizando
os mesmos mecanismos de controle de revisão, marcação e compartilhamento da base de testes.
WebTest vem com um layout padrão de como organizar testes e dados de teste em diretórios.
Você pode adaptar isso a qualquer estrutura que desejar, mas a “convenção sobre configuração”
mostra sua força aqui. Em grandes projetos, cada subprojeto mantém sua própria
base de testes em um “webtest”
subdiretório que segue a convenção.
Sempre que um cliente não seguia esta abordagem, a experiência era muito dolorosa para todas
as pessoas envolvidas. Vimos enormes bancos de dados de descrições de testes que nem
sequer apresentavam um controle de revisão adequado (ou seja, onde você poderia, por exemplo,
ver diferenças com versões antigas ou quem alterou qual teste por qual motivo).
Tenha em mente que os testes são compostos de módulos para que você possa eliminar a
duplicação do código de teste; caso contrário, a manutenção irá matá-lo.
E antes de alterar qualquer módulo, você precisa saber onde ele é utilizado.
Resumindo: certifique-se de que o mestre de seus testes e seus dados de teste estejam em um
formato de texto versionado junto com seu código em teste.
O pessoal não técnico (por exemplo, gerenciamento, controle de qualidade) pode exigir mais
informações de alto nível sobre a cobertura do teste, os resultados dos testes mais recentes
ou até mesmo meios de acionar uma execução de teste. Não deixe que esses requisitos
válidos prejudiquem a abordagem de engenharia para automação de testes. Em vez disso, crie
pequenas ferramentas, por exemplo, aplicativos de relatórios baseados na Web, que atendam
a essas necessidades.
A capacidade dos clientes de acessar informações sobre testes é tão importante quanto a capacidade
de manter os códigos de teste e produção coordenados. Como Dierk apontou, talvez você não consiga
fazer tudo isso com a mesma ferramenta.
O gerenciamento de testes ajuda sua equipe a responder perguntas como as seguintes:
Quais casos de teste foram automatizados?
Quais ainda precisam ser automatizados?

Quais testes estão sendo executados atualmente como parte de um conjunto de regressão?
Quais testes cobrem quais áreas funcionais?
Como o recurso XYZ foi projetado para funcionar?
Quem escreveu este caso de teste? Quando? Quem mudou por último?
Há quanto tempo esse teste faz parte do conjunto de regressão?
Como um dos principais motivos pelos quais escrevemos testes é para orientar o desenvolvimento,
precisamos organizar os testes para que todos da equipe possam encontrar os testes apropriados para cada
história e identificar facilmente quais funcionalidades os testes cobrem.
Como usamos testes como documentação, é fundamental que qualquer pessoa do
a equipe de desenvolvimento ou do cliente pode encontrar um teste específico rapidamente quando há
uma pergunta sobre como o sistema deve se comportar. Podemos precisar de várias ferramentas
para satisfazer diferentes objetivos de gerenciamento de testes.
É fácil perder o controle dos scripts de teste. Quando um teste falha, você precisa identificar
o problema rapidamente. Talvez você precise saber quais alterações foram feitas
recentemente ao script de teste, o que é fácil com o histórico disponível em uma fonte
sistema de controle de código. Sua equipe de clientes também precisa de uma maneira de acompanhar
progresso do projeto, para entender quanto do código é coberto com testes,
e possivelmente para executar os próprios testes. Sistemas de gerenciamento de testes, como os testes
em si, devem promover a comunicação e a colaboração entre a equipe
membros e entre diferentes equipes.
Teste de transparência
Declan Whelan, desenvolvedor de software e coach ágil, usa uma abordagem de
gerenciamento de testes projetada para manter os testes visíveis para testadores,
desenvolvedores, gerentes e outras equipes.
Tratamos todos os artefatos de teste da mesma forma que o código-fonte, do ponto de

vista organizacional e de controle de revisão. Usamos o Subversion, e quem quiser
executar ou editar os testes simplesmente os verifica.
Os testes de ajuste mais recentes estão disponíveis no Wiki do Confluence. Fizemos

isso para apoiar a colaboração (a equipe é distribuída) e para aproveitar os fortes
recursos do Confluence. Ter os testes visíveis no wiki também foi útil para outras
pessoas, como gerentes e outras equipes, que não queriam fazer check-out no
repositório.
Antes disso, a equipe de controle de qualidade mantinha casos de teste em uma unidade
que não era acessível a ninguém fora do controle de qualidade. Isso significava que os
desenvolvedores não conseguiam ver facilmente o que estava sendo testado. Tornar os
testes visíveis, transparentes e apoiados por um sistema de controle de versão (Subversion)
realmente ajudou a quebrar barreiras entre desenvolvedores e testadores da equipe.
Certifique-se de que seus testes sejam gerenciados com um controle de versão sólido, mas
aumente isso com uma maneira de todos usarem os testes de maneira a impulsionar o projeto
e garantir que o valor certo seja entregue.
Organizando resultados de testes
Todos os envolvidos no fornecimento de software precisam de acesso fácil a testes e

resultados. Outro aspecto do gerenciamento de testes é acompanhar quais testes são
de iterações anteriores e necessidade de continuar passando, versus testes que estão conduzindo
desenvolvimento na iteração atual e pode não estar passando ainda. Um processo contínuo de integração
e construção executa testes para feedback rápido sobre o progresso
e para detectar falhas de regressão. A Figura 14-4 mostra um exemplo de resultado de teste
relatório que é compreensível à primeira vista. Um teste falhou e a causa do
a falha é claramente declarada.
Se você está conduzindo o desenvolvimento com testes, e alguns desses testes ainda não foram
aprovados, isso não deve falhar na compilação. Algumas equipes, como a de Lisa, simplesmente mantêm
novos testes fora do processo de integração e construção até que passem pelo primeiro
tempo. Depois disso, eles sempre precisam passar. Outras equipes usam regras na construção
processar-se para ignorar falhas de testes escritos para cobrir o código atualmente
sendo desenvolvido.
Como acontece com qualquer ferramenta de automação de testes, você pode resolver seus problemas
de gerenciamento de testes com sistemas locais, de código aberto ou comerciais. Os mesmos critérios
descritos na seção sobre avaliação de ferramentas de teste podem ser aplicados a
selecionando uma abordagem de gerenciamento de testes.
O gerenciamento de testes é outra área onde se aplicam valores e princípios ágeis, juntamente com a
abordagem de toda a equipe. Comece simples. Experimente em
pequenos passos até encontrar a combinação certa de controle de código-fonte, repositórios e
gerenciamento de construção que mantém os testes e o código de produção em
sincronizar. Avalie sua abordagem de gerenciamento de testes com frequência e certifique-se de que ela
acomode todos os diferentes usuários de testes. Identifique o que está funcionando e
o que está faltando e planeje tarefas ou mesmo histórias para tentar outra ferramenta ou processo para
preencha quaisquer lacunas. Lembre-se de manter o gerenciamento de testes leve e fácil de manter para
que todos possam usá-lo.
Figura 14-4 Resultados de testes de uma ferramenta de gerenciamento de testes desenvolvida internamente
Gerenciando testes para feedback

Megan Sumrell, treinadora e coach ágil, descreve como sua equipe coordena o processo
de construção e testa para obter feedback ideal.
Criamos um conjunto de testes FitNesse para cada sprint. Nesse conjunto, criamos
um subwiki para cada história de usuário que contém seus testes. Conforme
necessário, criamos uma configuração e desmontagem por teste ou suíte. Se, por
algum motivo, não concluirmos uma história de usuário no sprint, moveremos os
testes para o conjunto do sprint no qual concluímos a história.
Introduzimos o script da seguinte regra em nosso build: Se algum dos conjuntos do

sprint anterior falhar, o build será interrompido. No entanto, se os testes no sprint
atual estiverem falhando, não falhe na compilação.
Cada conjunto de testes tem um processo de configuração demorado, portanto, quando

nossos testes FitNesse começaram a demorar mais de 10 minutos para serem executados,
nossa construção de integração contínua tornou-se muito lenta. Usamos links simbólicos
para criar um conjunto de testes que servem como testes de fumaça, executados como
parte de nosso processo de construção de integração contínua. Executamos o conjunto
completo de testes FitNesse em uma máquina separada. Nós o configuramos para verificar
o servidor de compilação a cada cinco minutos. Se existisse uma nova compilação, ele a
executaria e executaria todo o conjunto de testes FitNesse. Quando terminasse, ele
verificaria o servidor de compilação novamente a cada cinco minutos e, após a existência
de uma nova compilação, repetiria o processo.
A equipe de Megan aproveitou os recursos integrados às suas ferramentas, como links

simbólicos, para organizar conjuntos de testes FitNesse para diferentes finalidades – um para
teste de fumaça, outros para testes de regressão completos. Os membros da equipe recebem
feedback imediato dos testes de fumaça e saberão em uma hora se há algum bug que os testes
de fumaça não perceberam.
VAI COMEÇAR _
Não tenha medo de colocar algo - qualquer coisa - no lugar, mesmo que seja um pouco
deficiente. O fator mais importante para o sucesso é apenas começar. Muitos, se
não a maioria, as equipes de sucesso começaram com um processo ruim, mas conseguiram
transformar um processo inadequado em algo verdadeiramente essencial para o sucesso da equipe,
uma peça de cada vez. Tal como acontece com tantos aspectos dos testes ágeis, melhorar
em pequenos incrementos é a chave para o sucesso.
Se você não começar de algum lugar, nunca obterá força na automação. Pegar
toda a equipe junta e inicia um experimento. Sem o nível certo de
automação de testes, sua equipe não consegue fazer o melhor trabalho. Você precisa da automação
de teste certa para agregar valor ao negócio com frequência. Daqui a um ou dois anos, você
me pergunto por que você achou que a automação de testes era tão difícil.
RESUMO
Neste capítulo, consideramos como aplicar valores, princípios e práticas ágeis para desenvolver uma
estratégia de automação. Discutimos os seguintes assuntos
relacionado à automação:
Use os quadrantes de testes ágeis para ajudar a identificar onde você precisa da automação
de testes e quando precisará dela.
A pirâmide de automação de testes pode ajudar sua equipe a fazer os investimentos certos
em automação de testes que terão maior retorno.
RESUMO 325
Aplique valores, princípios e práticas ágeis para ajudar sua equipe a obter força na automação
de testes.
Tarefas repetitivas, integração contínua e processos de construção, testes unitários, testes

funcionais, testes de carga e criação de dados são bons candidatos para automação.
Os testes do quadrante 3, como testes de usabilidade e testes exploratórios, podem se beneficiar

de alguma automação para configurar cenários de teste e analisar resultados, mas os instintos
humanos, o pensamento crítico e a observação não podem ser automatizados.
Uma abordagem simples para toda a equipe, usando feedback iterativo e dedicando tempo
suficiente pode ajudá-lo a começar a encontrar uma boa solução.
Ao desenvolver uma estratégia de automação, comece com a maior área problemática, considere
uma abordagem em várias camadas e se esforce para revisitar e melhorar continuamente
sua estratégia, em vez de alcançar a perfeição desde o início.
Considere o risco e o ROI ao decidir o que automatizar.

Reserve um tempo para aprender fazendo; aplicar práticas de codificação ágil aos testes.
Decida se você pode simplesmente criar entradas na memória ou se precisa de dados de estilo
de produção em um banco de dados.
Forneça dados de teste que permitirão que os testes sejam independentes, reexecutáveis e o
mais rápidos possível.
Atenda a necessidade de uma ferramenta por vez, identifique seus requisitos e decida que tipo
de ferramenta escolher ou construir que atenda às suas necessidades.
Use boas práticas de desenvolvimento para automação de testes e reserve um tempo para um
bom design de testes.
As ferramentas automatizadas precisam se adequar à infraestrutura de desenvolvimento da equipe.
Testes automatizados de controle de versão junto com o código de produção que eles verificam.
Um bom gerenciamento de testes garante que os testes possam fornecer documentação eficaz
do sistema e do progresso do desenvolvimento.
Comece hoje mesmo com a automação de testes.

Parte V
UMA ITERAÇÃO EM
A VIDA DE UM TESTADOR
Sempre que realizamos tutoriais, webinars ou sessões de perguntas e respostas com participantes que
são relativamente novos no desenvolvimento ágil, sempre nos fazem perguntas como
“O que os testadores fazem durante a primeira parte de uma iteração antes de qualquer coisa
pronto para testar?” ou “Onde o teste de aceitação do usuário se encaixa em uma versão ágil
ciclo?" É fácil expor teorias sobre quem deve fazer o quê e quando, em
um processo ágil, mas achamos que dar exemplos concretos de nossa própria experiência é a melhor ajuda
que podemos dar aos novatos ágeis. Através de nossas conversas com muitos
diferentes equipes ágeis, aprendemos que há muitos pontos em comum no que
funciona bem para desenvolvimento e testes ágeis.
Nesta parte do livro, acompanharemos a vida de um testador ágil ao longo de uma iteração. Na verdade,
exploraremos mais do que apenas uma iteração. Começaremos com o que
os testadores fazem durante o planejamento do lançamento ou do tema, quando a equipe analisa o trabalho
isso servirá para várias iterações futuras. Daremos exemplos do que os testadores
pode fazer para ajudar os membros da equipe a começarem a trabalhar quando iniciarem o
iteração. Mostraremos como a codificação e os testes fazem parte de um processo integrado de entrega de
software e descreveremos como testadores e programadores
trabalhar de perto e de forma incremental. Explicaremos diferentes maneiras pelas quais os testadores podem
ajudam suas equipes a permanecer no caminho certo e avaliar o progresso, incluindo abordagens úteis para
métricas e tratamento de defeitos. Veremos as atividades relacionadas aos testes envolvidas na conclusão
de uma iteração e na descoberta de maneiras de melhorar para o
o próximo. Por fim, examinaremos o papel do testador em um lançamento bem-sucedido, incluindo o jogo
final, UAT, empacotamento, documentação e treinamento.
328 PARTE V UMA ITERAÇÃO NA VIDA DE UM TESTADOR
As atividades descritas nesta visão geral dos testes ágeis podem ser realizadas por qualquer pessoa
da equipe, não apenas por especialistas em testes. Em algumas equipes,
todos os membros da equipe podem executar e realizam qualquer tarefa, seja desenvolvimento, teste,
banco de dados, infraestrutura ou outras tarefas. Para simplificar, nesta seção presumiremos que
estamos seguindo alguém cuja função principal é testar, pois ajuda a
entregar software de alta qualidade.
Capítulo 15
ATIVIDADES DO TESTER EM
LANÇAMENTO OU PLANEJAMENTO DE TEMAS
Objetivo do planejamento de lançamento

Acompanhamento de tarefas de teste
Preparando para
Comunicação de resultados de testes
Visibilidade
Métricas de lançamento Dimensionando histórias
Dimensionamento
Função do testador
Um exemplo
Plano de teste leve
Matriz de Teste
Por que priorizamos?
Plano de teste Lançamento/Tema
Planilha Priorizando
Alternativas
Planejamento Considerações de teste
Quadro branco
Lista de testes automatizados

Prazos e cronogramas
Foco no valor
O que está no escopo?

Impacto em todo o sistema
Onde começar?
Envolvimento de terceiros
Por que plano de teste?
Tipos de teste
A infraestrutura Planejamento de teste
Ambientes de teste
Dados de teste
Resultado dos testes
As equipes de desenvolvimento ágil completam histórias e entregam software pronto para produção
em cada iteração, mas planejam o panorama geral ou uma parte maior da funcionalidade com
antecedência. Um tema, épico ou projeto pode abranger várias iterações. Neste capítulo,
veremos o que os testadores fazem quando sua equipe reserva um tempo para planejar seu
lançamento. Também consideramos formas de acompanhar se o nosso desenvolvimento está a
decorrer conforme previsto ou se são necessárias correções de rumo.
329
330 CAPÍTULO 15 ATIVIDADES DE TESTER NO PLANEJAMENTO DE LANÇAMENTO OU TEMÁTICO
O OBJETIVO DO PLANEJAMENTO DE LANÇAMENTO
Um dos motivos pelos quais as equipes de software tentam o desenvolvimento ágil é porque
sabem que planos de longo prazo não funcionam. A maioria dos ambientes de negócios é
volátil e as prioridades mudam toda semana, ou mesmo todos os dias. O desenvolvimento ágil deve
evite “grande design inicial”. A maioria de nós já experimentou fazer planos que
acabou sendo um desperdício de esforço. Mas precisamos ter alguma compreensão
o que nosso cliente está procurando e como podemos entregá-lo para obter
começou bem. Felizmente, uma abordagem ágil pode tornar o planejamento uma ferramenta útil
maneira de nos dar uma vantagem inicial para saber como entregaremos o produto.
Planejamento Ágil Aplicado

A irmã de Janet, Carol Vaage, leciona na primeira série quando não está dirigindo conferências.
Ela relata sua primeira experiência com o uso de práticas ágeis para organizar uma conferência:
Minha mesa está cheia de pastas e listas de tarefas, e uma sensação de estar
sobrecarregado me deixa inativo. Sou Diretor da Conferência e a tarefa neste momento
parece onerosa. Quando minha irmã se oferece para me ajudar, eu concordo, porque estou
desesperada para controlar esse planejamento. Dou as boas-vindas a Janet em minha
bagunça, mostro a ela minhas páginas com listas escritas à mão de coisas que precisam
ser feitas, explico as enormes tarefas que aguardam minha atenção e compartilho como
meu comitê funciona.
Janet me mostrou em linguagem simples como separar cada tarefa em um post-it e usar a
coordenação de cores para diferentes responsabilidades e diferentes indivíduos. Ela
explicou sobre as colunas “To Do”, “In
Progresso”, “Para revisar” e “Concluído”. Eu nunca tinha ouvido falar da palavra iteração
antes, mas entendia perfeitamente sobre uma linha do tempo. Ela recomendou blocos de
duas semanas, mas eu escolhi iterações de uma semana. Montamos uma parede para
meu quadro de planejamento e Janet me deixou para montá-lo e adicionar as tarefas
necessárias.
Nos seis dias desde que Janet chegou aqui, dez tarefas foram movidas da coluna
Tarefas pendentes para Em andamento. Três tarefas estão concluídas e específicas
as tarefas relacionadas ao tempo foram bloqueadas pelo período correto. O mais positivo
é que à medida que adiciono mais tarefas na coluna Tarefas, não me sinto sobrecarregado.
Entendo que tudo o que preciso fazer é iniciar os passos para iniciá-lo e então o trabalho
fica mais fácil. A sensação de caos desapareceu; Vejo progresso e entendo que ainda há
muito trabalho a ser feito. O cronograma é claro, as tarefas são discretas e concretas. E a
tarefa mais difícil de todas, encontrar uma forma de coordenar a videoconferência para o
nosso orador principal, foi abordada. Este sistema funciona!
As práticas ágeis de planejamento e rastreamento são úteis para mais do que o desenvolvimento
de software. Um pouco de tempo cuidadosamente investido e ferramentas simples usadas na
organização e planejamento das atividades de teste e recursos para um lançamento ajudarão
a equipe a entregar software de alta qualidade.
O OBJETIVO DO PLANEJAMENTO DE LANÇAMENTO 331
As equipes XP podem levar um dia a cada poucos meses para planejar o lançamento. Outras
equipes ágeis fazem planejamento antecipado quando se preparam para iniciar um tema, épico
ou recurso importante, que consideramos um grupo relacionado de histórias. Eles trabalham
para entender o tema ou lançamento em alto nível. Qual é a visão do cliente sobre o que
deveríamos entregar? Qual é o propósito do lançamento? Qual é o panorama geral? Que valor
isso agregará ao negócio, aos clientes?
Que outras equipes ou projetos estão envolvidos e requerem coordenação? Quando acontecerá
o UAT? Quando o código será liberado para teste, para produção?
Quais métricas precisamos saber se estamos no caminho certo? Essas questões gerais são
abordadas no planejamento do lançamento.
Algumas equipes não gastam muito tempo realizando atividades de planejamento de

lançamento. As prioridades mudam rapidamente, mesmo dentro de um determinado tema de
recursos. Ninguém quer fazer muito trabalho inicial que acaba sendo desperdiçado. Algumas
equipes apenas olham as primeiras histórias para ter certeza de que podem começar a correr.
No mínimo, as equipes querem saber o suficiente para direcionar a arquitetura do sistema na
direção certa e começar as primeiras histórias.
Essas reuniões de planejamento não têm como objetivo planejar detalhadamente cada iteração
do lançamento. E sabemos que não podemos prever exatamente quantas histórias podemos
completar em cada iteração. Porém, temos uma ideia da nossa velocidade média, para que
possamos ter uma ideia geral do possível alcance do lançamento. A equipe fala sobre os
recursos e histórias, tentando obter uma visão geral do que pode acontecer no lançamento e
quantas iterações serão necessárias para ser concluído.
Nós dois gostamos da abordagem de Mike Cohn para o planejamento de lançamentos em seu
livro Agile Estimating and Planning [2005]. As histórias que a empresa deseja incluir são
dimensionadas umas em relação às outras e, em seguida, os recursos são priorizados de
acordo com o valor que agregam. A equipe pode identificar “fatias finas” através dos recursos
para determinar quais histórias realmente precisam ser feitas, o que está no escopo, quais
“coisas interessantes” podem ser adiadas para mais tarde. Eles analisam as dependências
entre histórias, o risco relativo e outros fatores que determinam a ordem em que os recursos
devem ser codificados. A ordem em que as histórias são codificadas é tão importante, ou às
vezes mais importante, que o tamanho das histórias. As equipes desejam agregar valor na
primeira iteração do lançamento.
O planejamento de lançamento é uma oportunidade para os desenvolvedores e clientes

considerarem o impacto dos recursos planejados no sistema maior, esclarecer suposições e
observar as dependências que podem afetar quais histórias serão feitas primeiro. Eles podem
pensar em testar em alto nível e se serão necessários novos recursos, como ambientes de
teste e software.
Vamos acompanhar nossa testadora ágil nas atividades de planejamento de lançamento e ver
como ela agrega valor por meio de sua perspectiva e foco únicos.
DIMENSIONAMENTO
As equipes ágeis estimam o tamanho relativo de cada história. Algumas equipes dimensionam à
medida que avançam, atrasando a estimativa até a iteração em que realmente concluirão a história.
Outros realizam reuniões para estimar histórias antes mesmo do planejamento do lançamento.
Algumas equipes de desenvolvedores e clientes se reúnem para escrever e estimar o tamanho
das histórias de uma só vez. O objetivo do dimensionamento é que os programadores dêem ao
negócio uma ideia do custo de cada história e os ajudem a priorizar e planejar as primeiras
iterações. Equipes de alto desempenho que trabalham juntas há anos podem adotar uma
abordagem menos formal. Para novas equipes ágeis, aprender a dimensionar histórias exige muita
prática e experiência. Não é importante dimensionar cada história corretamente, mas estar próximo
o suficiente para dar aos clientes uma ideia do tamanho das histórias, para que possam priorizar
com melhores informações. Com o tempo, as variações no tamanho das histórias individuais
diminuirão e descobriremos que um tema ou grupo relacionado de histórias leva aproximadamente
o tempo esperado.
Como dimensionar histórias
No que diz respeito ao cálculo do tamanho da história, equipes diferentes usam técnicas diferentes,
mas, novamente, gostamos da abordagem de Mike Cohn para determinar o tamanho da história.
Dimensionamos em pontos da história, dias ideais ou simplesmente “pequeno, médio, grande”. O
tamanho relativo de cada história em relação às outras é o fator importante. Por exemplo, adicionar
um campo de entrada a uma interface de usuário existente é obviamente muito menor do que
desenvolver uma tela totalmente nova do zero.
Se a empresa conhece a velocidade média (o número de pontos da história que a equipe conclui
em cada iteração) e tem as estimativas iniciais do tamanho de cada história que deseja concluir,
ela tem uma ideia de quanto tempo pode levar para implementar um determinado tema. Tal como
acontece com qualquer outra metodologia de desenvolvimento, não há garantias, porque as
estimativas são apenas isso. Ainda assim, a empresa pode planejar bem o suficiente para conduzir
suas atividades habituais.
Nossas equipes usam o pôquer de planejamento (explicado no livro Agile Estimat-ing and
Planning, de Mike Cohn ) para estimar o tamanho da história. No planejamento do pôquer, cada
membro da equipe tem um baralho de cartas. Cada carta contém um número de pontos. O
processo começa com o cliente ou proprietário do produto lendo uma história e explicando seu
propósito e o valor que ela agregará. Ele pode listar algumas condições de satisfação ou casos
de teste de alto nível. Após uma breve discussão, cada membro da equipe segura um cartão que
representa o quão “grande” eles acham que a história é da sua perspectiva. Eles discutem
quaisquer grandes diferenças no valor dos pontos e estimam novamente até chegarem a um
consenso. A Figura 15-1 mostra os membros da equipe falando sobre
DIMENSIONAMENTO
333
Figura 15-1 Planejando o pôquer
os valores de pontos que cada um deles acabou de exibir. Este precisa ser um processo rápido -
longas discussões sobre detalhes não resultam em estimativas de tamanho mais precisas.
Algumas equipes calculam o tamanho relativo das histórias com base no número de pessoas necessárias
para completar uma determinada história em um determinado período de tempo. Outros estimam quantos
dias ideais que uma pessoa precisaria para terminá-lo. Use uma medida que faça
sentido para todos os membros da equipe e que forneça consistência entre as estimativas.
O papel do testador nas histórias de dimensionamento
Um dos nossos ditados favoritos é: “Nenhuma história está pronta até ser testada”. No entanto,
encontramos equipes onde os testes não foram incluídos nas estimativas do tamanho da história.
Em alguns casos, testar uma funcionalidade pode demorar mais do que codificá-la.
Em nossa experiência, os testadores geralmente têm um ponto de vista diferente do de outras equipes
membros. Eles geralmente têm um amplo conhecimento do domínio e podem
identificar rapidamente “efeitos em cascata” que uma história pode ter no resto do
sistema. Eles também tendem a pensar em atividades não diretamente relacionadas ao desenvolvimento
que talvez precisem ser realizadas, como treinar usuários em um ambiente novo ou alterado.
interface.
A história de Lisa
O que um testador faz durante o processo de dimensionamento da história? Penso rapidamente na
história de vários pontos de vista. Que problema de negócios a história está resolvendo ou que valor de
negócios ela agrega? Se isso não estiver claro, faço perguntas ao proprietário do produto.
Como o usuário final realmente usará o recurso? Se ainda não estiver claro, peço ao proprietário do
produto um exemplo rápido. Posso perguntar: “Qual é a pior coisa que pode dar errado nisso?” Essa
abordagem negativa ajuda a avaliar o risco da história. Quais considerações de teste podem afetar o
tamanho da história? Se for difícil obter dados de teste ou se a história envolver terceiros, o teste
poderá demorar mais do que a codificação. Tento eliminar rapidamente quaisquer suposições
ocultas. Existem dependências ou riscos especiais de segurança? Esta parte do aplicativo precisará
lidar com uma grande carga?
Muitas histórias não são grandes o suficiente para justificar tanta reflexão. Geralmente, nós não
precisa de muitos detalhes para ter uma ideia do tamanho relativo. No entanto, sua equipe pode
realmente se queimar se uma história for subestimada por um fator de cinco ou dez. Certa vez, demos
uma estimativa relativamente pequena para uma história que acabou sendo pelo menos dez vezes maior.
Estes são os desastres que queremos evitar fazendo boas perguntas.
—Lisa
Os testadores precisam fazer parte do processo de dimensionamento. Algumas equipes pensam que
apenas os programadores deveriam participar, mas quando os testadores são participantes ativos, eles
pode ajudar a obter um dimensionamento de história muito mais preciso, o que é do interesse de toda
a equipe.
Um exemplo de histórias de dimensionamento
Vamos imaginar que temos a história da Figura 15-2 para avaliar.
História PA-3
Como comprador em nosso site, quero excluir itens
fora do meu carrinho de compras para não comprar
itens extras que eu decido que não quero.
Figura 15-2 História para excluir itens

DIMENSIONAMENTO 335
Depois que o proprietário do produto lê a história, segue-se a seguinte discussão:
Dono do produto: “Queremos apenas uma maneira fácil para os usuários excluirem itens, mas
não temos uma implementação específica em mente.”
Testador: “Eles deveriam ser capazes de excluir vários itens de uma vez?”
Dono do produto: “Ah, sim, apenas torne isso o mais fácil possível.”
Testador: “E se eles excluirem acidentalmente um item que queriam comprar?”
Dono do produto: “Existe alguma maneira de salvar os itens excluídos para recuperação
posterior?”
Programador: “Claro, mas você deveria escrever uma nova história para isso. Por enquanto,
devemos começar com a funcionalidade básica de exclusão.”
Testador: “Na última versão, implementamos um recurso de lista de desejos. Você deseja que
os usuários possam mover itens do carrinho de compras para a lista de desejos? Essa também
seria uma nova história.”
Product Owner: “Sim, essas são mais duas histórias que queremos fazer, com certeza. Vou
anotá-los, podemos dimensioná-los também. Mas definitivamente poderíamos adiá-los até o próximo
lançamento, se for necessário.”
Testador: “Qual é a pior coisa que pode acontecer com esse recurso?”
Dono do produto: “Se eles não conseguirem descobrir como excluir, podem simplesmente
abandonar todo o carrinho de compras. Tem que ser muito fácil e óbvio.”
O ScrumMaster pede uma estimativa. A equipe entende que está dimensionando

apenas a história básica para excluir itens, não para fazer outra coisa com o
itens deletados. Eles rapidamente concordam com o valor dos pontos.
Vejamos outra história. (Veja a Figura 15-3.)
História PA-4
Como cliente, quero saber quanto meu
o pedido custará para enviar com base no frete
velocidade que escolho para poder escolher uma diferente
velocidade de envio se eu quiser.
Figura 15-3 História sobre velocidade de envio

Testador: “Quais são as velocidades de envio que o usuário pode escolher?”
Proprietário do produto: “Padrão 5 dias, 2 dias e dia seguinte.”
Programador: “Provavelmente deveríamos começar oferecendo apenas uma velocidade

e calculando esse custo. Então poderemos implementar facilmente as outras duas
velocidades.”
Dono do produto: “Não há problema em dividir assim.”
Testador: “Usaremos a API do BigExpressShipping para calcular o custo com base no

peso e no destino?”
Programador: “Isso seria o mais fácil.”
A equipe mostra suas cartas de pontos. O testador e um dos programadores

segure um 8; os outros desenvolvedores seguram um 5.
ScrumMaster: “Por que vocês dois escolheram 8?”
Testador: “Nunca usamos a API de custo do BigExpressShipping antes e não tenho

certeza de como isso afetará nossos testes. Temos que descobrir como acessar o sistema
deles para testes.”
Outro programador com 8: “Concordo, acho que o esforço de teste é mais intenso do
que o esforço de codificação para esta história.”
A equipe concorda em dimensionar a história em oito pontos.
Esse processo de dimensionamento pode ocorrer antes da reunião de planejamento e, se as

histórias foram dimensionadas ou estimadas há muito tempo, a equipe pode querer fazer
certeza de que eles se sentem confortáveis com o tamanho das histórias. As equipes podem ter mudado ou
pode ser mais experiente. Qualquer um desses fatores pode fazer uma mudança de equipe
as estimativas.
Muitas vezes uma história terá um grande componente de teste, e

o esforço de codificação é pequeno. Outras vezes, o inverso será verdadeiro. É importante
considerar todas as perspectivas.
DIMENSIONAMENTO
337
A história de Lisa
Nossa equipe começou a temer as reuniões de dimensionamento de histórias, porque entrávamos
em discussões muito longas sobre detalhes, e as reuniões sempre duravam muito além do horário
programado. Desde então, nosso ScrumMaster encontrou maneiras de nos manter no caminho certo.
Ela usa um cronômetro para cronometrar as discussões e as interrompe cada vez que a areia acaba
para ver se achamos que realmente precisamos de mais tempo para fazer perguntas. Nosso proprietário
do produto também aprendeu quais informações precisamos para fazer estimativas e geralmente
tem o que precisamos. Também aprendemos a trabalhar apenas em histórias que provavelmente
surgirão nas próximas iterações.
Com todas as nossas reuniões, pequenas tradições cresceram para torná-las mais divertidas. Alguém
sempre traz guloseimas para reuniões de planejamento de iteração. Nas reuniões em pé,
passamos uma combinação de lanterna e apontador laser, para que cada um de nós a segure
enquanto relatamos no que estamos trabalhando. Sempre terminamos as reuniões de avaliação de
histórias com uma competição para ver quem consegue jogar seu baralho de cartas de pôquer na
pequena banheira de plástico onde moram. A Figura 15-4 mostra essa atividade boba, mas divertida,
de encerramento de reunião. Lembre-se sempre do valor ágil da diversão e divirta-se em suas
reuniões.
—Lisa
Figura 15-4 Uma tradição de encerramento de reuniões

PRIORIZANDO
O objetivo da reunião de planejamento de lançamento também é ter uma ideia do que
histórias que a equipe tentará terminar até a data de lançamento. Os clientes priorizam
as histórias, mas pode haver dependências, então faz sentido fazer certas
histórias primeiro, mesmo que não sejam a prioridade mais alta. É importante que o
a equipe entende a possibilidade de que nem todas as histórias sejam concluídas
até a data de lançamento. Uma das premissas básicas do ágil é entregar trabalho
software, por isso é importante ter as histórias de maior valor concluídas primeiro
para que o software que entregamos atenda às necessidades do cliente.
Por que priorizamos histórias

O objetivo de todos é entregar valor real em cada iteração. Os testadores podem ajudar o
a equipe escolhe a funcionalidade principal que deve funcionar. No Capítulo 8, explicamos o conceito de
“fatia fina” ou “fio de aço”, identificando um caminho através
a funcionalidade para codificar e testar primeiro e adicionar mais recursos após o primeiro
caminho crítico funciona. Este conceito também se aplica no nível de lançamento. A ordem de
as histórias são críticas. A equipe de Lisa às vezes interrompe uma história e retira
uma parte central de um recurso a ser executado na primeira iteração.
Algumas equipes que não fazem um planejamento de lançamento completo reservam tempo para analisar
as histórias e decidir quais duas ou três devem ser as primeiras. Dessa forma, eles agregam valor
comercial logo na primeira iteração do lançamento.
Vejamos um exemplo.
Se nosso tema for fornecer a capacidade de um comprador on-line escolher

opções de envio e, em seguida, calcular o custo de envio com base no peso,
velocidade de envio e destino, pode ser uma boa ideia completar histórias simples ou até
mesmo subconjuntos de histórias para que o processo de checkout possa prosseguir de
ponta a ponta. Comece permitindo apenas itens com envio padrão de 5 dias
menos de 10 libras e destinos no território continental dos Estados Unidos.
Quando o usuário puder obter o custo de envio para esse cenário e finalizar a compra,
a equipe pode decidir as próximas prioridades. Eles podem incluir peso pesado
itens, velocidades de envio mais rápidas, envio para o Havaí e Alasca e envio para Canadá
e México.
Ao fornecer essa fatia fina primeiro, os testadores têm algo para começar a testar
imediatamente. Os programadores também testaram suas etapas de design e integração de código e,
portanto, têm uma ideia sólida de como as coisas funcionarão quando o todo
recurso está completo.
PRIORIZANDO 339
Considerações de teste durante a priorização

É importante que a equipe compreenda o panorama geral ou o tema. Em nosso exemplo, os membros
da equipe conhecem as histórias de remessas fora do continente
Os Estados Unidos virão mais tarde. Esse conhecimento pode afetar o modo como eles implementam a
primeira história. Isso não significa que eles tenham que se planejar para todas as eventualidades, mas
se souberem que precisam de mais opções de envio, poderão implementar um
lista suspensa em vez de um campo de texto básico. Não há necessidade de fazer mais trabalho ou
retrabalho do que o necessário.
Durante o planejamento do lançamento, também consideramos o risco relativo das histórias. Se

certas histórias têm muitas incógnitas, talvez seja melhor incluí-las em um
iteração inicial, então há tempo para se recuperar se uma história “explodir” e demorar muito
mais tempo do que o estimado. O mesmo pode aplicar-se a uma história que, se não for concluída ou
implementada incorretamente, teria um impacto negativo dispendioso.
Agendar com antecedência deixará mais tempo para testes.
Se for necessária nova tecnologia ou software, pode ser bom aprendê-los desenvolvendo uma história
simples e planeando histórias mais difíceis para iterações posteriores. Esta nova tecnologia pode ou não
afetar a automação de seus testes. Você
talvez precise de mais tempo para verificar o impacto. Se os recursos forem todos de marca
novo e a equipe precisa de mais tempo para entender como deve funcionar,
planeje fazer menos do que sua velocidade média na primeira iteração. Dessa maneira,
você terá mais tempo para escrever testes que orientarão corretamente o desenvolvimento.
Identifique os riscos e decida qual abordagem faz mais sentido em um teste
perspectiva, bem como uma perspectiva de desenvolvimento. Esta é uma das razões
é importante incluir toda a equipe nas sessões de planejamento.
Observar as histórias do ponto de vista dos testes é essencial. É aqui que

os testadores agregam mais valor. A equipe precisa desenvolver em pequenos e testáveis
pedaços para ajudar a decidir quais histórias estão provisoriamente planejadas para quais
iteração. A chave aqui é testável. Muitas novas equipes ágeis pensam em pequenos pedaços
significa fazer todo o trabalho do banco de dados primeiro ou todo o material de configuração.
Testável também não significa necessariamente que precise de uma GUI. Por exemplo, o algoritmo que
calcula o custo de envio é um trecho de código independente que
pode ser testado independentemente de qualquer interface de usuário, mas requer testes extensivos.
Essa pode ser uma boa história para a primeira iteração. Ele pode ser testado como código independente
e posteriormente testado em combinação com a UI e outros
partes do sistema.
Os testadores podem fazer lobby para obter um marcador ponta a ponta através do
código rapidamente, para que possam construir uma estrutura de automação e, em seguida, concretizá-la
à medida que o desenvolvimento da história prossegue. Se há histórias que apresentam um grande

desafio de teste, pode ser bom fazê-lo logo no início. Por exemplo, se o
lançamento inclui a implementação de uma nova ferramenta de terceiros para criar documentos
de modelos e dados dinâmicos, há muitas permutações para testar. Se o
não estiver familiarizada com a ferramenta, os testadores podem pedir à equipe que considere
fazer essas histórias na primeira iteração do lançamento.
O QUE ESTÁ NO ESCOPO?
As equipes ágeis gerenciam continuamente o escopo para cumprir os prazos de negócios

preservando a qualidade. Histórias de alto valor são a primeira prioridade. Histórias que
são “agradáveis” podem ser excluídos do lançamento.
Os clientes de nossa equipe listam suas histórias em ordem de prioridade e depois traçam uma
A história de Lisa
linha entre as histórias que devem ser feitas antes que o lançamento possa ocorrer e aquelas que
poderiam ser adiadas com segurança. Eles chamam as histórias menos importantes de “abaixo da linha”,
e essas histórias podem nunca ser concluídas.
Por exemplo, quando abordamos o tema para permitir que participantes de planos de aposentadoria
tomassem dinheiro emprestado de suas contas de aposentadoria, havia uma situação “abaixo da linha”
story para enviar e-mails a quaisquer participantes cujos empréstimos estejam mudando de status para
“inadimplência pendente” ou “inadimplência”. Quando o empréstimo está em situação de
“inadimplência”, o mutuário deve pagar impostos e multas sobre o saldo. O e-mail seria extremamente
útil para os mutuários, mas não era tão importante para o nosso negócio quanto o software para
solicitar, aprovar e distribuir empréstimos ou processar pagamentos de empréstimos.
A história do e-mail não foi incluída no lançamento. Isso só foi feito mais de dois anos depois, depois de
reclamações suficientes de pessoas que não sabiam que seus empréstimos iriam entrar em
inadimplência até que fosse tarde demais.
—Lisa
Janet trabalhou com uma equipe cujos clientes tinham a suposição equivocada de que todos os
recursos seriam incluídos no lançamento e que, quando
eles estavam priorizando, apenas escolhendo quais histórias seriam feitas primeiro.
Quando o resto da equipe percebeu o mal-entendido, eles também implementaram a ideia de
histórias acima e abaixo da linha. Ajudou a acompanhar o progresso
bem como tornar as histórias que foram colocadas abaixo da linha muito visíveis.
Prazos e cronogramas
Muitos domínios giram em torno de datas fixas no calendário. Negócios de varejo

obter a maior parte de seu lucro durante a temporada de férias. Um site de varejo na Internet é
inteligente ter todos os novos recursos implementados até 1º de outubro.
O QUE ESTÁ NO ESCOPO? 341
novo recurso próximo ao período de pico de compras é arriscado. Os clientes da empresa de

Lisa devem concluir tarefas exigidas pelo governo durante determinados períodos de
o ano. Quando é tarde demais para um recurso ser lançado este ano, muitas vezes ele fica
adiar para o próximo ano, porque é necessário abordar prioridades mais urgentes.
As mudanças regulatórias têm cronogramas específicos e as organizações não têm escolha
sobre a linha do tempo.
Enquanto trabalhava neste livro, planejei um lançamento com minha equipe na WestJet. Tínhamos
diversas histórias possíveis e trabalhamos com os clientes para decidir como seria o lançamento.
Tivemos uma mudança regulatória que foi um trabalho leve para os programadores, mas pesado para
os testadores. Precisava estar em produção até uma determinada data, então as outras histórias que
estávamos considerando para o lançamento levaram isso em consideração.
Decidimos criar uma pequena versão de manutenção com apenas um recurso importante, junto com
alguns bugs do backlog para que a liberação da mudança regulatória não fosse prejudicada.
Enquanto os testadores concluíam os testes, o restante da equipe iniciava algumas histórias de
elaboração para o próximo lançamento.
Um plano alternativo poderia ter sido que os programadores participassem e ajudassem a testar e
instalar mais recursos. No entanto, toda a equipe decidiu que esse plano funcionaria melhor com o
menor risco.
—Janet
Foco no valor
É muito fácil para uma equipe começar a discutir uma história complexa e perder de vista
qual valor os recursos realmente oferecem. O planejamento de lançamento é a hora de começar
pedindo exemplos e casos de uso de como os recursos serão usados e o que
valor que eles fornecerão. Desenhar fluxogramas ou exemplos de cálculos no quadro branco
pode ajudar a identificar a funcionalidade principal.
Nosso proprietário do produto escreveu uma história para fornecer um aviso caso um empregador
A história de Lisa
anule a data em que um participante se torna elegível para contribuir para uma conta de
aposentadoria depois que o participante já tiver feito contribuições.
O aviso precisava ser incorporado ao código da UI legado, o que não

acomodá-lo facilmente. A equipe discutiu como isso poderia ser implementado, mas todas as opções
eram bastante caras. A codificação não apenas seria complicada, mas também seria necessário muito
tempo para testá-la adequadamente e atualizar os testes automatizados existentes. Esse recurso não
agregaria muito valor ao negócio, apenas um pouco de ajuda aos usuários finais. O lançamento já
estava bem próximo do limite de recursos.
Um dos programadores sugeriu fornecer um relatório dos participantes que atendiam aos critérios
para que os administradores do plano pudessem simplesmente ligar para os empregadores que poderiam
preciso fazer correções. A história do relatório era muito menor que a história de advertência, cabia
facilmente no comunicado e era aceitável para o cliente.
—Lisa
Não há garantia de que essas “estimativas” iniciais sobre o que acontecerá em um

determinada liberação se manterá ao longo do tempo. É por isso que os clientes precisam compreender
as suas prioridades, realizar verificações no final de cada iteração e reavaliar as prioridades das histórias
restantes.
Impacto em todo o sistema
Um de nossos trabalhos como testadores é manter o panorama geral em mente. O testador ágil
Conversamos sobre
pensa em como cada história pode afetar o sistema como um todo, ou outros sistemas com os quais o
os “efeitos em cascata”
no Capítulo 8, “Testes nosso tenha que trabalhar. Por exemplo, se o armazém de brinquedos fizer um
voltados para mudança em seu software de inventário, e o novo código tem um bug que exagera
negócios que apoiam
o número de itens em estoque, o site pode vender mais da nova boneca
a equipe”.
do que os disponíveis, decepcionando milhares de crianças e seus pais no Natal. Quando o risco é alto,
listar as áreas do sistema que podem ser
afetado por um tema ou grupo de histórias pode ser um exercício válido, mesmo
durante o planejamento da versão.
Pontos de contato entre nosso sistema e o de parceiros ou fornecedores sempre

consideração de mérito. Mesmo uma pequena alteração em um formato de arquivo csv ou xml pode
terá um impacto enorme se não o comunicarmos corretamente aos parceiros que usam FTP
arquivos para nós. Histórias que significam mudanças para terceiros precisam ser feitas com antecedência
o suficiente no ciclo de lançamento para permitir que terceiros façam as alterações necessárias.
A Figura 15-5 mostra um diagrama simplificado de um novo sistema que abrange muitos
partes do sistema existente. Diferentes ferramentas podem ser necessárias para testar o
integrações.
Testadores que trabalharam com alguns dos outros sistemas ou entendem o que
os testes precisam acontecer nesses sistemas podem oferecer informações valiosas sobre o
impacto de uma nova história. Freqüentemente, as histórias precisarão ser adiadas até um lançamento
futuro se o impacto não tiver sido explorado. Este é um bom momento para relembrar lançamentos
anteriores que não terminaram tão bem.
Envolvimento de terceiros
Trabalhar com ferramentas de fornecedores, parceiros ou outras equipes terceirizadas em um grande

projeto complica o planejamento de lançamento. Se alguém fora da sua equipe for responsável por
alguma parte do projeto, essa é uma parte que está fora do seu controle. Se
O QUE ESTÁ NO ESCOPO? 343
abc
Sistema
Perfis
(NS Ferramenta 1)
Padrão
SEIVA
Relatórios
A sobrecarga
(NS Ferramenta 2)
Legado Gás
Sistema Sistema
Novo
Sistema
Rede
seguro médico obrigatório
Relatórios
Combustível Conversão
Sistema (NS Ferramenta 3)
Figura 15-5 Impactos no sistema
Se você precisar coordenar com outras pessoas, incluindo possíveis novos usuários do
sistema, é melhor começar cedo.
A equipe de Lisa escreveu diversas interfaces para permitir que os usuários carreguem dados
em seus sistemas. Em cada caso, eles tiveram que entregar o formato de arquivo proposto
aos usuários com antecedência para ter certeza de que funcionaria para eles. Outros
projetos envolviam o envio de dados a parceiros ou fornecedores. Eles exigiram planejamento
extra para organizar testes com seus sistemas de teste e obter feedback sobre se os dados
eram válidos e formatados corretamente.
Se você estiver usando um produto de terceiros como parte de sua solução, poderá presumir
que ele foi testado, mas isso pode ser uma suposição errada. Você precisará reservar mais
tempo para testar seu aplicativo em conjunto com o software do fornecedor. Se houver um
problema no software da outra empresa, poderá levar muito tempo para ser resolvido. A
equipe de Lisa usa software de terceiros para tarefas críticas, como criação de documentos.
Se um tema incluir modificação ou criação de novos documentos, eles planejam tempo extra
para atualizar o software, se necessário, e tempo extra
tempo para testes caso sejam necessárias correções. Se possível, traga o terceiro
software no projeto antecipadamente e iniciar os testes de ponta a ponta. Quanto mais você
puder trabalhar com a interface, melhor para você.
Outro software de terceiros que muitas vezes esquecemos até que seja tarde demais é o nosso
próprios ambientes de teste. Às vezes, uma equipe incorpora um novo código que
aproveita os novos recursos no idioma escolhido. Por exemplo, se
membros da equipe estão usando AJAX ou JavaScript, eles podem precisar atualizar o
kit de desenvolvimento de software que eles estão usando. Isso significa que uma equipe terá que
atualize também seu ambiente de tempo de execução de produção, portanto, leve isso em
consideração e teste o quanto antes.
Clientes ou parceiros podem ter preocupações sobre um lançamento que não está dentro do seu
escopo da própria equipe. A equipe de Lisa uma vez foi impedida no último minuto
de lançar um novo recurso porque um parceiro não teve tempo de aprovar o
alteração com seus assessores jurídicos. Os programadores tiveram que criar rapidamente um
maneira de desativar a funcionalidade sem exigir testes adicionais extensivos. Curiosamente, os
parceiros que não usam o desenvolvimento ágil às vezes
têm dificuldade em cumprir seus próprios prazos. Eles podem estar despreparados quando
sua equipe cumpre o prazo.
A história de Janete Trabalhei em um projeto para implementar um recurso que exigia um novo hardware
para digitalizar um novo código de barras 2D. A equipe decidiu implementar em etapas
porque não se sabia quando os scanners estariam disponíveis para testes completos,
mas o cliente queria o código pronto para quando os scanners chegassem.
A fase inicial exigiu muita programação porque havia muita pesquisa a ser feita. Depois
de determinarem como implementariam o recurso, a história foi criada para adicioná-lo
ao código. No entanto, sabíamos que não poderíamos testá-lo completamente até que
os scanners estivessem disponíveis. O código estava pronto para teste, mas em vez de
voltar atrás, só precisávamos nos preocupar em testar se o recurso poderia ser
desativado para o lançamento. A próxima versão exigiria mais testes, mas apenas se
os scanners estivessem disponíveis. O teste da história foi mantido no backlog do
produto para que não nos esquecêssemos de fazê-lo.
—Janet
Se você estiver trabalhando com outras equipes desenvolvendo diferentes componentes do

mesmo sistema, ou sistemas relacionados, reservem tempo para coordenar com eles. É um
É uma boa ideia designar um membro de cada equipe para coordenar.
O planejamento de lançamento é o momento de identificar funções extras que você precisa em

sua equipe, recursos adicionais e tempo necessário para circunstâncias fora do comum.
PLANEJAMENTO DE TESTE 345
PLANEJAMENTO DE TESTE
Não podemos esperar planejar as iterações em um lançamento em nível detalhado. Pudermos

Capítulo 8,
ter uma ideia dos fios de aço do tema, priorizar histórias e adivinhar
"Relacionado aos Negócios
Testes que apoiam a quais histórias estarão em qual iteração. O planejamento detalhado dos testes precisa esperar
equipe”, explica para planejamento de iteração. Ainda assim, precisamos pensar em testar em alto nível,
como identificar fios
e tente reservar tempo suficiente para isso. Podemos até tirar um tempo separadamente
de aço ou fatias
finas em uma história da reunião de planejamento de lançamento para traçar estratégias para nossos testes para o lançamento. Em
ou tema. Capítulo 8, Testes voltados para negócios que apoiam a equipe, mencionamos um
dos perigos dos testes ágeis: “esquecer o panorama geral”. O Planejamento de Teste
ajudá-lo com esse problema.
Onde começar
Durante o planejamento do lançamento, é útil conhecer as condições comerciais de satisfação para cada
história ou caso de teste de aceitação do usuário de alto nível. Quando histórias
precisam de esclarecimentos, os testadores ágeis pedem exemplos. Nesta fase, serão apresentados exemplos
ser de alto nível, abrangendo apenas o básico, mas o suficiente para poder dimensionar e priorizar a história.
Desenhar fluxogramas ou escrever cálculos no quadro branco e discuti-los nos ajuda a identificar problemas
de teste específicos do projeto.
No mínimo, a equipe precisa entender as histórias de maior prioridade que são

programado para ser executado primeiro. Um planejamento leve pode envolver apenas
olhando para essas histórias principais com a compreensão de que mais tempo será necessário
necessários para definir testes adicionais.
À medida que tivermos uma noção de quais histórias provavelmente serão incluídas no lançamento,
pode começar a pensar sobre o escopo dos testes. Quais suposições
foram feitas que possam afetar os testes? O uso de software de terceiros, como o
exemplo de uso da API de cálculo de frete de uma empresa de transporte, afeta o teste
planejamento. Há algum risco incomum nesta versão que afetará os testes?
Se tivermos histórias para implementar trabalhos em lote e nunca tivemos nenhum trabalho em lote
processamento no sistema antes, provavelmente existem novas estruturas que impactam os testes.
Precisamos reservar tempo para aprendê-los.
Por que escrever um plano de teste?
No planejamento do lançamento, falamos sobre o propósito do lançamento, o que está no escopo,

e quais suposições estamos fazendo. Fazemos algumas análises rápidas de risco e
planejar nossa abordagem de teste para lidar com esses riscos. Consideramos automação e
o que precisamos para ambientes de teste e dados de teste. Certamente queremos identificar marcos e
resultados. Hmmm, isso está começando a parecer. . . a
Plano de teste!
Se, como nós, você passou algum tempo trabalhando em um ambiente tradicional em cascata, você
pode ter perdido tempo escrevendo planos de teste volumosos que ninguém leu
“Transição
Processos Típicos,” e ninguém se preocupou em manter. No desenvolvimento ágil, queremos que nosso teste
para mais sobre planos para atender às nossas necessidades. Seu cliente pode exigir um plano de teste para cada
planos de teste e liberação por motivos de conformidade. Mesmo que não seja uma entrega obrigatória, pode ser
estratégias de teste.
útil. Mantenha-o conciso e leve. Só precisa servir aos seus propósitos
durante este lançamento. Resolva os problemas de teste específicos desta versão
ou projeto. Inclua sua análise de risco e identifique suposições. Descreva o
fatores críticos de sucesso que seu cliente identificou. Pensar sobre o que
as pessoas precisam saber em relação aos testes e remover qualquer coisa estranha.
Mesmo que você não crie um plano de teste formal, certifique-se de anotar todos
esses diferentes fatores de teste envolvidos no lançamento. Você vai querer mantê-los
em mente durante cada sessão de planejamento de iteração. O maior benefício no teste
o planejamento é o próprio planejamento. Ele permite que você considere e resolva problemas
como requisitos de dados de teste, infraestrutura ou até mesmo quais resultados de teste são
necessários. O planejamento de testes é uma estratégia de mitigação de riscos. Vamos considerar alguns destes
problemas.
Tipos de teste
Na Parte III, cobrimos os quatro quadrantes do teste e falamos sobre todos
os diferentes tipos de testes que você pode fazer durante seu projeto. O planejamento da versão é um
bom momento para considerar essas diferentes necessidades. Você precisa planejar
trazer uma ferramenta de teste de carga ou será necessário construir algum tipo de equipamento de
teste especializado?
Pode ser que o seu próximo lançamento seja apenas uma extensão do anterior, e você
continuará criando seus exemplos, automatizando seus testes de história e
fazendo o resto dos testes como você está fazendo. Você é um dos sortudos
uns. Para aqueles que estão iniciando um novo projeto sem nenhum
processos em vigor, agora é a hora de considerar quais testes você precisará. Nós
não significa que você tenha que decidir como testar cada história, mas observe o panorama geral e
pense nos quadrantes. Você precisará planejar um UAT especial,
ou as demonstrações de iteração serão suficientes? É importante levantar essas questões
cedo para que a equipe possa planejá-los.
A infraestrutura
Enquanto você planeja o teste, você precisa considerar sua infraestrutura. Infraestrutura pode significar
sua configuração de integração contínua, teste
ambientes e banco de dados de teste. Pode significar como você promove suas construções
para seus ambientes de teste. Pode significar seu laboratório de testes, se você tiver um, ou
ter um servidor separado para executar todos os seus testes de automação. Estes são geralmente
peças de infraestrutura que precisam de algum tempo para serem implementadas. Isto é o
hora de fazer um plano.
A história de Lisa
Alguns tipos de testes podem exigir esforço extra. Minha equipe tinha uma ferramenta para fazer
testes de desempenho e alguns scripts, mas faltava um ambiente de estilo de produção onde
pudéssemos controlar todas as variáveis que poderiam afetar o desempenho. Por exemplo, o
banco de dados de teste foi compartilhado por testadores, programadores e dois processos de
construção. Um desempenho mais lento pode simplesmente significar que alguém estava
executando testes com uso intensivo de banco de dados. Usamos nosso ambiente de teste para
obter uma linha de base, mas faltavam alguns componentes de produção. Estabelecemos uma
meta de seis meses para adquirir hardware e software para um ambiente de teste adequado e
configurá-lo. Escrevemos um ou dois cartões de tarefas a cada iteração para estabelecer o ambiente passo a p
—Lisa
Quaisquer que sejam suas necessidades, certifique-se de entendê-las e poder planejar

o que você precisa. Se não tivermos a infra-estrutura adequada, desperdiçaremos
tempo tentando juntá-lo e causar um gargalo no meio da iteração.
Ambientes de teste
Ao observarmos os tipos de recursos na próxima versão, poderemos ver a necessidade
para um ambiente de teste totalmente novo. Pense em ambientes de teste especializados
você também pode precisar. Você precisará de mais ferramentas? Você precisa expandir seu
laboratório de testes para que você possa testar com diferentes navegadores e sistemas operacionais?
Este é o momento de pensar em todas as considerações de teste.
Se você estiver planejando seu primeiro lançamento, os ambientes de teste são uma consideração
importante. Você pode precisar de uma história ou iteração apenas para configurar a infraestrutura que deseja
precisar. Iniciamos mais de um projeto onde o único lugar onde pudemos testar
foi o ambiente de desenvolvimento. Descobrimos que isso não funciona muito bem,
porque o ambiente nunca é estável o suficiente para testes eficazes.
Assim como os programadores têm seus próprios sandboxes para trabalhar e testar, isso funciona
bem se cada testador tiver a mesma disponibilidade e controle. Nós reconhecemos que
nem todos os aplicativos se prestam a isso, mas pelo menos você precisa
saiba qual compilação você está testando. Você também precisa de dados de teste que outros não
vá até lá com seus testes. Se você não tiver um sandbox de teste abaixo
seu próprio controle, reserve um tempo para planejar o que você precisa estabelecer para o seu teste
ambientes. Faça um brainstorming com sua equipe sobre como você pode obter o
hardware e software necessários. Pode levar algum tempo, então desenvolva um Plano B para
realizar algo enquanto espera pela infraestrutura necessária.
Se você estiver trabalhando em um sistema grande, talvez seja necessário entrar na fila junto com
outras equipes para obter tempo em um ambiente de teste ou preparação que inclui todos os
os vários softwares com os quais o seu deve funcionar. Este ambiente de teste deve imitar seu sistema de
produção tanto quanto possível. Se
Se sua organização não tiver alguém responsável pela criação de ambientes, sua equipe poderá precisar de
funções extras dedicadas à obtenção dos ambientes de teste necessários. Essas funções podem envolver
trabalhar com outras equipes como
bem. O planejamento da versão é o momento de considerar todos esses requisitos de infraestrutura de testes.
Dados de teste
O planejamento do lançamento ou do tema também é um bom momento para pensar sobre quais dados de teste
você pode precisar durante o projeto.
Usar dados de teste que se assemelhem muito aos dados reais geralmente é uma boa prática.
Planeje os dados que você precisa. Tivemos a oportunidade, em diversas organizações, de usar uma cópia
dos dados de produção. Dados reais fornecem uma boa base para
diferentes cenários para testes exploratórios. Os dados de produção podem precisar ser
“limpo” antes de ser usado para testes, a fim de remover qualquer informação sensível, como identificação
ou números de contas bancárias. Os dados precisam
ser alterado para ocultar os valores originais, mas permanecer válido para que não
violar as restrições do banco de dados. Porque leva tempo para que os especialistas em banco de dados
portar dados de produção para um ambiente de teste, certifique-se de que eles estejam incluídos em seu
planejamento.
Em uma das organizações com as quais trabalhei, usamos dois esquemas diferentes de dados
de teste de linha de base. Para nossos ambientes de teste individuais, usamos acessórios Fit
para carregar dados predefinidos. Tentamos tornar esses dados o mais próximo possível da
produção, mas também os semeamos com alguns dados de teste muito específicos.
Cada vez que verificamos uma nova versão do código, conseguimos recarregar um conjunto
básico de dados. Dessa forma, também testamos o esquema do banco de dados para ver
se algo havia mudado.
Para nosso ambiente de teste mais estável, onde queríamos que os dados persistissem, usamos
os scripts de migração de dados que os programadores desenvolveram à medida que faziam
alterações no banco de dados. Esses scripts de migração foram eventualmente usados para o
corte inicial da produção e então tínhamos certeza de que estavam corretos.
—Janet
Conte com o suporte de seus clientes para obter dados de teste significativos. Se vocês são
trabalhando em uma história que envolve o envio de um arquivo para um fornecedor terceirizado, seu
especialista em negócios pode descobrir quais dados o fornecedor espera no arquivo. Lisa
A equipe desenvolveu recursos para permitir que corretores de planos de aposentadoria oferecessem
carteiras de fundos mútuos aos seus clientes. Eles pediram ao proprietário do produto que fornecesse
amostras de carteiras, incluindo nome, descrição e conjunto de fundos para
cada. Isso os ajudou a testar com dados realistas.
Os dados de teste tendem a ficar obsoletos e desatualizados com o tempo. Dados mais antigos, mesmo que
veio da produção, pode não refletir mais com precisão a produção atual
dados. Um teste “aprovado” usando dados que não são mais válidos dá uma sensação enganosa
de confiança. Revise continuamente suas necessidades de dados de teste. Atualizar dados ou criar
usando uma nova abordagem, conforme necessário.
Os requisitos de dados de teste variam de acordo com o tipo de teste. Testes de regressão
Capítulo 14, “Um
geralmente podem criar seus próprios dados ou executá-los em um pequeno conjunto representacional
Automação de
de dados que podem ser atualizados rapidamente para um estado conhecido. Teste exploratório
Testes”, explora pode precisar de uma réplica completa dos dados do tipo de produção.
diferentes abordagens
para obter dados de teste
Resultado dos testes
Equipes diferentes têm requisitos diferentes para relatórios de resultados de testes. Pensar
sobre como você relatará os resultados dos testes nesta fase do jogo para que
você pode fazer isso de forma eficaz quando chegar a hora de fazer o relatório propriamente dito.
Sua organização pode ter requisitos de conformidade de auditoria, ou talvez seu
o cliente só quer saber como você testou. Entenda suas necessidades para que
você pode escolher a abordagem certa para sua equipe.
Existem muitas maneiras de relatar resultados de testes. Existem ferramentas de fornecedores que irão
registrar resultados automatizados e manuais. Sua equipe pode encontrar uma maneira de manter os
resultados de ferramentas como o Fit, ou você pode simplesmente optar por manter um grande
gráfico manual visível.
A abordagem que algumas equipes adotaram é criar resultados de testes caseiros

formulários. Por exemplo, uma aplicação Ruby simples escrita com Ruby em
Rails para o banco de dados ou um banco de dados MySQL com front-end PHP pode fazer um
sistema de gerenciamento de testes muito simples, mas fácil de usar.
Uma ferramenta como esta pode ser muito simples ou pode incluir complexidade adicional, como
como a capacidade de categorizar seus testes. O importante são os resultados dos testes. Se seus testes
automatizados registrarem o resultado de aprovação ou reprovação junto com o erro, você terá algum
histórico para ajudar a determinar a fragilidade do teste.
Sua equipe pode configurar seu processo de construção automatizado para fornecer resultados de testes
de cada build, por e-mail ou por um utilitário de feedback ou interface web que a equipe
os membros podem ver online. Os resultados ao longo do tempo podem ser resumidos em uma variedade de
formatos que tornam o progresso visível. Uma das equipes de Lisa produziu um gráfico diário
de testes escritos, executados e aprovados que foram afixados na área de trabalho da equipe. Outro produziu
um calendário diário com o número de testes unitários aprovados em cada
dia. Mesmo resultados visuais simples são eficazes.
Falaremos sobre algumas das métricas que você pode usar posteriormente neste capítulo.
ALTERNATIVAS DE PLANO DE TESTE
Já falamos sobre por que testar o plano e o que você deve considerar. Agora nós
fale sobre algumas das alternativas aos planos de testes pesados aos quais você pode estar acostumado.
Seja qual for o tipo de plano de teste que sua organização usa, personalize-o. Use-o em um
maneira que beneficie sua equipe e garanta que você atenda às necessidades do cliente.
Como acontece com qualquer documento produzido pela sua equipe, ele deve cumprir um propósito.
Planos de teste leves

Se sua organização ou cliente insistir em um plano de teste para conformidade com SOX ou
outras necessidades regulatórias, considere um plano de teste leve que cubra as necessidades, mas não
quaisquer extras. Não repita itens que já foram incluídos
no Plano do Projeto ou no termo de abertura do projeto. Um exemplo de Plano de Teste pode ser semelhante
ao mostrado na Figura 15-6.
Um plano de teste não deve cobrir todas as eventualidades ou todas as histórias, e não é
destinado a abordar a rastreabilidade. Deve ser uma ferramenta para ajudá-lo a pensar sobre os riscos de
teste para o seu projeto. Não deve substituir a conversa cara a cara com
seu cliente ou o resto de sua equipe.
Usando uma matriz de teste
Janet usa o planejamento de lançamento para trabalhar com os testadores e clientes para desenvolver
uma matriz de teste de alto nível. Uma matriz de teste é uma maneira simples de comunicar o grande
imagem sobre qual funcionalidade você deseja testar. Isso dá à sua equipe um
visão geral rápida dos testes necessários.
Uma matriz de teste é apenas uma lista de funcionalidades e condições de teste

Através do topo. Ao pensar em condições de teste e funcionalidade, considere todo o aplicativo e qualquer
impacto na funcionalidade nova ou alterada
ALTERNATIVAS DE PLANO DE TESTE 351
Plano de Teste do Projeto ABC

Preparado por: Janet Gregory e Lisa Crispin
Introdução
O Plano de Teste pretende ser uma linha de base para identificar o que é considerado dentro e fora do escopo do
teste e quais são os riscos e suposições.
Recursos
% do testador comprometido
Janete 100%
Lisa 50%
Na mira
Os testes incluem todas as novas funcionalidades, funcionalidades identificadas de conjunto de regressão de alto
risco, UAT e testes de carga. A localização faz parte deste projeto. Testes de regressão manuais
considerados de baixa prioridade serão executados se o tempo permitir.
Fora do escopo
Os testes reais de tradução são terceirizados e, portanto, não fazem parte deste plano de testes.
Nova funcionalidade
A seguinte funcionalidade está sendo alterada nesta versão.
Descrição do recurso Profundidade do teste

Adicionando nova alternância Testando todos os 5 idiomas (inglês, espanhol, francês, italiano e
para seleção de idioma na alemão). Testando se somos capazes de alternar idiomas
página inicial dinamicamente.
Teste de desempenho e carga

O teste de carga se concentrará nas seguintes áreas. Os detalhes do teste de carga serão encontrados no
documento Plano de Teste de Carga [link para Plano de Teste de Carga].
UAT (teste de aceitação do usuário)

O UAT será realizado e coordenado com o escritório de Paris e também com o escritório de Calgary. Os
usuários serão escolhidos por sua experiência em áreas e transações selecionadas, além de serem fluentes em um
dos seguintes idiomas: alemão, italiano, espanhol ou francês.
Considerações sobre infraestrutura

O laboratório de teste precisará de todos os 5 idiomas instalados e disponíveis para teste.
Premissas
A tradução foi testada antes de ser entregue à equipe do projeto.
Riscos
Os seguintes riscos foram identificados e as ações apropriadas identificadas para mitigar o seu impacto no
projeto. O impacto (ou gravidade) do risco baseia-se em como o projeto seria afetado se o risco fosse acionado.
# Risco Plano de Mitigação de Impacto

1 Os usuários não estão prontos para o UAT HIgh
Figura 15-6 Plano de Teste de Amostra

pode ter no resto do aplicativo. Testadores sentados com clientes e

pensar nas condições de teste é o que importa.
Também pode ser um mecanismo para rastrear a cobertura e pode ser tão detalhado quanto você
como. Uma matriz de teste de alto nível pode ser usada pela equipe para mostrar ao cliente
equipe ou gestão o que já foi testado e o que resta. Um mais
uma matriz de teste detalhada pode ser usada pela equipe para mostrar o que está planejado
para teste e acompanhar o progresso dos testes. Após a matriz ter sido criada, ela
torna-se fácil preencher os quadrados quando o teste é feito. Mantenha simples. Como gostamos
de gráficos grandes e visíveis e fáceis de ler, recomendamos cores
isso significa algo para sua equipe. Por exemplo, verde (G) significa que o teste está
feito e a equipe está feliz com isso, enquanto amarelo (Y) pode significar que alguns testes foram
feitos, mas mais testes exploratórios serão necessários se houver tempo. Vermelho
(R) significa que algo está quebrado. Um quadrado branco significa que não foi testado
ainda, e um quadrado cinza (não aplicável) significa que não precisa ser testado.
Vejamos um exemplo. Queremos lançar um pequeno comunicado que calcula os custos de envio.
Na Figura 15-7, diferentes funcionalidades são
representadas em um eixo e as propriedades da remessa são representadas em
o outro. As células individuais são codificadas por cores para mostrar quais casos são testados e
que precisam de mais atenção. Todas as células para “<= 2 lbs” estão concluídas, a parte superior
três células para> 4 libras são feitas, mas precisam de mais testes exploratórios, e o
A célula “Ship to Alaska”/“>4 lbs” indica um possível problema.
Matriz de teste de envio
Condições de teste
Destino Múltiplos Endereço <= 2 Mesmo Próximo <5 Estimativas
Funcionalidade
Enviar dentro dos EUA GG E
Enviar para o Canadá G E
Enviar para o Havaí G E
Enviar para o Alasca G R
Estimativas de envio G n/D
Figura 15-7 Uma matriz de teste de amostra

ALTERNATIVAS DE PLANO DE TESTE 353
Tive um efeito colateral inesperado ao usar uma matriz de teste em um projeto em que estava.
Os clientes e testadores montaram a matriz de teste e pensaram em todas as funcionalidades
afetadas para o projeto e nas condições de teste de alto nível que precisariam. Como esperado,
o ato de planejar trouxe à tona muitas questões que teriam sido esquecidas até mais tarde.
Quando penduraram a matriz na parede da área da equipe, Dave, o líder da equipe de

desenvolvedores, manifestou interesse. Um dos testadores explicou-lhe a matriz e fiquei
surpreso quando ele disse que também era muito útil para eles. Dave disse “Eu não sabia
que esta funcionalidade afetaria esta área. Precisamos ter certeza de que nossos testes de
unidade também abordam isso.”
Olhando para trás, eu não deveria ter ficado surpreso, mas nunca tive essa experiência com os
programadores antes.
—Janet
Uma matriz de teste é uma ferramenta muito poderosa e pode ser usada para ajudar a
resolver problemas de rastreabilidade se sua equipe tiver esses problemas. Pense no que faz sentido
para sua equipe e adapte-o para sua equipe e para o que faz sentido para você.
Planilha de teste
Janet também viu um formato de planilha ser usado com algum sucesso. Por exemplo, na
WestJet, a primeira guia de uma pasta de trabalho era uma lista de alto nível de funcionalidades
que existiam no aplicativo. Para cada linha, a equipe determinou se o
projeto afetou essa parte da funcionalidade. Em caso afirmativo, deram uma classificação do
impacto esperado. Após a determinação do impacto das mudanças, as decisões sobre
ambientes de teste, dados de teste ou UAT poderiam então ser tomadas.
As guias eram usadas para riscos e suposições, mas podiam ser usadas para qualquer coisa
sua equipe pode precisar. Um formato flexível, como uma planilha, significa que você pode
adapte-o para funcionar para você.
Essas informações podem ser usadas de diversas maneiras. Pode ser usado para
determinar onde concentrar seus esforços de testes exploratórios, ou talvez
ajude a criar uma matriz de teste de alto nível para garantir que você aborde todas as áreas
durante seus testes.
Um quadro branco
Se sua equipe é informal e tem lançamentos pequenos, qualquer tipo de documentação

pode ser demais. Às vezes é suficiente listar os riscos e suposições sobre
um quadro branco ou em fichas. Janet usou um quadro branco para gerenciar riscos,
e funcionou muito bem. Se um risco realmente se tornasse um problema, o resultado era documentado
e riscado. Foi fácil adicionar novos riscos e estratégias de mitigação, e a lista ficou visível para toda a
equipe. Isso também pode ser feito em uma página wiki.
Não podemos enfatizar o suficiente que você precisa conhecer sua equipe e suas necessidades.
Lista de testes automatizados
Às vezes, pode ser necessário que você apresente mais informações aos seus clientes, como uma
lista de casos de teste. Se sua equipe tiver uma ferramenta da qual você possa extrair uma lista de
nomes de casos de teste, você poderá fornecer essa lista facilmente para qualquer pessoa que
precise dela. Isso apresentaria um plano de teste detalhado do tipo tradicional, mas não estaria
disponível até que os testes fossem realmente escritos. Não recomendamos perder tempo com isto
porque não vemos valor acrescentado, mas por vezes esta lista pode ser necessária para avaliação
de riscos ou auditabilidade.
PREPARANDO-SE PARA A VISIBILIDADE
Se sua equipe está apenas começando com o desenvolvimento ágil, certifique-se de ter a infraestrutura
necessária para suas primeiras iterações. Você pode mudar a maneira como acompanha o progresso
à medida que avança, e suas retrospectivas o ajudarão a trazer essas questões à luz. Se você estiver
tendo problemas para concluir o trabalho planejado para cada iteração, talvez precise de gráficos ou
recursos visuais mais visíveis para ajudá-lo a avaliar o progresso e fazer ajustes no meio da iteração.
Seus clientes têm alguma maneira de saber como a iteração está progredindo e quais histórias foram
concluídas? Reserve um tempo antes de cada iteração para avaliar se você está recebendo o tipo
certo de feedback para acompanhar os testes.
Acompanhamento de tarefas e status de
teste Todas as equipes ágeis eficazes que conhecemos seguem esta regra simples: “Nenhuma
história é concluída até que seja testada”. Esta regra pode ser expandida para dizer que não apenas
a história deve ser testada, o código deve ser verificado, deve ter testes automatizados que são
executados por um processo de construção contínuo, deve ser documentado ou quaisquer que sejam
os critérios de “prontidão” da sua equipe são. A qualquer momento durante uma iteração, você precisa
ser capaz de avaliar rapidamente quanto trabalho de teste resta em cada história e quais histórias
estão “concluídas”. Os quadros de histórias ou tarefas são ideais para essa finalidade, especialmente
se usarem codificação por cores para denotar tarefas de teste versus desenvolvimento e outros tipos
de tarefas. Quadros de cortiça, chapas de aço com ímãs, post-its do tamanho de pôsteres ou quadros
brancos funcionam bem. Dê a cada história sua própria linha e ordene-as por prioridade. Tenha
colunas para “fazer”, “trabalho em andamento”, “verificar” e “concluído”.
PREPARANDO-SE PARA A VISIBILIDADE 355
A história de Janete Comecei com membros da equipe que já praticavam Agile há alguns meses, com apenas alguns
programadores e um testador. Eles estavam usando o XPlanner para rastrear suas tarefas e histórias,
e estava funcionando bem para eles. Ao mesmo tempo em que entrei, alguns novos programadores
foram adicionados e os stand-ups tornaram-se menos eficazes; a equipe não estava completando as
histórias planejadas. Sugeri um storyboard e, embora eles estivessem céticos quanto à manutenção
de dois conjuntos de “tarefas”, disseram que tentariam.
Pegamos uma parede aberta e usamos adesivos para criar nosso storyboard. Começamos a fazer stand-
ups em frente ao storyboard e nossa discussão tornou-se mais específica. Forneceu uma boa
maneira visível de saber quando as tarefas foram concluídas e o que faltava fazer. Depois de alguns
meses, a equipe cresceu novamente e tivemos que transferir o storyboard para um escritório. Também
movemos nossos stand-ups e nossos gráficos de resultados de testes para lá. No entanto, a visibilidade
constante foi perdida e os programadores e testadores pararam de mover as suas tarefas.
Tivemos que reavaliar o que queríamos fazer. Um tamanho único não serve para todas as equipes.
Certifique-se de planejar o que é certo para sua equipe.
—Janet
Algumas equipes usam fichas de cores diferentes para os diferentes tipos de tarefas:
verde para teste, branco para codificação, amarelo e vermelho para bugs. Outras equipes usam
um cartão por tarefa de desenvolvimento e adicione adesivos de cores diferentes para mostrar que
o teste está em andamento ou mostra que há bugs para resolver. Utilize qualquer método
que permite ver rapidamente quantas histórias estão “concluídas”, com todas as tarefas de codificação,
banco de dados, testes e outras tarefas concluídas. À medida que a iteração avança,
é fácil ver se a equipe está no caminho certo ou se você precisa divulgar uma história ou ter
os programadores contribuem nas tarefas de teste.
A história de Janete Nosso storyboard (mostrado na Figura 15-8) não era muito grande e não tínhamos muito espaço na
parede para expandir e ter o quadro de tarefas do tipo coluna normal. Em vez disso, decidimos usar
adesivos para designar o status.
Os cartões brancos, como os mostrados na primeira linha da Figura 15-8, eram tarefas regulares,
os cartões azuis designavam histórias técnicas, como refatoração ou picos, e os cartões rosa,
mostrados no lado direito do tabuleiro como a cor mais escura. , eram bugs que precisavam ser
resolvidos. É fácil ver que esta foto foi tirada no início de uma iteração porque não há círculos coloridos
em cada cartão. No canto superior direito você pode ver a legenda. Adesivos azuis significam que
foi codificado, verdes indicam concluído (testado) e vermelhos significam que a tarefa foi considerada
não concluída ou um bug foi rejeitado como não corrigido. À medida que uma tarefa ou história era
concluída (ou seja, o adesivo verde), ela era movida para a direita do quadro.
—Janet
Figura 15-8 Exemplo de storyboard
A história de Lisa
Por mais de quatro anos, nosso storyboard consistia em duas folhas de metal pintadas com as cores
da empresa, usando fichas codificadas por cores fixadas ao quadro com ímãs. A Figura 15-9 mostra
uma imagem disso no início de uma iteração. Nossos cartões de tarefas também foram codificados por
cores: branco para tarefas de desenvolvimento, verde para tarefas de codificação, amarelo e vermelho
para bugs e listrado para cartões não planejados originalmente na iteração.
O quadro foi tão eficaz em indicar nosso progresso que eventualmente paramos de nos preocupar com
um gráfico de esgotamento de tarefas. Isso nos permitiu focar em completar uma história de cada vez.
Também o usamos para postar outros grandes gráficos visíveis, como um grande sinal vermelho
mostrando que a construção falhou. Adorámos a nossa prancha.
Então, um dos membros da nossa equipe mudou-se para o exterior. Tentamos usar uma planilha
junto com nosso storyboard físico, mas nosso colega de equipe remoto achou a planilha muito difícil de
usar. Tentamos vários pacotes de software projetados para equipes Scrum, mas eles eram tão
diferentes do nosso storyboard real que não conseguimos nos adaptar ao seu uso. Finalmente
encontramos um produto (Mingle) que se parecia e funcionava o suficiente com nossa placa física
para que todos, incluindo nossa pessoa remota, pudessem usá-lo. Pintamos nosso antigo storyboard de
branco e agora podemos projetá-lo na parede durante reuniões em pé.
—Lisa
Figura 15-9 Outro exemplo de storyboard
As equipes distribuídas precisam de algum tipo de storyboard online. Pode ser uma planilha ou um
software especializado que imite um storyboard físico como o Mingle faz.
Comunicando os Resultados dos Testes
Anteriormente, falamos sobre como planejar como monitorar os resultados dos testes. Agora
queremos falar sobre como comunicá-los de forma eficaz. Os resultados dos testes são uma das
formas mais importantes de medir o progresso, ver se novos testes estão sendo escritos e
executados para cada história e se todos estão sendo aprovados. Algumas equipes publicam
grandes gráficos visíveis do número de testes escritos, executados e aprovados. Outros têm seu
processo de construção por e-mail com resultados de testes automatizados para membros da
equipe e partes interessadas. Algumas ferramentas de integração contínua fornecem ferramentas
GUI para monitorar compilações e resultados de compilações.
Ouvimos falar de equipes que possuem um projetor conectado à máquina que executa testes
FitNesse em uma construção contínua e exibe os resultados do teste o tempo todo.
Os resultados dos testes são uma representação concreta do progresso da equipe. Se o número de
os testes não aumentam todos os dias ou a cada iteração, o que pode indicar um problema.
Ou a equipe não está escrevendo testes (supondo que estejam desenvolvendo os testes primeiro)
ou não estão concluindo muito código. Claro, é possível que eles estejam copiando o código
antigo e os testes que o acompanham. É importante analisar por que as tendências estão indo na
direção errada. A próxima seção dá algumas ideias sobre os tipos de métricas que você pode
querer coletar e exibir.
Independentemente de como sua equipe decidir que deseja comunicar seu progresso, pense
nisso com antecedência e todos obterão valor com isso.
Métricas de lançamento
Incluímos esta seção aqui porque é importante entender quais métricas você deseja coletar desde
o início de um lançamento. Essas métricas devem fornecer feedback contínuo sobre como o
desenvolvimento está progredindo, para que você possa responder a eventos inesperados e
alterar seu processo conforme necessário. Lembre-se de que você precisa entender qual problema
está tentando resolver com suas métricas para poder rastrear as corretas. As métricas de que
falamos aqui são apenas alguns exemplos que você pode optar por acompanhar.
Número de testes aprovados
Muitas equipes ágeis monitoram o número de testes em cada nível: unitários, funcionais, testes
de história, GUI, carga e assim por diante. A tendência é mais importante que o número. Temos
uma sensação calorosa ao ver o número de testes aumentar. No entanto, um número sem
contexto é apenas um número. Por exemplo, se uma equipe diz que tem 1.000 testes, o que isso
significa? 1.000 testes fornecem 10% ou 90% de cobertura?
O que acontece quando o código que contém testes é removido?
Acompanhar o número de testes escritos, executados e aprovados no nível da história é uma

forma de mostrar o status de uma história. O número de testes escritos mostra o progresso dos
testes para impulsionar o desenvolvimento. Saber quantos testes ainda não foram aprovados dá
uma ideia de quanto código ainda precisa ser escrito.
Após a aprovação de um teste, ele precisa permanecer “verde” enquanto a funcionalidade estiver
presente no código. Gráficos do número de testes aprovados e reprovados ao longo do tempo
mostram se há algum problema com falhas de regressão e também mostram o crescimento da
base de código. Novamente, é a tendência que é importante. Fique atento a anomalias.
Esses tipos de medições podem ser relatados de forma simples e ainda assim serem eficazes.
Figura 15-10 E-mail com resultado completo da compilação da equipe de Lisa
Minha equipe envia por e-mail um calendário codificado por cores todos os dias mostrando se o “completo
A história de Lisa
build” com o conjunto completo de testes de regressão aprovados todos os dias (veja a Figura 15-10).
Dois dias “vermelhos” consecutivos (a cor mais escura) são motivo de preocupação e percebidos tanto
pela gestão quanto pela equipe de desenvolvimento. Ver os resultados visuais dos testes ajuda a
organização a se unir para corrigir os testes com falha ou quaisquer outros problemas que façam com que
a compilação não seja executada, como problemas de hardware ou de banco de dados.
—Lisa
Existem diferentes maneiras de medir o número de testes. Escolha um e experimente

para permanecer consistente em todos os tipos de testes, caso contrário, suas métricas
podem ficar confusas. Medir o número de scripts ou classes de teste é uma
maneira, mas cada um pode conter vários casos de teste individuais ou “afirmações”, portanto
pode ser mais preciso contá-los.
Se você for contar testes, certifique-se de relatar as informações para que possam ser
usado. Construir e-mails ou UIs de status de construção pode comunicar o número de testes
executado, aprovado e reprovado em vários níveis. A equipe do cliente pode ficar satisfeita
ver essas informações apenas no final de cada sprint, na revisão do sprint ou

um email.
Quaisquer que sejam as métricas que você escolher coletar, certifique-se de que a equipe as aceite.
Iniciei um novo contrato com uma equipe que já praticava Agile há alguns anos e eles desenvolveram
um grande número de testes funcionais automatizados. Comecei a acompanhar o número de testes
aprovados a cada dia. A equipe não viu problema quando a tendência mostrou que cada vez menos
testes estavam sendo aprovados. Os testes unitários foram mantidos e estavam fazendo o que
deveriam fazer, então a equipe se sentiu confiante no lançamento. Parecia que isso acontecia a cada
lançamento, e a equipe passaria a última semana antes do lançamento para fazer todos os testes
passarem. Era caro manter os testes, mas a equipe não queria desacelerar para corrigi-los. Todo mundo
estava bem com isso, exceto eu.
Eu não via como consertar os testes naquela data tardia poderia garantir que os resultados corretos
esperados fossem capturados. Senti que corríamos o risco de obter falsos positivos.
No início do próximo ciclo de lançamento, fiz com que a equipe concordasse em tentar consertar os
testes quando eles quebrassem. Não demorou muito para que a equipe percebesse que não era tão
difícil consertar os testes assim que soubemos que eles estavam quebrados, e encontramos muitos
problemas no início que normalmente só eram detectados muito mais tarde. A equipe logo estabeleceu
a meta de ter 95% dos testes aprovados em todos os momentos.
Também percebemos como os testes eram frágeis. A equipe fez um esforço conjunto para
refatore alguns dos testes mais complexos e elimine os redundantes. Com o tempo, o número de
testes de alto nível foi reduzido, mas a qualidade e a cobertura aumentaram.
Começamos medindo as taxas de aprovação, mas acabamos com muito mais.
—Janet
Não fique tão envolvido com as medidas reais a ponto de não reconhecer
outros efeitos colaterais da tendência. Esteja aberto para ajustar o que você está medindo se houver
necessidade.
Cobertura de código
A cobertura de código é outra métrica tradicional. Quanto do nosso código é exercitado pelos nossos
testes? Existem excelentes ferramentas comerciais e de cobertura de código-fonte aberto disponíveis, e
elas podem ser integradas ao seu processo de construção para
que você saiba imediatamente se a cobertura aumentou ou diminuiu. Tal como acontece com a maioria
das métricas, a tendência é algo a ser observado. A Figura 15-11 mostra um exemplo de cobertura de código
relatório.
GHIDRAH
Resumo da cobertura geral
Nome Aula, % Método, % Bloquear, Linha, %

% todas as classes 95% (1727/1809) 77% (13605/17678) 72% (201131/279707) 75% (43454,5/58224)
Resumo geral das estatísticas
total de pacotes: 240

total de arquivos executáveis: 1329
aulas totais: 1809
métodos totais: 17678
total de linhas executáveis: 58224
WHITNEY
Resumo da cobertura geral
Nome Classe, % Método, % Bloquear, Linha, %

todas as aulas 15% (109/737) 8% (669/8760) % 4% (16292/363257) 5% (3713,7/80358)
Resumo geral das estatísticas
total de pacotes: 46
total de arquivos executáveis: 655
aulas totais: 737
métodos totais: 8760
total de linhas executáveis: 80358
Figura 15-11 Exemplo de relatório de cobertura de código da equipe de Lisa. “Ghidrah” é a nova
arquitetura; “Whitney” é o sistema legado.
As Figuras 15-12 e 15-13 são dois exemplos de tendências que funcionam juntas.
A Figura 15-12 mostra uma tendência do número total de métodos em cada iteração. A Figura 15.12
mostra a cobertura do código correspondente. Esses exemplos mostram por que os gráficos
precisam ser vistos em contexto. Se você olhar apenas para o primeiro gráfico mostrando
o número de métodos, você obterá apenas metade da história. O número de métodos está a aumentar,
o que parece bom, mas a cobertura está, na verdade, a diminuir.
Não sabemos a razão da diminuição da cobertura, mas deveria ser uma
gatilho para perguntar à equipe: “Por quê?”
Lembre-se de que essas ferramentas só podem medir a cobertura do código que você
escrito. Se alguma funcionalidade for perdida, seu relatório de cobertura de código não será
Figura 15-12 Tendência do número de métodos
Figura 15-13 Cobertura do teste

trazer isso à luz. Você pode ter 80% de cobertura de código com seus testes, mas
você está perdendo 10% do código que deveria ter. Impulsionando o desenvolvimento com
testes ajudam a evitar esse problema, mas não valorizam mais as estatísticas de cobertura de código
do que merecem.
Saiba o que você está medindo

Alessandro Collino, engenheiro de ciência da computação e informação da Onion SpA que
trabalha em projetos ágeis, nos contou sobre uma experiência em que a cobertura de código
caiu repentina e desastrosamente. Sua equipe ágil desenvolveu middleware para um
sistema operacional de tempo real em um sistema embarcado. Ele explicou:
Uma abordagem TDD foi seguida para desenvolver um grande número de bons testes
unitários orientados para alcançar uma boa cobertura de código. Escrevemos muitos
testes de aceitação eficazes para verificar todas as funcionalidades complexas. Depois
disso, instrumentamos o código com uma ferramenta de cobertura de código e
atingimos uma cobertura de declaração de 95%.
O código que não pôde ser testado foi verificado pela inspeção, levando-os a declarar
100% de cobertura da declaração após dez sprints de quatro semanas.
Depois disso, o cliente solicitou que adicionássemos um pequeno recurso antes de

entregarmos o produto de software. Implementamos esta solicitação e aplicamos a
otimização do código do compilador.
Desta vez, quando fizemos os testes de aceitação, o resultado foi desastroso; 47% dos
testes de aceitação falharam e a cobertura das declarações caiu para 62%!
O que aconteceu? O problema ocorreu devido à ativação da otimização do compilador, mas

com uma configuração incorreta. Por causa disso, um valor-chave foi lido uma vez quando o
aplicativo foi inicializado e armazenado em um registro da CPU.
Mesmo quando a variável foi modificada na memória, o valor no registro da CPU nunca foi
substituído. A rotina continuou lendo esse mesmo valor obsoleto em vez do valor atualizado
correto, causando falha nos testes.
Alessandro conclui: “A lição aprendida com este exemplo é que a habilitação das opções
de otimização do compilador deve ser planejada no início do projeto. É um erro ativá-los nas
fases finais do projeto.”
Boas métricas requerem um bom planejamento. Esforço extra pode lhe dar mais
dados significativos. Os membros da equipe de Pierre Veragen usam uma linha de base de teste de interrupção
técnica para saber se sua métrica de cobertura de código é significativa. Eles introduzem
manualmente uma falha em cada método e então executam seus testes para garantir
os testes detectam o problema. Alguns testes apenas garantem que o código retorne algum
valor, qualquer valor. A equipe de Pierre garante que os testes retornem o valor correto . Em
dessa forma, eles podem determinar se a cobertura do teste é boa o suficiente.
A cobertura do código é apenas uma pequena parte do quebra-cabeça. Use-o como tal. Isso não diz
você quão bons são seus testes, mas apenas se um determinado pedaço de código foi executado durante
o teste. Ele não informa se diferentes caminhos através do aplicativo foram executados,
qualquer. Entenda sua aplicação e tente identificar suas áreas de maior risco,
e definir uma meta de cobertura que seja mais elevada para essas áreas do que para áreas de baixo risco.
Não se esqueça de incluir também seus testes funcionais no relatório de cobertura.
Métricas de Defeito
À medida que sua equipe define metas relacionadas a defeitos, use métricas apropriadas para medir
progresso em direção a esses objetivos. Existem tendências que você deseja monitorar
para toda a versão, e há aqueles que são específicos da iteração. Por exemplo, se você está tentando atingir
zero defeitos, você pode querer rastrear os problemas em aberto.
bugs no final de cada iteração, ou quantos bugs foram encontrados após o desenvolvimento, mas antes do
lançamento. A maioria de nós está interessada em saber quantos
defeitos foram relatados após o código estar em produção, o que é algo completamente diferente. Essas
questões serão informadas após o fato
quão bem sua equipe se saiu no último lançamento, mas não quão bem você está no
a versão atual. Eles podem lhe dar alguma indicação de quais processos
você precisa mudar para reduzir o número de defeitos. A equipe de Lisa está mais preocupada com os
defeitos de produção encontrados no “novo” código que foi reescrito
na nova arquitetura. Eles estão trabalhando duro para produzir esse novo código com
zero defeitos, então eles precisam saber se estão indo bem. Eles esperam que
bugs serão encontrados com bastante frequência no sistema legado, onde apenas a funcionalidade mais
crítica é coberta por testes automatizados de fumaça da GUI, e há poucos
unidade automatizada e testes por trás da GUI.
Conhecer a taxa de defeitos do código legado pode ser uma boa justificativa para refatorá-lo ou reescrevê-lo,
mas a principal prioridade da equipe é fazer um bom trabalho com o código legado.
novo código, então eles agrupam os bugs por código “novo” e “antigo” e se concentram no
“novos” erros.
Certifique-se de que seu banco de dados de bugs possa rastrear o que você deseja medir. Você pode
Mais informações sobre
precisa fazer algumas alterações no banco de dados e no seu processo para obter o
sistemas de rastreamento
de defeitos podem ser dados que você precisa. Por exemplo, se você quiser medir quantos defeitos foram
encontradas no Capítulo encontrado na produção após um lançamento, você deve ter certeza de que tem ambiente e versão como
5, “Transição de Processos
campos obrigatórios, ou certificar-se de que as pessoas que inserem
Tradicionais”.
bugs sempre os preenchem.
Como os sistemas de rastreamento de defeitos são frequentemente usados para outros fins além do rastreamento
erros, certifique-se de não confundir os números. Uma solicitação de atualização manual para
o banco de dados não reflete necessariamente um problema com o código existente. Usar
sua ferramenta de rastreamento de defeitos corretamente para garantir que suas métricas sejam significativas.
Avalie periodicamente as métricas que você está reportando e veja se elas ainda são relevantes.
A história de Lisa
A Figura 15-14 mostra dois relatórios de defeitos que a equipe de Lisa utilizou durante anos.
Quando fizemos a transição para o Agile pela primeira vez, os gerentes e outras pessoas
analisaram esses relatórios para ver o progresso resultante do novo processo. Quatro anos
depois, nosso ScrumMaster descobriu que ninguém mais lia esses relatórios, então paramos
de produzi-los. Naquela época, as taxas de novos defeitos haviam reduzido drasticamente e
ninguém realmente se importava com os defeitos antigos que ainda persistiam no código legado.
—Lisa
Figura 15-14 Exemplos de relatórios de defeitos usados (e não mais usados) pela equipe de Lisa
O planejamento de lançamento é um bom momento para avaliar o ROI das métricas que você
estava rastreando. Quanto esforço você está gastando para coletar e relatar os
Métricas? Eles dizem o que você precisa saber? O código que você libera
atende aos padrões de qualidade interna da sua equipe? A porcentagem de cobertura do código está
aumentando? A equipe está atingindo suas metas de redução do número de defeitos que chegam à
produção? Se não, houve um bom motivo?
As métricas são apenas uma peça do quebra-cabeça. Use seu lançamento, tema ou projeto
planejando reuniões para focar novamente na entrega de valor comercial quando o negócio
precisa disso. Reserve algum tempo para aprender sobre os recursos que você está prestes a desenvolver.
Não se preocupe em se comprometer com seus planos – a situação está fadada
mudar. Em vez disso, prepare-se para realizar as atividades certas e obter os resultados certos.
recursos a tempo de atender às prioridades dos clientes.
RESUMO
À medida que sua equipe elabora o plano para um novo tema ou lançamento, mantenha os principais
pontos deste capítulo em mente.
Ao dimensionar uma história, considere diferentes pontos de vista, incluindo valor comercial,
risco, implementação técnica e como o recurso será usado. Faça perguntas esclarecedoras,
mas não se prenda a detalhes.
Os testadores podem ajudar a identificar a “fatia fina” ou “caminho crítico” por meio de um
conjunto de recursos para ajudar a priorizar histórias. Agende histórias de alto risco com
antecedência se elas exigirem testes extras antecipadamente.
O tamanho do esforço de teste de uma história ajuda a determinar se essa história está no
escopo para lançamento.
Os testadores podem ajudar a equipe a pensar sobre como as novas histórias impactarão o
sistema como um todo.
Planeje tempo e recursos extras para testes quando os recursos puderem afetar sistemas ou
subsistemas desenvolvidos por equipes externas.
À medida que a equipe identifica o escopo do lançamento, avalie o escopo dos testes e
reserve tempo e recursos suficientes para isso.
Passe algum tempo durante o planejamento da versão para abordar questões de infraestrutura,
ambiente de teste e dados de teste.
Um plano de teste leve e ágil pode ajudar a garantir que todas as considerações de teste sejam
abordadas durante a vida do lançamento ou projeto.
Considere alternativas para planos de teste que possam ser mais apropriados para sua equipe;
matrizes de teste, planilhas ou até mesmo um quadro branco podem ser suficientes.
RESUMO 367
O planejamento formal de lançamento pode não ser apropriado para sua situação.
Na ausência de planejamento de lançamento, considere identificar e discutir pelo
menos as primeiras histórias que devem ser feitas primeiro.
Planeje quais métricas você deseja capturar durante a vida do lançamento;
pense sobre qual problema você está tentando resolver e capture apenas as
métricas que são significativas para sua equipe.

Capítulo 16
ACESSE O CHÃO CORRENDO
Benefícios
Recursos Seja pro ativo Você realmente precisa disso?
Potenciais desvantagens da preparação avançada
Os clientes falam com uma só voz

Antes de o
Priorize defeitos Clareza Avançada Tamanho da história
Iteração
Clientes e equipes geograficamente dispersos
Estratégias de teste Exemplos
No desenvolvimento ágil, geralmente gostamos de realizar as tarefas “na hora certa”. Não
podemos ver além das curvas da estrada à frente, então nos concentramos nas atividades que
temos em mãos. Então, novamente, queremos começar a trabalhar quando iniciarmos cada nova iteração.
Isso pode exigir um pouco de preparação. Cozinhar é uma boa analogia aqui. Você decide que quer
fazer biscoitos porque alguém está vindo. Antes de começar, certifique-se de ter os ingredientes
certos. Do contrário, você compra o que precisa ou escolhe um tipo diferente para fazer.
Não exagere — se uma atividade de pré-iteração não economizar tempo durante a iteração
ou não ajudar você a fazer um trabalho melhor, não faça isso antes da iteração. Faça o que for
apropriado para sua equipe e continue experimentando. Talvez você faça algumas dessas
atividades após o início da iteração. Aqui estão algumas idéias para pensar que podem ajudá-lo
a “incorporar qualidade” ao seu produto.
SEJA PROATIVO
No Capítulo 2, “Dez princípios de um testador ágil”, explicamos como o ágil
os testadores precisam mudar sua mentalidade. Em vez de esperar que o trabalho chegue
nós, desenvolvemos uma atitude proativa onde nos levantamos e vamos procurar maneiras de
369
370 CAPÍTULO 16 ACESSE O CHÃO CORRENDO
contribuir. Com o ritmo rápido e constante do desenvolvimento ágil, é fácil

mergulhe nas histórias da iteração atual. Estamos tão ocupados garantindo
cobrimos os recursos com testes iniciais, realizando testes exploratórios para garantir que entendemos
os requisitos de negócios e automatizando
testes de regressão adequados, é difícil pensar em outra coisa. No entanto, é
às vezes é apropriado reservar um pouco de tempo para ajudar nossos clientes e nossos
equipe se prepara para a próxima iteração. Quando nossa equipe está prestes a lançar novidades
no terreno ou trabalhar em histórias complexas e arriscadas, algum trabalho antes da iteração pode
ajudar a maximizar a velocidade da nossa equipe e minimizar a frustração.
Com certeza não queremos gastar todo o nosso tempo em reuniões ou planejando histórias
que pode ser re-priorizado. No entanto, se pudermos fazer o nosso planejamento de iteração
ir mais rápido e reduzir o risco das histórias que estamos prestes a empreender, é
vale a pena fazer alguma pesquisa e brainstorming antes de iniciarmos a iteração.
Benefícios
Trabalhar em histórias antes da iteração pode ser especialmente útil para

equipes divididas em diferentes localizações geográficas. Trabalhando adiante,
há tempo para levar informações a todos e dar-lhes a oportunidade de dar
sua contribuição.
O problema é que estamos tão ocupados durante cada curta iteração ágil que é
difícil encontrar tempo para conversar sobre as histórias da próxima iteração, muito menos para começar
escrever casos de teste. Se suas iterações sempre correrem bem, com histórias entregues
de forma incremental e com bastante tempo para testar, e o software entregue corresponde
expectativas do cliente, talvez você não precise de tempo para se preparar com antecedência.
Se sua equipe tiver problemas para terminar histórias ou acabar com grandes incompatibilidades entre
o comportamento real e desejado dos recursos, um pouco de planejamento antecipado pode ajudar.
economizar tempo durante a iteração.
Nossa equipe costumava sentir que não tínhamos tempo para planejar antecipadamente a próxima iteração.
A história de Lisa
Depois de muitas experiências de mal-entendidos de histórias e de tê-las ultrapassado em muito as
estimativas, e de descobrir que a maioria dos “bugs” eram requisitos perdidos, decidimos reservar um tempo
na iteração para começar a falar sobre a próxima. Agora toda a equipe, incluindo o proprietário do produto e
outros clientes, conforme necessário, se reúne por uma hora ou menos no dia anterior à reunião de
planejamento do próximo sprint.
Nós, rindo, chamamos isso de reunião de “pré-planejamento”. Repassamos as histórias para a próxima
iteração. O proprietário do produto explica o propósito de cada história. Ele analisa as condições de
satisfação do negócio e outros itens de suas listas de verificação de histórias e dá exemplos de comportamento
desejado. Fazemos brainstorming sobre possíveis riscos e dependências e identificamos fios de aço quando
apropriado.
SEJA PROATIVO 371
Às vezes é suficiente passar alguns minutos ouvindo o que o proprietário do produto diz.
explicação das histórias. Outras vezes, reservamos um tempo para diagramar fatias finas de uma
história no quadro branco. A Figura 16-1 mostra um diagrama de exemplo onde entramos nos
detalhes do fluxo da UI e das tabelas do banco de dados. Observe os números dos “threads”. O tópico
nº 1 é nosso caminho crítico. O segmento 2 é a segunda camada e assim por diante. Carregamos fotos
desses diagramas no wiki para que nosso desenvolvedor remoto também possa vê-los.
Podemos começar a pensar em quais cartões de tarefas poderemos escrever no dia seguinte e
que abordagem adotaremos para cada história. Por alguma razão, ser capaz de ruminar sobre as
histórias durante a noite nos torna mais produtivos na reunião de planejamento da iteração no dia
seguinte. Depois de fazer isso por algumas iterações, estávamos gastando menos tempo
planejando a iteração, embora tivéssemos duas reuniões para fazer isso.
Às vezes chamamos outros clientes para discutir histórias que os afetam diretamente. Se eles não
estiverem disponíveis naquele momento, ainda teremos tempo antes da reunião de planejamento
da iteração para conversar com eles e esclarecer a história.
Em uma reunião de pré-planejamento, nosso product owner apresentou uma história sobre a
obtenção de dados de desempenho para fundos mútuos. Enviaríamos um arquivo ao fornecedor
contendo uma lista de fundos mútuos, e o fornecedor forneceria um arquivo XML em um site com
todas as informações mais recentes sobre o desempenho desses fundos. Em seguida,
carregaríamos esses dados em nosso banco de dados.
Figura 16-1 Exemplo de diagrama de quadro branco de planejamento

Na reunião de pré-planejamento, fizemos perguntas como: “Qual é o formato do arquivo que enviamos
ao fornecedor?” “A data final de cada fundo é sempre o último dia do mês?” “Existe alguma segurança no
site que contém o XML?” "Vai
alguma vez obteremos um registro para o mesmo fundo e data “de” que contém novos dados, ou podemos
ignorar registros com uma data que já temos em nosso banco de dados?”
Na reunião de planejamento da iteração do dia seguinte, o proprietário do produto obteve respostas para
todas as nossas perguntas. A escrita dos cartões de tarefas foi rápida e a codificação pôde prosseguir
com suposições corretas.
Freqüentemente, encontramos uma solução muito mais simples para uma história quando a discutimos
na discussão do planejamento pré-iteração. Descobrimos que para ir rápido, precisávamos primeiro
desacelerar.
—Lisa
Você realmente precisa disso?

Sua equipe pode não precisar de muita ou nenhuma preparação antecipada. Pierre Veragen
e Erika Boyer descreveram para Lisa como suas equipes na iLevel by Weyerhaeuser
escrever testes de aceitação do usuário juntos na reunião inicial da iteração.
Esses testes, que foram escritos em uma página wiki ou alguma ferramenta semelhante junto
com a narrativa da história, são usados posteriormente quando os membros da equipe escrevem cartões de tarefas
para cada história e comece a escrever mais testes e códigos. Exemplos são transformados
em testes executáveis. Porque os testes mudam à medida que a equipe aprende mais sobre
história, a equipe pode optar por não manter as originais que foram escritas no início.
Mantenha a simplicidade no início e aprofunde-se nos detalhes mais tarde.
Posteriormente, Lisa observou uma de suas sessões de planejamento e viu em primeira mão
quão eficaz foi essa técnica. Mesmo quando o gerente de produto fornece
exemplos concretos, transformá-los em testes pode eliminar requisitos ausentes. A equipe
deles não precisava fazer isso antes da sessão de planejamento da iteração, mas não é o
caso com todas as equipes.
Minha equipe gostou da prática de escrever testes juntos, mas como estávamos escrevendo cartões de
A história de Lisa
tarefas durante o planejamento da iteração, decidimos escrever testes de aceitação do usuário juntos
durante a reunião de pré-planejamento. Descobrimos que isso manteve nossas discussões focadas e
entendemos cada história mais rapidamente. Também fizemos um trabalho melhor ao entregar
exatamente o que o cliente tinha em mente. Nossos clientes notaram uma diferença na qualidade e nosso
proprietário do produto nos incentivou a continuar essa prática.
—Lisa
CLAREZA AVANÇADA 373
Experimente pequenas discussões pré-iteração e sessões de redação de testes.

Serão necessárias várias iterações para encontrar o ritmo da sua equipe e descobrir se as
discussões antecipadas da história o tornam mais produtivo durante a iteração.
Possíveis desvantagens da preparação antecipada

Existe o risco de “trabalhar com antecedência”. Você poderia gastar tempo aprendendo mais
detalhes sobre um recurso apenas para que os empresários redefinissem a prioridade no final.
minuto e adiar esse recurso indefinidamente. Invista tempo de preparação quando for
apropriado. Quando você sabe que tem um tema ou história complexa surgindo,
e tem um prazo difícil, como o que a equipe de Lisa teve com a história da declaração,
considere passar algum tempo verificando diferentes pontos de vista.
A única razão para discutir histórias com antecedência é economizar tempo durante a iteração
planejamento e durante o desenvolvimento. Uma compreensão mais profunda do comportamento
do recurso pode acelerar os testes e a codificação e pode ajudar a garantir que você entregue o
funcionalidade correta.
Se a sua situação for tão dinâmica que as histórias possam ser re-priorizadas no dia em que
a iteração começa, não vale a pena tentar fazer esse planejamento. Em vez disso, faça
certifique-se de reservar tempo para essas discussões durante sua reunião de planejamento.
CLAREZA AVANÇADA
O proprietário do produto de Lisa, Steve Perkins, criou o termo “claridade avançada”.

Diferentes partes de cada organização têm prioridades e agendas diferentes.
Por exemplo, o Desenvolvimento de Negócios está procurando novos recursos para atrair
novos negócios, enquanto Operações está priorizando recursos que reduziriam o
número de telefonemas dos usuários. A equipe de desenvolvimento tenta entender
a gama de necessidades de negócios e ter uma ideia do trabalho de cada indivíduo.
Com muitas agendas diferentes, alguém precisa decidir quais histórias devem ser
ser implementado na próxima iteração. Como há muitas maneiras de implementar qualquer
história, alguém precisa decidir os requisitos específicos e
capturá-los na forma de exemplos, condições de satisfação e testar
casos. Steve reúne todos para concordar sobre o valor que desejam de cada um
história e para fornecer “claridade antecipada”.
Os clientes falam com uma só voz

Scrum fornece o papel útil do proprietário do produto para ajudar todos os clientes a “Falar com
Uma Voz”. Esteja você em uma equipe Scrum ou não, encontre
alguma forma de ajudar seus clientes a concordarem sobre a prioridade das histórias e como
os componentes de cada história devem ser implementados. O apoio da gestão é crucial, porque qualquer
pessoa nesta função precisa de tempo e autoridade para
coloque todos na mesma página.
Outras equipes usam analistas de negócios para ajudar a detalhar as histórias antes da próxima
iteração. Numa organização com a qual Janet trabalhou, os clientes não eram
disponível em tempo integral para tirar dúvidas, mas cada equipe contava com um analista de negócios
que trabalhou com os clientes para definir os requisitos antes da reunião de planejamento da iteração. Se
houvesse alguma dúvida que ela não pudesse responder na reunião, a equipe ligava diretamente para o
cliente ou para o
analista fez o acompanhamento imediatamente após a reunião.
Como testador, você deseja participar de reuniões de redação de histórias e priorização.

Faça perguntas que ajudem os clientes a se concentrarem na funcionalidade principal, no
valor comercial crítico de que necessitam. Ajude os participantes a manterem o foco no concreto
exemplos que cristalizam o significado das histórias. Nas reuniões que envolvem
vários clientes, é fundamental ter um facilitador forte e um método para
determinação do consenso.
Tal como acontece com o código, as histórias são melhores se tiverem o mínimo. Por exemplo, um
O carrinho de compras pela Internet precisa de alguma forma de excluir itens indesejados, mas o
a capacidade de mover itens do carrinho para uma lista “salvar para mais tarde” provavelmente pode esperar.
Pode ser útil conversar sobre isso antes da iteração, para que a equipe esteja
claro sobre quais tarefas precisam ser planejadas. Concentre-se primeiro na coisa mais simples e
use um exemplo para deixar claro.
Obtenha todos os pontos de vista
Obter requisitos de diferentes clientes para uma história, cada um dos quais tem
uma agenda diferente, pode criar o caos. É por isso que é essencial para alguém
na equipe do cliente para obter consenso e coordenar todos os pontos de vista.
Isso não significa que não devemos receber informações de clientes diferentes. Como um
testador, você está considerando cada história de vários pontos de vista. Isso ajuda a
saber o que a história significa para pessoas em diferentes papéis.
Quando minha empresa decidiu redesenhar os extratos contábeis trimestrais dos participantes do plano de
A história de Lisa
aposentadoria, diferentes pessoas do lado comercial queriam mudanças por diferentes motivos. Os
administradores do plano queriam um layout claramente compreensível que minimizasse o número de
chamadas de participantes confusos para o suporte ao cliente.
Por exemplo, queriam que o extrato mostrasse a data e o valor da contribuição mais recente do participante.
Isso ajuda o participante a saber se ela
o empregador está atrasado no lançamento das contribuições nas contas. O desenvolvimento de

negócios queria novos recursos interessantes que pudessem vender a clientes em potencial, como
gráficos de desempenho por categoria de fundo. Nossa pessoa jurídica precisava de novos textos e
dados na declaração para atender às regulamentações federais.
Enquanto o product Owner equilibrava todas as diferentes necessidades e apresentava o resultado final
layout do extrato, ainda era importante para nossa equipe entender o propósito de cada nova
informação. Precisávamos conversar diretamente com especialistas em negócios nas áreas de
administração de planos, desenvolvimento de negócios e jurídica, e com o proprietário do produto.
Um testador e um programador reuniram-se com cada grupo para reunir os diferentes pontos de vista.
Ao fazer isso antes de iniciar as histórias para coletar e exibir dados, entendemos os requisitos com
muito mais clareza e até fizemos sugestões para produzir as informações de forma mais eficiente.
—Lisa
Certifique-se de ser o mais eficiente possível na coleta desses dados. Às vezes

é importante que toda a equipe entenda a necessidade, e às vezes é
suficiente para que um ou dois membros da equipe façam a pesquisa.
Tamanho da história
Ao discutir histórias para a próxima iteração com os membros da equipe do cliente, faça perguntas
para ajudá-los a garantir que cada história agregue valor
necessário. Este é um bom momento para identificar novas histórias que eles possam precisar escrever.
Mesmo que a equipe tenha dimensionado as histórias anteriormente, você pode descobrir que uma história é
maior do que se pensava anteriormente. Você pode até descobrir que um recurso pode ser
implementado de forma mais simples do que o planejado, e a história pode ser menor.
Às vezes, suposições são feitas quando a história é dimensionada e, após investigações mais
aprofundadas, revelam-se falsas. Mesmo histórias simples merecem um olhar mais atento. Isso é
difícil para qualquer pessoa lembrar todos os detalhes de um aplicativo.
A história de Lisa Aqui estão alguns exemplos de histórias que se revelaram significativamente maiores ou menores
do que se pensava originalmente.
1. A história consistia em produzir um arquivo de extratos de contas para todos os participantes de um

determinado plano de aposentadoria da empresa, que deveria ser enviado a um fornecedor que
imprimiria e enviaria os extratos. Ele foi originalmente dimensionado com a suposição de que
todas as declarações tinham exatamente três páginas. Após uma investigação mais aprofundada,
descobrimos que alguns participantes tinham declarações de quatro páginas, mas o fornecedor
exigia que todas as declarações tivessem o mesmo tamanho. Nossos especialistas em negócios
tiveram que decidir se teriam um recurso para sinalizar quaisquer planos cujos participantes
tivessem extratos de quatro páginas e lidar com eles manualmente, ou alterar os extratos para que
tivessem quatro páginas. É um esforço muito maior do que o original
história. Depois que começamos a desenvolver a história, os clientes revelaram outro requisito:
se o endereço de algum participante estivesse faltando ou fosse inválido, o extrato deveria ser
enviado ao empregador. É razoável, mas não sabíamos disso quando avaliamos a história.
2. Nossos clientes queriam começar a exibir o número de telefone de vendas em vários locais da
IU. Há um número de telefone de vendas diferente para cada parceiro
site, e na época havia cerca de 25 sites parceiros diferentes. Parecia uma história tão direta que
nem sequer foi dada à equipe.
O gerente de desenvolvimento apenas atribuiu a ele um pequeno valor de ponto e ele foi
simplesmente “adicionado” à iteração. Ele presumiu que o número de telefone estava armazenado
no banco de dados, quando na verdade estava codificado no HTML da página de “contato” de
cada parceiro. Armazenar o número correto de cada parceiro no banco de dados e alterar o
código para recuperar o valor tornou a história duas vezes maior, e não havia espaço para isso
naquela iteração, por isso não foi concluída.
3. Dimensionamos uma história para a interface do usuário para permitir que os administradores enviem uma
solicitação de um trabalho em lote para reequilibrar contas de participantes que atenderam a
uma determinada condição. Incluía uma página de confirmação exibindo o número de
participantes afetados. Como a solicitação foi colocada na fila para ser executada como um
trabalho em lote assíncrono, o código para determinar quais participantes foram afetados estava
no código do trabalho em lote. Refatorar o código para obter o número de participantes no
momento da solicitação foi um grande trabalho. Depois que começamos a trabalhar na história,
perguntamos ao usuário principal do recurso se ele realmente precisava daquele número ao
enviar a solicitação, e ele decidiu que não era necessário. A história se tornou muito menor do
que se pensava originalmente. Sempre fazemos perguntas para descobrir o verdadeiro valor
comercial que os clientes desejam e eliminar componentes que não tenham um bom ROI.
—Lisa
Essas histórias mostram que algumas perguntas iniciais podem economizar tempo durante o
iteração que poderia ser gasta para descobrir o que fazer com novas descobertas.
No entanto, reconhecemos que nem todas as descobertas podem ser encontradas precocemente. Por
exemplo, na primeira história, uma simples pergunta sobre o tamanho do extrato pode ter evitado
confusões de última hora sobre como lidar com extratos de quatro páginas,
mas a questão do endereço impreciso pode não ter sido considerada até que fosse
sendo codificado ou testado.
Sabemos que sempre haverá descobertas ao longo do caminho, mas se conseguirmos captar
as grandes “pegadinhas” primeiro, que ajudarão a equipe a trabalhar da maneira mais eficaz possível.
Equipes geograficamente dispersas

Alguma preparação para a próxima iteração pode ser útil para equipes divididas
em diferentes locais. Equipes distribuídas em vários locais
podem fazer o planejamento da iteração por teleconferência, reunião on-line ou teleconferência. Uma
prática usada por uma equipe de Lisa é atribuir a cada equipe um
subconjunto das próximas histórias e peça-lhes que escrevam cartões de tarefas com antecedência.
Durante a reunião de planejamento, todos podem revisar todos os cartões de tarefas e fazer
alterações conforme necessário. O trabalho antecipado melhora a comunicação, torna o
histórias e tarefas visíveis para todos e acelera o processo de planejamento.
Claro, isso pressupõe que a equipe esteja usando uma história ou tarefa eletrônica
quadro. A equipe de Lisa usa o Mingle da Thoughtwork, mas há muitos outros
produtos que servem a esse propósito.
Lidando com a Diversidade Geográfica

Conversamos com uma equipe que conhecemos de uma empresa de software que tem
clientes, desenvolvedores e testadores espalhados por todo o mundo. Além de os
clientes estarem distantes da equipe técnica, eles também não têm largura de banda
para responder às perguntas da equipe de desenvolvimento. Em vez disso, a equipe
conta com analistas funcionais que entendem tanto o lado comercial da aplicação em
nível detalhado quanto a implementação técnica do software.
Esses analistas funcionais atuam como elos de ligação entre as equipes de negócios e
técnicas.
Patrick Fleisch e Apurva Chandra são consultores que trabalharam com esta empresa e
atuaram como analistas funcionais em um projeto de desenvolvimento de software de
titularidade baseado na web, porque são especialistas neste domínio. Eles viajaram
entre locais para facilitar a comunicação entre as partes interessadas e os desenvolvedores.
Os analistas funcionais trabalharam antes da iteração, dimensionando e preparando as

histórias para dimensionar, ajudando a equipe técnica a entender as histórias.
Eles inseriram histórias em uma ferramenta on-line e as desenvolveram definindo casos
de teste, condições extremas e outras informações que ajudaram a equipe técnica a
entender a história. Eles documentaram funcionalidades de alto nível em um wiki
voltado para usuários corporativos.
Apurva e Patrick desempenharam um papel fundamental na tomada de decisões que a

equipe técnica precisava para começar com as novas histórias. Seu profundo conhecimento
técnico e comercial permitiu que eles fornecessem à equipe os requisitos necessários
para obter a codificação, porque os clientes reais não estavam
disponível para eles. David Reed, testador e engenheiro de automação, nos contou como
confiou em Apurva e Patrick para obter as informações necessárias para realizar e
automatizar testes. Embora os princípios ágeis digam para colaborar estreitamente com
o cliente, em algumas situações é necessário ser criativo e encontrar outra maneira de
obter requisitos de negócios claros.
Se os clientes não estiverem prontamente disponíveis para responder perguntas e tomar decisões,
outros especialistas do domínio que estejam sempre acessíveis devem ser capacitados
para orientar a equipe determinando prioridades e expressando o sistema desejado
comportamento com exemplos. Testadores e analistas de negócios são frequentemente chamados

para fazer essas atividades.
EXEMPLOS
Você pode notar que falamos sobre exemplos em quase todos os capítulos deste livro.
este livro. Os exemplos são uma forma eficaz de aprender e ilustrar
funcionalidade (e indesejada); vale a pena usá-los durante todo o seu ciclo de desenvolvimento. Nosso
lema foi cunhado por Brian Marick: “Um exemplo seria
útil agora. (Veja a Figura 16-2.) Comece suas discussões sobre recursos e histórias com um exemplo
realista. A idéia decolou, de modo que em um
No recente workshop para testes funcionais, estávamos discutindo ideias sobre como chamá-lo de
“Desenvolvimento Orientado a Exemplos”.
Quando os membros da equipe de Lisa se reúnem com o proprietário do produto para falar sobre o
na próxima iteração, eles pedem exemplos de comportamento desejado para cada história.
Isto mantém a discussão em um nível concreto e é uma maneira rápida de aprender como o
novos recursos devem funcionar. Tenha um quadro branco à mão enquanto faz isso e
comece a desenhar. Se alguns membros da equipe estiverem em um local distante, considere usar
ferramentas que permitem que todos vejam diagramas do quadro branco e participem do
discussão. Veja exemplos reais com seus clientes ou seus representantes.
Assim como durante o planejamento do lançamento, considere diferentes pontos de vista: o negócio,
usuários finais, desenvolvedores e parceiros de negócios. Ao contrário do planejamento de lançamento, você
estão analisando muito mais detalhes porque essas são as histórias que você está planejando
para a próxima iteração.
Usando exemplos, você pode escrever testes de alto nível para detalhar um pouco cada história
mais. Talvez você não precise fazer isso antes do início da iteração, mas para fins
Figura 16-2 Exemplo de adesivo de Brian Marick

EXEMPLOS 379
histórias complexas, pode ser uma boa ideia escrever pelo menos um caminho feliz e um
caso de teste de caminho negativo com antecedência. Vamos considerar a história da Figura 16-3.
História PA-3
Como comprador em nosso site, quero excluir itens
fora do meu carrinho de compras, então não compro nada extra
itens que eu não quero.
Figura 16-3 História para excluir itens do carrinho de compras
O proprietário do produto esboça a IU desejada no quadro branco. Há um

caixa de seleção “excluir” ao lado de cada item e um botão “atualizar carrinho”. O usuário
pode selecionar um ou mais itens e clicar no botão para remover os itens. O
testes de alto nível podem ser:
Quando o usuário clica na caixa de seleção de exclusão ao lado do item e clica no botão
“atualizar carrinho”, a página é atualizada mostrando que o item não está mais no carrinho.
Quando o usuário clica nas caixas de seleção de exclusão ao lado de cada item do carrinho
e clica no botão “atualizar carrinho”, a página é atualizada mostrando um carrinho vazio.
(Isso gerará perguntas – o usuário deve ser direcionado para outra página? Um botão
“continuar comprando” deve ser exibido?)
Quando o usuário clica no botão “atualizar carrinho” sem marcar um item para exclusão,
a página é atualizada e nada é removido do carrinho.
Peça aos seus clientes para anotarem exemplos e casos de teste de alto nível antes
a iteração. Isto pode ajudá-los a refletir melhor sobre as histórias e a definir as suas condições de
satisfação. Também os ajuda a identificar quais recursos
são críticos e que podem esperar. Também ajuda a definir quando o
história é feita e gerencia as expectativas entre a equipe.
Figura 16-4 Exemplo de modelo de cliente
A Figura 16-4 mostra um modelo de amostra, onde o proprietário do produto marcou

alterações na página existente. Tenha cuidado ao usar uma captura de tela existente
de um sistema antigo, pois você correrá o risco de ter um novo sistema
parecer exatamente igual ao antigo, mesmo que não seja isso que você queria.
Os modelos são essenciais para histórias que envolvem a IU ou um relatório. Peça aos seus
clientes que elaborem ideias sobre a aparência da página. Compartilhe estes
ideias com a equipe. Uma ideia é escaneá-los e carregá-los no wiki
então todos têm acesso. Use-os como ponto de partida e faça mais protótipos de papel ou
desenhe-os no quadro branco. Estes podem ser fotografados e
carregado para membros remotos da equipe verem.
ESTRATÉGIAS DE TESTE
À medida que você aprende sobre as histórias da próxima iteração, pense em como abordar
o teste delas. Eles apresentam algum desafio especial de automação? São
alguma nova ferramenta necessária?
A história de Lisa Recentemente, nossa empresa precisou substituir o hardware da unidade de resposta de voz e o software de
interface de voz interativa. Um contratante deveria fornecer o software para operar o aplicativo de voz, mas
ele precisava interagir por meio de procedimentos armazenados com o banco de dados.
RECURSOS 381
Este foi um grande diferencial em relação a qualquer software em que havíamos trabalhado
antes, por isso foi útil ter um dia extra para pesquisar como outras equipes testaram esse tipo
de aplicativo antes do planejamento da primeira iteração que envolveu uma história
relacionada a esse projeto. Durante a sessão de planejamento da iteração, conseguimos
escrever tarefas pertinentes aos testes necessários e fornecer estimativas melhores.
—Lisa
Quando sua equipe embarca em um novo tipo de software, você pode decidir fazer um
pico de desenvolvimento para ver o que você pode aprender sobre como desenvolvê-lo. No
Enfrentando testes que ao mesmo tempo, tente um pico de teste para ter certeza de que você saberá como conduzir o
Apoiar o desenvolvimento com testes e como testar o software resultante. Se uma grande novidade
Equipe”, Capítulo 10,
um épico ou recurso está chegando, escreva alguns cartões para pesquisá-lo e realize reuniões de
brainstorming com uma ou duas iterações de antecedência. Isso ajuda você a saber o que
produto”, histórias e tarefas para planejar quando você realmente começar a programar. Uma ideia é ter um
e Capítulo 11, Equipe de “olheiros” que analisa quais soluções técnicas podem funcionar para histórias ou temas
“Criticando o
futuros.
Uso do produto
Tecnologia-
Facing Tests”,
fornece exemplos de PRIORIZAR DEFEITOS
ferramentas para diferentes
Em nosso mundo ideal, queremos zero defeitos no final de cada iteração e definitivamente no final do
tipos de testes.
lançamento. No entanto, reconhecemos que não vivemos numa
mundo ideal. Às vezes, temos defeitos de sistemas legados com os quais nos preocupar, e
às vezes, consertar um defeito simplesmente não tem valor alto o suficiente para ser corrigido pela empresa.
O que acontece com esses defeitos? Falaremos sobre estratégias no Capítulo 18,
“Codificação e Teste”, mas por enquanto, vamos apenas considerar que temos defeitos para
tratar.
Antes da próxima iteração é o momento ideal para revisar questões pendentes com
o cliente e fazer a triagem do valor de consertar versus deixá-los no sistema.
Aqueles que forem considerados necessários para serem consertados deverão ser agendados no
próxima iteração.
RECURSOS
Outra coisa a verificar antes da iteração é se sua equipe tem
todos os recursos necessários para concluir qualquer história de alto risco. Você precisa de alguma
especialistas que são compartilhados com outros projetos? Por exemplo, você pode precisar de um
especialista em segurança se uma das histórias representar um risco à segurança ou se tratar de um
recurso de segurança. Se o teste de carga for feito, você pode precisar de uma ferramenta especial ou ter
ajuda de um especialista em testes de carga de outra equipe ou até mesmo de um fornecedor que
fornece serviços de teste de carga. Esta é sua última chance de planejar com antecedência.
RESUMO
Sua equipe pode ou não precisar fazer qualquer preparação antes de uma iteração. Como as
prioridades mudam rapidamente no desenvolvimento ágil, você não quer
perder tempo planejando histórias que podem ser adiadas. No entanto, se você estiver prestes
implementar alguma nova tecnologia, embarcar em um novo tema complexo, espero
para economizar tempo no planejamento de iterações, ou se sua equipe estiver dividida em locais
diferentes, você pode achar que algum planejamento e pesquisa iniciais são produtivos.
Como testador, você pode fazer o seguinte:
Ajude os clientes a alcançar “clareza antecipada” – consenso sobre o

comportamento desejado de cada história – fazendo perguntas e obtendo
exemplos.
Seja proativo, aprenda sobre histórias complexas antes da iteração e certifique-se de
que estejam dimensionadas corretamente.
Você nem sempre precisa de preparação antecipada para poder começar a
trabalhar na próxima iteração. Não faça nenhuma preparação que não economize
tempo durante a iteração ou garanta mais sucesso no atendimento aos requisitos do
cliente.
Coordene entre diferentes locais e facilite a comunicação.
Existem muitas ferramentas para ajudar com isso.
Obtenha exemplos para ajudar a ilustrar cada história.
Desenvolva estratégias de teste antes da próxima iteração para recursos novos e
incomuns.
Faça a triagem e priorize os defeitos existentes para determinar se algum deve ser
agendado para a próxima iteração.
Determine se quaisquer recursos de teste necessários que não estejam disponíveis no

momento precisam ser alinhados para a próxima iteração.
Capítulo 17
INÍCIO DA ITERAÇÃO
Aprendendo os detalhes
Revise com os clientes
Alto nível Considerando todos os pontos de vista
Iteração
Revisão com programadores Testes e
Planejamento
Exemplos Escrevendo cartões de tarefas
Casos de teste como documentação
Decidindo sobre a carga de trabalho
Iteração
Começo
Colabore com
Histórias testáveis
os clientes
Os testadores ágeis desempenham um papel essencial durante o planejamento da iteração,

ajudando a planejar tarefas de teste e desenvolvimento. À medida que a iteração avança, os
testadores colaboram ativamente com clientes e desenvolvedores, escrevendo os testes de alto
nível que ajudam a orientar o desenvolvimento, obtendo e ilustrando exemplos, garantindo que
as histórias sejam testáveis. Vamos dar uma olhada mais de perto nas atividades do testador ágil
no início de cada iteração.
PLANEJAMENTO DE ITERAÇÃO
A maioria das equipes inicia sua nova iteração com uma sessão de planejamento. Isso pode ser
precedido por uma sessão retrospectiva, ou de “lições aprendidas”, para olhar para trás e ver o que
funcionou bem e o que não funcionou na iteração anterior. Embora os itens de ação da retrospectiva
ou sugestões de “iniciar, parar, continuar” afetem a iteração que está prestes a começar, falaremos
sobre a retrospectiva como uma atividade de fim de iteração no Capítulo 19, “Concluir a iteração”.
Ao planejar o trabalho para a iteração, a equipe de desenvolvimento discute uma história por vez,
escrevendo e estimando todas as tarefas necessárias para implementar
383
384 CAPÍTULO 17 INÍCIO DA ITERAÇÃO
Figura 17-1 Reunião de planejamento de iteração
essa história. Se você fez algum trabalho antes para se preparar para a iteração,
esta sessão de planejamento provavelmente será bastante rápida.
Equipes novas no desenvolvimento ágil geralmente precisam de muito tempo para iterar
sessões de planejamento. O planejamento da iteração geralmente demorava um dia inteiro quando Lisa
a equipe começou. Agora são feitas em duas ou três horas, o que inclui o tempo da retrospectiva. A equipe
de Lisa usa um projetor para exibir o usuário
casos de teste de aceitação e condições de satisfação de seu wiki para que
todos na equipe podem vê-los. Eles também projetam sua história online
ferramenta de tabuleiro, onde escrevem os cartões de tarefas. Outro componente tradicional
de suas reuniões de planejamento é um prato de guloseimas que eles se revezam no fornecimento.
A Figura 17-1 mostra uma reunião de planejamento de iteração em andamento.
Aprendendo os detalhes
Idealmente, o proprietário do produto e/ou outros membros da equipe do cliente participam
no planejamento da iteração, respondendo perguntas e fornecendo exemplos descrevendo os requisitos
de cada história. Se ninguém do lado comercial puder comparecer, os membros da equipe que trabalham
em estreita colaboração com os clientes, como analistas
e testadores, podem servir como proxies. Eles explicam detalhes e tomam decisões sobre
em nome dos clientes ou anote as perguntas para obter respostas rápidas. Se
PLANEJAMENTO DE ITERAÇÃO 385
sua equipe repassou histórias com os clientes antes da iteração,

você pode pensar que não precisa deles em mãos durante o planejamento da iteração
sessão. No entanto, sugerimos que eles estejam disponíveis caso você tenha
perguntas extras.
Como enfatizamos ao longo do livro, use exemplos para ajudar a equipe

entenda cada história e transforme esses exemplos em testes que impulsionam a codificação.
Aborde as histórias em ordem de prioridade. Se você ainda não leu histórias
com os clientes, o proprietário do produto ou outra pessoa que representa a equipe do cliente lê
primeiro cada história a ser planejada. Eles explicam o propósito
a história, o valor que ela agregará e dê exemplos de como será usada.
Isso pode envolver passar exemplos ou escrever em um quadro branco. IU
e reportagens podem já ter wireframes ou modelos que a equipe
pode estudar.
Uma prática que ajuda algumas equipes é escrever testes de aceitação do usuário para cada
história juntos, durante o planejamento da iteração. Junto com o proprietário do produto
e possivelmente outras partes interessadas, eles escrevem testes de alto nível que, quando
aprovados, mostrarão que a história está concluída. Isso também poderia ser feito em breve,
antes do planejamento da iteração, como parte do “trabalho de preparação” da iteração.
As histórias devem ser dimensionadas para que não levem mais do que alguns dias para serem concluídas.
Quando testamos pequenas histórias regularmente, não temos todas elas
terminado de uma vez e empilhado no final da iteração esperando para ser
testado. Se uma história passou pelas discussões de planejamento de lançamento e pré-iteração
e ainda é muito grande, esta é a última chance de dividi-la em partes menores.
peças. Mesmo uma pequena história pode ser complexa. A equipe pode realizar um exercício
para identificar as fatias finas ou o caminho crítico através da funcionalidade. Usar
exemplos para orientá-lo e encontrar os cenários de usuário mais básicos.
Os testadores ágeis, juntamente com outros membros da equipe, estão alertas para o “aumento do escopo”. Não
tenha medo de levantar uma bandeira vermelha quando uma história parece estar crescendo em todas as direções.
A equipe de Lisa faz um esforço consciente para apontar “bling” ou “bom ter”
componentes, que não são centrais para a funcionalidade da história. Esses podem ser
adiar para o final, ou adiar, caso a história demore mais do que o planejado para
terminar.
Considerando todos os pontos de vista
Como testador, você tentará colocar cada história no contexto do sistema maior
e avaliar o potencial de impactos imprevistos em outras áreas. Como você fez
na reunião de planejamento de lançamento, coloque-se nas diferentes mentalidades de
usuário, parte interessada no negócio, programador, redator técnico e todos os envolvidos na criação
e uso da funcionalidade. Agora você está trabalhando em um nível detalhado.
No capítulo de planejamento de lançamento, usamos este exemplo de história:
Como cliente, quero saber quanto custará o envio do meu pedido

com base na velocidade de envio que eu escolher, então posso alterar se quiser.
Decidimos pegar uma “fatia fina” e mudar essa história para assumir que só existe
uma velocidade de envio. As outras velocidades de envio serão histórias posteriores. Por esta
história, precisamos calcular o custo de envio com base no peso do item e no destino, e decidimos
usar a API do BigExpressShipping para o cálculo.
Nossa história agora é mostrada na Figura 17-2.
História PA-5
Como cliente, quero saber quanto custa meu pedido
custará o envio para entrega padrão de 5 dias com base
peso e destino, para que eu possa decidir se
essa é a opção de frete que eu quero.
Figura 17-2 Velocidade de envio da história para entrega em 5 dias
A equipe começa a discutir a história.
Testador: “Esta história se aplica a todos os itens disponíveis no site? Algum item é muito
pesado ou desqualificado para entrega em 5 dias?
Dono do produto: “O terreno de 5 dias está disponível para todos os nossos itens. São
os períodos noturno e de 2 dias que estão restritos a menos de 25 libras.
Testador: “Qual é o objetivo aqui, do ponto de vista comercial? Facilitando o cálculo do

custo para agilizar a finalização da compra? Você está esperando
incentive-os a verificar os outros métodos de envio – são mais lucrativos?”
Product Owner: “A facilidade de uso é o nosso principal objetivo, queremos que o

processo de checkout seja rápido e queremos que o usuário determine facilmente o custo
total do pedido para que não tenha medo de finalizar a compra.”
Programador: “Poderíamos exibir o custo de envio de 5 dias como padrão assim que o
usuário inserir o endereço de envio. Quando fazemos os stories para as outras opções
de frete, podemos colocar botões para exibir esses custos rapidamente.”
Dono do Produto: “É isso que queremos: antecipar os custos. Vamos comercializar nosso
site como o mais amigável ao cliente.”
Testador: “Existe alguma maneira de o usuário errar? O que eles farão nesta página?
Dono do produto: “Quando adicionamos as outras opções de envio, eles podem optar
por alterar sua opção de envio. Mas, por enquanto, é realmente simples. Já temos
validação para garantir que o código postal corresponde à cidade inserida no endereço de
entrega.”
Testador: “E se eles perceberem que erraram no endereço de entrega?

Talvez eles tenham fornecido acidentalmente o endereço de cobrança. Como eles podem
voltar para alterar o endereço de entrega?”
Programador: “Colocaremos botões para editar endereços de cobrança e envio, assim

será muito fácil para o usuário corrigir erros. Mostraremos ambos os endereços nesta
página onde o custo de envio é exibido. Podemos estender isso mais tarde, quando
adicionarmos a opção de vários endereços de entrega.”
Testador: “Isso tornaria a IU fácil de usar. Eu sei que quando faço compras on-line, fico
chateado por não poder ver o custo do frete até a confirmação do pedido. Se o frete for
ridiculamente caro e eu não quiser continuar, já perdi tempo. Queremos garantir que os
usuários não fiquem presos no processo de finalização da compra, fiquem frustrados e
simplesmente desistam. Então, a próxima página que eles verão é a página de confirmação
do pedido. Existe alguma chance de o custo de envio ser diferente quando o usuário
acessar essa página?
Programador: “Não, a API que nos dá o custo estimado deve sempre corresponder ao
custo real, desde que os mesmos itens ainda estejam no carrinho de compras.”
Dono do produto: “Se eles alterarem as quantidades ou excluirem algum item, precisamos
garantir que o custo de envio seja alterado imediatamente para refletir isso.”
Como você pode perceber pela conversa, muitos esclarecimentos vieram à tona. Todos na equipe
agora têm um entendimento comum da história. É importante falar sobre todos os aspectos da
história. Escrever testes de aceitação do usuário como um
grupo é uma boa maneira de garantir que a equipe de desenvolvimento entenda o
requisitos do cliente. Vamos continuar monitorando essa conversa.
Testador: “Vamos apenas escrever alguns testes rápidos para ter certeza de que acertamos.”
Cliente: “OK, que tal esse exemplo?
Posso selecionar dois itens com opção de envio em 5 dias e ver meu
custos imediatamente.
Testador: “Ótimo começo, mas não saberemos para onde enviá-lo nesse momento.
Que tal um teste mais genérico como:
Verifique se o custo de envio de 5 dias é exibido como padrão assim que o

o usuário insere um endereço de entrega.
Cliente: “Isso funciona para mim.”
Considerando todas as facetas

Paul Rogers relata uma situação durante uma reunião de planejamento de iteração, onde surgiu
um problema de desempenho para uma história que parecia simples e rápida.
Durante nossa reunião de iteração, uma das histórias que discutimos foi sobre a adição de
algumas novas imagens a parte de uma aplicação web. Essa discussão se seguiu.
Dono do produto: “Gostaria também de entrar na história para obter imagens adicionais.”
Desenvolvedor 1: “OK, quem tem ideia de quanto tempo vai demorar?”
Desenvolvedor 2: “É bastante rápido, talvez meio dia.”
Desenvolvedor 3: “Mas e as mudanças no banco de dados?”
Desenvolvedor 2: “Incluí isso na estimativa.”
Desenvolvedor 1: “OK, vamos com meio dia.”
Eu: “Espere aí. Analisamos alguns problemas de desempenho na última iteração.

Se adicionarmos todas essas imagens, teremos um impacto no desempenho.
Desenvolvedor 1: “OK, deveríamos pensar um pouco mais sobre isso. Talvez existam
outras maneiras de implementá-lo.
Desenvolvedor 2: “Por que não fazemos um pico rápido, adicionamos as imagens simuladas
e executamos outro teste de desempenho?”
Foi muito bom que essa discussão antes mesmo de começar uma história nos deu algumas
ideias sobre os problemas que podemos encontrar.
Qualquer pessoa que não tenha certeza sobre o impacto de uma história no resto do sistema ou sobre a
dificuldade de desenvolver a funcionalidade pode, e deve, levantar uma questão durante o planejamento
da iteração. É melhor abordar a incerteza desde o início e depois fazer mais pesquisas ou fazer um pico
para obter mais informações.
Fazer perguntas com base em diferentes pontos de vista ajudará a esclarecer a história
e permitir que a equipe faça um trabalho melhor.
Escrevendo cartões de tarefas
Quando sua equipe tiver um bom entendimento de uma história, você poderá começar a escrever
e estimando cartões de tarefas. Como o desenvolvimento ágil impulsiona a codificação com
testes, escrevemos cartões de tarefas de teste e desenvolvimento ao mesmo tempo.
Se você fez algum pré-planejamento, talvez já tenha alguns cartões de tarefas

escrito. Caso contrário, escreva-as durante a reunião de planejamento da iteração. Isto
não importa quem escreve os cartões de tarefas, mas todos na equipe devem
revise-os e tenha a oportunidade de dar sua opinião. Reconhecemos que as tarefas podem
serão adicionados quando começarmos a codificar, mas reconhecer a maioria das tarefas e estimá-
las durante a reunião dá à equipe uma boa noção do que está envolvido.
Quando nossa equipe está pronta para começar a escrever cartões de tarefas, os programadores geralmente
A história de Lisa
criam os cartões de tarefas de codificação. Os testadores escrevem cartões de tarefas de teste ao mesmo tempo.
Normalmente começo com um cartão para escrever casos de teste de alto nível. Pergunto aos
programadores se a história pode ser testada por trás da GUI e escrevo cartões de tarefas de teste de
acordo. Isso geralmente significa um cartão de teste para “Escrever casos de teste do FitNesse” e um cartão
de tarefas do desenvolvedor para “Escrever acessórios do FitNesse”, a menos que os acessórios já existam.
Às vezes, todos os testes por trás da GUI podem ser abordados mais facilmente em testes unitários, por isso é
sempre bom perguntar se esse é o caso.
Colocamos tudo o que a equipe precisa lembrar durante a iteração em um cartão de tarefas.
“Mostrar UI para Anne” ou “Enviar arquivos de teste para Joe” aparecem no storyboard junto com todas as outras
tarefas.
Eu estimo os cartões de tarefas de teste à medida que prossigo e peço feedback à equipe sobre os
cartões e as estimativas. Às vezes nos dividimos em grupos, e cada grupo pega algumas histórias e escreve
cartões de tarefas para elas. Sempre analisamos todos os cartões em conjunto, juntamente com o tempo
estimado. Se o tempo de desenvolvimento for relativamente baixo comparado ao tempo de teste, ou vice-
versa, isso provoca uma discussão. Chegamos a um consenso sobre se achamos que todos os aspectos da
história foram cobertos com cartões de tarefas. Se ainda houver algumas incógnitas, simplesmente adiamos
a escrita dos cartões de tarefas até termos a informação.
Todos os cartões de teste e desenvolvimento vão para o storyboard na coluna “tarefas”. Qualquer pessoa
da equipe pode se inscrever em qualquer cartão. Alguns cartões de tarefas de teste passam para a coluna
“trabalho em andamento” ou “concluído” antes que os cartões de codificação comecem a se mover, para que
os programadores tenham alguns testes para orientar sua codificação. À medida que os cartões de tarefas de
codificação são movidos para a coluna “concluído”, os cartões para testar a funcionalidade “concluído” são
movidos para “trabalho em andamento”.
—Lisa
Janet usa uma abordagem semelhante a esta, mas o cartão de codificação do programador
permanece na coluna “Para testar” até que a tarefa de teste seja concluída. Ambos
os cartões são movidos ao mesmo tempo para a coluna “Concluído”.
Três cartões de teste para Story PA-5 (Figura 17-2), exibindo o custo de envio para 5-
entrega por dia com base no peso e destino, que a equipe de Lisa pode escrever são:
Escreva testes FitNesse para calcular o custo de envio de 5 dias com base no
peso e no destino.
Escreva testes WebTest para exibir o custo de envio em 5 dias.
Teste manualmente a exibição do custo de entrega em 5 dias.
Algumas equipes preferem escrever tarefas de teste diretamente na tarefa de desenvolvimento

cartões. É uma solução simples, porque a tarefa obviamente não está “concluída” até que o
o teste está concluído. Você está tentando evitar uma abordagem de “mini-cascata”, onde
o teste é feito por último, e o programador sente que terminou porque “enviou
a história para o controle de qualidade.” Veja qual abordagem funciona melhor para sua equipe.
Se a história envolver fortemente partes externas ou recursos compartilhados, escreva a tarefa

cartões para garantir que essas tarefas não sejam esquecidas e faça estimativas generosas
o suficiente para permitir dependências e eventos além do controle da equipe. Nossa equipe
hipotética que trabalha na história dos custos de envio precisa trabalhar
com a API de cálculo de custos do remetente.
Testador: “Alguém sabe com quem trabalhamos no BigExpressShipping para obter especificações
sobre sua API? O que passamos para eles, apenas o peso e o CEP? Já temos acesso para
testar isso?”
Scrum Master: “Joe da BigExpressShipping é nosso contato e ele já enviou este documento
especificando o formato de entrada e saída. Eles ainda precisam autorizar o acesso do nosso
sistema de teste, mas isso deve ser feito em alguns dias.”
Testador: “Ah, que bom, precisamos dessas informações para escrever casos de teste.
Escreveremos um cartão de teste apenas para verificar se podemos acessar sua API e receber
de volta o custo de envio. Mas como sabemos que o custo está realmente correto?”
Scrum Master: “Joe nos forneceu alguns casos de teste para peso, código postal e custo
esperado, para que possamos enviar essas entradas e verificar a saída correta. Também temos
esta planilha mostrando as taxas para alguns códigos postais diferentes.”
Testador: “Devemos reservar bastante tempo apenas para ter certeza de que estamos
acessando sua API corretamente. Vou colocar uma estimativa alta neste cartão para verificar
usando a API para teste. Talvez o cartão do desenvolvedor para a interface da API também
deva ter uma estimativa bastante conservadora.”
Ao escrever cartões de tarefas do programador, certifique-se de que as estimativas das tarefas de codificação
inclua tempo para escrever testes unitários e para todos os testes necessários por parte dos
programadores. Um cartão para testes “ponta a ponta” ajuda a garantir que os programadores
trabalhando em tarefas diferentes e independentes, verifique se todas as peças funcionam juntas. Os
testadores devem ajudar a garantir que todos os cartões necessários estejam escritos e que
eles têm estimativas razoáveis. Você não quer estimativas duvidosas, mas se
as estimativas de teste são duas vezes maiores que as estimativas de codificação, pode ser
vale a pena falar.
Algumas equipes continuam testando tarefas para um dia de trabalho ou menos e não se preocupam em
escreva horas estimadas no cartão. Se um cartão de tarefa ainda estiver disponível após um dia
trabalho, a equipe fala sobre por que isso aconteceu e escreve novos cartões para ir
avançar. Isso pode reduzir despesas gerais e manutenção de registros, mas se você
estão inserindo tarefas em seu sistema eletrônico, talvez não. Faça o que faz
sentido para sua equipe.
Estimar o tempo para correção de bugs também é sempre complicado. Se os defeitos existentes forem
puxado como histórias, é muito simples. Mas e os bugs que são
encontrado como parte da iteração?
Com novas equipes ágeis, descobri que elas sempre acabam gastando um tempo em bugs que não
foi alocado como parte de suas estimativas para as histórias. Com o tempo, os programadores
aprendem quanto tempo normalmente gastam corrigindo bugs de uma história e podem simplesmente
adicionar meio dia ou algumas horas às suas tarefas para esse propósito. Testar novamente as
correções de bugs também adiciona tempo às estimativas do testador.
Até que os membros da equipe entendam isso, pode ser apropriado monitorar o tempo gasto na
correção e teste de bugs separadamente. Minha equipe atual adiciona uma história no XPlanner
com tarefas para corrigir e testar os bugs que não foram detectados imediatamente. Estamos
monitorando o tempo para que possamos estimar melhor no futuro.
—Janet
Seja como for, sua equipe escolhe estimar o tempo gasto para corrigir defeitos durante
a iteração, seja ela incluída na estimativa da história ou monitorada separadamente, certifique-se de
que seja feita de forma consistente.
Outro item a considerar ao estimar tarefas de teste são os dados de teste. O início de uma iteração
é quase tarde demais para pensar nos dados que você precisa
teste com. Como mencionamos no Capítulo 15, “Atividades do testador em lançamento ou
Theme Planning”, pense nos dados de teste durante o planejamento do lançamento e pergunte ao
clientes para ajudar a identificá-lo e obtê-lo. Certamente pense nisso enquanto se prepara
para a próxima iteração. Quando a iteração começa, quaisquer dados de teste que estejam faltando
deve ser criado ou obtido, então não se esqueça de levar isso em consideração nas estimativas.
Trabalhamos um tema relacionado aos extratos contábeis trimestrais dos participantes de planos de
A história de Lisa
aposentadoria. Estávamos modificando um trabalho mensal que tira um “instantâneo” da conta
de cada participante na data especificada. O snapshot depende de uma enorme quantidade de
dados no banco de dados de produção, incluindo milhares de transações diárias. Planejamos com
antecedência.
Para a primeira iteração, fizemos algumas histórias sobre o tema sabendo que só poderíamos
testar alguns casos usando alguns planos de aposentadoria individuais para os quais tínhamos
dados no banco de dados de teste. Também sabíamos que precisávamos de um teste em maior
escala, com todos os planos de aposentadoria no banco de dados e pelo menos um mês inteiro de
dados. Escrevemos um cartão de tarefas para copiar dados de produção suficientes para
produzir um “instantâneo” mensal e garantimos que os dados fossem limpos para proteger a privacidade.
Em seguida, planejamos o teste completo na próxima iteração. Esses dados permitiram que os
testadores encontrassem problemas que antes eram indetectáveis, quando apenas dados parciais
estavam disponíveis. Foi um bom equilíbrio entre dados “suficientes” para fazer a maior parte da
codificação e a quantidade total disponível a tempo de verificar a funcionalidade completa. Como a
equipe planejou com antecedência, os bugs foram corrigidos a tempo para o lançamento crítico.
—Lisa
HISTÓRIAS TESTÁVEIS 393
Decidindo sobre a carga de
trabalho Nós, como equipe técnica, controlamos nossa própria carga de trabalho. À medida que
escrevemos tarefas para cada história e as publicamos em nosso storyboard (real ou virtual),
somamos as horas estimadas ou verificamos visualmente a quantidade de cartões. Quanto
trabalho podemos realizar? No XP, não podemos exceder o número de pontos de história que
completamos na última iteração. No Scrum, nos comprometemos com um conjunto de histórias
com base no tempo real que achamos que precisamos para concluí-las.
A equipe atual de Lisa tem vários anos de experiência em processos ágeis e descobre que às
vezes perde tempo escrevendo cartões de tarefas para histórias que talvez não tenham tempo de
fazer durante a iteração. Eles começam com histórias suficientes para manter todos ocupados. À
medida que as pessoas começam a se liberar, elas contam mais histórias e planejam as tarefas
relacionadas. Eles podem ter algumas histórias prontas “no convés” para serem apresentadas
assim que terminarem as iniciais. Isso parece fácil, mas é difícil de fazer até que você tenha
aprendido o suficiente para ter mais confiança sobre o tamanho das histórias e a velocidade da
equipe e saber o que sua equipe pode ou não fazer em um determinado período de tempo e em
circunstâncias específicas.
Seu trabalho como testador é garantir que seja alocado tempo suficiente para os testes e lembrar
à equipe que o teste e a qualidade são responsabilidade de toda a equipe. Quando a equipe
decide quantas histórias podem entregar na iteração, a pergunta não é “Quanto código podemos
terminar?” mas “Quanta codificação e testes podemos concluir?” Haverá momentos em que uma
história será fácil de codificar, mas o teste consumirá muito tempo. Como testador, é importante
que você aceite na iteração apenas o número de histórias que podem ser testadas.
Se você tiver que se comprometer, comprometa-se de forma conservadora. É sempre melhor

trazer outra história do que ter que abandonar uma. Se você tiver histórias de alto risco que são
difíceis de estimar, ou se algumas tarefas forem desconhecidas ou precisarem de mais pesquisas,
escreva cartões de tarefas para uma ou duas histórias extras e deixe-os prontos à margem para
serem trazidos no meio da iteração.
Como equipe, vamos sempre dar o nosso melhor. Precisamos lembrar que nenhuma história está
pronta até ser testada, então planeje adequadamente.
HISTÓRIAS TESTÁVEIS
Quando você estiver olhando histórias e os programadores começarem a pensar em
implementação, sempre pense em como você pode testá-las. Um exemplo ajuda muito a “testar a
testabilidade”. Que impacto isso terá em meus testes? A Parte III, “Os quadrantes de testes
ágeis”, dá muitos exemplos de como
projetar o aplicativo para permitir testes eficazes. Esta é sua última oportunidade de pensar sobre a
testabilidade de uma história antes de começar a codificação.
Uma equipe com quem trabalhei me contou sobre os problemas que teve na versão anterior.
A equipe estava reescrevendo a primeira etapa de um processo de várias etapas. O que eles
não previram foi que, quando o desenvolvimento da nova etapa começou, o resto do processo foi
interrompido. Nenhum teste poderia ser feito em quaisquer outras alterações nessa iteração até
que toda a primeira etapa fosse concluída.
A testabilidade não foi considerada no planejamento da história. Na versão seguinte, quando

decidiram reescrever a segunda etapa, aprenderam com o erro anterior. Os programadores
criaram um botão extra na página que permitia aos testadores chamar a nova página (em fluxo)
ou a página antiga para testar outras histórias.
Lembre-se de perguntar: “Como podemos testar isso?” se não for óbvio para você.
—Janet
Durante o planejamento da iteração, pense nos tipos de variações que você precisará
testar. Isso pode gerar outras questões.
Durante uma reunião de planejamento de iteração em que participei, os programadores
começaram a conversar sobre implementação e a fazer desenhos no quadro branco para mostrar
o que estavam pensando.
Pensei um pouco e fiz a pergunta: “Isso pode ser feito de forma mais simples?
As permutações e combinações para testar a implementação proposta tornarão os testes
horríveis.”
Os programadores pensaram por alguns minutos e sugeriram uma alternativa que não apenas
atendesse às necessidades do cliente, mas também fosse mais simples e fácil de testar.
Foi uma combinação ganha-ganha para todos.
—Janet
Quando a testabilidade for um problema, faça com que o problema seja resolvido pela equipe. Equipes que
começar seu planejamento escrevendo cartões de tarefas de teste provavelmente terá uma vantagem
aqui, porque ao pensarem sobre suas tarefas de teste, eles perguntarão como a história
pode ser testado. Alguma funcionalidade pode ser testada por trás da GUI? É possível
fazer os testes voltados para os negócios em nível de unidade? Toda equipe ágil deve ser
pensando primeiro no teste. À medida que sua equipe escreve cartões de tarefas de desenvolvedor para uma história, pense
sobre como testar a história e como automatizar os testes dela. Se os programadores ainda não têm o
hábito de codificar TDD ou automatizar testes unitários, tente
HISTÓRIAS TESTÁVEIS 395
escrever um cartão de tarefas “XUnit” para cada história. Escreva cartões de tarefas de programação para
quaisquer acessórios de automação de teste que serão necessários. Pense na aplicação
mudanças que podem ajudar nos testes, como propriedades de tempo de execução e APIs.
O aplicativo em que trabalho tem muitas atividades que dependem de data e hora.
A história de Lisa
Os programadores adicionaram uma propriedade de servidor de tempo de execução ao aplicativo da web
para definir a data do servidor. Posso especificar uma substituição de data e hora e, quando o servidor for
inicializado, ele se comportará de acordo. Isso permite iniciar processos mensais ou trimestrais com uma
simples substituição. Esta propriedade ajudou a testar uma ampla variedade de histórias.
Markus Gärtner [2008] nos disse que sua equipe tem uma propriedade semelhante, um “DATE_OFFSET”
contados em “dias para avançar”. No entanto, isso foi usado apenas pelos componentes Java da aplicação
onde reside a lógica de negócios. Os sistemas back-end em C e C++ não usam o deslocamento de data,
o que causou um problema.
—Lisa
Se você tiver problemas semelhantes porque outras equipes estão desenvolvendo partes do sistema,
escreva um cartão de tarefas para discutir o problema com a outra equipe e venha
encontrar uma solução coordenada. Se trabalhar com a outra equipe não for uma opção, reserve um
tempo para pensar em outra solução. No mínimo, esteja atento às limitações, ajuste as estimativas de
teste de acordo e gerencie
o risco associado.
Iniciamos um projeto para substituir o sistema interativo de resposta de voz (IVR) de nossa empresa, que
A história de Lisa
permite aos participantes de planos de aposentadoria obter informações de contas e gerenciar contas por
telefone. Contratamos outra empresa para escrever o sistema em Java, com a intenção de que nossa
equipe o mantivesse após um determinado período de tempo.
Passamos algum tempo pensando em quais testes seriam necessários e como fazê-los. Presumivelmente, o
contratante testaria coisas como a funcionalidade de conversão de texto em fala, mas tivemos que fornecer
procedimentos armazenados para recuperar dados apropriados do banco de dados.
Nosso primeiro passo foi negociar com o empreiteiro a entrega de pequenos pedaços de recursos em
iteração, para que pudessem ser testados à medida que o projeto avançasse e o trabalho fosse distribuído
uniformemente ao longo da vida do contrato. Decidimos testar os procedimentos armazenados usando
acessórios FitNesse e exploramos as opções. Optamos pelo PL/SQL para acessar os procedimentos
armazenados. Um programador foi encarregado de se familiarizar com PL/SQL para lidar com a
A equipe buscou uma abordagem passo a passo. Ao alocar bastante tempo para as tarefas no início,
permitimos as curvas de aprendizado acentuadas envolvidas.
Curiosamente, o contratante entregou uma construção inicial para a primeira iteração, mas
não foi capaz de entregar os incrementos de código para as próximas iterações. Acabamos
cancelando o contrato e adiando o projeto até encontrarmos uma solução melhor. Ao forçar
o empreiteiro a trabalhar em incrementos, descobrimos imediatamente que ele não
conseguiria cumprir. E se tivéssemos deixado que levassem seis meses para redigir o
requerimento completo? Provavelmente não teria terminado bem. Colocamos em
bom uso o que aprendemos na pesquisa de uma abordagem melhor.
—Lisa
Quando você estiver embarcando em algo novo para a equipe, como uma nova estrutura de modelos
ou biblioteca de relatórios, lembre-se de incluí-la como um risco no
seu plano de teste. Esperançosamente, sua equipe considerou a testabilidade antes de escolher uma
nova estrutura ou ferramenta e selecionou uma que melhorasse sua capacidade de
teste. Seja generoso com suas estimativas de tarefas de teste com tudo que é novo, incluindo novos
domínios, porque há muitas incógnitas. Às vezes novo
conhecimento de domínio ou nova tecnologia significa uma curva de aprendizado acentuada.
COLABORAR COM OS CLIENTES

Trabalhar em estreita colaboração com clientes, ou representantes de clientes, como analistas
funcionais, é uma de nossas atividades mais importantes como testadores ágeis. Assim que você começar
Após a iteração, a colaboração do cliente também entrará em alta velocidade. Esse
é o momento de realizar todas as boas atividades descritas no Capítulo 8, “Testes voltados para os
negócios que apoiam a equipe”. Peça exemplos aos clientes, pergunte
perguntas abertas sobre a funcionalidade e comportamento de cada história, têm
discussões no quadro branco e depois transformar esses exemplos em testes
para conduzir a codificação.
Mesmo que o proprietário do produto e/ou outros clientes tenham explicado as histórias antes e durante
o planejamento da iteração, às vezes é útil repassá-las
brevemente mais uma vez quando a iteração começa. Nem todo mundo pode ter ouvido isso
antes, e o cliente pode ter mais informações.
Começamos a escrever testes de aceitação de alto nível no primeiro dia da iteração. Como
A história de Lisa
analisamos todas as histórias com o proprietário do produto no dia anterior à iteração e
escrevemos testes de aceitação do usuário em equipe para as histórias mais complexas,
temos uma boa ideia do que é necessário. No entanto, o ato de escrever mais casos de
teste muitas vezes traz à tona novas questões. Repassamos os testes de alto nível e
quaisquer dúvidas que tenhamos com o product owner, que também tem pensado mais nas histórias.
TESTES E EXEMPLOS DE ALTO NÍVEL 397
Um exemplo disso foi uma história que envolvia um arquivo de distribuições monetárias para
participantes do plano que retirassem dinheiro de suas contas de aposentadoria. Esse arquivo
é enviado a um parceiro que utiliza as informações para passar cheques ao participante. Os
valores em alguns registros não estavam sendo reconciliados corretamente no sistema do
parceiro, e o parceiro solicitou uma nova coluna com um valor para permitir a reconciliação.
Após a reunião de planejamento da iteração, nosso proprietário do produto ficou preocupado

com o fato de a nova coluna não ser a solução certa e levantou suas dúvidas na reunião de
revisão da história. Ele e um testador estudaram mais a fundo o problema e descobriram que,
em vez de adicionar um novo valor, um cálculo precisava ser alterado. Na verdade, essa era
uma história maior, mas abordava um problema central das distribuições. A equipe discutiu a
história mais ampla e escreveu novos cartões de tarefas. Valeu a pena dedicar um pouco mais
de tempo para discutir mais a história, porque o entendimento inicial acabou se revelando errado.
—Lisa
Uma boa comunicação geralmente dá trabalho. Se você não estiver aproveitando oportunidades
suficientes para fazer perguntas e revisar casos de teste, vá em frente e agende reuniões
regulares para fazer isso. Se não houver muito o que discutir, as reuniões serão
rapidamente. O tempo gasto em uma reunião para uma discussão esclarecedora pode economizar codificação e
teste mais tarde, porque você terá mais certeza dos requisitos.
TESTES E EXEMPLOS DE ALTO NÍVEL

Queremos testes de “visão geral” para ajudar os programadores a começar da maneira certa
direção em uma história. Como sempre, recomendamos começar com exemplos e
transformando-os em testes. Você terá que experimentar para ver quantos detalhes são
apropriado no nível do teste de aceitação antes do início da codificação. A equipe de Lisa tem
descobriram que testes de alto nível extraídos de exemplos são o que eles precisam para começar
uma história.
Os testes de alto nível devem transmitir o objetivo principal da história. Eles podem
inclua exemplos de comportamento desejado e indesejado. Para o nosso anterior
Na história PA-5 (Figura 17-2) que pede para mostrar o custo de envio para entrega em 5 dias
com base no peso e destino do pedido, nossos testes de alto nível podem
incluir:
Verifique se o custo de envio de 5 dias é exibido como padrão assim que o usuário
insere um endereço de entrega.
Verifique se o custo de envio estimado corresponde ao custo de envio na fatura final.
Verifique se o usuário pode clicar em um botão para alterar o endereço de entrega e,

quando isso for feito, o custo de frete atualizado será exibido.
Verifique se o usuário exclui itens do carrinho ou adiciona itens ao carrinho, a opção de
envio atualizada é exibida.
Não se limite às palavras de uma página wiki ao escrever

Consulte a bibliografia
testes. Por exemplo, uma matriz de teste como a mostrada na Figura 15-7 pode
para obter links
para mais informações trabalhe melhor. Algumas pessoas expressam testes graficamente, usando desenhos de fluxo de trabalho
sobre testes gráficos e fotos. Brian Marick [2007] possui uma técnica para desenhar testes gráficos que
e desenvolvimento
podem ser transformados em scripts de teste Ruby. O desenvolvimento orientado a modelos
orientado a modelos.
fornece outra maneira de expressar o escopo de alto nível de uma história. Os casos de uso são
outro caminho possível para expressar o comportamento desejado no nível do “quadro geral”.
Uma imagem vale mais que mil palavras

O ditado “Uma imagem vale mais que mil palavras” também pode ser aplicado a casos de teste e
validações de teste.
Paul Rogers [2008] tem experimentado algumas ideias interessantes sobre isso e explica a abordagem
de sua equipe para o problema na barra lateral a seguir. A Figura 17-3 mostra o modelo de UI que
ele descreve.
O aplicativo em que trabalho é de natureza muito gráfica. Ele permite que um usuário modifique
uma página da web adicionando “aprimoramentos de fotos”, como óculos, chapéus ou balões de
fala às imagens, ou destacando o texto na página da web com um efeito de caneta marca-
texto.
Há um conjunto complexo de regras de negócios sobre quais acréscimos podem ser aplicados
às imagens, como e onde eles são afixados e como podem ser girados. Para explicar os testes
dessas regras, foi muito mais simples desenhar um esboço de uma página web típica com os
diferentes tipos de acréscimos e adicionar pequenas notas a cada imagem.
O realce do texto também apresentou muitos desafios. As mais problemáticas eram as áreas
onde o realce do texto cobria apenas parte de uma tag HTML. Para descrever o que deve
ser esperado em muitas situações diferentes, criamos diferentes páginas da web e as imprimimos.
Usando marcadores de caneta reais, destacamos as áreas que esperávamos mostrar como
destacadas após iniciar e terminar em determinadas áreas. Dessa forma, tivemos um teste de
regressão de fácil leitura.
Ferramentas de baixa tecnologia podem desvendar o mistério do design complexo de aplicativos.

Encontre maneiras de expressar regras de negócios da maneira mais simples possível e compartilhe-
as com toda a equipe.
Figura 17-3 Exemplo de técnica de modelagem de UI
Os modelos podem transmitir requisitos para uma IU ou relatório de forma rápida e clara. Se
Veja o modelo de
um relatório existente precisa ser modificado, faça uma captura de tela do relatório e use
amostra das
mudanças na interface marcadores, caneta, lápis ou qualquer outra ferramenta útil. Se você quiser capturar
do usuário no eletronicamente, experimente o programa Windows Paint ou outra ferramenta gráfica para
Capítulo 16, “Comece a correr”. desenhe as alterações e publique-as na página wiki que descreve o relatório
requisitos.
As equipes distribuídas precisam de testes de alto nível disponíveis eletronicamente, enquanto as

9, “Kit de
equipes co-localizadas podem trabalhar bem a partir de desenhos em um quadro branco ou até mesmo de
ferramentas para negócios fazer com que o cliente se sente com eles e lhes diga os requisitos conforme eles
Testes que apoiam a código.
equipe”, para
algumas ideias
O que é importante ao iniciar a iteração é que você aprenda rapidamente os requisitos básicos de
sobre ferramentas
para coletar e comunicar cada história e os expresse no contexto de uma forma que
requisitos. funciona para toda a equipe. A maioria das equipes ágeis com quem conversamos dizem que seus maiores
O problema é entender cada história bem o suficiente para entregar exatamente o que o
cliente queria. Eles podem produzir código tecnicamente livre de erros, mas
não corresponde exatamente à funcionalidade desejada pelo cliente. Ou eles podem acabar
fazer muito retrabalho em uma história durante a iteração à medida que o cliente esclarece os requisitos
e, como resultado, fica sem tempo para concluir outra história.
Dedique tempo e esforço para experimentar diferentes maneiras de capturar e

expresse os testes de alto nível de uma forma que se adapte ao seu domínio e ambiente.
Testes que apoiam a equipe”, Janet gosta de dizer que um requisito é uma combinação de história + conversa + um cenário de
para saber mais sobre usuário ou imagem de apoio, se necessário + um teste de coaching ou
o que constitui um
exemplo.
requisito.
Revendo com clientes

No início deste capítulo, falamos sobre a importância do contato constante com o cliente.
colaboração. A revisão de testes de alto nível com os clientes é uma boa oportunidade para
colaboração reforçada e comunicação aprimorada, especialmente para
uma nova equipe ágil. Depois que sua equipe adquirir o hábito de falar continuamente sobre
histórias, requisitos e casos de teste, talvez você não precise sentar e ir
em cada caso de teste.
Se sua equipe está contratando para desenvolver software, requisitos e casos de teste
podem ser resultados formais que você deve apresentar. Mesmo que não sejam, é
uma boa ideia fornecer os casos de teste em um formato que os clientes possam facilmente
leia por conta própria e entenda.
Revendo com programadores

Você pode ter todos os diagramas e páginas wiki do mundo, mas se ninguém
olha para eles, eles não vão ajudar. A comunicação direta é sempre melhor. Sentar-se
com os programadores e analise os testes e requisitos de alto nível. Ir
em diagramas de quadro branco ou protótipos de papel juntos. A Figura 17-4 mostra um
testador e um programador discutindo um diagrama de fatias finas ou fios através
um fluxo de trabalho do usuário. Se você estiver trabalhando com um membro da equipe em outro local,
encontre uma maneira de agendar uma conversa telefônica. Se os membros da equipe tiverem problemas
compreendendo os testes e requisitos de alto nível, você saberá que deve tentar uma abordagem
diferente na próxima vez.
Programadores com bom conhecimento do domínio podem entender uma história corretamente
longe e ser capaz de começar a codificar antes mesmo de os testes de alto nível serem escritos. Até
então, é sempre uma boa ideia revisar as histórias do cliente e do testador
perspectiva com os programadores. A compreensão deles da história pode
Figura 17-4 Uma discussão no quadro branco
ser diferente do seu e é importante observar as incompatibilidades. Lembrar

O Capítulo 2, “Dez
a regra do “Poder de Três” e conquiste um cliente se houver duas opiniões que você
princípios para
testadores ágeis”,
não consigo conciliar. Os casos de teste também ajudam a contextualizar a história com o resto
apresenta o “Poder do aplicativo. Os programadores podem usar os testes para ajudá-los a codificar o
regra de três”.
história corretamente. Esta é a principal razão pela qual você deseja fazer isso o mais próximo possível
o início da iteração possível - antes que os programadores comecem a codificar.
Não se esqueça de perguntar aos programadores o que eles acham que você perdeu.
Quais são as áreas de alto risco do código? Onde eles acham que os testes
deve ser focado? Obter uma perspectiva mais técnica ajudará no projeto de casos de teste detalhados.
Se você criou uma matriz de teste, talvez queira revisar
as áreas impactadas novamente também.
Um efeito colateral benéfico da revisão dos testes com os programadores é a

aprendizagem cruzada que acontece. Você, como testador, está exposto ao que eles são
pensando, e aprendem algumas técnicas de teste que não usariam
de outra forma encontrei. Como programadores, eles podem compreender melhor quais testes de alto
nível não consideraram.
Casos de teste como documentação
Casos de teste de alto nível, juntamente com os testes executáveis que você escreverá durante o
iteração, formará o núcleo da documentação do seu aplicativo. Os requisitos mudarão durante e após
essa iteração, portanto, certifique-se de que seus casos de teste executáveis sejam fáceis de manter.
Pessoas não familiarizadas com o desenvolvimento ágil
muitas vezes temos a ideia errada de que não há documentação. Na verdade, ágil
projetos produzem documentação utilizável que contém testes executáveis e
portanto, está sempre atualizado.
A grande vantagem de ter testes executáveis como parte de seus requisitos

documento é que é difícil contestar seus resultados.
Freqüentemente, proprietários de produtos, administradores de planos ou gerentes de

A história de Lisa
desenvolvimento de negócios vêm me fazer perguntas como: “O que o sistema deve fazer se
alguém enviar um pagamento de empréstimo de zero dólares?” ou “Por que nem todos neste
plano receberam uma contribuição não eletiva de 3%?”
Mostrar a eles um teste FitNesse que reproduz o cenário é muito mais poderoso do que apenas
mostrar requisitos narrativos. Talvez o sistema não tenha sido projetado como deveria, mas o
teste ilustra como ele realmente funciona, pois podemos ver claramente os resultados das
entradas e operações. Isso salvou muitos argumentos do tipo “Achei que funcionasse assim”.
Se eles decidirem que a funcionalidade implementada está incorreta, podemos alterar os

resultados esperados do teste e escrever uma história para implementar o código para fazer
o teste passar novamente com as novas expectativas. Você não pode fazer isso com um
documento de requisitos.
—Lisa
Organizar os casos de teste e os testes nem sempre é simples. Muitas equipes

documentar testes e requisitos em um wiki. A desvantagem da flexibilidade de um wiki é que você
pode acabar com uma confusão de hierarquias. Você talvez tenha
dificuldade em encontrar o requisito ou exemplo específico que você precisa.
A equipe de Lisa revisita periodicamente a documentação do wiki e os testes FitNesse, e

Capítulo 14, “Um
refatora a maneira como são organizados. Se você estiver tendo problemas para organizar seus
requisitos e casos de teste, reserve algum tempo para pesquisar novas ferramentas que possam
Automação de Testes,”
tem mais em teste ajuda. Contratar um redator técnico qualificado é uma boa maneira de fazer seu valioso teste
gerenciamento. casos e exemplos em um repositório utilizável de informações fáceis de encontrar.
RESUMO 403
RESUMO
A sessão de planejamento da iteração dá o tom para toda a iteração. Nisso
capítulo, vimos o que os testadores ágeis fazem para ajudar a iniciar a iteração para um
bom começo.
Durante o planejamento da iteração, os testadores ajudam a equipe a aprender sobre as

histórias fazendo perguntas e considerando todos os pontos de vista.
Os cartões de tarefas precisam ser escritos junto com os cartões de tarefas de desenvolvimento
e estimados de forma realista.
Outra maneira de lidar com tarefas de teste é escrevê-las diretamente nos cartões de tarefas do
desenvolvedor.
As equipes devem se comprometer com o trabalho para o qual possam concluir todas as tarefas
de teste, porque nenhuma história é concluída até que seja totalmente testada.
O início de uma iteração é a última chance de garantir que as histórias sejam testáveis e que
sejam fornecidos dados de teste adequados.

Os testadores colaboram com os clientes para explorar histórias detalhadamente e escrever
casos de teste de alto nível para permitir que os programadores iniciem a codificação.
Os testadores analisam os testes e requisitos de alto nível com os programadores para garantir
que estejam se comunicando bem.
Os testes constituem o núcleo da documentação do aplicativo.

Capítulo 18
CODIFICAÇÃO E TESTE
Medindo o Progresso Iteração

Métricas
Comece simples
Recursos Adicionar Complexidade
Avalie o risco
Dirigindo
Mantenha a construção “verde” Teste e progresso de codificação juntos
Desenvolvimento
Mantenha a construção rápida Identificar variações

Regressão
Testes Poder dos Três
Construindo um Conjunto de Regressão
Verificando o “quadro geral” Concentre-se em uma história
Testadores facilitam a comunicação

Facilitar Codificação e Testes que criticam o
Comunicação produto
Equipes Distribuídas Teste
Colabore com Teste de pares
Quais bugs registrar? programadores Mostre-me
Quando corrigir bugs?
É tudo sobre
Que mídia usamos para registrar bugs?
Escolhas
Mostrar clientes
Falar com
Alternativas e sugestões
Clientes Entenda as necessidades do negócio
Comece simples
Defeito vs. Recurso Aborde a crise de testes

Concluindo
Lidando Tarefas de teste
Dívida Técnica Qualquer um pode realizar tarefas de teste
com insetos
Tolerância Zero a Bugs
Nosso testador ágil ajudou a planejar o lançamento, dimensionar as histórias adequadamente e

garantir que elas sejam testáveis. Ela, junto com colegas da equipe de clientes e de
desenvolvimento, transformou exemplos de comportamento desejado para cada história em
testes de aceitação de usuário de alto nível. Ela e sua equipe reuniram os recursos e a
infraestrutura necessários para agregar valor ao negócio. Agora, os membros da equipe pegaram
os cartões de tarefas e começaram a escrever o código. O que os testadores fazem a seguir,
especialmente antes de qualquer história estar pronta para teste?
405
406 CAPÍTULO 18 CODIFICAÇÃO E TESTE
IMPULSIONANDO O DESENVOLVIMENTO
O início da codificação é um bom momento para começar a escrever testes detalhados. O

testes de alto nível escritos antes da iteração, ou nos primeiros dias dela,
fornecem informações suficientes para os programadores iniciarem seu próprio desenvolvimento orientado
a testes. Então agora temos um pouco de espaço para respirar, mas se não o fizermos
mover-se rapidamente, a codificação pode ficar muito à frente dos testes e dar errado
direção.
Agora é a hora de começar a escrever testes executáveis que ilustrem os detalhes

sobre uma história, a fim de manter o desenvolvimento avançando suavemente e
ajude os testes a acompanhar o ritmo da codificação. Assim como os testes de alto nível, baseamos
testes em exemplos fornecidos pelos clientes.
Neste ponto, estamos escrevendo principalmente testes que serão automatizados, mas também estamos
pensando no futuro, nos importantes testes exploratórios que precisamos fazer como codificação
está completo.
Comece simples
Como testadores, somos facilmente distraídos por cheiros de código interessantes e casos extremos.
No entanto, se estivermos usando testes para orientar a codificação, teremos que começar com o básico.
Escreva o teste do caminho da felicidade mais simples que puder para mostrar que o núcleo
funcionalidade funciona.
Por que testes executáveis? Estamos trabalhando com um cronograma extremamente apertado e
Capítulo 14, “Um
nem os programadores nem os testadores têm tempo para parar e executar o manual
Estratégia de
Automação Ágil”, testes repetidamente. Eles têm tempo para clicar em um botão e executar um teste automatizado. Esse
fornece dicas para teste precisa falhar de uma forma que torne a causa tão óbvia quanto
selecionar as ferramentas certas.
possível. Idealmente, daríamos esses testes aos programadores para que eles
poderia executá-los enquanto eles codificam. Essa é uma das razões pelas quais escolher o caminho certo
estrutura de automação é muito importante.
Para algumas histórias, automatizar os testes pode levar muito tempo. Ao manter o
primeiro teste simples, você mantém o foco no design da solução de automação.
Quando o teste simples funciona, vale a pena investir tempo em testes mais complexos
casos.
Ressaltamos a importância da automação, mas Janet trabalhou com equipes

que usaram com sucesso testes manuais na forma de listas de verificação ou planilhas para fornecer aos
programadores as informações de que precisam para começar. No entanto,
para terem sucesso no longo prazo, esses testes precisam ser automatizados.
IMPULSIONANDO O DESENVOLVIMENTO 407
Adicione
complexidade Assim que o teste do caminho feliz funcionar, comece a adicionar mais
casos de teste. Adicione condições de limite e borda. Os testes podem mostrar que os
programadores entenderam mal um requisito, ou podem mostrar que um testador
entendeu, ou talvez o verdadeiro significado do requisito tenha escapado a todos. O
importante é que todos falem sobre isso e entrem no caminho certo.
À medida que os testadores pensam em novos cenários para validar com testes executáveis,
eles também pensam em cenários potenciais para testes exploratórios manuais. Anote-os para
pesquisa posterior.
Lembre-se do propósito desses testes. Eles devem fornecer exemplos que informem aos
programadores qual código escrever. À medida que o código evolui, seus testes podem desafiá-
lo ainda mais, mas resista à tentação de seguir imediatamente os cheiros até os casos extremos.
Faça o básico funcionar primeiro. Se você pensar em mais casos com base em alguma análise
de risco, poderá adicionar testes extras posteriormente.
Avalie o risco
Há muito tempo que os testadores usam a análise de risco para ajudar a priorizar os testes, e a
consideração do risco já está incorporada no desenvolvimento ágil. Histórias de alto risco
podem receber estimativas de tamanho maiores, e as equipes consideram o risco ao priorizar
histórias durante o planejamento do lançamento e da iteração.
Algumas análises rápidas de risco podem ajudá-lo a decidir quais testes fazer primeiro e onde
concentrar seus esforços. Nunca temos tempo para testar tudo e podemos usar a análise de
risco para descobrir quantos testes são suficientes.
Se você tiver uma história realmente complexa, você pode começar listando todos os riscos
potenciais relacionados à história. Eles não estão limitados à funcionalidade. Considere
segurança, desempenho, usabilidade e outras “ilidades”. Em seguida, para cada item, avalie o
impacto no negócio caso ele ocorra, usando uma escala de 1 a 5 (ou qualquer escala que
funcione para você): 1 sendo um impacto baixo, 5 sendo um impacto negativo crítico.
Agora, considere a probabilidade de cada item ocorrer, usando a mesma escala: 1 para nada
provável de acontecer e 5 para itens que provavelmente surgirão.
Multiplique as duas classificações para obter a classificação de risco total para cada item.
Isso torna mais fácil escolher as áreas onde sua equipe deve concentrar primeiro seus esforços
de teste. Os itens de baixo risco podem ser deixados para o final ou, porque o seu impacto é
baixo ou é altamente improvável que ocorram, podem nem sequer ser abordados.
Seu domínio faz uma grande diferença aqui. Se você estiver testando um software que executa
em marca-passos cardíacos, você provavelmente precisará cobrir todos os riscos com seus testes, não
não importa quão baixos ou improváveis eles sejam. Se você estiver testando um site interno da empresa
aplicativo a ser usado por alguns especialistas treinados no assunto, você pode estar
capaz de ignorar cenários improváveis ou que tenham uma solução alternativa óbvia.
Considere a história da Figura 18-1.
História PA-5
Como cliente, quero saber quanto custa meu pedido
custará o envio com base na velocidade de envio
Eu seleciono para poder escolher um frete diferente
velocidade se eu quiser.
Figura 18-1 História sobre velocidades de envio
A Figura 18-2 mostra uma possível avaliação de risco para esta história de custos de envio.
# Item Risco de probabilidade de impacto

1 Custo incorreto exibido 4 2 8
2 O usuário não pode escolher uma opção de envio diferente 5 1 5
3 O item não é elegível para a opção de envio selecionada, 3 26
mas a seleção é permitida
4 O custo estimado não corresponde ao custo real em 3 4 12
Confira
5 Código postal inválido inserido e não detectado pela 4 14
validação
6 O usuário não consegue entender as regras de opções de envio 2 3 6
7 O usuário não pode alterar o endereço de entrega 5 2 10
8 Usuário muda endereço de entrega, mas custo não 5 4 20
mude de acordo
Figura 18-2 Exemplo de avaliação de risco
O item 8 é o item de maior risco, portanto, gostaríamos de testar a alteração dos endereços de entrega
e verificar os custos atualizados. Poderíamos querer automatizar um
teste ponta a ponta com este cenário. Não estamos muito preocupados com o item 5;
talvez já tenhamos testado nossa validação de código postal e nos sintamos bem com isso
isso, então não precisamos testá-lo mais. Você pode até ter um item de risco muito baixo
que você optou por não testar.
A história geralmente é uma boa professora. Anote os problemas anteriores e certifique-se de que eles
não aconteça novamente.
Progresso de codificação e teste juntos

Neste ponto da iteração, a codificação e o teste continuam lado a lado.
Testadores, programadores, especialistas em banco de dados e outros membros da equipe colaboram
para desenvolver as histórias, seguindo as diretrizes fornecidas pelos exemplos
e testes. Diferentes membros da equipe podem contribuir com seus conhecimentos específicos,
mas todos se sentem responsáveis por garantir que cada história seja concluída. Tudo de
eles aprendem sobre a história e aprendem uns com os outros à medida que o trabalho avança.
Vejamos como uma equipe poderia trabalhar na história dos custos de envio na Figura 18-1.
Patty Programmer pega um cartão de tarefas para codificar o custo estimado de envio
cálculos. Ela já entende a história muito bem das discussões anteriores, mas pode olhar as páginas wiki
ou o verso do cartão da história onde
os testadores escreveram alguma narrativa descrevendo o propósito da história,
alguns exemplos de como deveria funcionar e alguns testes de alto nível para fazer
certeza de que ela tem uma boa ideia de por onde começar. Tammy Tester vê essa codificação
o trabalho começou e começa a escrever casos de teste por trás da GUI para o custo
cálculos.
A equipe concordou durante o planejamento em começar calculando o custo de envio de 5 dias com base
no endereço de entrega e no peso do item. Os itens só podem ser
enviado dentro da América do Norte continental, mas essa validação será feita
na camada de apresentação, portanto os testes de cálculo de custos podem assumir apenas valores válidos
destinos são considerados para entrada. Eles estão usando uma API de cálculo de custos
fornecido pelo parceiro de transporte, e Tammy pergunta a Patty onde encontrar os algoritmos para que
ela mesma possa calcular o custo para escrever os testes. Tammy
escreve o caso de teste mais simples que ela consegue imaginar no teste por trás da GUI
ferramenta. Mostramos isso como uma tabela simples na Figura 18-3.
Peso 5 Código postal de destino Custo

libras 80104 7h25
Figura 18-3 Teste simples do caminho feliz

Patty ainda não terminou o código que faria esse teste passar, então Tammy
começa a trabalhar em outra tarefa de teste para a história, configurando o ambiente de teste
para funcionar com o sistema de teste do parceiro de remessa.
Identificar variações
Como esta história e o teste são tão simples, Patty e Tammy não
discuta o design do teste e ajuste-o como fariam em histórias mais complexas.
Eles também não precisaram fazer mais perguntas ao proprietário do produto ainda. Patty
chama Tammy para mostrar que o teste simples agora está funcionando. Tammy
escreve mais casos de teste, tentando diferentes pesos e destinos dentro
os Estados Unidos. Tudo isso funciona bem. Ela tenta um código postal canadense e
o teste obtém uma exceção. Ela mostra isso para Patty, que percebe que a API
o padrão é o código postal dos EUA e requer um código de país para códigos no Canadá e no
México. Ela ainda não havia escrito nenhum teste unitário para outros países.
Eles revisam as entradas de teste e Patty se junta a Paul Programmer para mudar
o código que chama a API. Agora o teste se parece com a Figura 18-4.
Peso 5 Código postal de destino Código do país Custo

libras 80104 NÓS 7h25
5 libras T2J2M7 QUE 9h40
Figura 18-4 Teste do caminho feliz revisado
Este exemplo simples ilustra as idas e vindas iterativas entre codificação e teste. Equipes
diferentes adotam abordagens diferentes. Patty e Tammy
pode emparelhar tanto na codificação quanto no teste. Tammy pode formar dupla com Paul para
escreva o fixture para automatizar o teste. Tammy pode estar em um escritório remoto,
usando uma ferramenta de colaboração online para trabalhar com Patty. Patty pode escrever o
a história executável testa a si mesma e depois escreve o código para fazê-los funcionar,
praticando o desenvolvimento orientado a testes de histórias reais. A questão é que testar e
codificação fazem parte de um processo de desenvolvimento no qual todos os membros da equipe
participar.
Tammy pode continuar a identificar novos casos de teste, incluindo casos extremos e
condições limite, até que ela sinta que todas as áreas de risco foram cobertas pelo
quantidade mínima e variedade de casos de teste. Ela pode testar com o mais pesado
item disponível no site enviado para o destino mais caro. Ela
pode testar ter uma grande quantidade do mesmo item. Alguns casos extremos podem ser
tão improvável que ela não se preocupe com eles, ou decida fazer um teste, mas
depois de aprovado, não o inclui no conjunto de regressão. Alguns testes podem ser
é melhor fazer manualmente depois que uma IU estiver disponível.
Poder dos Três
Patty escreveu testes unitários tendo o Havaí como destino de envio, mas
Tammy acredita que apenas destinos continentais são aceitáveis. Nem de
eles têm certeza se os destinos de caixas postais militares são aceitáveis.
Eles vão ver a proprietária do produto Polly para perguntar o que ela pensa. Eles estão usando o
Poder de Três. Quando surgem divergências ou dúvidas, ter três pontos de vista diferentes é uma
maneira eficaz de garantir que você obtenha uma boa solução e
você não terá que refazer o problema mais tarde. Se um dos participantes da discussão não estiver
familiarizado com o tema, os demais terão que organizar suas
pensamentos para explicá-lo claramente, o que é sempre útil. Envolver pessoas em diferentes
funções ajuda a garantir que as mudanças nos requisitos não sejam ignoradas.
radar e surpreender os membros da equipe mais tarde.
Quando surgem problemas inesperados, como sempre acontece, a regra do Poder de Três
é um ótimo lugar para começar. Você pode precisar atrair mais pessoas, ou até mesmo o
toda a equipe, dependendo da gravidade ou complexidade do problema. E se o
A API do parceiro de remessa é tão lenta que o tempo de resposta no
site será inaceitável? Tanto a equipe de desenvolvimento quanto o cliente
a equipe precisa explorar rapidamente soluções alternativas.
Concentre-se em uma história
Paul procura uma tarefa de programação para trabalhar. Embora as tarefas de UI para o
a história do custo de envio estimado ainda está na coluna “tarefas pendentes” da tarefa
quadro, ele está mais interessado na história para deletar itens do shopping
carrinho, então ele pega uma dessas cartas. Ninguém tem tempo para começar a escrever o
testes executáveis para essa história, então ele avança sozinho.
Agora a equipe tem duas histórias. Eles realmente não sabem quanto tempo
será necessário para terminar qualquer uma das histórias. Uma abordagem muito melhor seria Paulo
comece a trabalhar em uma tarefa de UI para a primeira história para que essa história possa ser concluída
mais cedo. Quando uma história termina (ou seja, todo o código é escrito e testado),
você sabe exatamente quanto trabalho resta fazer: zero. Se o desastre acontecesse
e nenhuma outra história foi concluída nesta iteração, há pelo menos uma concluída
história para lançar.
Concluir a história toda não é um conceito de teste, mas é algo que os testadores deveriam
promover e seguir. Se um programador começou a codificar uma história, certifique-se
alguém também começou a trabalhar em tarefas de teste para essa história. Este é um ato de
equilíbrio. E se ninguém tiver escrito testes de alto nível para os itens excluídos?
história? Talvez essa seja a maior prioridade de teste? Normalmente, terminar uma história
deve ser o objetivo antes que a equipe possa passar para a próxima história.
A menos que a equipe seja muito pequena, sempre há mais de uma história em andamento
a qualquer momento. Pode ser mais difícil, mas tente se concentrar em terminar um
história de cada vez. Patty está prestes a encerrar a história do custo do frete, e Paul
passou para a história de exclusão de itens. Patty se depara com um obstáculo e não tem certeza
como resolver isso. Paul a ajuda a terminar o código para que Tammy possa terminá-lo
testes exploratórios e eles podem marcar a história como “concluída”. Agora eles têm uma ideia melhor de
quanto ainda lhes resta para terminar esta iteração (ou pelo menos, quanto
muito que eles ainda não precisam trabalhar).
Às vezes, várias histórias diferentes podem ser feitas ao mesmo tempo se um programador e um testador
se unirem para completar cada história juntos. Isso funciona se o
as histórias são pequenas e independentes. O que você não quer ver são programadores iniciando a
codificação sem que as tarefas de teste sejam concluídas ao mesmo tempo.
TESTES QUE CRÍTICAM O PRODUTO

Assim que pedaços de código testáveis estiverem disponíveis e os testes automatizados que
guiado sua passagem de codificação, reserve um tempo para explorar a funcionalidade mais profundamente.
Experimente diferentes cenários e aprenda mais sobre o comportamento do código. Você deve
tenha cartões de tarefas para testes que criticam o produto, tanto voltados para negócios quanto para
tecnologia. A história não estará “pronta” até que todos esses tipos de testes sejam concluídos.
Isto se torna mais importante quando todas as tarefas, exceto o teste, são concluídas para um
história. Agora você deve ser capaz de testar desde uma extremidade do fio da história até o
outra extremidade, com todas as variações intermediárias. Não adie esse teste. Você
pode encontrar requisitos que estavam na história, mas foram perdidos nos testes que
impulsionou o desenvolvimento e, portanto, está faltando no código. Agora é a hora de escrever
aqueles testes e códigos ausentes. Preencha todas as lacunas e agregue mais valor enquanto o
a equipe ainda está focada na história. Fazer isso mais tarde custará muito mais.
Esteja ciente de que parte do que você aprende ao testar a história final pode ser considerada “bom de se
ter”, talvez tornando a funcionalidade mais fácil ou rápida de usar.
Capítulo 10,
“Visado para negócios itens que não faziam parte da história original. Consulte seu cliente. Se
Testes que Criticam o há tempo para adicioná-lo na iteração e a empresa pode usar o extra
Produto” e o Capítulo valor, vá em frente. Essas adições são muito mais baratas de adicionar agora. Mas não
11, “Testes
comprometer outras histórias gastando muito tempo adicionando “bling” que
voltados para a
tecnologia que Criticam não tem um grande ROI.
o Produto”, ajudarão
você a garantir a
Se o seu teste exploratório levar a equipe e os clientes a perceberem que
cobertura de todos os
funcionalidades significativas não foram cobertas pelas histórias, escreva novas histórias para
testes necessários
que criticam o produto. iterações futuras. Mantenha um controle rígido sobre o “aumento do escopo” ou sua equipe não terá
tempo para entregar o valor que você planejou originalmente.
COLABORAR COM PROGRAMADORES 413
Testes voltados para a tecnologia para criticar o produto geralmente são mais bem realizados durante
codificação. Este é o momento de saber se o projeto não é dimensionável ou se há falhas de
segurança.
COLABORAR COM PROGRAMADORES

Nossa vinheta que descreve uma equipe escrevendo e usando testes detalhados para conduzir a
codificação mostra o quão estreitamente colaboram testadores e programadores. Isso continua
à medida que a codificação e o teste prosseguem. Trabalhar em conjunto aumenta a capacidade da equipe
para entregar o produto certo e oferece muitas oportunidades para transferir
habilidades. Os programadores aprendem novas maneiras de testar e serão melhores em testes
seu próprio código enquanto o escrevem. Os testadores aprendem mais sobre o processo de
codificação e como os testes certos podem torná-lo mais fácil.
Teste de pares
Paul Programmer concluiu a interface do usuário para a história das opções de envio estimadas,
mas ainda não fez o check-in. Ele pede a Tammy para sentar
com ele e demonstra como o usuário final inseriria o endereço de entrega durante o processo de
finalização da compra. O custo de envio estimado é exibido à direita
ausente. Tammy altera o endereço de entrega e vê o novo custo aparecer. Ela
insere um código postal que não corresponde ao resto do endereço e vê o
mensagem de erro apropriada será exibida. A IU parece boa para ambos, então
Paul verifica o código e Tammy continua com seu manual exploratório
testando isso.
Janet gosta que o programador “dirija” durante essas sessões de testes em pares
enquanto ela observa o que acontece. Ela acha que é muito mais eficaz do que
assumindo o controle do teclado e do mouse enquanto o programador assiste.
"Mostre-me"
Tammy está especialmente preocupada em alterar o endereço de entrega e ter

recalcular o custo estimado, porque identificaram isso como uma área de risco. Ela
descobre que, se exibir o custo estimado, avança para o endereço de cobrança
página e depois volta para alterar o endereço de entrega, os custos estimados
não mude corretamente. Ela faz com que Paul venha observar esse comportamento. Ele percebe
há um problema com o cache da sessão e volta para corrigi-lo.
Mostrar um problema a alguém e resolvê-lo juntos é muito mais

eficaz do que registrar um bug em um sistema de rastreamento de defeitos e esperar por alguém
ter tempo para olhar para isso. É mais difícil fazer isso se a equipe não estiver localizada no mesmo local. Se equipe
membros trabalham em fusos horários muito diferentes, é ainda mais difícil. Atenha-se
a comunicação mais direta disponível para você. Um dos companheiros de equipe de Lisa está em
um fuso horário 121 ÿ2 horas à frente. Ele trabalha até tarde da noite, e quando
necessário, ele liga para Lisa e eles trabalham juntos nos resultados dos testes e nos exemplos.
O simples ato de mostrar a GUI para outra pessoa pode ajudar Paul a perceber
A bibliografia
contém ele implementou algum comportamento errado. Da mesma forma, se Tammy estiver tendo
referências para problemas para fazer seu script de teste GUI funcionar, explicar o problema pode ser
leitura adicional o suficiente para ela perceber o que está causando isso. Se não houver ninguém disponível para olhar
sobre este assunto. no que você acabou de codificar ou ajudá-lo a depurar um problema, às vezes ajuda
explique em voz alta para si mesmo. “Esquecimento de borracha” e “Pensando em voz alta”
são maneiras surpreendentemente eficazes de resolver seus próprios problemas. Janet gosta de ter
seu próprio patinho de borracha em sua mesa para se lembrar de pensar antes de perguntar.
FALE COM OS CLIENTES

É surpreendentemente fácil para os membros da equipe de desenvolvimento se concentrarem
criando histórias e esquecendo de manter os clientes informados. Além de
consultar especialistas em negócios quando temos dúvidas, precisamos mostrar a eles
o que entregamos até agora.
Esperamos que você tenha conseguido revisar os casos de teste com os clientes, ou com alguém que
pudesse representar o cliente, antes do início da codificação. Se não, nunca é
tarde demais. Para situações em que os clientes precisam estar mais envolvidos com o
detalhes dos testes executáveis, certifique-se de encontrar ferramentas de teste que funcionem para eles como
bem como para membros da equipe técnica.
Como descrevemos nos dois últimos capítulos, você já deve ter repassado
maquetes ou protótipos de papel com seus clientes. Se as tarefas para simular um relatório ou interface
permanecerem no plano de iteração, lembre-se de manter o processo
simples. Por exemplo, não codifique um protótipo HTML ao desenhar em um
quadro branco também servirá. Queremos manter o processo o mais simples possível; a simplicidade é um
valor fundamental.
Mostrar clientes
Assim que uma interface de usuário ou relatório codificado estiver pronto, mesmo que ainda seja rudimentar,
sem todos os recursos ou exibindo dados codificados, mostre-os ao apropriado
clientes. Ninguém pode explicar exatamente o que quer com antecedência. Eles
precisa ver, sentir e usar o aplicativo para saber se está certo. Você pode não estar
CONCLUINDO TAREFAS DE TESTE 415
capaz de implementar grandes mudanças no meio da iteração, mas se você começar cedo, pode haver
será hora de pequenos ajustes e seus clientes saberão o que esperar.
A reunião de revisão da iteração é uma ótima oportunidade para mostrar o que a equipe
entregue e obtenha feedback para a próxima iteração, mas não espere até então para
obter informações dos clientes. Mantenha-os envolvidos durante toda a iteração.
Entenda o negócio
Embora sejamos apanhados pelo ritmo acelerado das iterações, também precisamos parar
e reserve um tempo para entender melhor o negócio. Passe algum tempo conversando com
empresários sobre seus empregos e quais aspectos podem ser melhorados com
novos recursos de software. Quanto melhor você entender o negócio do seu cliente,
melhor você poderá fornecer um bom produto.
Minha equipe reserva tempo para cada membro da equipe de desenvolvimento sentar-se com os
A história de Lisa
membros da equipe de administração do plano de aposentadoria enquanto eles realizam seu
trabalho diário. Não apenas entendemos melhor essas tarefas, mas frequentemente identificamos
pequenas alterações na aplicação que facilitarão o trabalho do administrador.
Adições simples, como alguns dados extras fornecidos, um filtro de pesquisa adicional ou alterar a
ordem de uma exibição podem fazer uma grande diferença em um processo tedioso e detalhado.
Também documentamos o que aprendemos com fluxogramas e páginas wiki para que outros
membros da equipe possam se beneficiar.
—Lisa
Algumas equipes, na verdade, sentam-se permanentemente com os empresários para que eles
estão envolvidos com o negócio real diariamente.
CONCLUINDO TAREFAS DE TESTE

Os testadores ágeis são proativos. Não sentamos e esperamos que o trabalho chegue até nós.
Os testadores que estão acostumados com um processo em cascata podem sentir que não há nada a
faça até que a história esteja 100% concluída. Isso raramente é verdade durante uma iteração ágil.
Trabalhe com programadores para que eles produzam algum código testável
desde cedo. O algoritmo de custo de envio apresentado anteriormente é um bom exemplo. Isto
pode ser testado completamente isoladamente, sem necessidade de acessar o banco de dados
ou a interface do usuário. Alternativamente, a interface do usuário pode ser apagada
com dados codificados antes que os serviços que acessam os dados reais sejam concluídos,
e o comportamento da camada de apresentação pode ser testado por si só.
Perigo: a crise dos testes

Mesmo equipes ágeis experientes muitas vezes enfrentam dificuldades de testes no final de uma iteração.
Talvez uma ou duas histórias tenham demorado muito mais do que o esperado ou um problema de
produção tenha demorado para ser desenvolvido. O que acontece quando amanhã terminar sua
iteração e seu quadro de tarefas (real ou virtual) ainda estiver cheio de cartões de teste?
Se você vir isso, reconheça como um cheiro ruim. Trabalhe com a equipe para determinar qual pode
ser o problema. Os programadores não estão trabalhando suficientemente próximos dos testadores?
Houve muitas interrupções?
A maneira de enfrentar esse perigo é envolver toda a equipe. Lembre-se de que qualquer pessoa da
equipe pode se inscrever para tarefas de teste. No seu stand-up diário, você pode avaliar se a equipe
está no caminho certo para finalizar todas as histórias. Se várias histórias correm o risco de não serem
concluídas, escolha uma história para descartar ou reduza o escopo de uma ou mais histórias.
Concentre-se em completar uma história de cada vez. À medida que o fim da iteração se aproxima, os
programadores podem ter que parar de trabalhar em novos recursos e começar a realizar tarefas de
teste. Perder alguma funcionalidade de uma versão é melhor do que perder a versão inteira porque o
teste não pôde ser concluído em todas ou na maioria das histórias.
Os programadores da equipe de Lisa automatizam regularmente os testes por trás da GUI em

além de testes unitários e de integração. Eles também costumam escrever o funcional
casos de teste por trás da GUI. Às vezes, eles escrevem o teste executável inicial do caminho
feliz para que possam coordenar o teste e o design do código; então um testador adiciona mais
casos de teste. Ocasionalmente, eles escrevem todos os casos de teste funcionais, porque o
os testadores não têm largura de banda para cobrir todas as histórias com uso intensivo de testes.
Todos na equipe também devem estar dispostos a realizar tarefas de teste manuais. Se
sua equipe está apenas começando e não conseguiu atender às necessidades de automação
ainda assim, toda a equipe deve planejar um tempo para executar o teste de regressão manual
scripts, bem como testar manualmente novos recursos. Como a equipe de Lisa pode atestar, isso
tarefa fornece grande motivação para aprender como projetar o aplicativo para
facilitar a automação de testes. Outras equipes nos dizem que isso também funcionou para elas.
LIDANDO COM BUGS

Conhecemos muitas equipes que lutam com a questão de como rastrear
bugs, ou se deve rastreá-los. Como Tom e Mary Poppendieck escrevem em
seu livro Implementando Lean Software Development: From Concept to Cash
[2006], as filas de defeitos são filas de retrabalho e, portanto, pontos de coleta para
LIDANDO COM BUGS 417
desperdício. Algumas equipes simplesmente corrigem os bugs assim que são descobertos. Eles escrevem um
teste de unidade para reproduzir o bug, corrija o código para que o teste passe, verifique o teste
e a correção do bug e continue. Se alguém quebrar esse trecho de código mais tarde, o teste
irá capturar a regressão.
Outras equipes encontram valor em documentar problemas e soluções em um sistema de

O Capítulo 5,
rastreamento de defeitos (DTS), especialmente problemas que não foram detectados até depois do código
“Transição de
Processos Típicos”, foi liberado. Eles podem até procurar padrões nos bugs que chegaram à produção e fazer análises
fala sobre por que de causa raiz para aprender como evitar problemas semelhantes.
sua equipe pode ou
recorrente. Ainda assim, os sistemas de defeitos não proporcionam um bom fórum para discussões face a face.
não querer usar um
comunicação sobre como produzir código de maior qualidade.
Sistema de
Rastreamento de Defeitos.
Lisa e seus colegas testadores preferem conversar com um programador assim que um problema
for encontrado. Se o programador puder consertar imediatamente, não há necessidade de registrar
o bug em qualquer lugar. Se nenhum programador estiver disponível imediatamente para trabalhar no
problema, e há uma possibilidade de o bug ser esquecido, eles escrevem um
cartão para ele ou insira-o em sua ETED.
Adicionamos esta seção a este capítulo porque é quando você se depara com o
problema. Você tem escrito testes primeiro, mas está encontrando problemas à medida que
trabalhar com o programador. Você registra um bug? Se sim, como? Você tem feito
seu teste exploratório e encontrou um bug em uma história que foi marcada como concluída.
Você registra um bug para isso? Vamos discutir mais sobre defeitos e considerar as opções que
estão disponíveis para você e sua equipe.
É um defeito ou é uma característica?
Primeiro, vamos falar sobre defeitos versus recursos. A velha questão do software
desenvolvimento é: “O que é um bug”? Algumas respostas que ouvimos são: É um desvio dos
requisitos ou é um comportamento que não é o esperado. De
é claro que existem alguns defeitos realmente óbvios, como saída incorreta ou mensagens de erro
incorretas. Mas o que realmente importa é a percepção do usuário sobre o
qualidade do produto. Se o cliente disser que é um defeito, então é um defeito.
No Agile, temos a oportunidade de trabalhar com os clientes para consertar as coisas

para sua satisfação. Os clientes não precisam tentar pensar em todos os possíveis
recurso e detalhes na frente. Não há problema em eles mudarem de ideia quando
eles veem alguma coisa.
No final das contas, realmente importa se é um bug ou um recurso se precisa ser corrigido?
O cliente escolhe as prioridades e a proposta de valor. Se a qualidade do software
é uma prioridade mais alta para o cliente do que obter todos os novos recursos, então
devemos tentar consertar todos os defeitos à medida que os encontramos.
Os clientes da equipe usam seu conhecimento para dar o melhor conselho possível
para a equipe no desenvolvimento diário. No entanto, quando um produto vai para
UAT e está exposto a uma base de clientes maior, sempre haverá solicitações em
na forma de bugs ou novas melhorias.
Dívida Técnica
Uma maneira de pensar nos defeitos é como uma dívida técnica. Quanto mais tempo um defeito
Capítulo 6, “O
permanece no sistema e não é detectado, maior será o impacto. Também é verdade
Finalidade do
teste”, explica como que deixar bugs apodrecendo em uma base de código tem um efeito negativo na qualidade do código,
os testes ajudam a intuitividade do sistema, flexibilidade do sistema, moral da equipe e velocidade. Consertando um
gerenciar o débito técnico.
defeitos no código com bugs podem revelar mais, então as tarefas de manutenção demoram mais.
Tolerância Zero a Bugs

Janet incentiva as equipes com as quais ela trabalha a se esforçarem para ter “tolerância zero” em
relação à contagem de bugs. Novas equipes ágeis geralmente têm dificuldade em acreditar que isso pode
ser feito. Numa organização com a qual Janet trabalhava, ela desafiou cada um dos
as cinco equipes de projeto para ver o quão perto poderiam chegar de zero bugs pendentes no final de
cada iteração e zero no momento do lançamento.
Zero Iterações de Bug

Jakub Oleszkiewicz, gerente de controle de qualidade da NT Services [2008], conta como sua equipe
aprendeu como terminar cada iteração sem erros transferidos para a próxima.
Acho que tudo se resume a uma comunicação excepcional entre os testadores, os desenvolvedores
e os analistas de negócios. A disciplina também foi fundamental, porque estabelecemos a meta
de encerrar iterações com recursos totalmente desenvolvidos, funcionais, implantáveis e livres
de defeitos, ao mesmo tempo em que nos esforçamos para evitar cair em uma armadilha em
cascata. Para nós, evitar a cascata significava que tínhamos que manter o alinhamento com o
código e as atividades de teste; tentamos planejar as atividades de uma iteração para que os
casos de teste de um determinado recurso fossem projetados e automatizados ao mesmo tempo
em que o código desse recurso era escrito. Nós
rapidamente descobrimos que estávamos praticando uma forma de desenvolvimento orientado
a testes. Não acho que tenha sido TDD puro, porque na verdade não estávamos executando
os testes até que o código fosse verificado, mas estávamos desenvolvendo os testes enquanto
os desenvolvedores escreviam o código, e os desenvolvedores nos perguntavam como
nossos testes estavam estruturados e o que nossos resultados esperados foram.
É TUDO UMA QUESTÃO DE ESCOLHAS 419
Por outro lado, perguntávamos regularmente aos desenvolvedores como eles estavam
implementando um determinado recurso. Esse tipo de questionamento bidirecional muitas
vezes aumentava as inconsistências na forma como os requisitos eram interpretados e,
em última análise, destacava defeitos em nossas interpretações antes que o código
fosse realmente confirmado.
Todas as manhãs, durante nosso Scrum, garantimos ainda mais a paridade entre os grupos
funcionais da equipe por meio de um diálogo simples. A comunicação era ridiculamente boa –
sentávamos perto um do outro, muitas vezes até no mesmo computador. Quando um defeito
era descoberto, o desenvolvedor estava ali observando, tomando notas e conversando sobre
os requisitos. Um analista de negócios estava sempre por perto para validar ainda mais
nosso pensamento. Muitas vezes, em poucos minutos, uma resolução era registrada,
implantada no ambiente de teste e verificada.
Tanto os desenvolvedores quanto os testadores tiveram que estar comprometidos com essa
abordagem ou ela não teria funcionado. Sem disciplina, os desenvolvedores poderiam
facilmente ter avançado para mais recursos e deixado os bugs passarem até o final do projeto,
arriscando uma iteração incompleta. Se não estivéssemos co-localizados como estávamos,
a comunicação teria sido prejudicada; provavelmente um sistema de rastreamento de bugs
ou e-mail teria se tornado nosso principal meio de comunicação de defeitos, resultando em
tempos de resposta mais longos e em uma maior probabilidade de retrabalho.
Como parte de qualquer desenvolvimento, você sempre precisará fazer concessões. Seu
equipe pode decidir lançar com alguns bugs pendentes porque é considerado
mais importante lançar novas funcionalidades do que consertar problemas de baixo nível
insetos.
É TUDO UMA QUESTÃO DE ESCOLHAS
As equipes resolveram o problema de como lidar com defeitos de muitas maneiras diferentes.
caminhos. Algumas equipes colocam todos os seus bugs em cartões de tarefas. Outras equipes
optaram por escrever um cartão, avaliá-lo e programá-lo como uma história. Outros ainda sugerem
adicionando um teste para cada bug – dessa forma você não precisa registrar o defeito, apenas
o teste.
Existe um caminho certo? Claro que não! Mas, como você sabe o que é certo para
seu time? Temos algumas sugestões para ajudá-lo a escolher e decidir o que é
certo para você. Pense na sua equipe e no seu produto e no que pode
trabalhe na sua situação. Primeiro, falaremos sobre quais defeitos devemos registrar,
então falaremos um pouco sobre quando você deve corrigi-los e, finalmente, veremos
que mídia escolher. A combinação certa dependerá de quão longe
sua equipe está em sua jornada ágil e quão maduro é seu produto.
Decida quais bugs registrar

Nem todos os bugs precisam ser registrados, mas as equipes muitas vezes têm dificuldade em saber quais
devem ser registrados e quais não precisam ser. Recomendamos que
você evita criar um relatório de defeitos, se possível. Converse com um verdadeiro
pessoa primeiro, e só produza um relatório de defeito se for realmente um problema real que
exige uma mudança no produto ou os programadores simplesmente não conseguem fazer isso direito
ausente.
Falhas em testes unitários
Não registre falhas em testes de unidade. Se você faz parte de uma equipe que pratica TDD
(desenvolvimento orientado a testes) e tem boa cobertura com seus testes unitários, você
saiba que os testes que falharam durante a construção não devem ser registrados. Um teste falhado
durante a construção de integração contínua é um sinal para os programadores
resolver o problema imediatamente. Registrar esses bugs seria redundante e
uma perda de tempo.
Falhas em testes de regressão de nível superior
Muitas equipes têm compilações que executam testes de regressão acima do nível da unidade, como
testes por trás da GUI e testes por meio da GUI. Quando uma dessas construções
falhar, você deve registrar o bug em um DTS?
Temos duas compilações, uma “compilação contínua” que executa apenas testes de unidade e uma “compilação completa”
A história de Lisa
que executa os testes funcionais por trás e por meio da GUI. Quando a “construção completa”
quebras, se um desenvolvedor investigar e resolver o problema imediatamente, como às vezes
acontece, geralmente nenhum bug é registrado. O problema é resolvido rapidamente. Outras
vezes, o fracasso não é simples. Um dos testadores investiga, restringe o problema e registra um
bug que indica o nome do teste com falha ou fornece etapas manuais para recriar o problema.
Em ambos os casos, são escritos testes que reproduzem o bug e o código é corrigido para que os
testes sejam aprovados. Os testes passam a fazer parte de uma das compilações.
—Lisa
A falha nos testes em si é um tipo de bug registrado. Mas às vezes, como em

No caso de Lisa, mais informações precisam ser adicionadas para permitir uma abordagem eficaz e
correção limpa, portanto, o registro do defeito é garantido.
Bugs de história na iteração atual
Não registre bugs que possam ser corrigidos imediatamente, especialmente se você os registraria em uma
ETED eletrônica. Se sua equipe estiver trabalhando em estreita colaboração com
Para os programadores e estiver praticando testes em pares assim que uma história for
concluída, recomendamos fortemente que você não registre esses bugs, desde que o
programador os resolva imediatamente. Ao notar problemas, converse sobre eles com o
programador e decida se são problemas reais ou não. Converse com o cliente se precisar,
mas faça algumas anotações para lembrar o que viu e poder ajustar seus testes, se
necessário.
Se você estiver usando fichas para registrar bugs, você pode colocar uma ficha no quadro
de tarefas (ou um cartão no quadro eletrônico) apenas como um lembrete.
Bugs pós-iteração (ou aqueles que não podem ser corrigidos imediatamente)
Registre bugs que não podem ser corrigidos imediatamente. Enfatizamos os testes
antecipadamente para detectar o máximo de bugs possível enquanto os programadores
ainda estão trabalhando na história. Sabemos que é mais barato consertá-los quando
detectados precocemente; no entanto, às vezes simplesmente não os pegamos
imediatamente. O programador passou para outra história e não pode largar tudo para
consertar agora. Esses são os bons candidatos para registro. Às vezes, um “bug” é realmente
um requisito perdido e precisa ser tratado como uma história – estimada e priorizada para
uma iteração futura.
Do sistema legado Faça log

de bugs que ocorrem no sistema legado. Se o seu produto já existe há muito tempo,
provavelmente contém vários bugs que estão à espreita, esperando para serem descobertos.
Ao encontrá-los, você tem algumas opções. Se o proprietário do produto achar que vale a
pena corrigi-los, registre os bugs e eles poderão ser priorizados como parte do backlog do
produto. No entanto, se eles já existem há muito tempo e não causam problemas, o
proprietário do produto pode decidir que não vale a pena corrigi-los. Nesse caso, não se
preocupe em registrá-los. Eles nunca serão abordados de qualquer maneira, então não
perca tempo.
Encontrado em produção
Registre todos os bugs de produção. Quando sua aplicação estiver em produção, todos os
bugs encontrados pelo cliente deverão ser registrados. Dependendo da gravidade, esses
bugs podem ser corrigidos imediatamente, no momento do próximo lançamento, ou serão
estimados, priorizados e colocados no backlog do produto.
Escolha quando corrigir seus bugs

Existem três opções. Todos os bugs que você encontrar precisam ser triados para determinar
se você os corrige agora, depois ou simplesmente não os corrige. Esta triagem pode ser tão
simples quanto uma discussão com o programador para determinar se eles estão realmente
bugs na história em que ele está trabalhando. A triagem pode ser uma discussão com o
proprietário do produto para determinar se deve haver outra história para a próxima iteração. A triagem
também pode ser um processo formal com os clientes para priorizar quais bugs corrigir.
Conserte agora
Quanto mais bugs você puder corrigir imediatamente, menos dívida técnica sua aplicação gerará e
menos inventário de “defeitos” você terá. Os defeitos também são
mais barato para consertar quanto mais cedo forem descobertos. Em um artigo na revista iSixSigma,
Mukesh Soni [2008] cita um relatório da IBM de que o custo para consertar um
O erro encontrado após o lançamento do produto foi de quatro a cinco vezes maior do que um erro não
coberto durante o projeto, e até 100 vezes mais do que um identificado no
fase de manutenção (ver Figura 18-5).
A Figura 18-5 mostra uma estatística baseada em metodologia faseada, mas a estatística
ainda vale para o desenvolvimento ágil. É mais barato consertar bugs encontrados
durante o desenvolvimento do que depois.
Se um defeito for encontrado durante o desenvolvimento de um novo recurso ou for um efeito colateral
de outra correção de bug, ele deverá ser corrigido automaticamente. Mas, como sempre, isto deve ser
aplicado com prudência. Por exemplo, se for encontrado um bug que os programadores dizem
será difícil de consertar e poderá desestabilizar o produto, deve-se tomar
os clientes devem priorizar.
Fase/Estágio do Desenvolvimento S/W em que o Defeito é Encontrado
120
100x
100
80
60
40
20 15x
1x 6,5x
0
Projeto Implementação Teste Manutenção
Figura 18-5 Custos relativos para corrigir defeitos de software (Fonte: Sistemas IBM
Instituto de Ciências)
Se você corrigir os bugs durante o desenvolvimento, diminuirá a presença de bugs posteriormente no processo. A
velocidade da sua equipe pode incluir tempo para corrigir bugs. Com o tempo, os membros da sua equipe terão uma
boa ideia de quanto tempo gastam corrigindo bugs encontrados pelos testadores de uma história. Felizmente, existem
poucos. Se sua equipe for uma nova equipe ágil, pode haver alguns bugs que escapam ao desenvolvimento, mas à
medida que a equipe fica mais confortável com as ferramentas e os processos, o número de bugs encontrados
diminuirá. Para começar, tente fazer uma estimativa para uma história incluir duas horas ou meio dia para corrigir bugs
associados.
Corrigir mais tarde
Equipes diferentes têm maneiras diferentes de lidar com defeitos. Algumas equipes acreditam que todos os defeitos
encontrados devem ser priorizados pelos clientes antes de serem colocados na lista para correção. Eles acreditam que
cabe inteiramente ao cliente determinar se realmente são defeitos e, em caso afirmativo, se devem ser corrigidos.
Nunca conserte
Sua equipe reconheceu um defeito, mas sabe que ele não será corrigido. Talvez essa seção do código precise de uma
reescrita completa posteriormente porque a funcionalidade mudará, ou talvez seja apenas um problema de baixa
prioridade ou tão obscuro que seus clientes talvez nunca o encontrem. Há uma infinidade de razões pelas quais isso
não será corrigido. Se a sua triagem determinar que este é o caso, sugerimos que você simplesmente feche o bug. Não
deixe isso aberto fingindo que um dia você vai consertar.
Escolha a mídia que você deve usar para registrar um bug Quando falamos sobre
mídia, queremos dizer a variedade de maneiras pelas quais você pode registrar um bug. Pode ser um sistema de
rastreamento de defeitos ou fichas, ou talvez você opte por não ter nenhum registro físico.
Cartões de índice
Os cartões de índice (sejam cartões reais ou virtuais em um sistema de planejamento e rastreamento on-line) não
deixam muito espaço para muitos detalhes administrativos, mas dão grande visibilidade às questões pendentes quando
são fixados no storyboard, especialmente se eles estiverem em outra cor. Algumas equipes usam impressões de tela e
grampeiam-nas no verso do cartão ou escrevem os detalhes em um arquivo de texto, ou até mesmo gravam as etapas
em formato de áudio em um gravador de voz portátil.
Existem muitas opções, mas sugerimos que você escolha uma que contenha informações suficientes para orientar
alguém na reprodução de um problema ou para focar uma discussão quando o programador estiver pronto para corrigi-
lo. O cartão é tangível. Quinhentos bugs em uma ETED são apenas um número. Uma pilha de 500 cartas é
impressionante.
Use cartões nas seguintes circunstâncias:
Você é uma equipe ágil disciplinada e está corrigindo todos os bugs em uma iteração.
Você deseja tornar os bugs visíveis para a equipe.
Não há nada que impeça você de ter fichas e uma ETED.
Sistema de rastreamento de defeitos
Use uma DTS nas seguintes circunstâncias:
Sua equipe está distribuída.

Você precisa rastrear bugs para fins de auditoria ou capturá-los em notas de lançamento.
Você tem bugs que escapam de uma iteração e precisa se lembrar de corrigi-los mais tarde.
Você tem um sistema legado com um grande número de defeitos.
De uma forma ou de outra, você provavelmente desejará ter algum tipo de DTS para registrar
alguns dos erros. Isso não significa que você precise registrar todos eles. Seja esperto
sobre quais você registra.
Nenhum mesmo
Por que você não registraria um bug? A maioria das equipes com as quais trabalhamos definiu
regras para si mesmos que nenhum bug é corrigido sem um teste de unidade. Se você também tem um
suíte de automação funcional, então você pode detectar bugs maiores com eles.
O argumento é que se houver um teste que detecte o bug, você não tem
precisa registrar o bug. Qualquer coisa aprendida com a correção do bug foi capturada em
o teste e o código. No entanto, você precisa reconhecer que nem todos os testes são
fácil de automatizar.
Use testes para capturar bugs nas seguintes circunstâncias:
Sua equipe é disciplinada e escreve testes para cada bug encontrado.
Alternativas e sugestões para lidar com bugs

À medida que as equipes amadurecem, elas encontram procedimentos que funcionam para elas. Eles eliminam
tarefas redundantes. Eles se tornam mais experientes no uso de cartões de histórias,
quadros e pendências de projetos. Eles usam testes de forma eficaz e aprendem quais bugs
registrar e quais métricas fazem sentido para sua equipe. Nesta seção, compartilharemos
algumas ideias que outras equipes encontraram que funcionam para elas.
Defina as regras
Estabeleça regras como: “O número de cartas rosa (bugs) nunca deve ultrapassar
dez de cada vez.” Revise-os sempre que tiver uma retrospectiva da equipe. Se
sua taxa de defeitos está diminuindo, não se preocupe. Se a tendência for oposta, gaste
tempo analisando a causa raiz dos bugs e criando novas regras para mitigá-los.
Corrigir todos os bugs
Não se esqueça de corrigir bugs de baixa prioridade encontrados durante a iteração também, porque
eles afetam o desenvolvimento futuro. Em nossa experiência, há
parece haver uma forte correlação entre “baixa prioridade” e “rápida solução”, embora não tenhamos
fatos concretos para apoiar isso. Sugerimos parar pequenos,
insetos isolados antes que se tornem insetos grandes e emaranhados.
Combinar insetos
Se você encontrar muitos bugs em uma área, pense em combiná-los em uma melhoria ou história.
Quando comecei a trabalhar na WestJet, encontrei vários pequenos problemas com o aplicativo móvel.
O aplicativo funcionou corretamente, mas fiquei confuso quanto ao fluxo.
Só encontrei esses problemas porque era novo e não tinha percepções anteriores.
A equipe decidiu agrupar as questões que eu havia levantado e encarar toda a questão como uma
nova história. Depois de estudar o problema completo com todos os detalhes conhecidos, o resultado final
o resultado foi um recurso sólido. Se os bugs tivessem sido corrigidos aos poucos, o efeito não
teria sido tão bonito.
—Janet
Trate isso como uma história
Se uma funcionalidade de “bug” realmente estiver faltando, opte por escrever um cartão para o bug
e programe-o como uma história. Essas histórias são estimadas e priorizadas assim como
qualquer outra história. Esteja ciente de que as histórias de bugs podem não receber tanta atenção
como as novas histórias de usuários no backlog do produto. Também leva tempo para criar o
história, priorizá-la e programá-la.
O backlog oculto
Antony Marcano, autor de www.TestingReflections.com, ressalta que, embora as histórias de
usuários e seus testes de aceitação descrevam o comportamento desejado, os relatórios de defeitos
descrevem o mau comportamento. Por trás de cada mau comportamento está um comportamento
desejado, muitas vezes não definido previamente. Assim, por trás de cada relatório de defeito pode
haver uma história de usuário oculta. Ele explica suas experiências.
No Capítulo 5, “Transição de Processos Típicos”, mencionamos o trabalho de Antony Marcano

postagem no blog sobre sistemas de rastreamento de defeitos sendo um backlog oculto em equipes ágeis.
Antônio compartilha suas ideias sobre como revelar esse segredo.
As publicações do XP sugerem que se você encontrar um bug, você deve escrever

um teste automatizado reproduzindo-o. Muitas equipes enviam um relatório de bug e
depois escrevem um teste automatizado separado. Descobri que isso resulta em
duplicação de esforços – e, portanto, em desperdício. Quando escrevemos um
relatório de bug, declaramos as etapas, o que deveria ter acontecido (expectativa)
e o que realmente aconteceu (anti-expectativa). Um teste automatizado informa
as mesmas coisas: etapas, expectativa e executá-lo pela primeira vez deve
demonstrar a antiexpectativa. Quando você é capaz de escrever um teste de
aceitação automatizado com a mesma facilidade com que escrevee um relatório de
e bug, seus backlogs e
bug, o teste comunica tanto quanto o relatório de
storyboards permitem que você gerencie o trabalho envolvido na correção dele,
então por que escrever um relatório de bug separado?
Métricas de bugs são tudo o que resta. As métricas de bugs são tradicionalmente
usadas para ajudar a prever quando o software estará pronto para lançamento ou
para destacar se a qualidade está melhorando ou piorando. Nas abordagens de
teste primeiro, em vez de nos dizer se a qualidade está a melhorar ou a piorar,
diz-nos até que ponto éramos bons a prever os testes – ou seja, quão grandes
eram as lacunas no nosso pensamento original. Esta é uma informação útil
para retrospectivas e pode ser alcançada simplesmente marcando cada teste com
detalhes de quando ele foi identificado – elaboração da história, exploração pós-
implementação ou em produção. Quanto a prever quando seremos capazes de
lançar – quando estivermos completando software de “qualidade liberável” a cada
iteração – esse trabalho é feito por gráficos de burn-down/burn-up e similares.
Com um novo projeto em que estava trabalhando, sugeri que começássemos

a usar um sistema de rastreamento de bugs quando a necessidade fosse
urgente. Capturamos o resultado dos testes exploratórios realizados dentro da
iteração como testes automatizados, em vez de relatórios de bugs.
Determinamos se o teste pertencia à história atual, a outra história ou se esses
testes inspiraram novas histórias. Gerenciamos essas histórias como faríamos
com qualquer outra história e usamos gráficos burn-down para prever quanto
escopo seria alcançado ao final da iteração. No final, nunca configuramos um
sistema de rastreamento de bugs.
No entanto, há uma diferença entre histórias de usuários típicas e histórias de usuários
inspiradas em bugs. Anteriormente, nossas histórias e testes tratavam apenas de
comportamentos ausentes (ou seja, recursos que sabemos que queremos implementar no futuro).
Agora, eles também começaram a representarmau comportamento. Achamos útil in-

informações resumidas completas sobre o mau comportamento em nossa história de usuário
proposta para ajudar o cliente a priorizá-lo melhor. Por exemplo:
Como um cadastrado serei impedido

seja de acessaro usuário desejado, caso minha senha
possa medigitada utilizando
sentir mais seguroodo
caso
queincorretodo sistema,
outra senha, para
ninguém que eu
poderá adivinhar
minhasenha ao invés de ter acesso ao sistema .
acesso
O “em vez de” foi entendido pelo cliente como significando “isso é algo que acontece
atualmente” – o que é um mau comportamento e não apenas um comportamento ainda a ser
implementado.
Usando essa abordagem apenas de teste para capturar bugs, percebi que histórias
inspiradas em bugs são priorizadas mais como iguais às histórias de usuários de novos
recursos, enquanto antes muitas vezes davam mais atenção aos “novos recursos interessantes”
no backlog do produto do que os maus comportamentos descritos no rastreamento de bugs.
Foi então que percebi que os sistemas de rastreamento de bugs estão essencialmente
ocultos, ou pendências secretas.
Em algumas equipes, entretanto, o oposto é verdadeiro. As políticas de correção de todos os

bugs podem dar mais atenção aos bugs em detrimento de novos recursos talvez mais
importantes no backlog principal.
Agora, se estou treinando uma equipe no meio do projeto, eu a ajudo a encontrar maneiras
melhores e mais rápidas de escrever testes automatizados. Eu os ajudo a usar essas
melhorias na escrita de testes automatizados derivados de bugs. Eu os ajudo a encontrar
a história apropriada – nova ou existente – e os ajudo a aproveitar as informações agregadas
úteis para retrospectivas. Eventualmente, eles chegam à mesma conclusão que eu: o
rastreamento tradicional de bugs começa a parecer um desperdício e redundante. É quando
eles decidem que não querem mais ou não precisam mais de um backlog oculto.
Se os bugs forem simplesmente registrados em uma DTS, informações importantes poderão ser
efetivamente perdidas do projeto. Quando escrevemos testes de aceitação para impulsionar o
desenvolvimento, tendemos a focar no comportamento desejado. Aprender sobre o comportamento
indesejado de um defeito e transformá-lo em histórias é um acréscimo vital para produzir a
funcionalidade certa.
Adesivos azuis, verdes e vermelhos
Cada equipe precisa determinar o processo que funciona para ela e como fazer
esse processo facilmente visível. A história a seguir é sobre um processo que funcionou
para Janete.
Há alguns anos, trabalhei em um sistema legado com muitos bugs já registrados no sistema antes da
introdução do ágil. Um dos desenvolvedores foi inflexível ao afirmar que não usaria um sistema de
rastreamento de defeitos. Ele acreditava firmemente que eles
foram uma perda de tempo. No entanto, os testadores precisavam dos defeitos registrados porque
eram muitos.
A equipe chegou a um acordo que funcionou para todos. Bugs encontrados durante testes em
pares com os programadores não foram registrados, pois foram corrigidos imediatamente. Todos os
outros foram registrados na ETED. Os bugs que precisavam ser corrigidos na iteração atual foram
registrados em cartões rosa com o resumo e o número do bug e depois colocados no storyboard.
Todos os outros passaram a fazer parte do backlog do produto.
Os programadores puderam examinar os detalhes do sistema, mas também pediram mais

informações aos testadores, se necessário. Como as questões estavam no storyboard, elas
passaram a fazer parte dos stand-ups e discussões diárias. Quando um bug era corrigido, os
programadores escreviam a correção e qualquer informação extra no verso do cartão.
Eles colocaram um adesivo azul no cartão para que os testadores soubessem que ele estava pronto para o teste. Um
adesivo verde significava que havia sido verificado como corrigido e um adesivo vermelho significava que não estava
consertado e precisava de mais trabalho. Claro, houve muitas conversas entre os testadores e
os programadores. James, um dos programadores, e eu nos divertimos muito com um bug que
simplesmente não conseguia ser corrigido. No final, o cartão parecia ter uma lagarta – azul,
vermelho, azul, vermelho, azul e, finalmente, verde.
Ficamos todos muito entusiasmados quando aquele bug foi eliminado.
Os testadores fecharam bugs e fizeram a maior parte da administração, porque o DTS era seu
requisito. Depois de um tempo, os programadores começaram a inserir o que consertaram
no sistema de rastreamento de defeitos porque era mais fácil do que escrever no cartão. A equipe
ainda continuou a usar os cartões por causa da visibilidade. Foi fácil ver rapidamente quantos bugs
pendentes havia na iteração ou no backlog.
—Janet
Essa abordagem funcionou para esta equipe porque havia muita disciplina
a equipe, e a maioria dos novos bugs foram corrigidos na iteração se fizessem parte
a funcionalidade nova ou alterada. Os únicos bugs que entraram no backlog
eram bugs legados considerados de baixo risco.
Comece simples
Sugerimos usar um sistema o mais simples possível e aplicar a complexidade o mais

obrigatório. O código produzido test-first é, em nossa experiência, bastante livre de bugs
no momento do check-in. Se você encontrar muitos bugs no novo código, seu
a equipe precisa descobrir o porquê e agir. Tente encurtar o ciclo de
codificação, integração e teste para que os programadores obtenham feedback imediato
sobre a qualidade do código. Talvez alguma seção com erros do código legado precise
ser redesenhado antes que afunde sua equipe em dívidas técnicas. Talvez você
precisa trabalhar mais de perto com os especialistas de negócios para compreender a
funcionalidade desejada.
FACILITAR A COMUNICAÇÃO 429
Outra ideia poderia ser criar uma lista contínua de “iniciar, parar, continuar” para que
Mais sobre retro-
você pode se lembrar de alguns dos problemas durante a retrospectiva da iteração.
perspectivas no
Capítulo 19,
“Concluir a Iteração”.
FACILITAR A COMUNICAÇÃO
O stand-up diário ajuda as equipes a manter a comunicação próxima que

precisar. Todos na equipe aprendem o status atual das tarefas e histórias, e
podem ajudar uns aos outros com obstáculos. Muitas vezes, os programadores auditivos descrevem
tarefas nas quais estão trabalhando fornece uma pista de que eles podem ter entendido mal
os requisitos do cliente. Isso sinaliza a necessidade de uma discussão em grupo após o stand-up. Se
um testador precisar de ajuda com um problema de teste que surgir, ele
pode pedir à equipe que fique após o confronto para conversar sobre isso. As tarefas perdidas são
frequentemente identificados durante trocas, e novos cartões podem ser escritos no local.
O stand-up é um bom momento para observar o progresso. Use gráficos grandes e visíveis, como
como storyboards, gráficos burndown e outras dicas visuais para ajudar a manter o foco
e conheça seu status. Se o fim da iteração estiver próximo e a codificação
em uma história parece “travada”, levante uma bandeira vermelha e pergunte à equipe o que pode ser feito
sobre isso. Talvez algum emparelhamento ou ajuda extra faça as coisas andarem. Lisa sempre notou
quando ainda há muitos testes a fazer e o tempo está se esgotando. Ela
pede ajuda para compensar a folga. Toda a equipe se concentra no que precisa
ser feito para completar cada história e fala sobre a melhor abordagem.
Quando as equipes usam um meio eletrônico para acompanhar histórias, há uma

tendência a esquecer o storyboard. Janet descobre que ter os dois pode parecer
como uma duplicação de esforços, mas a visibilidade do progresso para a equipe supera em muito a
sobrecarga extra de escrever os cartões de tarefas e movê-los conforme
eles estão concluídos. Ter o storyboard dá foco à sua equipe durante o
stand-ups ou quando você está conversando com alguém de fora da equipe sobre o seu
progresso.
Testadores facilitam a comunicação
Os testadores podem ajudar a manter o progresso da iteração sem problemas, ajudando a fazer
certeza de que todos estão se comunicando o suficiente. Converse com os programadores quando eles
comece a trabalhar em uma história e certifique-se de que eles a entendam. Lisa descobre que
ela pode escrever todos os testes e exemplos que quiser no wiki da equipe, mas se
ninguém se preocupa em lê-los, eles não ajudam. Na dúvida, ela vai até lá
requisitos e testes com o programador que pega os cartões de tarefas.
Os programadores sempre terão dúvidas enquanto desenvolvem uma história, mesmo que
entender bem o negócio e a história. É melhor se um cliente estiver disponível
para responder perguntas, porque essa é a comunicação mais direta. Testadores

não deveria atrapalhar isso; no entanto, observamos que os especialistas em negócios
às vezes têm dificuldade em explicar um requisito, ou um programador
simplesmente tem a ideia errada e não consegue entrar na mesma página do cliente.
O Poder dos Três se aplica aqui. Os testadores podem ajudar clientes e programadores
a encontrar uma linguagem comum.
Uma pequena competição amigável

Gerard Meszaros, conhecido treinador ágil e autor de [2007], compartilhou xUnidade Teste Padrões
esta história sobre uma equipe com a qual estava trabalhando e como um jogo resolveu um problema
de comunicação.
Estávamos tendo problemas para fazer com que os desenvolvedores conversassem com os
empresários sobre suas suposições. Quando eles conversavam, o testador muitas vezes
ficava de fora. O testador às vezes discutia algo com a empresa, mas nunca repassava ao
desenvolvedor. Nossa gerente de projeto, Janice, decidiu tentar mudar o comportamento
por meio de uma competição amigável.
Todos os desenvolvedores receberam fichas de pôquer azuis com um “D” escrito nelas.
Todos os testadores receberam uma ficha vermelha com um “T” e os empresários receberam
fichas amarelas com um “B”. Sempre que alguém se encontrasse com alguém de outra
área, ele poderia trocar uma ficha com cada pessoa. O objetivo era obter os conjuntos de chips
mais completos: TBD. O vencedor ganhou um troféu TBD personalizado, decorado com os
três tipos de fichas. O resultado final foi que todos ficaram muito mais interessados em se
encontrarem porque ganhariam mais fichas!
Encontre maneiras criativas de fazer com que especialistas em negócios e programadores

conversem e cheguem a um acordo sobre os requisitos. Se um jogo de fichas de pôquer os faz falar, aceite-o.
Facilitar a comunicação geralmente envolve desenhar em um quadro branco, criar

modelos de interfaces, listar outras áreas que podem ser afetadas ou trabalhar
exemplos reais. Sempre que a comunicação parecer chegar a um beco sem saída ou a
confusão for galopante, peça um novo exemplo e concentre-se nele.
A história de Lisa
Quando os participantes de planos de aposentadoria desejam sacar dinheiro de suas contas, muitas
regras complexas de aquisição de direitos e regulamentações governamentais entram em jogo. Piora
se o participante já retirou dinheiro no passado. Trabalhando em uma história para calcular o saldo
adquirido de um participante, todos os membros da minha equipe tinham ideias diferentes sobre o algoritmo
correto, embora o proprietário do produto tivesse trabalhado
FACILITAR A COMUNICAÇÃO 431
vários exemplos no início da iteração. Meu colega testador, Mike, pediu ao proprietário do produto
que trabalhasse em um novo exemplo, e vários programadores e testadores participaram da
sessão. Foram necessárias algumas horas tortuosas escrevendo números e fluxogramas em um
quadro branco, mas finalmente eles chegaram à fórmula correta e todos estavam na mesma página.
—Lisa
Trabalhe com quantos exemplos forem necessários até que a equipe entenda
aspectos bastante diferentes do sistema. Tente um formato diferente se não estiver funcionando. Por
exemplo, se as imagens desenhadas no quadro branco não forem suficientes para entender a história,
experimente planilhas ou algum outro formato que seja familiar para você.
os especialistas em negócios.
Equipes Distribuídas
Enfrentando testes que
Apoiar o Como observamos em outros capítulos, ter membros de equipe em locais diferentes
Equipe”, fala sobre
e fusos horários diferentes significam que você terá que trabalhar mais na comunicação.
algumas ferramentas
que podem ajudar

Telefones, e-mail e mensagens instantâneas constituem a base da comunicação, mas
equipes distribuídas melhores ferramentas de colaboração são desenvolvidas o tempo todo.
A história de Lisa Um dos programadores da nossa equipe, que também é gerente, mudou-se para a Índia.
Nanda trabalha lá até tarde da noite, então ele está disponível para o time de Denver no período da
manhã. Ele tem um celular com um número local de Denver, então é fácil falar com ele por telefone,
bem como por mensagem instantânea e e-mail. Agendamos reuniões onde discutimos histórias,
como reuniões de estimativas, sessões de brainstorming e planejamento de iterações, no início
da manhã para que ele possa participar. Embora a equipe não possa ser tão produtiva quanto
éramos quando estávamos co-localizados, ainda podemos nos beneficiar da experiência de domínio
e do profundo conhecimento da Nanda sobre o software.
Se Nanda contratar mais membros para a equipe na Índia, poderemos ter que abordar questões
mais complexas, como coordenação de integração e construção. Podemos considerar soluções
técnicas mais sofisticadas para problemas de comunicação.
—Lisa
Você precisará experimentar para ver o que funciona para sua equipe distribuída. Usar
retrospectivas para avaliar se a colaboração e a comunicação precisam
melhorar e debater maneiras de melhorar. Você, como testador, pode ter muito
de experiência em ajudar em projetos de melhoria de processos. Basta pensar
melhorar a comunicação como uma dessas necessidades de melhoria contínua.
A história de um testador remoto

Às vezes, os testadores são membros remotos da equipe. Erika Boyer, da iLevel by Weyerhaeuser,
mora na Costa Leste e trabalha com uma equipe em Denver. Ela é
testadora de profissão, mas em sua equipe todas as tarefas estão disponíveis. Ela pode escrever
acessórios para automatizar um teste FitNesse ou emparelhar com um programador para escrever
código de produção. Ser capaz de entrar em contato com as pessoas quando ela precisa delas é
um problema. Se ela não obtiver resposta ao enviar uma mensagem instantânea para um colega
de trabalho, ela telefona; todas as áreas de trabalho do escritório de Denver possuem um telefone. Isso é
não é infalível, porque todo mundo poderia estar na sala de descanso de uma festa de despedida e
esquecer de contar a ela. Equipes em locais diferentes precisam fazer um esforço especial para
manterem-se informadas.
Como Erika começa a trabalhar algumas horas antes da reunião diária da equipe, ela precisa de
um trabalho que possa fazer sozinha durante esse período. Ela trabalha com qualquer membro da
equipe que chega cedo em Denver e conversa com outros programadores no final do dia sobre
o trabalho que fará na manhã seguinte.
Erika consegue visualizar as tarefas da equipe por meio de uma ferramenta na intranet que mostra
cada tarefa, seu status e percentual concluído. Com algumas acomodações extras, a equipe (que
conta com outros membros remotos) consegue manter uma boa comunicação.
Mesmo à distância, Erika conseguiu transferir habilidades de teste para os programadores, mas
descobriu que eles pensam de forma diferente dos testadores. Sua equipe usa essas perspectivas
variadas a seu favor, alternando todos os tipos de tarefas entre todos os membros da equipe.
Equipes bem-sucedidas mantêm os membros remotos “informados” e compartilham habilidades e

conhecimentos. As equipes distribuídas enfrentam desafios extras para concluir com êxito as
atividades de teste, mas alguns pequenos ajustes, a consideração por parte de todos os membros
da equipe e boas ferramentas de comunicação ajudam a garantir que os testadores remotos
possam ser produtivos.
Todos nós precisamos ser capazes de nos comunicar bem uns com os outros em nossos projetos
ter sucesso. Quando as equipes estão em locais geográficos diversos, elas podem ter
trabalhar duas vezes mais para manter contato constante.
TESTES DE REGRESSÃO
A menos que você faça parte de uma equipe que está apenas começando seus esforços de automação, você tem
testes de regressão automatizados cobrindo histórias de iterações anteriores. Esperançosamente, eles estão
sendo executados como parte de um processo de construção contínuo, ou pelo menos parte de
um processo de construção diário. Se não estiverem, peça à sua equipe para implementar isso
infraestrutura crítica uma prioridade e debater com eles como isso pode
ser feito. Planeje o tempo na próxima iteração para iniciar um processo de construção.
TESTES DE REGRESSÃO 433
Mantenha a construção “verde”
Os programadores devem executar todos os testes de unidade automatizados antes de fazer check-
in do novo código. No entanto, os testes de unidade podem falhar na construção contínua, seja
porque alguém se esqueceu de executá-los antes do check-in ou devido a uma diferença no
ambiente de tempo de execução ou IDE. Temos testes de unidade por um motivo, então sempre
que um falhar, a maior prioridade da equipe (além de um problema de produção que atrapalha a
produção) deve ser consertá-lo e fazer a compilação funcionar novamente.
As equipes adotam abordagens diferentes para garantir que sua construção permaneça “verde”. A
equipe de Lisa tem um processo de construção que envia resultados por e-mail após cada
construção. Se a compilação falhar, a pessoa que verificou a falha geralmente a corrige
imediatamente. Se não estiver claro por que a compilação falhou, os membros da equipe se reunirão para inve
O ScrumMaster deles tem um brinquedo de pelúcia que ela coloca na mesa da pessoa que
“quebrou a construção”, como um lembrete visual de que ele precisa ser consertado imediatamente.
Algumas equipes usam um semáforo, um orbe ambiental, uma ferramenta de monitoramento de

construção de GUI ou outra forma visual eletrônica para mostrar o status da construção. Quando
as luzes ficam vermelhas, é hora de interromper o novo desenvolvimento e consertar a construção.
Outra técnica é fazer com que uma tela apareça no IDE de todos mostrando que a compilação
falhou, e o pop-up não desaparecerá até que você clique em “Ok, vou consertar a compilação”.
Divirta-se com isso, mas manter a construção funcionando é um negócio sério.
Em casos extremos, você pode ter que comentar temporariamente um teste que falhou até que
ele possa ser diagnosticado, mas esta é uma prática perigosa, especialmente para uma equipe
novata. Todos na equipe devem parar o que estão fazendo, se necessário, até que a compilação
funcione novamente.
Mantenha a construção rápida
A compilação precisa fornecer feedback imediato, portanto, seja breve. Se a compilação demorar
mais do que a frequência média de check-ins de código, as compilações começarão a se acumular
e os testadores não conseguirão obter o código que precisam testar. A diretriz do XP para o tempo
de construção é de dez minutos [Fowler, 2006]. A equipe de Lisa tenta manter a construção em
menos de oito minutos, porque eles fazem check-in com frequência.
Testes que demoram muito, como testes que atualizam o banco de dados, testes funcionais acima
do nível de unidade ou scripts de teste de GUI, devem ser executados em um processo de
construção separado. Se a equipe estiver limitada em hardware, talvez seja necessário executar a
compilação “completa” com o conjunto completo de testes à noite e a compilação “contínua” que
possui apenas testes de unidade continuamente durante o horário de trabalho. Ter uma construção
“completa” separada e contínua com todos os conjuntos de testes de regressão vale o investimento.
A equipe de Lisa recebe feedback a cada 90 minutos de sua construção “completa”, e isso tem
comprovadamente inestimável para evitar problemas de regressão. Este conjunto secundário de

testes não impede um programador de verificar seu código.
Construindo um Conjunto de Regressão
Durante a iteração, você automatiza novos testes. Assim que passarem, adicione
para o conjunto de regressão, conforme apropriado. Você pode não precisar de todas as arestas
caso ou permutação incluída no conjunto de regressão e você deseja manter
os conjuntos de regressão são rápidos o suficiente para fornecer feedback oportuno. Como cada história é
concluído, os testes que confirmam sua funcionalidade devem ser incluídos no conjunto de regressão e
fazer parte do ciclo regular de construção.
Os próprios testes de regressão devem estar sob alguma forma de controle de versão.
É melhor mantê-los no mesmo sistema de controle de código-fonte que o código de produção. Dessa
forma, quando você marca o código para lançamento de produção, a tag
também contém todas as versões dos testes que funcionaram com o código. No
no mínimo, mantenha um backup diário do código de teste.
Quando os testes são adicionados ao conjunto de regressão, sua finalidade muda.

Já não existem para ajudar a impulsionar o desenvolvimento e não se espera que
encontre novos bugs. O único propósito na vida é detectar mudanças inesperadas ou
efeitos colaterais no sistema.
Verificando o “quadro geral”
Esperançosamente, você escreveu cartões de tarefas para testar a história no contexto da aplicação
maior e testar a regressão de outras partes do sistema para garantir que a nova história
não teve um efeito negativo. Você pode ter automatizado alguns desses testes ponta a ponta, como o
exemplo do Capítulo 12, “Resumo dos quadrantes de teste”.
Mas às vezes, mesmo que você tenha um grande conjunto de testes de regressão, testes exploratórios
manuais podem ser apropriados. A história não estará “pronta” até que você também tenha concluído
essas tarefas.
RECURSOS
Ao iniciar a iteração, certifique-se de que os ambientes de teste, os dados de teste e
ferramentas de teste estão disponíveis para acomodar o teste das histórias desta iteração. Ter esperança-
MÉTRICAS DE ITERAÇÃO 435
você antecipou totalmente essas necessidades, mas alguns requisitos só podem se tornar óbvios quando
você começar a trabalhar em uma história. Colabore com banco de dados
especialistas, administradores de sistema e outros membros da equipe para configurar qualquer
infraestrutura adicional necessária.
Você pode ter trazido recursos externos para esta iteração para ajudar no desempenho, usabilidade,
segurança ou outras formas de teste. Inclua-os em
stand-ups e discussões com os clientes conforme necessário. Combine com eles e
ajudá-los a compreender os objetivos da equipe. Esta é uma oportunidade para escolher
desenvolver novas habilidades.
MÉTRICAS DE ITERAÇÃO
No Capítulo 5, “Transição de Processos Típicos”, falamos um pouco sobre o

Capítulo 15,
propósito das métricas, mas porque as métricas são críticas para entender como
“Atividades do testador
no planejamento suas atividades de codificação e teste estão progredindo, iremos nos aprofundar mais nelas
de lançamento ou tema” aqui. Saiba qual problema você está tentando resolver antes de começar a medir
fala sobre métricas pontos de dados e passando por todo o trabalho de análise dos resultados. Nesta secção,
úteis a serem mantidas.
abordaremos algumas das medições típicas que as equipes coletam através do
iteração.
Medindo o Progresso
Você precisa saber de alguma forma quanto trabalho sua equipe concluiu em
qualquer ponto da iteração e uma ideia de quanto trabalho ainda falta fazer. Você
preciso saber quando fica óbvio que algumas histórias não podem ser concluídas
e a equipe precisa de um Plano B. Gráficos de burndown de iteração e estimativa versus
o tempo real para tarefas são exemplos usados para medir o progresso da equipe. Eles podem
ou pode não agregar valor para sua equipe específica.
Painéis de histórias ou tarefas são uma boa maneira visual de saber o status da iteração, especialmente
se for usado código de cores. Se muitos cartões de tarefas de teste ainda estiverem na área “para
coluna fazer” ou cartões de tarefas de codificação insuficientes foram movidos para “Concluído” ou
“Testado”, é hora da equipe pensar em maneiras de garantir que todos os testes
está completo. Talvez alguns membros da equipe precisem parar de codificar e começar a realizar tarefas
de teste, ou talvez uma história ou parte menos crítica de uma história precise
ser adiado até a próxima iteração para que o teste de todas as outras histórias possa
estar terminado.
Isso pode ser conseguido tanto com storyboards virtuais quanto físicos.
Seja criativo com seus efeitos visuais para que os problemas fiquem instantaneamente visíveis.
Lembre-se de que nenhuma história está “pronta” até ser testada em todos os níveis apropriados.
As equipes podem ter outros critérios para determinar quando uma história está “pronta”, como se
foi revisado por pares ou os testes de regressão automatizados foram concluídos. Sobre
o storyboard mostrado na Figura 18-6, a coluna “Concluído” para cada linha da história
é a coluna mais à direita. A coluna logo à esquerda é a coluna “Verificar”. A história não é
considerada “terminada” até que todas as cartas, incluindo os testes
cartões de tarefas, estão na coluna “Concluído”. Uma olhada no quadro é suficiente para
saber quais histórias terminaram.
Mesmo as equipes que não acompanham o burndown no nível da tarefa podem fazê-lo na história
nível. Saber quanto trabalho a equipe pode realizar em cada iteração (sua velocidade)
ajuda com o plano geral de lançamento e com a redefinição de prioridades para cada iteração.
Simplesmente saber o número de histórias concluídas em uma iteração pode ser suficiente se
elas tenderem a ter o mesmo tamanho médio. Embora os planos sejam, na melhor das hipóteses,
provisórios, é útil ter uma ideia de quantas histórias podem ser
Figura 18-6 Storyboard mostrando histórias e tarefas de iteração

concluído até uma data de lançamento definitiva ou quais histórias poderão ser concluídas no
próximo trimestre.
Falamos sobre métricas de defeitos no Capítulo 15, “Atividades do testador em lançamento ou

Planejamento Temático” dando a você algumas ideias de alto nível sobre o que monitorar.
A coleta de métricas sobre defeitos pode consumir muito tempo, portanto, considere sempre
o objetivo antes de começar a medir. Qual é o propósito das métricas que você
gostaria de reunir? Quanto tempo você precisará para seguir a tendência antes de
sabe se eles são úteis?
A contenção de defeitos é sempre uma métrica favorita para capturar. Quando o defeito foi
encontrado? Em projetos tradicionais, é muito mais fácil porque você tem requisitos e fases de
codificação “difíceis”. Quando toda a equipe é responsável por
qualidade, e todos estão trabalhando juntos o tempo todo, é muito mais difícil
determinar “quando” o defeito foi injetado no sistema.
Gostaríamos de desafiar a ideia deste tipo de métrica como desnecessária em

desenvolvimento ágil. No entanto, se você descobrir que muitos bugs estão escapando,
você pode querer começar a rastrear que tipo de bugs eles são para que você possa resolver
a causa raiz. Por exemplo, se os bugs pudessem ter sido detectados com a unidade
testes, então talvez os programadores precisem de mais treinamento para escrever testes unitários.
Se os bugs forem perdidos ou os requisitos forem mal compreendidos, talvez não
tempo suficiente é gasto no planejamento da iteração ou os testes de aceitação não são detalhados
suficiente.
Se você pratica tolerância zero com defeitos, provavelmente não tem

precisa rastrear defeitos durante a codificação e o teste. Um simples cartão no
O storyboard lhe dará todas as informações que você precisa.
Quaisquer que sejam as métricas que você escolher medir, opte pela simplicidade.
Em uma organização em que estive, rastreamos o número de defeitos registrados no DTS

em diversas versões. Foram defeitos que escaparam da iteração ou foram encontrados no
sistema legado. A Figura 18-7 mostra a tendência ao longo de um ano e meio.
No início, o número de problemas encontrados logo após a liberação para o controle de

qualidade para teste final era alto (33 problemas encontrados em um mês). Os clientes
encontraram ainda mais problemas durante o UAT, que durou mais de dois meses porque não estavam
Figura 18-7 Exemplo de tendência de defeito (mas interrompido depois de um tempo)
confiante na qualidade do lançamento. No mês em que foram relatados zero defeitos,

estávamos apenas iniciando uma nova versão, portanto não havia novas funcionalidades
para testar. Durante o ano seguinte, cada vez menos defeitos foram registrados e tornou-
se impossível dizer onde ocorreu um lançamento real apenas observando a tendência.
Este gráfico foi usado para mostrar aos clientes que a equipe estava se tornando
consistente com seus testes e lançamentos. Depois que a equipe e os clientes
acreditaram que os números não aumentariam, as métricas não eram mais
necessárias e foram abandonadas.
—Janet
Não tenha medo de parar de usar métricas quando elas não forem mais úteis. Se o
problema pelo qual foram inicialmente reunidos não existe mais, não há razão para
continue reunindo-os.
Sua equipe pode ter que fornecer métricas aos gerentes superiores ou a um Escritório de
Gerenciamento de Projetos (PMO), especialmente se você trabalha para uma grande organização. Patrício
Fleisch, consultor da Accenture que trabalhava como analista funcional em uma
Métricas úteis de iteração
Coni Tartaglia, gerente de teste de software da Primavera Systems, Inc., explica algumas maneiras
que encontrou para obter métricas de iteração úteis.
A coleta de métricas no final da iteração é particularmente útil quando muitas equipes diferentes
estão trabalhando no mesmo lançamento de produto. Isso ajuda a garantir que todas as
equipes terminem a iteração com o mesmo padrão de “pronto”. As equipes devem concordar
sobre o que deve ser medido. A seguir estão alguns padrões para software potencialmente
distribuível [Schwaber 2004] e diferentes maneiras de julgar o estado de cada um.
• As entregas do Sprint são refatoradas e codificadas de acordo com padrões.
Use uma ferramenta de análise estática. Concentre-se em dados que sejam úteis e acionáveis.
Decida cada sprint se uma ação corretiva é necessária. Por exemplo, use uma ferramenta de
código aberto como FindBugs e procure um aumento a cada sprint no número de problemas
de prioridade um. Corrija-os adequadamente.
• As entregas do Sprint são testadas em unidade.
Por exemplo, observe os resultados da cobertura de código de cada sprint. Conte o número de
pacotes com cobertura de teste de unidade dentro de intervalos de 0% a 30%
(baixa cobertura), 31%–55% (cobertura média) e 56%–100% (alta) cobertura. Os pacotes legados
podem cair na faixa de cobertura baixa, enquanto a cobertura para novos pacotes deve cair na
faixa de 56% a 100%, se você estiver praticando o desenvolvimento orientado a testes. É desejável
um aumento na faixa de cobertura alta.
• As entregas do Sprint passam por testes de aceitação automatizados e aprovados.
Mapeie testes de aceitação automatizados para requisitos em um sistema de gerenciamento de

qualidade. Ao final da iteração, gere um relatório de cobertura mostrando que todos os
requisitos selecionados como objetivos para a iteração passaram nos testes. Os requisitos que
não mostram aprovação na cobertura do teste não estão completos. A mesma abordagem é
facilmente executada usando cartões de histórias em um quadro de avisos. A intenção é
simplesmente mostrar que os testes acordados para cada requisito ou história estão sendo
aprovados no final do sprint.
• As entregas do Sprint são integradas com sucesso.
Verifique os resultados do teste de construção de integração contínua para garantir que eles
estão passando. Execute outros testes de integração durante o sprint. Faça correções antes do
início da próxima iteração. Hesite em iniciar uma nova iteração se os testes de integração falharem.
• As entregas do Sprint estão livres de defeitos.
Os requisitos concluídos durante a iteração devem estar livres de defeitos.
• O produto pode ser enviado em [30] dias?

Simplesmente faça esta pergunta a si mesmo no final de cada iteração e prossiga para a
próxima iteração de acordo com a resposta.
Métricas como essa são fáceis de coletar e analisar e podem fornecer oportunidades valiosas para
ajudar as equipes a corrigir seu rumo. Eles também podem confirmar
os padrões de engenharia que as equipes implementaram para criar software potencialmente distribuível
em cada iteração.
empresa de software durante o tempo em que escrevemos este livro, nos deu o seguinte
exemplos de métricas que sua equipe fornece ao PMO.
Números de execução de testes por história e área funcional

Status de automação de teste (número de testes automatizados vs. manuais)
Gráfico de linha do número de testes aprovados/reprovados ao longo do tempo

Resumo e status de cada história
Métricas de defeito
A coleta e o relatório de métricas como essas podem resultar em custos indiretos significativos. Procure as
maneiras mais simples de satisfazer as necessidades da sua organização.
RESUMO
Neste ponto da nossa iteração de exemplo, nosso testador ágil trabalha em estreita colaboração com
programadores, clientes e outros membros da equipe para produzir histórias em pequenos formatos.
incrementos de teste-codificação-revisão-teste. Alguns pontos a ter em mente são:
A codificação e o teste fazem parte de um processo durante a iteração.

Escreva testes detalhados para uma história assim que a codificação começar.
Impulsione o desenvolvimento começando com um teste simples; quando os testes simples
forem aprovados, escreva casos de teste mais complexos para orientar ainda mais a codificação.
Use técnicas simples de avaliação de risco para ajudar a concentrar os esforços de teste.
Use o “Poder dos Três” quando os requisitos não forem claros ou as opiniões variarem.
Concentre-se em completar uma história de cada vez.

Colabore estreitamente com os programadores para que os testes e a codificação sejam integrados.
Testes que criticam o produto fazem parte do desenvolvimento.

Mantenha os clientes informados durante toda a iteração; deixe-os revisar com antecedência e com
frequência.
Todos na equipe podem trabalhar nas tarefas de teste.
RESUMO 441
Os testadores podem facilitar a comunicação entre a equipe do cliente e a equipe de
desenvolvimento.
Determine qual é a melhor opção de “correção de bugs” para sua equipe, mas um bom
objetivo é tentar não ter bugs até o momento do lançamento.
Adicione novos testes automatizados ao conjunto de regressão e programe-o para execução
com frequência suficiente para fornecer feedback adequado.
O teste exploratório manual ajuda a encontrar requisitos ausentes depois que todo o
aplicativo foi codificado.
Colabore com outros especialistas para obter os recursos e a infraestrutura necessários para
concluir os testes.
Considere quais métricas você precisa durante a iteração; métricas de progresso e defeito
são dois exemplos.

Capítulo 19
CONCLUIR A ITERAÇÃO
Demonstração de Iteração
Embrulhar
a Iteração
Iniciar, parar, continuar

Comemore os sucessos Retrospectivas
Ideias para Melhoria
Concluímos uma iteração. O que os testadores fazem enquanto a equipe conclui esta iteração e se
prepara para a próxima? Gostamos de nos concentrar em como nós e o restante da nossa equipe
podemos melhorar e entregar um produto melhor na próxima vez.
DEMONSTRAÇÃO DE ITERAÇÃO
Um dos prazeres do desenvolvimento ágil é a oportunidade de mostrar resultados completos

histórias para os clientes no final de cada iteração. Os clientes podem ver uma experiência real,
aplicativo ativo e funcional. Eles podem fazer perguntas e dar feedback. Todos os envolvidos no
projeto, tanto do lado comercial quanto técnico, recebem
para desfrutar de uma sensação de realização.
Na equipe de Lisa, os testadores conduzem a revisão da iteração. Entre toda a equipe

membros, eles geralmente trabalharam na maioria das histórias. Eles têm uma natureza
papel como provedores de informações, e eles têm uma boa ideia do que os clientes
precisa saber sobre a nova funcionalidade. Fazer com que os testadores exibam os resultados é
uma prática comum, embora não exista uma regra rígida e rápida. O
os especialistas em negócios da equipe também são uma boa escolha para conduzir a demonstração,
porque eles têm a melhor compreensão de como o software atende aos
necessidades do negócio e eles se sentirão mais proprietários do produto. O Scrum-Master, um
programador ou um analista de negócios poderiam demonstrar os novos recursos e frequentemente
o fazem. Janet incentiva a rotação desta honra.
443
444 CAPÍTULO 19 CONCLUIR A ITERAÇÃO
Ouvindo os Clientes
Pierre Veragen explica como sua equipe usa demonstrações de iteração.
“Nós nos calamos e ouvimos nossos clientes. É tudo uma questão de química da apresentação
do grupo. De alguma forma, compartilhar o momento une os cérebros – olhamos as coisas de
uma perspectiva diferente. O evento dá origem a ideias e conceitos. Alguns morrem enquanto a
próxima pessoa fala; alguns sobrevivem e se tornam aquela grande ideia que diferencia o produto.”
A demonstração é uma oportunidade de mostrar as novas histórias, mas o feedback fornecido pelos
clientes é o maior motivo para fazê-las.
Qualquer pessoa pode anotar os comentários feitos pelos clientes enquanto participam de
a demonstração, mas os testadores são bons candidatos. Eles podem notar inconsistências
anteriormente não detectadas à medida que a demonstração avança. À medida que surgem
dúvidas, os clientes podem decidir que desejam alterar algo menor, como texto de ajuda,
ou algo maior, como o comportamento de um recurso. Pequenas alterações geralmente podem
ser feitas em tarefas e tratadas na próxima iteração, mas algumas alterações
são grandes o suficiente para se transformarem em histórias para planejar lançamentos futuros.
Demonstrações de iteração (chamadas de revisões de sprint no mundo Scrum) são uma super
oportunidade para fazer com que todos falem e pensem sobre o aplicativo. Pegar
vantagem disso. As reuniões de revisão são geralmente curtas e podem durar menos de meia hora.
hora. Se sobrar tempo depois de demonstrar novas histórias, pergunte aos clientes
se eles tiveram algum problema com a versão anterior que não tenham
relatado. Eles têm alguma preocupação geral, precisam de ajuda para entender como usar um
recurso ou surgiram novos problemas? Claro que você pode
converse com os clientes a qualquer hora, mas tenha a maioria das partes interessadas na sala
com a equipe de desenvolvimento pode levar a ideias interessantes.
RETROSPECTIVAS
Desenvolvimento ágil significa melhorar continuamente a maneira como você trabalha, e
retrospectivas são um excelente lugar para começar a identificar o que e como você pode
Faça melhor. Recomendamos reservar um tempo no final de cada iteração e lançamento
ciclo para olhar para trás e falar sobre o que deu certo, o que não deu e o que você
talvez você queira tentar na próxima iteração. Existem diferentes abordagens para a realização de
sessões retrospectivas. Não importa qual abordagem você use, é fundamental que
cada membro da equipe se sente seguro, todos são respeitados e não há acusações ou acusações.
RETROSPECTIVAS 445
A ideia é melhorar o processo, um pequeno passo de cada vez.
Iniciar, parar, continuar

Um exercício comum usado em retrospectivas de iteração é “iniciar, parar, continuar”.
A equipe se pergunta: “O que deu certo durante a iteração anterior? O que aconteceu
que não deveria acontecer novamente? O que podemos começar a fazer para ajudar
coisas que não correram bem?” Cada membro da equipe pode sugerir coisas para
começar a melhorar, coisas para parar de fazer que não estavam funcionando e coisas que estão
ajuda que deve continuar. Um facilitador ou ScrumMaster os lista em um
quadro branco ou grande pedaço de papel. Publique-os em um local onde todos possam
leia-os novamente durante a iteração. A Figura 19-1 mostra uma retrospectiva “parar,
iniciar e continuar” em andamento. O ScrumMaster (em pé) está parando de escrever,
comece e continue as sugestões no grande pedaço de papel no storyboard.
Algumas equipes iniciam esse processo com antecedência. Todos os membros da equipe escrevem “início”,
Ágil
Retrospectivas: “parar” e “continuar” em post-its e depois, durante a reunião retrospectiva, eles colocam
Tornando boas equipes excelentes os post-its no quadro e os agrupam por tópico.
[2006] tem ideias “Iniciar, parar, continuar” é apenas um exemplo dos termos que você pode usar. Alguns
imaginativas
outras ideias são: “Coisas que correram bem”, “Coisas para melhorar”, “Agradável”,
para tornar as
retrospectivas
“Frustrante” e “Para tentar”. Use os nomes que funcionarem para você. Pode ser
mais produtivas
(ver bibliografia).
Figura 19-1 Uma retrospectiva em andamento

difícil lembrar das últimas duas semanas, muito menos de um lançamento inteiro, se é isso que sua retrospectiva
cobre. Pesquise diferentes abordagens criativas para refletir sobre as experiências da sua equipe.
Aqui está um exemplo de lista “pare, comece, continue” da equipe de Lisa:
Começar:
Enviando as histórias do próximo sprint para nós mais cedo.

Não faça processamento preguiçoso de registro único. Pense em cada chamada de serviço como
uma chamada remota.
Comunique quaisquer alterações no banco de dados a todos.
Parar:
Aceitar histórias sem requisitos completos.
Continuar:
Executando testes FitNesse para o código em que você está trabalhando.

Documentar o que surgiu em reuniões ou discussões informais.
Comunicando-se melhor uns com os outros.
Mostrando maquetes antecipadamente.
Fazendo desenvolvimento orientado ao FitNesse.
Se a lista de itens “iniciar, parar, continuar” for longa, é uma boa ideia escolher um ou dois para focar na nova
iteração. Para priorizar os itens, dê a cada membro da equipe “n” votos que eles possam atribuir aos itens. Cada
uma das dez pessoas da equipe de Lisa recebe três votos e podem aplicá-los todos a um item, se acharem que
isso é mais importante, ou podem votar em dois ou três itens diferentes. Os itens com mais votos são considerados
itens em foco. Janet também teve sucesso com essa forma de priorizar.
Além dos itens “iniciar, parar, continuar”, a equipe pode simplesmente escrever cartões de tarefas para ações a
serem realizadas na próxima iteração. Por exemplo, se a construção em andamento for muito lenta, escreva um
cartão para “obter a construção em andamento em menos de dez minutos”.
Na próxima iteração, reserve um tempo para examinar um ou dois itens de foco que você deseja melhorar. No
final dessa iteração, faça um checkpoint para ver se você melhorou. Se não, pergunte por quê. Você deveria
tentar algo diferente? Ainda é importante? Pode ser que tenha perdido importância ou realmente não fosse
importante no quadro geral. Se você pensou que melhorou em uma área problemática e ela ressurgiu, você terá
que decidir fazer algo a respeito ou então parar de falar sobre isso.
RETROSPECTIVAS 447
Descobrimos que as retrospectivas são uma forma simples e altamente eficaz de

equipes para identificar e resolver problemas. A reunião retrospectiva é perfeita
oportunidade de levantar questões relacionadas com os testes. Traga as questões em um objetivo,
maneira sem culpa. A equipe pode discutir cada problema, o que pode estar causando isso, e anotar
algumas ideias para solucioná-lo.
Ideias para melhorias

Vamos dar uma olhada em alguns dos itens que entraram na lista para melhorias. Muitas vezes, uma
equipe identificará problemas realmente grandes, mas nunca os seguirá
e realmente fazer algo sobre eles. Por exemplo, talvez muitos bugs em nível de unidade sejam
descobertos depois que os programadores alegaram que a codificação foi
completo.
A equipe pode decidir que os programadores não estão cobrindo código suficiente com
testes unitários. Eles podem escrever um item de ação para executar a ferramenta de cobertura de código
antes de fazer check-in do novo código ou começar a escrever um cartão de tarefa de “testes de unidade” para cada
história para ter certeza de que eles estão concluídos. Talvez a equipe não tenha terminado todos os
testar tarefas de automação antes do término da iteração. Ao discutir o problema, a equipe descobre que
os testes executáveis iniciais eram muito complexos e
eles precisam primeiro se concentrar em escrever e automatizar um teste simples ou formar pares para um
melhor design de teste. Certifique-se de que os itens de ação sejam concretos.
As equipes ágeis tentam resolver seus próprios problemas e definir diretrizes para ajudá-las a melhorar.
Itens de ação direcionados a um problema podem ajudar em outros.
Quando a equipe de Lisa teve problemas para terminar histórias e testá-las durante cada iteração, ela
criou várias regras ao longo de alguns
retrospectivas:
Conclua os casos de teste de alto nível para todas as histórias até o quarto dia da
iteração.
Entregue uma história para testar até o quarto dia da iteração.

Concentre-se em terminar uma história de cada vez.
100% dos recursos devem ser verificados até o fechamento do expediente, no penúltimo dia
da iteração.
Essas regras fizeram mais do que ajudar a equipe a concluir as tarefas de teste. Eles facilitaram
um fluxo e ritmo que ajudou a equipe a trabalhar em um ritmo constante e sustentável
ao longo de cada iteração.
Comece a próxima reunião retrospectiva revisando os itens de ação para ver o que
itens foram benéficos. A equipe de Lisa coloca rostos felizes, tristes ou neutros ao lado
itens para indicar se a equipe os experimentou e concluiu que foram bem-sucedidos. O

a equipe deve descobrir as razões por trás de qualquer rosto triste. Foram alguns itens
simplesmente esquecido? As restrições de tempo impediram a equipe de tentar uma
nova atividade? Pareceu menos uma boa ideia mais tarde? Essas discussões poderão
levar à alteração do item de melhoria ou à sua evolução para um novo.
Quando as ações de melhoria se tornam um hábito para a equipe, elas não

não precisa mais ser escrito na lista “parar, iniciar e continuar”. Itens “iniciais”
que funcionam bem podem ser movidos para a coluna “Continuar”. Algumas ideias não
trabalho, ou se revelarem desnecessários, e também podem ser retirados da lista para
a próxima iteração.
Consulte suas ideias para melhorias e itens de ação durante a iteração. Publicar
coloque-os em um local (na parede ou online) onde todos os vejam com frequência. Lisa
a equipe às vezes analisa a lista durante uma reunião stand-up no meio da iteração.
Se você pensar em novas ideias de melhoria durante a iteração, anote-as,
possivelmente até na lista existente, então você não esquecerá na próxima iteração.
É uma boa ideia acompanhar as coisas que atrapalham durante a iteração. Mantenha
uma lista de pendências de impedimentos em algum gráfico grande e visível. Falar sobre
os impedimentos em cada iteração e escrever cartões de tarefas ou tomar medidas para
eliminá-los.
Uma abordagem para melhoria de processos

Rafael Santos, VP de Desenvolvimento de Software e Chefe ScrumMaster da Ultimate Software, e
Jason Holzer, Chefe PSR (Desempenho, Segurança, Confiabilidade)
Architect, nos explicou que suas equipes consideraram as retrospectivas que usavam o modelo
“parar, iniciar e continuar” ineficazes. Eles fizeram listas de “parar, começar e continuar”, mas
elas não forneceram foco suficiente para resolver os problemas.
Em vez disso, o ScrumMaster manteve um backlog de impedimentos, e a equipe descobriu que

isso funcionava melhor do que as retrospectivas. Os impedimentos podem estar relacionados a
testes ou ferramentas.
Eles também fazem mapeamento do fluxo de valor para encontrar o maior “tempo de espera” e
Consulte a bibliografia
usam os “cinco porquês” da Toyota para entender qual impedimento é o maior ou qual restrição
para obter bons
precisa ser abordada.
recursos para o
desenvolvimento enxuto Um exemplo compartilhado foi que em uma equipe com três programadores e um testador, o
práticas. maior problema era um gargalo nos testes. Rafael perguntou à equipe o que o testador faz e
escreveu esses itens em um quadro branco. Então ele perguntou aos programadores quais das
coisas no quadro eles não poderiam fazer. Havia apenas um item que eles achavam que não
conseguiriam resolver. Isso ajudou os programadores
CELEBRAR SUCESSOS 449
entender como todos na equipe de desenvolvimento, não apenas os testadores,

poderiam ser responsáveis pelas tarefas de teste. Este foi um exercício altamente eficaz.
Abordagens criativas como essa ajudam novas equipes ágeis a enfrentar desafios
difíceis de testes. Retrospectivas são um bom ambiente para experimentação.
Use retrospectivas como uma oportunidade para levantar questões relacionadas aos testes e obter o
toda a equipe pensando em possíveis soluções. Ficamos agradavelmente surpresos com as ideias
inovadoras que surgem de uma equipe inteira focada em
como melhorar a forma como funciona.
CELEBRAR SUCESSOS
As práticas de desenvolvimento ágil tendem a moderar os altos e baixos que existem
em processos mais tradicionais ou caóticos. Se sua equipe em cascata finalmente conseguir lançar um
lançamento após um ciclo de um ano que termina em um estressante ciclo de correção e teste de dois
meses, todos podem estar prontos para comemorar o sucesso.
evento com uma grande festa - ou eles podem simplesmente entrar em colapso por algumas semanas.
Equipes ágeis que lançam lançamentos a cada duas semanas tendem a permanecer na codificação normal e
testando o groove, começando no próximo conjunto de histórias depois de desenhar apenas o suficiente
fôlego para realizar uma revisão e retrospectiva da iteração. Isso é legal, mas você
sei o que dizem sobre todo trabalho e nenhuma diversão.
Certifique-se de que sua equipe reserve pelo menos um tempinho para dar tapinhas nas costas e
reconhecer suas conquistas. Mesmo pequenos sucessos merecem uma recompensa. O prazer é um valor
ágil vital, e um pouco de motivação ajuda sua equipe a continuar
em seu caminho de sucesso. Por alguma razão, isso pode ser difícil de fazer. Muitos ágeis
as equipes têm dificuldade em reservar tempo para comemorar o sucesso. Às vezes você está ansioso
para prosseguir com a próxima iteração e não perca tempo para parabenizar-se pelas realizações anteriores.
A equipe de Lisa termina uma iteração todas as quintas-feiras alternadas e conduz sua retrospectiva, revisão
da iteração e lançamento no dia seguinte. Depois de suas reuniões
Para concluir, eles geralmente se envolvem em algo que chamam de “Diversão de sexta-feira”. Esse
às vezes consiste em jogar um jogo de curiosidades ou de tabuleiro bobo, sair para um
beber ou jogar uma partida de minigolfe. Ter a oportunidade de relaxar e
dar boas risadas traz um benefício colateral para a formação de equipes.
Para marcos maiores, como um grande lançamento ou atingir uma meta de cobertura de testes, o
toda a empresa tem uma festa para comemorar, trazendo comida servida ou saindo
a um restaurante na sexta-feira à tarde. Esta é uma bela recompensa e um reconhecimento

para todos, tanto da equipe comercial quanto da técnica.
Se a sua equipe é nova e ágil, motive-se recompensando pequenas realizações. Comemore

o número crescente de testes de unidade aprovados em cada compilação.
Oooh e aaah sobre o gráfico mostrando o burndown real correspondente ao burndown
projetado. Toque uma campainha quando os testes de unidade quebrados na compilação forem
corrigido (ok, isso pode ser irritante, mas reconheça-o de alguma forma).
Comemore seus sucessos individuais também. Parabenize seu colega de trabalho por
completando a primeira linha de base de teste de desempenho do projeto. Dê ao seu DBA um
estrela de ouro pela implementação de um sistema de backup de produção. Dê a si mesmo um
tratar para resolver esse difícil problema de automação de testes. Leve biscoitos para o seu
próxima reunião com os clientes. Reconheça o programador que lhe deu um
Chicote de JavaScript que acelerou o teste de algumas validações de GUI. Use o seu
imaginação.
A caixa de sapatos gritante
Adoramos a ideia de celebração que recebemos de Megan Sumrell, uma treinadora e treinadora
ágil. Ela compartilhou isso com uma sessão de testes ágeis do Open Space no Agile
2007.
Comemorar conquistas é algo que me apaixona muito nas equipes. Num projeto recente,
implementámos a caixa de sapatos Shout-Out. Peguei uma caixa de sapatos velha e
decorei. Depois, fiz apenas uma fenda na parte superior da tampa para que as pessoas
pudessem colocar suas mensagens na caixa. A caixa é aberta a toda a equipe durante o
sprint.
Sempre que os membros da equipe quiserem dar um “grito” a outro membro da

equipe, eles podem escrevê-lo em um cartão e colocá-lo na caixa. Eles podem variar
desde alguém ajudando você em uma tarefa difícil até alguém que vai além do seu dever.
Se você distribuiu membros da equipe, incentive-os a enviar suas mensagens por e-
mail para o seu ScrumMaster, que também poderá colocá-las na caixa.
No final da nossa demonstração, alguém da equipe se levanta e lê todas as cartas que

estão na caixa. Isso é ainda melhor se você tiver outras partes interessadas na sua
demonstração. Dessa forma, os membros da sua equipe obtêm reconhecimento público
por seu trabalho diante de um público maior. Você também pode incluir pequenos
brindes para as pessoas.
Pode ser um clichê, mas pequenas coisas podem significar muito. A Shout-Out Shoebox é uma
ótima maneira de reconhecer o valor que os diferentes membros da equipe contribuem.
RESUMO 451
Reservar um tempo para comemorar os sucessos permite que sua equipe dê um passo atrás e tenha uma nova
perspectiva e renovar sua energia para que possa continuar melhorando seu produto.
Dê aos membros da equipe a oportunidade de apreciar as contribuições uns dos outros. Não
caia em uma rotina onde todo mundo fica de cabeça baixa trabalhando o tempo todo.
No desenvolvimento ágil, temos a oportunidade de parar e obter uma nova perspectiva do

final de cada iteração curta. Podemos fazer pequenas correções de curso, decidir
experimente uma nova ferramenta de teste, pense em maneiras melhores de extrair exemplos dos clientes ou
identifique a necessidade de um tipo específico de experiência em testes.
RESUMO
Neste capítulo, examinamos algumas atividades para encerrar a iteração ou lançamento.
A revisão da iteração é uma excelente oportunidade para obter feedback e sugestões da equipe
do cliente.
Retrospectivas são uma prática crítica para ajudar sua equipe a melhorar.
Observe todas as áreas onde a equipe pode melhorar, mas concentre-se em uma ou duas de cada
vez.
Encontre uma maneira de manter os itens de melhoria em mente durante a iteração.

Comemore grandes e pequenos sucessos e reconheça as contribuições de diferentes funções e
atividades.
Aproveite a oportunidade após cada iteração para identificar obstáculos relacionados aos
testes e pensar em maneiras de superá-los.

Capítulo 20
ENTREGA COM SUCESSO
O que faz um produto?
Suporte à Produção Expectativas do cliente
Planejando tempo suficiente para testes
Critérios de aceitação de liberação
Liberando Testando o Release Candidate

Gerenciamento de Liberação
o produto
Embalagem Teste em um ambiente de teste
Teste final de não funcionamento
Bem-sucedido Integração com aplicativos externos

Fim do jogo
Entrega
Conversão de dados, atualizações de banco de dados
Teste de instalação
Entregáveis
Comunicação
E se não estiver pronto?

Ciclos de testes pós-desenvolvimento
UAT
Teste do cliente
Teste Alfa/Beta
Neste capítulo, compartilhamos o que você, como testador, pode fazer para ajudar sua equipe
e sua organização a entregar com sucesso um produto de alta qualidade. O mesmo processo
e ferramentas podem ser usados para produtos embalados, soluções personalizadas ou
produtos de desenvolvimento interno. Os testadores ágeis podem fazer contribuições
exclusivas que ajudam tanto o cliente quanto a equipe de desenvolvedores a definir e
produzir o valor que o negócio precisa.
O QUE FAZ UM PRODUTO?

Muitos dos livros sobre desenvolvimento ágil falam sobre o ciclo de desenvolvimento real, mas
deixam de falar sobre o que constitui um produto e o que é necessário para entregá-lo com
sucesso. Não basta apenas codificar, testar e dizer que está
453
454 CAPÍTULO 20 ENTREGA COM SUCESSO
feito. É como comprar algo em uma loja: se houver um ótimo serviço para ir
com a compra, qual é a probabilidade de você voltar e comprar lá
de novo?
Eu estava conversando com meu amigo Ron, que compra e vende moedas. Ao longo dos anos, ele
desenvolveu uma reputação muito boa no setor e recusou clientes em potencial porque está muito
ocupado.
Quando perguntei qual era o seu segredo, ele disse: “Não é segredo. Eu apenas trabalho com meus
clientes para que se sintam confortáveis e estabeleça uma relação de confiança com eles.
No final das contas, tanto eu quanto meu cliente precisamos estar satisfeitos com o negócio. Basta
um cliente insatisfeito para quebrar minha reputação.”
As equipes ágeis podem aprender com a experiência de Ron. Se tratarmos nossos clientes com
respeito e entregarmos um produto que os satisfaça, teremos um bom relacionamento com eles,
esperamos que por muitos anos.
—Janet
Nosso objetivo é entregar valor ao negócio em tempo hábil. Nós não queremos
apenas para atender às necessidades, mas também para encantar nossos clientes. Antes
de lançarmos, queremos ter certeza de que todas as entregas estão prontas e polidas
adequadamente. Felizmente, você começou a planejar cedo para conhecer não apenas o
requisitos de código, mas para planejar treinamento, documentação e tudo mais
isso é necessário para fazer um produto de alto valor.
Ajustar e finalizar
Coni Tartaglia, gerente de testes de software da Primavera Systems, Inc., explica os resultados
de “ajuste e acabamento”.
É útil ter uma lista de verificação de “Ajuste e Acabamento”. Às vezes ajuste e termine
os itens não estão prontos para serem incluídos no produto até perto do fim. Pode ser
necessário reconstruir partes do produto para incluir itens como nova arte, licença ou
acordos legais, assinaturas digitais para executáveis, datas de direitos autorais, marcas
registradas e logotipos.
É útil montá-los durante a última iteração completa de desenvolvimento e incorporá-los

ao produto enquanto os ciclos de construção de integração contínua estão em
execução, para que construções extras não sejam necessárias posteriormente.
O valor do negócio é o objetivo do desenvolvimento ágil. Isso pode incluir muito além do código
de produção. As equipes precisam planejar todos os aspectos da entrega do produto.
PLANEJANDO TEMPO SUFICIENTE PARA TESTE 455
Imagine-se preparando seu lançamento para produção.

Você acabou de terminar sua última iteração e está encerrando sua última história
teste. Seu conjunto de regressão automatizado está em execução em cada nova compilação,
ou pelo menos em todas as construções noturnas. O que você fará agora dependerá de quão
disciplinado foi seu processo. Se você tem mantido a “tolerância zero”
para bugs, você provavelmente está em muito boa forma.
Se você é uma daquelas equipes que pensa que pode deixar bugs até o fim para
correção, você provavelmente não está em tão boa forma e pode precisar introduzir uma iteração
para “endurecimento” ou correção de bugs. Não recomendamos isso, mas se o seu
equipe tem muitos bugs pendentes que foram introduzidos durante o ciclo de desenvolvimento,
você precisa resolvê-los antes de chegar ao final
jogo. Descobrimos que novas equipes tendem a cair nessa armadilha.
Além disso, existem muitos componentes variados para qualquer versão, alguns no
software, alguns não. Você tem clientes que precisam instalar e aprender a usar
os novos recursos. Pense em todos os elementos que são críticos para um lançamento bem-
sucedido, porque é hora de resolver todas essas pontas soltas e aprimorar seu
produtos.
Bob Galen, coach ágil e especialista em end-game, observa que o desenvolvimento ágil pode não
ter se infiltrado em todos os cantos da organização. Ele
observa: “Os testadores ágeis podem servir como um canal ou facilitador quando se trata de
entrega física do software.”
PLANEJANDO TEMPO SUFICIENTE PARA TESTE

Como o teste e a codificação fazem parte de um processo de desenvolvimento ágil, gostaríamos
prefiro não fazer planos especiais para tempo extra de teste, mas na vida real
pode precisar de algum tempo extra.
A maioria das equipes acumula alguma dívida técnica, apesar das melhores intenções,
especialmente se estiverem trabalhando com código legado. Para manter a velocidade, sua equipe pode
precisa planejar uma iteração de refatoração em intervalos regulares para adicionar testes, atualizar
ferramentas e reduzir a dívida técnica. A equipe de Lisa conduz um sprint de refatoração
aproximadamente a cada seis meses. Embora a empresa normalmente não receba nenhum benefício direto
benefícios no final de um sprint de refatoração, os especialistas de negócios entendem
que esses sprints especiais resultem em melhor cobertura de testes, uma base sólida para futuros
desenvolvimento, redução do débito técnico e maior velocidade geral da equipe.
Algumas equipes recorrem a iterações de “endurecimento”, onde gastam tempo apenas encontrando
e corrigindo bugs, e não introduzem nenhuma funcionalidade nova. Este é o último recurso para
manter a aplicação e sua infraestrutura sólidas. Novas equipes podem precisar de uma iteração extra
para concluir as tarefas de teste e, nesse caso, reservam tempo para isso no plano de lançamento.
Use retrospectivas e outras práticas de melhoria de processos para aprender maneiras de integrar
testes e codificação para que o código produzido em cada iteração esteja pronto para produção.
Quando esse objetivo for alcançado, trabalhe para garantir que uma compilação estável que possa
ser liberada para produção esteja disponível todos os dias. Os membros da equipe de Lisa pensaram
que essa era uma meta inatingível na época em que lutavam para obter qualquer compilação estável
antes do lançamento, mas demorou apenas alguns anos para que quase todas as compilações
valessem a pena ser lançadas.
Quando sua construção estiver estável, você estará pronto para entrar no “Jogo Final”.
O FIM DO JOGO
Qual é o jogo final? Ouvimos muitas pessoas avisarem o momento antes da entrega, mas o “fim do
jogo” parece ser o mais adequado. É o momento em que a equipe dá os retoques finais no produto.
Você está pontilhando seus i e cruzando seus t. É o último trecho antes da linha de chegada da
entrega. Não foi feito para ser um ciclo de correção de bugs, porque você não deverá ter nenhum
bug pendente até então, mas isso não significa que você não tenha um ou dois para corrigir.
Talvez você tenha grupos em sua organização que não envolveu em seu planejamento anterior.
Agora é hora de trabalhar em estreita colaboração com as pessoas que administram os ambientes
de preparação e produção, os gerentes de configuração, os administradores de banco de dados fora
de sua equipe e todos que desempenham um papel na movimentação do software do desenvolvimento
para a preparação e produção. Se você não trabalhou com eles antes desta vez, considere conversar
com essas pessoas durante as próximas sessões de planejamento de lançamento e mantenha
contato com elas durante todo o ciclo de desenvolvimento.
Bob Galen nos conta que os testadores de sua equipe fizeram parceria com o grupo de operações
que gerencia os ambientes de teste e produção. Como o grupo de operações é remoto, a orientação
da equipe ágil é particularmente valiosa.
Sempre há testes em nível de sistema que não podem ser automatizados ou que não valem a pena
automatizar. Na maioria das vezes, seu ambiente de teste é o único lugar
O FIM DO JOGO 457
onde você pode fazer alguns testes de integração em nível de sistema ou carga em nível de sistema
e testes de estresse. Sugerimos que você reserve algum tempo após o desenvolvimento para
esses tipos de tarefas de acabamento. Não codifique até o fim.
Planeje quanto tempo você precisar para o final do jogo. Janet descobriu que o
o tempo necessário para o final do jogo varia de acordo com a maturidade da equipe
e o tamanho do aplicativo. Pode ser que seja necessário apenas um dia para terminar
as tarefas extras, mas pode levar uma semana ou às vezes até o total
iteração de duas semanas. A equipe do exemplo usado no Capítulo 12, “Resumo dos Quadrantes
de Teste”, programou duas semanas, porque era uma tarefa complexa.
sistema que exigia bastante configuração e testes do sistema.
Quando trabalhei em uma equipe desenvolvendo aplicativos para um cliente, tínhamos que seguir
A história de Lisa
o cronograma de lançamento do cliente. Os testes com outras partes do sistema maior só foram
possíveis durante determinados períodos de duas semanas, a cada seis ou oito semanas.
Nossa equipe completou duas ou três iterações, finalizando todas as histórias de cada uma
como se estivessem lançando cada iteração.
Em seguida, entramos em uma janela de testes onde poderíamos coordenar os testes do

sistema com outras equipes de desenvolvimento, auxiliar o cliente com o UAT e planejar o
lançamento real. Isto constituiu o nosso jogo final.
—Lisa
Se você tiver uma organização grande, poderá ter dez ou quinze equipes desenvolvendo software
para produtos individuais ou para áreas separadas de funcionalidade para
o mesmo aplicativo. Todas essas áreas ou produtos podem precisar ser lançados juntos, portanto,
é necessário um jogo final integrado. Isso não significa que você
deixe a integração até o final. Coordenação com as outras equipes
será crítico ao longo de todo o seu ciclo de desenvolvimento, e se você tiver um sistema de
integração de teste, recomendamos que você tenha certeza de ter tentado a integração muito
antes do final do jogo.
Você também pode ter considerações além da sua equipe, por exemplo, trabalhar
com software fornecido por equipes externas em nível empresarial.
Use esse tempo final do jogo para fazer alguns testes exploratórios finais. Dê um passo para trás e
observe todo o sistema e faça alguns cenários de ponta a ponta. Tais testes irão
confirmar se o aplicativo está funcionando corretamente, proporcionando mais confiança
no produto e fornecer informações para a próxima iteração ou lançamento.
Testando o Release Candidate

Recomendamos que o teste de regressão automatizado seja feito contra todos
candidato liberado. Se você estiver seguindo nossa recomendação para executar ações automatizadas
testes de regressão continuamente em cada nova construção, ou pelo menos diariamente, você já
feito isso. Se alguns de seus testes de regressão forem manuais, você precisará planejar o tempo
para aqueles ou eles podem não ser feitos. Uma avaliação de risco baseada em mudanças
feitos em cada compilação determinarão quais testes precisam ser executados se houver mais
de um candidato a lançamento.
Teste em um ambiente de teste

Esteja você usando processos de desenvolvimento tradicionais ou ágeis, um ambiente de teste que
imite a produção também é vital para os testes finais antes do lançamento.
quanto a testar o próprio processo de lançamento. Como parte do jogo final, seu aplicativo deve ser
implantado no teste da mesma forma que você o implantaria na produção,
ou como seus clientes fariam em seus ambientes. Em muitas organizações
que Janet viu, o ambiente de teste geralmente é compartilhado entre vários
projetos, e a implantação deve ser agendada como parte do planejamento da versão. Considere
antecipadamente como lidar com dependências, integrando-se com
outras equipes usando o ambiente de teste e trabalhando com terceiros externos
festas. Pode parecer um planejamento de teste “tradicional”, mas você pode estar lidando
com equipes que não adotaram o desenvolvimento ágil.
Embora o Agile promova a integração contínua, muitas vezes é difícil integrá-lo com produtos de
terceiros ou outras aplicações fora do âmbito do seu projeto.
ao controle. Os ambientes de teste podem ter melhores controles para que aplicativos externos
possam se conectar e ter acesso a ambientes de teste de terceiros. Ambientes de teste também
podem ser usados para testes de carga e desempenho, simulações
implantações, testes de failover e testes de regressão manuais e testes funcionais exploratórios.
Sempre há diferenças de configuração entre ambientes, portanto seu ambiente de teste é um bom
lugar para testá-las.
Teste Não Funcional Final

Os testes de carga devem ser programados durante todo o projeto em peças específicas do
o aplicativo que você está desenvolvendo. Se o seu ambiente de teste estiver em alta
demanda, talvez você não consiga fazer testes completos de carga do sistema até o final do jogo.
A essa altura, você deverá ser capaz de realizar testes de confiabilidade de longa duração em todos
funcionalidade do produto. Verifique se há falhas e degradação do desempenho
com carga normal. Quando feito no momento do lançamento, deverá ser apenas uma confirmação
final.
O FIM DO JOGO 459
Os testes de tolerância a falhas e recuperação são melhor realizados em seu ambiente de teste
também, porque os ambientes de teste geralmente não possuem a configuração necessária. Para
pelos mesmos motivos, talvez você só consiga testar determinados aspectos da segurança.
Um exemplo é https, uma conexão http segura através de conexões seguras criptografadas.
tomadas. Algumas organizações podem optar por ter os certificados necessários em
apenas seu ambiente de teste. Outros exemplos são clustering ou replicação de dados. Certifique-
se de envolver todas as partes que precisam ser incluídas neste teste.
Integração com aplicativos externos

Sua equipe pode ser ágil, mas outras equipes de produto em sua organização, ou
terceiros com quem sua equipe trabalha, podem não ser.
Em uma organização com a qual trabalhei, o parceiro terceirizado que aprovou cartões
de crédito tinha uma conta de teste que podia ser usada, mas só era acessível no
ambiente de teste.
Para testar durante o desenvolvimento, foram criados stubs de teste para retornar
resultados específicos dependendo do número do cartão de crédito utilizado. No
entanto, isso não foi suficiente porque o terceiro às vezes alterava funcionalidades que não estávamos
ciente de. Testar com terceiros foi fundamental para o sucesso do projeto e é uma
parte fundamental do jogo final.
—Janet
Coordene com antecedência com outras equipes de produto ou parceiros externos

que possuem produtos que precisam ser integrados ao seu produto. Se você tem
identificou esses riscos antecipadamente e fez tantos testes iniciais quanto possível, o
os testes feitos durante o jogo final devem ser apenas uma verificação final. No entanto,
sempre há surpresas de última hora, então você pode precisar estar preparado para
faça alterações em seu aplicativo.
Ferramentas como simuladores e objetos simulados usados para testes durante o desenvolvimento
pode ajudar a aliviar alguns dos riscos, mas quanto mais cedo você puder testar com
aplicações, menor será o risco.
Conversão de dados e atualizações de banco de dados
À medida que desenvolvemos uma aplicação, alteramos campos, adicionamos colunas no banco
de dados ou removemos colunas obsoletas. Equipes diferentes abordam isso de maneiras diferentes.
Algumas equipes recriam o banco de dados a cada nova construção. Isso funciona para novos
aplicativos, porque não há dados existentes. Contudo, após uma aplicação
existe em produção e tem dados associados, esta abordagem não funcionará.
Uma aplicação precisa considerar os dados que fazem parte do produto. Como com
tanto no desenvolvimento ágil, é necessário um esforço conjunto de especialistas em banco de dados,
programadores e testadores da equipe para garantir a liberação bem-sucedida das alterações no banco
de dados. Janet viu algumas táticas diferentes para lidar com dados
conversão e compatibilidade com versões anteriores. Os scripts de banco de dados podem ser criados por
os desenvolvedores ou administradores de banco de dados à medida que a equipe faz alterações. Esses
os scripts tornam-se parte da construção e são continuamente testados. Outra opção é
para a equipe executar “diffs” no banco de dados após todas as alterações no banco de dados
tem sido feito.
Se você for um testador, peça ao seu administrador/desenvolvedor de banco de dados para ajudar seu
A equipe garante que os esquemas sejam mantidos consistentes entre os ambientes de produção, teste
e preparação. Encontre uma maneira de garantir que todas as alterações
feitos nos ambientes de teste serão feitos na preparação e produção
ambientes durante a liberação. Mantenha os esquemas correspondentes (exceto para o
novas mudanças ainda em desenvolvimento) em termos de nomes de colunas, gatilhos,
restrições, índices e outros componentes. A mesma disciplina aplicada
codificação e testes também devem ser aplicados ao desenvolvimento de banco de dados e
manutenção.
A história de Lisa
Recentemente, tivemos um bug lançado para produção porque alguns dos esquemas de teste,
incluindo aquele usado pelos testes de regressão, não tinham uma restrição. Sem a restrição
estabelecida, o código não falhou. Isso desencadeou um esforço para garantir que exatamente os
mesmos scripts de atualização sejam executados em cada esquema para fazer alterações em
uma determinada versão.
Descobriu-se que diferentes esquemas de teste tinham pequenas diferenças, como colunas
antigas que ainda permaneciam em alguns ou colunas em ordem diferente em esquemas diferentes,
portanto não era possível executar o mesmo script em todos os ambientes. Nosso administrador
de banco de dados liderou um grande esforço para recriar todos os esquemas de teste para
serem perfeitamente compatíveis com a produção. Ele cria um script em cada iteração com todas
as alterações necessárias no banco de dados e executa esse mesmo script no ambiente de
preparação e produção quando lançamos. Isso parece simples, mas é fácil ignorar diferenças
sutis quando você está focado em fornecer novos recursos.
—Lisa
Automatizar as migrações de dados aumenta sua capacidade de testá-los e reduz

a chance de erro humano. Ferramentas nativas de banco de dados como SQL, procedimentos
armazenados, ferramentas de importação de dados como SQL*Loader e bcp, scripts de shell e arquivos
de comando do Windows podem ser usados para automação porque podem ser clonados
e alterado facilmente.
O FIM DO JOGO 461
Não importa como os scripts de atualização e conversão do banco de dados são criados ou
mantidos, eles precisam ser testados. Uma das melhores maneiras de garantir todos os
alterações foram capturadas nos scripts de atualização é usar os dados do cliente
se estiver disponível. Os clientes têm o hábito de usar o aplicativo de maneiras estranhas e
maneiras maravilhosas, e os dados nem sempre são tão limpos quanto gostaríamos. Se o
equipe de desenvolvimento limpa o banco de dados e coloca restrições extras em um
coluna, o aplicativo no site do cliente pode explodir assim que um
consulta toca um dado que não corresponde às novas restrições. Você
precisa ter certeza de que todas as alterações feitas ainda são compatíveis com os dados
existentes.
A história de Lisa
Minha equipe usa o ambiente de teste para testar os scripts de atualização do banco de dados. Após
a execução dos scripts, fazemos testes manuais para verificar se todas as alterações e conversões
de dados foram concluídas corretamente. Alguns de nossos scripts de teste de GUI cobrem um
subconjunto de cenários de regressão. Isso nos dá confiança quanto ao lançamento para produção,
onde nossa capacidade de teste é mais limitada.
—Lisa
Ao planejar uma conversão de dados, pense na limpeza de dados como parte do

estratégia de mitigação. Você tem a oportunidade de pegar os dados que foram inseridos de
algumas das maneiras “estranhas e maravilhosas” que mencionamos antes e
massageie ou manipule-o para que se adapte às novas restrições. Esse tipo de
Esse trabalho pode levar muito tempo para ser executado, mas muitas vezes vale muito a pena em termos de
manutenção da integridade dos dados.
Nem todos conseguem fazer uma simulação suficientemente boa dos dados de produção no
ambiente de preparação. Se os dados de um cliente não estiverem disponíveis, uma estratégia
de mitigação é ter um UAT nas instalações do cliente. Outra forma de mitigar o risco é
tente evitar atualizações em grande escala e lançamentos em etapas menores. Desenvolva novos
funcionalidade em paralelo com a funcionalidade antiga e usar uma propriedade do sistema
para “ligar” um ou outro. A funcionalidade antiga pode continuar funcionando em
produção até que a nova funcionalidade seja concluída. Enquanto isso, os testes podem
ser feito no novo código em cada iteração. Novas colunas e tabelas podem ser
adicionados às tabelas de produção sem afetar o código antigo para que os dados
a migração ou conversão para a versão final é minimizada.
Teste de instalação
As organizações geralmente têm uma equipe separada que implanta a produção ou cria o
conjunto de produtos. Esses membros da equipe devem ter a oportunidade de
pratique a implantação exatamente como fariam para a produção. Se eles usarem o

implantação para o estágio como campo de provas, eles podem resolver qualquer um dos
problemas muito antes de serem liberados para o cliente.
Testar instalações de produtos também pode significar testar várias instalações de

produtos embalados em plástico para diferentes sistemas operacionais ou hardware. Como
o produto se comporta? Faz o que é esperado? Quanto tempo o sistema precisará ficar inativo
para instalação? Podemos implantar sem interrupção? Podemos tornar a experiência do usuário
o mais agradável possível?
Tive uma experiência há algum tempo que não foi tão agradável e me levou a desejar que alguém tivesse
testado e corrigido o problema antes de eu encontrá-lo. Comprei um laptop novo e queria transferir minha
licença de um dos meus aplicativos para o novo computador. Ele veio com uma versão de teste do mesmo
aplicativo, então a transferência deveria ter sido fácil, mas o novo PC não reconheceu a chave do produto –
ele dizia que era inválida. Liguei para o suporte e após alguns diagnósticos, fui informado que eram
considerados produtos diferentes, portanto a chave não funcionava.
Mais duas horas de suporte e o problema foi resolvido. A versão de teste teve que ser removida, uma versão
antiga teve que ser reinstalada, a chave teve que ser digitada novamente e todas as atualizações desde a
compra original tiveram que ser carregadas. Teria sido muito mais fácil para a equipe de desenvolvimento testar
esse cenário e oferecer ao cliente uma mensagem informativa dizendo: “A versão de teste não é compatível
com sua chave de produto”. Uma mensagem como essa teria me permitido descobrir o problema e resolvê-lo
sozinho, em vez de tomar o tempo da pessoa de apoio.
—Janet
Reserve o tempo necessário para determinar quais são seus requisitos para teste
instalação. No final valerá a pena se você satisfazer seus clientes.
Comunicação
A comunicação constante entre os diferentes membros da equipe de desenvolvimento é

é sempre importante, mas é especialmente crítico quando encerramos o lançamento. Ter
reuniões extras extras, se necessário, para garantir que tudo esteja pronto para o
liberar. Escreva cartões para tarefas de liberação se houver alguma chance de alguma etapa ser
esquecido.
Minha equipe lança após cada iteração. Geralmente fazemos uma rápida reunião na última tarde do sprint para
A história de Lisa
entrar em contato e identificar quaisquer pontas soltas. Antes de a equipe ter muita prática com
lançamentos, escrevemos cartões de tarefas de lançamento, como “executar
script de atualização do banco de dados em teste” e “verificar atualizações do banco de dados em produção”.
O FIM DO JOGO 463
Com mais experiência em implantação, não precisaremos mais desses cartões, a menos que
tenhamos um novo membro da equipe que precise de um lembrete extra. No entanto, nunca é
demais ter cartões para tarefas de liberação.
—Lisa
Lembretes de tarefas, estejam elas em um plano de implementação completo ou apenas

escritas em cartões de tarefas, como faz a equipe de Lisa, são muitas vezes necessárias. Em
implementações simples, um quadro branco funciona bem.
E se não estiver pronto?

Acompanhando constantemente o progresso de várias formas, como compilações, testes de regressão
suítes, storyboards e gráficos de burndown, uma equipe geralmente sabe com antecedência quando
está com problemas em um lançamento. Há tempo para contar histórias e apenas ler. Ainda assim,
desastres de última hora podem acontecer. E se a máquina de construção quebrar
no último dia da iteração? E se o banco de dados de teste travar e o resultado final
o teste não pode ser concluído? E se um bug impeditivo não for detectado até o teste funcional final?
É altamente desaconselhável adicionar dias extras a uma iteração, pois isso

coma na próxima iteração ou no desenvolvimento do lançamento. Uma equipe experiente
pode ser flexível o suficiente para fazer isso, mas pode inviabilizar uma nova equipe. Ainda assim,
tempos de desespero exigem medidas desesperadas. Se você liberar a cada duas semanas, você
pode simplesmente ser capaz de pular o lançamento real, orçamentar o tempo para o próximo
iteração para corrigir os problemas e finalizar, e liberar na próxima
data marcada. Se as tarefas de teste estiverem sendo adiadas ou ignoradas e a liberação
segue em frente, traga esse assunto à equipe. As necessidades de teste mudaram,
ou a equipe está se arriscando e sacrificando a qualidade para cumprir um prazo? O
a equipe deve reduzir o escopo do lançamento se a data de entrega for fixa e estiver em risco.
Se o seu ciclo de lançamento for mais longo, cerca de três meses, você deve saber em
antecipadamente se sua libertação estiver em perigo. Você provavelmente planejou um fim
jogo de pelo menos duas semanas, que será apenas para validação final. Quando você
tiver um ciclo de lançamento mais longo, você terá mais tempo para determinar o que deseja
deveria fazer, seja eliminando funcionalidades ou alterando a programação.
Se a sua organização exigir que determinadas funcionalidades sejam lançadas em um

falhas do dia e de última hora ameaçam o lançamento, avalie suas alternativas.
Veja se você consegue continuar no mesmo ciclo de desenvolvimento, mas atrasar o lançamento
sozinho por um dia ou uma semana. Talvez o trecho de código ofensivo possa ser apoiado
temporariamente e um patch feito mais tarde. Os clientes têm a palavra final
no que funcionará para o negócio.
Nas raras ocasiões em que a nossa equipa enfrentou o problema de obstáculos de última hora,
A história de Lisa
utilizámos abordagens diferentes de acordo com a situação. Se houver
nada crítico que precise ser lançado agora, às vezes pulamos o lançamento e lançamos duas
iterações no próximo dia de lançamento. Se algo crítico precisar ser feito, adiaremos o lançamento
um ou dois dias. Às vezes podemos ir em frente e liberar o que temos e lançar um patch no dia
seguinte. Em uma ocasião, decidimos fazer uma iteração especial de uma semana para corrigir
os problemas, lançar e depois voltar ao cronograma normal de iteração de duas semanas.
Depois de mais de quatro anos praticando desenvolvimento ágil, temos uma compilação estável
quase 100% do tempo e nos sentimos confiantes em poder lançar sempre que necessário.
Precisávamos de muita disciplina e melhoria contínua em nosso processo para sentir que uma
abordagem mais flexível poderia funcionar para nós. Isso é
também é bom poder lançar uma funcionalidade valiosa antecipadamente, se pudermos. O que
temos trabalhado duro para evitar é cair em uma espiral mortal onde nunca poderemos lançar no
prazo e estamos sempre tentando recuperar o atraso.
Não se culpe se não conseguir liberar a tempo. Sua equipe está fazendo o seu melhor. Passe algum
tempo analisando por que você atrasou ou se comprometeu demais e tome medidas para evitar que
isso aconteça novamente.
—Lisa
Trabalhe para evitar uma situação de “não avançar” com bom planejamento, estreita colaboração,
conduzindo a codificação com testes e testando enquanto você codifica. Se o seu rastreamento mostrar o
lançamento pode estar em perigo, remova a funcionalidade que não pode ser concluída, se
possível. Se algo ruim e inesperado acontecer, não entre em pânico. Envolva o
toda a equipe e a equipe do cliente e debater sobre a melhor solução.
TESTE DE CLIENTE
Existem algumas maneiras diferentes de envolver seus clientes para obter
sua aprovação ou feedback. O teste de aceitação do usuário pode ser bastante formal,
com aprovações da empresa. Significa aceitação de uma liberação. Alfa ou
o teste beta é uma forma de obter feedback sobre um produto que você deseja lançar
mas que ainda não está pronto.
UAT
O Teste de Aceitação do Usuário (UAT) é importante em grandes aplicações personalizadas
bem como aplicativos internos. É realizado por todos os departamentos de negócios afetados para
verificar a usabilidade do sistema e para confirmar a funcionalidade de negócios existente e nova (ênfase
em novas) do sistema. Seus clientes são os
TESTE DE CLIENTE 465
aqueles que têm que conviver com o aplicativo, então eles precisam ter certeza de que
funciona em seu sistema e com seus dados.
Nos capítulos anteriores, falamos muitas vezes sobre como envolver os clientes
cedo, mas nesses momentos, os testes são feitos em recursos específicos em desenvolvimento. O UAT
geralmente é feito depois que a equipe decide que a qualidade é boa o suficiente para
liberar. Às vezes, porém, o cronograma dita o ciclo de lançamento. Se esse for o
caso, tente mover o ciclo UAT para cima para funcionar paralelamente ao seu jogo final.
O aplicativo deve ser estável o suficiente para que sua equipe possa implantar no
sistema de teste do cliente ao mesmo tempo em que são implantados no teste.
Em uma equipe da qual entrei, os clientes eram muito exigentes. Na verdade, o mais exigente que eu já
vi. Eles sempre pediam uma semana inteira de UAT só para ter certeza de que teriam tempo de testar
tudo. Eles prepararam casos de teste e verificaram todos, inclusive todo o conteúdo, tanto em inglês
quanto em francês. Os bugs do Showstopper incluíam erros de ortografia, como falta de sotaque no
conteúdo em francês. Com o tempo, à medida que ganharam mais confiança em nossos lançamentos
e encontraram cada vez menos erros, eles relaxaram suas exigências, mas ainda queriam uma semana,
caso não conseguissem fazer isso imediatamente.
Seu grupo empresarial estava muito ocupado.
Chegou um lançamento que adiantou o cronograma. Estávamos aguardando a data de lançamento,

mas não conseguimos obter todas as funcionalidades e deixamos duas semanas para o jogo final.
Conversamos com os usuários empresariais e decidimos diminuir o final do jogo para uma semana;
os usuários empresariais realizariam seu UAT enquanto a equipe do projeto terminava o teste e a limpeza
do sistema. A única razão pela qual conseguimos fazer isso foi a confiança que o cliente depositava em
nossa equipe e a consistência
tenência de nossos lançamentos.
A boa notícia foi que, mais uma vez, o UAT não encontrou problemas que não pudessem esperar até o
próximo lançamento.
—Janet
A Figura 20-1 mostra um exemplo de cronograma com um UAT normal no final do

ciclo de lançamento. A equipe começa a trabalhar no próximo lançamento, fazendo o planejamento do
lançamento, e inicia a primeira iteração com todos os membros da equipe prontos para começar.
Trabalhe com os clientes para que eles entendam o processo, sua função e o que
é esperado deles. Se o UAT não for tranquilo, então é provável que haja
ser necessário um elevado nível de apoio. Uma equipe experiente de testes de clientes pode
definiram casos de teste, mas na maioria das vezes seus testes são ad hoc. Os clientes podem
abordar seus testes como se estivessem fazendo seu trabalho diário, mas provavelmente irão
concentre-se na nova funcionalidade. Esta é uma oportunidade para observar como as pessoas
Cronograma de lançamento
Liberação normal com UAT
Iter 2 Iter 3 Fim do jogo

... Lançamento 1
Sistema UAT
Código e Teste Código e Teste
Teste
Iter 1 Iter 2
... Lançamento 2
Liberar Código e Teste Código e Teste

Planejamento
Figura 20-1 Cronograma de liberação com UAT
usar o sistema e obter feedback deles sobre o que funciona bem e o que
melhorias os ajudariam.
Os testadores podem fornecer suporte aos clientes que estão fazendo o UAT, revisando os testes
executados e os defeitos registrados, e rastreando os defeitos até a conclusão.
Nós dois achamos útil fornecer aos clientes envolvidos na realização do UAT
com um relatório de todos os testes feitos durante o desenvolvimento, junto com o
resultados. Isso os ajuda a decidir onde concentrar seus próprios testes.
Teste Alfa/Beta
Se você é uma organização que distribui software para uma grande base de clientes,
você pode não ter um UAT formal. É muito mais provável que você incorpore testes alfa ou beta.
Sua equipe desejará receber feedback sobre novos recursos de
seus clientes reais, e este é um mecanismo para fazer isso. O teste alfa é
distribuição antecipada de novas versões de software. Porque é provável que haja
alguns bugs importantes, você precisa escolher seus clientes com sabedoria. Se você escolher isso
método de feedback do cliente, certifique-se de que seus clientes entendam seus
papel. O teste Alpha serve para obter feedback sobre os recursos – não para relatar bugs.
O teste beta está mais próximo do UAT. Espera-se que o lançamento seja bastante estável e
realmente pode ser usado. Pode não estar “pronto para o horário nobre” para a maioria dos
clientes, mas muitos clientes podem achar que os novos recursos valem o risco. Cus-
CICLOS DE TESTE PÓS-DESENVOLVIMENTO 467
os clientes devem entender que não é um comunicado formal e que você está
pedindo-lhes para testar seu produto e relatar bugs.
Como testador, é importante entender como os clientes veem o produto,

porque isso pode afetar o modo como você testa. Os testes alfa e beta podem ser os únicos
tempo que você tem para interagir com os usuários finais, então aproveite a oportunidade para
aprender até que ponto o produto atende às suas necessidades.
CICLOS DE TESTE PÓS-DESENVOLVIMENTO

Se você trabalha em uma grande organização ou está desenvolvendo um componente de uma grande,
sistema complexo, pode ser necessário reservar tempo para testes após o desenvolvimento ser
completo. Às vezes, o teste UAT, ou a coordenação do teste, não é tão tranquilo
como poderia ser, então a linha do tempo se estende. Ambientes de teste que incluem teste
versões de todos os sistemas de produção podem estar disponíveis apenas para pequenas e programadas
janelas do tempo. Talvez seja necessário coordenar sessões de teste com equipes que trabalham
em outros aplicativos que interagem com o seu. Seja qual for o motivo, você precisa
tempo extra de teste que não inclui toda a equipe de desenvolvimento.
Trabalhei em uma equipe desenvolvendo componentes de aplicações internas e externas para

A história de Lisa
um grande cliente de telecomunicações. Só conseguimos acesso ao ambiente de teste completo
em intervalos programados. Os lançamentos também foram bem programados.
A equipe de desenvolvimento trabalhou em iterações de duas semanas. Ele poderia ser lançado no
ambiente de teste somente após cada terceira iteração. Naquela época, houve um ciclo de
integração de sistema e teste de aceitação do usuário de duas semanas, seguido pelo lançamento.
Alguém da minha equipe precisava dirigir a fase de testes pós-desenvolvimento.

Enquanto isso, os desenvolvedores estavam iniciando uma nova iteração com novos recursos e
precisavam de um testador para ajudar nesse esforço.
A equipe teve que fazer um esforço especial para garantir que alguém na função de testador
acompanhasse cada versão do início ao fim. Por exemplo, trabalhei do início ao fim
na versão 1. Shauna assumiu a função de testador quando a equipe começou a trabalhar na
primeira iteração da versão 2, enquanto eu coordenava os testes do sistema e o UAT na versão
1. Shauna permaneceu como testador principal na versão 2, enquanto eu presumi que papel para o
lançamento 3.
—Lisa
A Figura 20-2 mostra um exemplo de cronograma em que o UAT foi estendido. Esse
pode acontecer por uma série de razões, e o problema pode nem sempre ser
UAT. A maior parte da equipe está pronta para começar a trabalhar no próximo lançamento, mas muitas vezes
Cronograma de lançamento
Sobreposição de versões com UAT estendido
O testador permanece com

esta versão até que o
UAT seja concluído
Iter 2 Iter 3 Fim do jogo
... Lançamento 1
Sistema UAT Se não houver nenhum testador disponível

Código e Teste Código e Teste
Teste para trabalhar na nova versão, os
programadores poderão fazer refatoração, picos
Iter 1 Iter 2
... Versão 2 – Alternativa 1
Liberar Código e teste

Reestruturação,
Planejamento Espigões
Outro testador trabalha

na próxima versão
Iter 0 Iter 1
... Versão 2 – Alternativa 2
Liberar Código e Teste Código e Teste

Planejamento
Figura 20-2 Cronograma de liberação – abordagem alternativa com UAT estendido
um testador ainda está trabalhando com os clientes, concluindo os testes finais. Às vezes, um
programador também estará envolvido. Há um par de opções. Se a equipe for grande o
suficiente, você provavelmente poderá iniciar a próxima versão enquanto alguns membros da
equipe trabalham com a versão existente (Versão 2 – Alternativa 2 na Figura 20-2). Se você
tiver uma equipe pequena, talvez seja necessário considerar uma Iteração 0 com
programadores fazendo refatoração ou picos (experimentos) em novas funcionalidades para
que o testador que trabalha com o cliente não fique para trás (Versão 2 – Alternativa 1 na
Figura 20-2).
Seja criativo ao lidar com as circunstâncias impostas à sua equipe pelas realidades do seu
projeto. Embora os planos raramente funcionem conforme o esperado, planejar com
antecedência ainda pode ajudá-lo a garantir que as pessoas certas estejam no local para
entregar o produto em tempo hábil.
ENTREGAS
Na primeira seção deste capítulo falamos sobre o que constitui um produto. A resposta
dependerá, na verdade, do público: quem está aceitando o produto e quais são suas
expectativas?
ENTREGAS 469
Se seus clientes precisarem atender aos requisitos de conformidade da SOX (Sarbanes-Oxley), algumas
entregas serão necessárias. Por exemplo, uma cliente Janet trabalhou com resultados de testes de feltro
que deveriam ser minuciosamente documentados,
e fez dos resultados dos testes um de seus pontos de medição de conformidade com a SOX, enquanto um
clientes diferentes não mediram os resultados dos testes. Trabalhe com conformidade e
pessoal de auditoria para identificar necessidades de relatórios quando você inicia um projeto.
Quanta documentação é suficiente? Janet sempre faz duas perguntas antes

respondendo a essa pergunta: “Para quem é?” e “Para que eles estão usando isso?” Se
não há respostas adequadas para essas perguntas, então considere se o
a documentação é realmente necessária.
As entregas nem sempre são para o cliente final e nem sempre estão em
a forma de software. Existem muitos clientes internos, como os membros da equipe de suporte à produção.
O que eles precisarão para tornar seu trabalho mais fácil?
Os diagramas de fluxo de trabalho podem ajudá-los a compreender novos recursos. Eles iriam
provavelmente gostaria de saber se existem soluções alternativas para que possam ajudar
clientes através de problemas.
Janet costuma ser questionada sobre a cobertura de testes de código, geralmente pela gerência.
Quanto do aplicativo está sendo testado pelos testes de unidade ou regressão
testes? O problema é que o número por si só é apenas um número, e há
tantas razões pelas quais pode ser alto ou baixo. Além disso, a cobertura do código não informa
você sobre recursos que podem ter sido perdidos, para os quais ainda não existe código.
O público para uma entrega como a cobertura de código não deve ser o gerenciamento, mas a própria
equipe. Pode ser usado para ver quais áreas do código não são
sendo testado.
O treinamento também pode ser considerado um resultado final. Muitas aplicações exigem
sessões de treinamento personalizadas para clientes. Outros podem precisar apenas online
ajuda ou um manual do usuário. O treinamento pode determinar o sucesso do seu produto,
então é importante considerar. A equipe de Lisa costuma escrever cartões de tarefas para um
testador ou proprietário do produto para garantir que os materiais e sessões de treinamento sejam
arranjado. Algumas pessoas podem achar que o treinamento não é tarefa dos testadores ou de qualquer outra pessoa
na equipe de desenvolvimento. No entanto, as equipes ágeis pretendem trabalhar o mais próximo possível
possível com o negócio. Os testadores geralmente têm experiência no domínio para poder
para pelo menos identificar o treinamento que pode ser necessário para recursos novos ou atualizados.
Mesmo que o treinamento não seja de responsabilidade do testador, ele poderá levantar a questão se o
a empresa não está planejando sessões de treinamento.
Muitas equipes ágeis têm redatores técnicos como parte da equipe que escreve online
ajuda ou formulários eletrônicos de documentação. Um aplicativo ainda incluído
vídeos de treinamento para ajudar a começar, e diferentes membros da equipe foram

os treinadores. É responsabilidade da equipe criar um produto de sucesso.
Entregáveis não relacionados a software
Coni Tartaglia, gerente de testes de software da Primavera Systems, Inc., reflete sobre o que
funcionou para sua equipe na entrega de itens que não são códigos, mas são necessários para um
lançamento bem-sucedido.
Além do software, o que a equipe está entregando? É útil conversar com pessoas fora da equipe
de desenvolvimento que possam estar preocupadas com esta questão. Grupos como Jurídico,
Marketing de Produto, Treinamento e Suporte ao Cliente desejarão contribuir para a lista de
resultados.
Após haver acordo sobre o que está sendo entregue, a montagem dos componentes pode
começar, e a função de Gerenciamento de Liberação pode fornecer a confirmação da entrega
através da execução de um check-list de liberação. Se a versão for uma atualização de um
produto existente, os testadores poderão verificar os resultados das versões anteriores para
garantir que nada crítico seja deixado de fora do pacote de atualização. Os resultados podem
incluir avisos legais, documentação, traduções e software de terceiros que são fornecidos como
cortesia aos clientes.
As equipes ágeis estão agregando valor, não apenas software. Trabalhamos em conjunto com a equipe
do cliente para melhorar todos os aspectos do produto.
Não existem regras rígidas e rápidas sobre o que deve ser entregue com o produto. Pense nas entregas
como algo que agrega valor ao seu produto. Quem deve ser o destinatário da entrega e quando faz mais
sentido entregá-la?
LIBERANDO O PRODUTO
Quando falamos em lançar o produto, queremos dizer disponibilizá-lo para
o cliente em qualquer formato que possa assumir. Sua organização pode
ter um site que é atualizado ou um aplicativo personalizado que é entregue a um
poucos grandes clientes. Talvez o produto seja embalado e entregue em
milhões de PCs em todo o mundo ou baixados da Internet.
Critérios de aceitação de liberação
Como você sabe quando terminou? Os critérios de aceitação são tradicionais

forma de definir quando aceitar o produto. Os critérios de desempenho podem ter
LIBERANDO O PRODUTO 471
para ser atendido. Nós os capturamos para cada história no início de cada iteração e
também podemos especificá-los para conjuntos de recursos maiores quando iniciamos um tema ou
épico. Os clientes podem definir critérios de qualidade, como uma certa porcentagem de código
cobertos por testes automatizados ou que determinados testes devem ser aprovados. Itens de linha como
ter zero bugs críticos ou zero bugs com sério impacto no sistema são
muitas vezes parte dos critérios de liberação. Os clientes precisam decidir como irão
saiba quando há valor suficiente no produto. Os testadores podem ajudá-los a definir
liberar critérios que cumpram seus objetivos.
As equipes ágeis trabalham para atingir o espírito das metas de qualidade, não apenas a letra.
Eles não rebaixam a gravidade dos bugs para médio, então podem dizer que
atingiu o critério de ausência de bugs de alta gravidade. Em vez disso, eles frequentemente olham
nas tendências de bugs e pense em maneiras de garantir que bugs de alta gravidade não ocorram
em produção.
Seu nível de qualidade deve ser negociado antecipadamente com seu cliente para que
não há surpresas desagradáveis. A aceitação testa sua equipe e seu
clientes definidos, usando exemplos reais, devem servir como marcos para
progresso em direção à liberação. Se o seu cliente tem uma tolerância muito baixa a bugs,
e 100% desses testes de aceitação devem ser aprovados, sua velocidade de iteração
deveria levar isso em consideração. Se novos recursos são mais importantes do que
correções de bugs, bem, talvez você envie com bugs.
Uma história de “doença” em várias camadas
Bob Galen, treinador ágil e autor de suas Jogos Finais de Software, explica como
equipes define critérios de aceitação de lançamento e avalia se eles
perna com.
Participei de várias novas equipes ágeis nos últimos anos e tenho visto um padrão
comum nessas equipes. Minha equipe atual faz um trabalho maravilhoso ao
estabelecer critérios em nível de história de usuário ou recurso - basicamente
definição de critérios de aceitação. Trabalhamos muito para refinar nossos critérios
de aceitação. Inicialmente eles foram desenvolvidos a partir dos Product Owners
perspectiva, e muitas vezes eram bastante ambíguos e mal definidos. Os testadores
decidiram que poderiam realmente ajudar os clientes a refinar seus testes para
torná-los muito mais relevantes, claros e testáveis. Essa colaboração provou ser
uma vitória significativa no nível da história, e os Product Owners realmente
valorizaram o envolvimento e a ajuda.
Muitas vezes, os testadores também automatizavam os testes de aceitação das

histórias de usuário, executando-os durante cada sprint, mas também demonstrando
aceitação geral durante a revisão do sprint.
Um problema que tivemos, porém, foi conseguir que o mesmo nível de clareza de
“prontidão” no nível da história se estendesse além das histórias individuais. Descobrimos
que muitas vezes, quando nos aproximamos do final de um Sprint ou do jogo final de um
lançamento, tínhamos expectativas abertas sobre o que a equipe deveria realizar dentro do
sprint. Por exemplo, entregaríamos histórias que foram exaustivamente testadas “nos
pequenos”; isto é, a funcionalidade dessas histórias foi testada, mas as histórias não
foram integradas em nosso ambiente de teste para testes mais amplos. Isso não fazia
parte do nosso “entendimento”, mas as partes interessadas externas tinham essa expectativa
em relação aos resultados das equipes.
A forma como as equipes resolveram esse problema foi encarar nossos critérios como
um conjunto de metas orientadoras de vários níveis que envolvem cada fase, por assim
dizer, do desenvolvimento ágil. Um exemplo disso é mostrado na Tabela 20-1.
Definir o cozimento nesses níveis individuais provou funcionar para nossas equipes e
melhorou significativamente nossa capacidade de quantificar e atender a todas as diversas
expectativas dos clientes. Tenha em mente que existe uma conexão entre todos os
critérios, portanto definir um nível realmente ajuda a definir os outros. Muitas vezes
começamos no nível dos Critérios de Liberação e trabalhamos “de trás para frente”.
O desenvolvimento ágil não funciona se histórias, iterações ou lançamentos não forem

"feito." “Pronto” inclui testes, e testes geralmente são adiados quando o tempo é curto. Certifique-
se de que seus critérios de sucesso em todos os níveis incluam todos os testes necessários
para orientar e validar o desenvolvimento.
Tabela 20-1 Diferentes níveis de cozimento

Atividade Critério Exemplo
Trabalho Básico em Equipe Critérios de cozimento Emparelhamento ou inspeções de par de código antes
Produtos do check-in ou do desenvolvimento, execução e
aprovação de testes de unidade
Nível da história do usuário Testes de aceitação Desenvolvimento de testes de aceitação baseados em FitNesse
com o cliente E sua execução e aprovação bem-
sucedidas
Sprint ou Iteração Critérios de cozimento Definir uma meta do Sprint que esclareça o
Nível desenvolvimento de recursos e todas as dependências
externas associadas a um sprint
Nível de liberação Critérios de liberação Definir um amplo conjunto de condições
(artefatos, atividades de teste ou níveis de cobertura,
resultados/métricas, colaboração com outros
grupos, cumprimento de níveis de conformidade, etc.)
que, se atendidas, significariam que a liberação
poderia ocorrer
LIBERANDO O PRODUTO 473
Cada projeto, cada equipe, cada negócio é único. Equipes ágeis trabalham com
especialistas em negócios decidam quando estarão prontos para entregar software para produção. Se o
prazo de lançamento for definitivo, a empresa terá que modificar
escopo. Se houver flexibilidade suficiente para lançar quando o software tiver o suficiente
valor, as equipes podem decidir quando os critérios de qualidade foram atendidos e o
o software pode ir para produção.
Construções desafiadoras do Release Candidate

A equipe de Coni Tartaglia usa uma lista de verificação para avaliar cada versão do release
candidate. A lista de verificação pode especificar que o release candidate compile:
• Inclui todos os recursos que agregam valor comercial ao lançamento, incluindo arte, logotipos,
acordos legais e documentação
• Atende todos os critérios de aceitação de
construção • Tem prova de que todos os testes acordados (aceitação, integração, regressão
missão, não funcional, UAT) passaram
• Não possui relatórios de defeitos abertos
A equipe de Coni desafia o software que eles podem enviar com um conjunto final de inspeções e “testes
de aceitação de lançamento” ou “RATS” acordados. Ela explica:
A frase-chave é “testes acordados”. Ao concordar antecipadamente com os testes, o escopo

da lista de verificação de liberação fica bem definido. Inclua testes ponta a ponta em nível de
sistema no RATS e selecione a partir da lista de testes de compatibilidade, o que realmente
desafiará a construção do release candidate. Testes de desempenho também podem ser
incluídos nos RATs. Combine antecipadamente o conteúdo dos pacotes de automação,
bem como um subconjunto de testes manuais para cada RAT.
Combine antecipadamente quais testes serão repetidos se um RAT conseguir causar a falha de
uma versão release candidate. Se o software sobreviveu a várias iterações de testes de
regressão automatizados executados continuamente, passar nesses desafios finais deverá ser
muito fácil.
A definição dos critérios de aceitação depende, em última análise, dos clientes. Os testadores estão em
uma posição única para ajudar o cliente e as equipes de desenvolvimento a chegarem a um acordo
sobre os critérios que otimizam a qualidade do produto.
O desenvolvimento de software tradicional funciona em longos prazos, com prazos

definidos com muita antecedência e obstáculos a serem superados de uma fase para outra. O desenvolvimento
ágil nos permite produzir software de qualidade em pequenos incrementos e lançá-lo conforme necessário.
necessário. As equipes de desenvolvimento e do cliente podem trabalhar em estreita colaboração para definir
e decidir o que lançar e quando. Os testadores podem desempenhar um papel crítico nisso
processo de definição de metas.
Gerenciamento de Liberação
Muitas organizações têm uma equipe de gerenciamento de lançamento, mas se você não tiver, alguém
ainda fará o trabalho. Muitas vezes, em uma organização pequena, é o gerente de controle de qualidade
quem cumpre essa função. A pessoa que lidera a liberação pode realizar uma liberação
reunião de preparação com as partes interessadas para avaliar a preparação.
Uma lista de verificação de preparação para lançamento é uma ótima ferramenta para analisar o que é
importante para sua equipe. A intenção desta lista de verificação é ajudar a equipe a determinar
objetivamente o que foi concluído e identificar os riscos associados
não completar uma tarefa.
Por exemplo, se o treinamento não for necessário porque as alterações feitas no produto foram
transparentes para o usuário final, o risco será baixo. No entanto, se houver
houve mudanças significativas no processo de como um novo usuário é criado no
sistema, o risco seria muito alto para as equipes de suporte ou ajuda à produção,
e pode justificar um atraso. As necessidades de todas as partes interessadas devem ser consideradas.
As notas de versão são importantes para qualquer lançamento de produto. A formalidade destes
depende do público. Se o seu produto é voltado para desenvolvedores, então uma “leitura
me” provavelmente está bom. Em outros casos, você pode querer torná-los
mais formal. Qualquer que seja a mídia, ela deve atender às necessidades do público. Não forneça
muitas informações adicionais que não sejam necessárias.
Quando Janet recebe um novo lançamento, uma das primeiras coisas que ela faz é verificar o
versão e todos os componentes. “Recebi o que eles disseram que me deram?
Há instruções especiais que preciso considerar antes da instalação, como dependências ou scripts de
atualização?” Essas são boas perguntas simples de responder
nas notas de lançamento. Outras coisas a incluir são os novos recursos que o cliente deve procurar.
As notas de versão devem dar atenção especial aos componentes que não são
parte do que sua equipe de desenvolvimento entregou, como um arquivo de ajuda ou usuário
manuais preparados por uma equipe diferente. Às vezes, notas de lançamento antigas são deixadas
a mídia de liberação, que pode ou não ser útil para o usuário final. Considerar
o que é certo para sua equipe e sua aplicação.
Embalagem
Falamos muito sobre integração contínua. Tendemos a considerar isso garantido

e esqueça o que significa um bom gerenciamento de configuração. “Construa uma vez, implante
várias vezes” é parte do que nos dá confiança quando lançamos. Nós sabemos
que a compilação que testamos na preparação é a mesma que o cliente testou
EXPECTATIVAS DO CLIENTE 475
no UAT e é a versão que lançamos para produção. Isso é fundamental para um lançamento bem-
sucedido.
Se o produto for destinado a um cliente externo, a instalação deverá ser

fácil, pois a instalação pode ser a primeira visão do produto que o cliente possui. Conheça o seu público
e seu nível de tolerância a erros. Como vai
o produto será entregue? Por exemplo, se for para ser baixado da Internet, então deverá ser um simples
download e instalação. Se for uma grande empresa
sistema, então talvez sua organização precise enviar uma pessoa de suporte com
o produto para ajudar na instalação.
EXPECTATIVAS DO CLIENTE
Antes de lançarmos um novo software para nossos clientes, é melhor termos certeza de que eles
estão prontos para isso. Devemos ter certeza de que eles sabem quais novas funcionalidades esperar
e que eles tenham alguns meios para lidar com os problemas que surgirem.
Suporte à Produção
Muitas organizações têm uma equipe de suporte à produção ou operações que
mantém o código e oferece suporte aos clientes após sua produção. Se seu
empresa possui uma equipe de suporte à produção, esse grupo é seu primeiro cliente.
Faça dele seu parceiro também. As equipes de suporte à produção recebem relatórios de defeitos
e solicitações de melhorias dos clientes, e eles podem trabalhar com seu
equipe para identificar áreas de alto risco.
Muitas vezes a equipe de suporte à produção é a equipe que aceita o lançamento

da equipe de desenvolvimento. Se a sua organização tiver esse tipo de transferência,
é importante que sua equipe de desenvolvimento trabalhe em estreita colaboração com a produção
equipe de suporte para fazer uma transição tranquila. Certifique-se de que a equipe de suporte à
produção entenda como usar os arquivos de log e as mensagens do sistema
e sistemas de monitoramento para acompanhar as operações e identificar
problemas rapidamente.
Entenda o impacto nos negócios

Sempre que uma implantação em produção requer uma interrupção, o produto é
indisponível para seu cliente. Se o seu produto for um site, isso pode ser um grande
impacto. Se o seu produto for um produto independente para ser baixado em um
PC, o impacto é baixo. As equipes ágeis lançam lançamentos com frequência para maximizar o valor para o
negócios, e pequenos lançamentos têm um risco menor de um grande impacto negativo. Isso é
bom senso para trabalhar com a empresa para cronometrar liberações por períodos de tempo
que minimizem a interrupção. Automatize e simplifique os processos de implantação conforme

tanto quanto possível para manter pequenas as janelas de tempo de inatividade. Uma implantação rápida
processo também é útil durante o desenvolvimento em iterações curtas onde podemos
implantar uma dúzia de vezes em um dia.
Considerações Internacionais
Markus Gärtner, líder do grupo de testes “afetados pelo ágil”, explica a abordagem de sua equipe para
cronometrar seus lançamentos:
Construímos software de telecomunicações para celulares, por isso geralmente instalamos nosso
software à noite, quando é provável que ninguém faça chamadas. Isso pode ocorrer durante
nosso horário comercial, quando atendemos um cliente na Austrália, mas geralmente é durante a
noite.
Meus colegas que fazem a instalação propriamente dita (há três em nossa equipe) provavelmente
chegarão atrasados durante o horário comercial do dia seguinte porque não temos um grupo
separado para essas tarefas.
À medida que as empresas e as equipes de desenvolvimento se tornam mais globais, o tempo de

lançamento fica mais complicado. Felizmente, as configurações de produção podem facilitar os
lançamentos. Se o seu ambiente de produção tiver vários servidores de aplicativos, você poderá desativá-
los, um de cada vez, para lançamento, sem interromper os usuários.
Novos lançamentos devem ser o mais transparentes possível para o cliente. Quanto menos
lançamentos de emergência ou patches necessários após um lançamento, mais confiança
seu cliente terá tanto no produto quanto na equipe de desenvolvimento.
Aprenda com cada lançamento e tome medidas para fazer com que o próximo seja mais produtivo
suavemente. Envolva todas as funções, como administradores de sistema e de banco de dados,
o planejamento. Avalie cada lançamento e pense em maneiras de melhorar o próximo.
RESUMO
Este capítulo abordou os seguintes pontos:
A entrega bem-sucedida de um produto inclui mais do que apenas a aplicação que você
está construindo. Planeje as entregas que não sejam de software, como documentação, avisos
legais e treinamento.
O jogo final é uma oportunidade de dar brilho e polimento, os retoques finais, ao seu produto.
RESUMO 477
Outros grupos podem ser responsáveis pelos ambientes, ferramentas e outros

componentes do jogo final e do lançamento. Coordene com eles com antecedência.
Certifique-se de testar scripts de atualização de banco de dados, conversões de dados

e outras partes da instalação.
O UAT é uma oportunidade para os clientes testarem seus dados e aumentarem sua
confiança no produto.
Reserve tempo para ciclos extras conforme necessário, como ciclos pós-
desenvolvimento para coordenar testes com terceiros.
Estabeleça critérios de aceitação da versão durante o planejamento da versão para
saber quando estiver pronto para a versão.
Os testadores geralmente estão envolvidos no gerenciamento de versões e no
teste do pacote.
Ao lançar o produto, considere o pacote completo – o que o cliente precisa e espera.
Aprenda com cada versão e adapte-se para melhorar seus processos.


Parte VI
RESUMO
No Capítulo 21, “Fatores-chave de sucesso”, reunimos tudo e resumimos

a abordagem ágil para testes.

Capítulo 21
PRINCIPAIS FATORES DE SUCESSO
Olhe para o quadro grande

Use a abordagem de equipe inteira
Colabore com os clientes

Adote uma mentalidade de teste ágil
Sucesso chave
Fatores
Integração contínua
Automatize testes de regressão
Ambientes de teste
Construir um
Gerenciar dívida técnica Fundação Fornecer e obter feedback
Trabalhando incrementalmente
do Núcleo Ágil
Práticas
Codificação e teste fazem parte de um processo
Sinergia entre Práticas
Tendo viajado por uma iteração e além, acompanhando um testador ágil enquanto ele se envolve
em muitas atividades, podemos agora escolher alguns fatores-chave que ajudam os testadores a ter
sucesso em equipes ágeis e ajudam as equipes ágeis a ter sucesso no fornecimento de um produto
de alta qualidade. Acreditamos que os testadores ágeis têm algo especial a oferecer. Testadores
“infectados pelo Agile” aprendem como aplicar práticas e princípios ágeis para ajudar toda a equipe
a produzir um produto melhor. Programadores “infectados por testes” em equipes ágeis aprendem
como usar testes para produzir um trabalho melhor. As linhas entre os papéis são confusas, mas
isso é uma coisa boa. Todos estão focados na qualidade.
Reunimos algumas diretrizes críticas de testes para equipes ágeis e testadores a partir de
nossas próprias tentativas e erros, bem como de equipes com as quais trabalhamos.
Essas diretrizes são construídas na matriz de testes ágeis, em nossa experiência de aprender a
superar obstáculos culturais e organizacionais, em nossas aventuras no desempenho da função de
testador em equipes ágeis e em nossa experiência em descobrir a melhor forma de usar a
automação de testes. Gostamos de números da sorte, por isso neste capítulo apresentamos sete
fatores-chave que ajudam um testador ágil a ter sucesso.
Pedimos a um pequeno grupo de pessoas que estava revisando alguns de nossos capítulos
que sugerissem a ordem de apresentação desses fatores de sucesso. Os resultados variaram
bastante, embora muitos (mas não todos) concordassem com os dois primeiros. Escolha o fator
de sucesso que lhe proporcionará o maior retorno do investimento e comece a trabalhar nisso hoje.
481
482 CAPÍTULO 21 PRINCIPAIS FATORES DE SUCESSO
FATOR DE SUCESSO 1: USE A ABORDAGEM DE EQUIPE INTEIRA

Quando toda a equipe de desenvolvimento assume a responsabilidade pelos testes e pela qualidade, você
tem uma grande variedade de conjuntos de habilidades e níveis de experiência para lidar com quaisquer
problemas de teste que possam surgir. A automação de testes não é um grande problema para um
grupo de programadores qualificados. Quando o teste é uma prioridade da equipe e qualquer pessoa
pode se inscrever para tarefas de teste, a equipe projeta o código testável.
Tornar os testadores realmente parte da equipe de desenvolvimento significa dar-lhes o

suporte e treinamento de que precisam para se adaptar ao ritmo acelerado do desenvolvimento ágil. Eles
têm tempo para adquirir novas habilidades para colaborar estreitamente
com membros das equipes de desenvolvimento e do cliente.
Se você gerencia uma equipe ágil, use as sugestões da Parte II, “Organizacional
Desafios”, para ajudar sua equipe a adotar a abordagem de equipe inteira. Lembrar
que a qualidade, e não a velocidade, é o objetivo do desenvolvimento ágil. Sua equipe precisa
testadores para ajudar os clientes a esclarecer os requisitos, transformá-los em testes que orientam
desenvolvimento e fornecer um ponto de vista único que promoverá a entrega de um
produto sólido. Certifique-se de que os testadores possam transferir suas habilidades e conhecimentos para
o resto da equipe. Certifique-se de que eles não sejam classificados em uma função como apenas
fazendo testes manuais. Certifique-se de que, quando eles pedirem ajuda (o que pode exigir muita coragem
da parte deles), os membros da equipe a ajudem. O
o inverso também é verdadeiro; um testador deve intervir sempre que alguém precisar de assistência que
possa fornecer.
Se você é um testador em uma equipe ágil e há reuniões de planejamento e discussões de design

acontecendo que não incluem você, ou os usuários de negócios estão
2, “Dez Princípios para
Testadores Ágeis”,
lutando para definir suas histórias e requisitos sozinho, é hora de levantar
para ver um e vá falar com o resto da equipe. Sente-se com os programadores, convide-se
exemplo de como
às reuniões e proponho tentar o “Poder dos Três” envolvendo um testador, um
funciona o “Poder dos Três”.
programador e especialista em negócios. Seja útil, dando feedback e ajudando
os clientes fornecem exemplos. Faça dos seus problemas os problemas da equipe,
e faça com que os problemas deles sejam seus. Peça aos seus colegas de equipe para adotarem uma equipe inteira
abordagem.
FATOR DE SUCESSO 2: ADOTE UM ÁGIL

TESTE A MENTE
No Capítulo 2, “Dez princípios para testadores ágeis”, alertamos os testadores ágeis a
perder qualquer mentalidade de “Polícia da Qualidade” que possam ter trazido consigo.
Você agora faz parte de uma equipe ágil, onde os programadores testam e os testadores fazem tudo o
que podem para ajudar a equipe a entregar o melhor produto possível. Como
FATOR DE SUCESSO 2: ADOTE UMA MENTE DE TESTE ÁGIL 483
enfatizamos no Capítulo 2, uma atitude de teste ágil é proativa, criativa e

aberto a novas ideias e disposto a assumir qualquer tarefa. O testador ágil constantemente
aprimora sua arte, está sempre pronta para colaborar, confia em seus instintos e é apaixonada por
ajudar a equipe e o negócio a terem sucesso.
Não queremos dizer que você deva colocar sua capa de Super Tester e ir se proteger
o mundo de insetos. Não há espaço para grandes egos em equipes ágeis. Seu
colegas de equipe compartilham sua paixão pela qualidade. Concentre-se nos objetivos da equipe e faça
o que você puder para ajudar todos a fazerem seu melhor trabalho.
Use princípios e valores ágeis para orientá-lo. Sempre tente a abordagem mais simples para atender a
uma necessidade de teste. Seja corajoso ao procurar ajuda e experimentar novas ideias. Concentre-se
em entregar valor. Comunique-se diretamente
e tão frequentemente quanto possível. Seja flexível ao responder às mudanças. Lembre-se disso
o desenvolvimento ágil é centrado nas pessoas e que todos devemos gostar do nosso trabalho.
Na dúvida, volte aos valores e princípios para decidir o que fazer.
Um componente importante da mentalidade de testes ágeis é o impulso para encontrar continuamente

melhores maneiras de trabalhar. Um testador ágil de sucesso aprimora constantemente
2, “Dez princípios para
testadores ágeis”, para seu ofício. Leia bons livros, blogs e artigos para obter novas ideias e habilidades. Participe de reuniões
obter mais informações de grupos de usuários locais. Participe de discussões em listas de discussão para obter
sobre a
feedback sobre problemas ou novas ideias. Se sua empresa não pagar para você participar de uma
mentalidade de teste ágil.
boa conferência, coloque o que aprendeu em um relatório de experiência para
troque por uma inscrição gratuita na conferência. Retribuindo aos seus testes e
comunidades de desenvolvimento ágil também ajudarão você.
Experimente novas práticas, ferramentas e técnicas. Incentive sua equipe

para tentar novas abordagens. Iterações curtas são ideais para experimentação.
Você pode falhar, mas será rápido e você poderá tentar outra coisa.
Se você gerencia testadores ágeis ou uma equipe ágil, dê-lhes tempo para aprender e forneça suporte
para o treinamento necessário. Remova os obstáculos para que eles possam fazer
seu melhor trabalho.
Quando você se deparar com problemas que afetam os testes, traga esses problemas
para a equipe. Peça à equipe que pense em maneiras de superar esses obstáculos.
As retrospectivas são um lugar para falar sobre problemas e como resolvê-los.
Mantenha um backlog de impedimentos e resolva um ou dois em cada iteração. Usar
grandes gráficos visíveis, ou seus equivalentes virtuais, para garantir que todos estejam
ciente dos problemas que surgem e que todos podem acompanhar o progresso da codificação e dos
testes.
FATOR DE SUCESSO 3: TESTES DE REGRESSÃO AUTOMATIZADOS

Uma equipe ágil pode ter sucesso sem automação de testes? Talvez, mas as equipes de sucesso que
conhecemos dependem de testes de regressão automatizados. Como dissemos muitas vezes neste livro,
se você gasta todo o seu tempo fazendo regressão manual
testes, você nunca terá tempo para os importantes testes exploratórios que
descobrir os comportamentos prejudiciais ocultos no código.
O desenvolvimento ágil usa testes para orientar o desenvolvimento. Para escrever código para
para passar no teste, você precisa de uma maneira rápida e fácil de executá-lo. Sem o
curto ciclo de feedback e regressão da rede de segurança que as suítes fornecem, sua equipe
em breve ficará atolado em dívidas técnicas, com uma fila crescente de defeitos e
Consulte a Parte II para obter
velocidade cada vez mais lenta.
mais informações sobre os
quadrantes de testes ágeis.
Automatizar testes de regressão é um esforço de equipe. Toda a equipe deve escolher

ferramentas adequadas para cada tipo de teste. Pensar nos testes antecipadamente permitirá
“Estratégia de automação”,
os programadores projetam código para facilitar a automação de testes. Use o teste ágil
para obter mais informações Quadrantes e pirâmide de automação de testes para ajudá-lo a automatizar diferentes
sobre a pirâmide de
tipos de testes de forma eficaz.
Lembre-se de começar de forma simples. Você ficará surpreso com o valor de alguns itens básicos
testes automatizados de fumaça ou testes unitários automatizados podem fornecer.
A automação de testes é um esforço de equipe. Também é difícil, pelo menos no início. Muitas vezes há um
Consulte a bibliografia para
grande “corcunda de dor” a superar. Se você gerencia um projeto de desenvolvimento ou teste
recursos sobre promoção de
mudanças. equipe, certifique-se de fornecer suporte suficiente na forma de tempo, treinamento e motivação. Se você
é um testador em uma equipe sem automação e o
os programadores estão muito frenéticos tentando escrever código de produção para parar e
pense em testar, você tem um grande desafio pela frente. Experimente com
diferentes maneiras de obter apoio da gestão e dos membros da equipe
para iniciar algum pequeno esforço de automação.
FATOR DE SUCESSO 4: FORNECER E OBTER FEEDBACK

O feedback é um valor ágil fundamental. As iterações curtas do ágil são projetadas para
fornecer feedback constante para manter a equipe no caminho certo. Os testadores estão em um
posição única para ajudar a fornecer feedback na forma de resultados de testes automatizados, descobertas
feitas durante testes exploratórios e observações de situações reais.
usuários do sistema.
FATOR DE SUCESSO 4: FORNECER E OBTER FEEDBACK 485
Ágil tem tudo a ver com feedback

Bret Pettichord, CTO da WatirCraft e coautor de compartilhou Lições aprendidas em Macio-
louça Teste , essas idéias sobre a importância do feedback para o desenvolvimento ágil.
Os métodos ágeis permitem que sua equipe obtenha feedback sobre o software que você
está construindo. Essa é a questão. O feedback funciona em vários níveis.
A programação em pares oferece aos desenvolvedores feedback instantâneo sobre seu
código. As histórias representam unidades de trabalho onde testadores e analistas
podem fornecer feedback aos desenvolvedores. As versões de iteração facilitam o
feedback de fora da equipe. A maioria das práticas ágeis são valiosas porque criam
ciclos de feedback que permitem que as equipes se adaptem.
Muitas equipes adotam o Agile com uma abordagem de sacola sem perceber o objetivo das
práticas. Eles programam em pares sem discussão ou mudança de drivers. Eles enviam ao
controle de qualidade código que os testadores não podem testar porque os limites da
história são arbitrários; eles não sabem dizer se encontraram um bug ou apenas o fim
da história. As iterações tornam-se marcos do cronograma, em vez de oportunidades
reais para melhorar o alinhamento e ajustar os objetivos.
A razão pela qual as equipes ágeis podem fazer isso com menos planejamento é porque o
feedback permite que você tenha certeza de que está no caminho certo. Se você não
tiver feedback significativo, então você não é ágil. Você está apenas em uma nova forma de caos.
No meu último projeto, definimos nossas histórias para que fizessem sentido para todos
da equipe. Nossos analistas, testadores e desenvolvedores puderam compreender e
revisar histórias individuais. Mas descobrimos que precisávamos criar um agrupamento
maior, que chamamos de recursos, para facilitar uma revisão significativa de fora da nossa
equipe. Garantimos que todas as histórias de um recurso estivessem completas antes de
solicitar feedback de fora da equipe.
Ser capaz de dar e receber feedback significativo costuma ser um desafio para as pessoas.
No entanto, é crucial para o sucesso com o Agile.
As equipes ágeis enfrentam dificuldades terríveis quando executivos ou clientes lhes

entregam uma lista de requisitos no início e lhes dizem para usar o Agile (porque é
mais rápido) e então não quer participar do processo de feedback.
O Agile não é mais rápido por si só. Agile é apenas um benefício em um mundo que
reconhece o valor da adaptação. E essa adaptabilidade precisa chegar até quem está
financiando o projeto. Não basta a equipe ser ágil. Os patrocinadores também precisam ser
ágeis. Todos os requisitos são realmente necessários? Sabemos exatamente como o
software precisa ser desde o início?
O Agile é mais rápido porque o feedback permite que você encontre e se concentre nos
recursos mais valiosos. Se você tem certeza de que sabe o que precisa ser construído, não
use o Agile. Se você não tem tempo para reunir e agir de acordo com o feedback dos clientes,
não use o Agile. Se você tem certeza de que todos entendem exatamente o que precisa ser feito
desde o início, então não
use Ágil.
As práticas ágeis constroem uma infraestrutura técnica e organizacional para facilitar a obtenção
e a ação de feedback. Se você não for se adaptar ao feedback, então essa infraestrutura
será um desperdício que só irá atrasá-lo.
Para nós, o valor do desenvolvimento ágil não é ser mais rápido, mas sim entregar valor com rapidez
suficiente para ajudar o negócio a crescer e ter sucesso. Os testadores desempenham um papel
fundamental no fornecimento do feedback que permite que isso aconteça.
Os testadores também precisam de feedback. Como você sabe que tem os exemplos certos de
comportamento desejado por parte dos clientes? Como saber se o teste
casos que você escreveu refletiram esses exemplos corretamente? Podem os programadores
entenda o que codificar observando os exemplos que você capturou e o
testes que você criou?
Uma das habilidades mais valiosas que você pode aprender é como pedir feedback sobre
seu próprio trabalho. Pergunte aos programadores se eles obtêm informações suficientes para
compreender os requisitos e se essas informações orientam sua codificação.
Pergunte aos clientes se eles acham que seus critérios de qualidade estão sendo atendidos. Reserve um tempo
tanto as reuniões de planejamento da iteração quanto as retrospectivas para falar sobre esses
questões e sugerir maneiras de melhorar.
FATOR DE SUCESSO 5: CONSTRUA UMA FUNDAÇÃO

DAS PRÁTICAS ESSENCIAIS
Um velho ditado no ramo de testes diz: “Você não pode testar a qualidade do produto”. É claro que
isso também se aplica ao desenvolvimento ágil. Nós sentimos que você não pode
entregar software de alta qualidade sem seguir algumas práticas fundamentais.
Embora pensemos nelas como práticas ágeis, elas existem há mais de
o termo “desenvolvimento ágil” e são simplesmente práticas centrais de sucesso
desenvolvimento de software.
Integração contínua
Toda equipe de desenvolvimento precisa de gerenciamento de código-fonte e integração contínua
para ter sucesso. Você não pode testar com eficácia se não souber exatamente
FATOR DE SUCESSO 5: CONSTRUIR UMA BASE DE PRÁTICAS ESSENCIAIS 487
o que você está testando e não poderá testar se não tiver nenhum código que possa implantar. Todos
os membros da equipe precisam verificar seu trabalho pelo menos uma vez por dia. Todo
a integração deve ser verificada por uma construção automatizada que inclua testes para fornecer
feedback rápido sobre o estado do software.
Implementar um processo de integração contínua deve ser um dos primeiros

Consulte a
prioridades de qualquer equipe de desenvolvimento de software. Se sua equipe não tiver pelo menos
bibliografia para
mais informações pelo menos uma compilação verificada diariamente, pare o que estiver fazendo e comece. Isso é
sobre integração tão importante. Não precisa ser perfeito para começar. Se você tem um enorme
contínua. sistema para integrar, é definitivamente mais desafiador. Em geral, porém, é
não é tão difícil. Há uma infinidade de ferramentas excelentes, tanto de código aberto
e comerciais, disponíveis para esse fim.
Ambientes de teste
Você não pode testar de forma produtiva sem um ambiente de teste controlado. Você
precisa saber qual compilação está implantada, qual esquema de banco de dados está sendo usado,
se alguém está atualizando esse esquema e quais outros processos estão
rodando na máquina.
O hardware está cada vez mais barato e há mais software de código aberto
está disponível e pode ser usado para ambientes de teste. Sua equipe deve fazer o
investimento para que você possa realizar testes exploratórios automatizados e manuais com eficácia,
de forma rápida e eficiente. Se houver um problema com o ambiente de teste, fale e deixe que seja
um problema para a equipe resolver de forma criativa.
Gerenciar dívida técnica

Mesmo boas equipes de desenvolvimento de software, sentindo pressão de tempo, negligenciam a
refatoração ou recorrem a soluções rápidas e hacks para resolver um problema rapidamente. Enquanto o
o código se torna mais confuso e difícil de manter, mais bugs aparecem,
e não demora muito para que a velocidade da equipe seja consumida pelas correções de bugs
e tentando entender o código para adicionar novos recursos. Seu
a equipe deve avaliar constantemente a quantidade de dívida técnica que a arrasta
diminuir e trabalhar para reduzi-lo e preveni-lo.
As pessoas costumam dizer: “Nossa administração não nos dá tempo para fazer as coisas direito, nós
não temos tempo para refatorar e estamos com prazos apertados.” No entanto, é
não é difícil apresentar um caso de negócios claro mostrando o quão crescente é a dívida técnica
está custando à empresa. Existem muitas maneiras de medir código e defeito
taxas que podem traduzir a dívida técnica no seu impacto nos resultados financeiros.
Apenas apontar para sua velocidade decrescente pode ser suficiente. As empresas precisam
suas equipes de desenvolvimento de software permaneçam consistentemente produtivas. Eles

pode ter que reduzir o escopo de seus recursos desejados, a fim de permitir
tempo suficiente para um bom design de código guiado por testes e boas práticas, como
refatoração pequena e contínua.
Uma boa cobertura de testes de regressão automatizados é fundamental para minimizar problemas técnicos.
dívida. Se estes estiverem faltando, reserve tempo em cada iteração para construir os testes automatizados,
planeje uma “iteração de refatoração” para atualizar ou adicionar as ferramentas necessárias,
e escrever testes e fazer grandes esforços de refatoração. Em cada iteração, pegue o
hora de guiar o código com testes, refatorar o código que você está tocando conforme necessário e
adicione testes automatizados onde eles estão faltando. Aumente suas estimativas para contabilizar
para este trabalho. No longo prazo, a equipe poderá ir muito mais rápido.
Trabalhando incrementalmente
Uma das razões pelas quais as equipes ágeis são capazes de criar um produto de qualidade é que elas trabalham
em pequena escala. As histórias representam alguns dias de trabalho, e cada história pode ser
quebrado em várias fatias finas ou fios de aço e construído passo a passo. Isso permite testar cada peça
pequena e, em seguida, testar gradativamente à medida que as peças são
coloque junto.
Se os membros da sua equipe ficarem tentados a assumir uma grande quantidade de funcionalidades
Leia mais sobre
imediatamente, incentive-os a adotar uma abordagem gradual. Pergunte:
pequenos pedaços
e fatias finas no “Qual é o valor comercial central nesta história? Qual é o caminho mais básico
Capítulo 8, através deste pedaço de código? O que viria a seguir? Sugerir tarefa de escrita
“Testes voltados cartões para codificar e testar as pequenas peças, obter uma prova de conceito para o seu design,
para os
e confirme sua estratégia de testes e automação de testes.
negócios que apoiam a equipe”.
Codificação e teste fazem parte de um processo
Pessoas que são novas no Agile geralmente perguntam aos testadores ágeis: “O que vocês fazem até que todos
as histórias terminaram e você pode testar?” Praticantes ágeis experientes dizem:
“Os testadores devem estar envolvidos em toda a iteração, em todo o processo de desenvolvimento. Caso
contrário, não funciona.”
Os testadores escrevem testes, com base em exemplos fornecidos pelos clientes, para ajudar os programadores
a entender a história e começar. Testes e exemplos fornecem uma linguagem comum que todos os envolvidos
na produção do software entendem.
Testadores e programadores colaboram estreitamente à medida que a codificação avança, e ambos
também colaborar estreitamente com os clientes. Os programadores mostram aos testadores o
funcionalidade que escreveram, e os testadores mostram aos programadores o inesperado
comportamentos que encontraram. Os testadores escrevem mais testes à medida que a codificação prossegue, a programação
FATOR DE SUCESSO 6: COLABORAR COM OS CLIENTES 489
os participantes os fazem passar e os testadores fazem mais testes exploratórios para saber se
o valor certo foi entregue. Cada iteração ágil consiste em dezenas de
iterações constantes, rápidas e incrementais de teste-código-teste-código-teste.
Quando esse ciclo de colaboração e feedback é perturbado e os testes são separados do desenvolvimento,
coisas ruins acontecem. Se uma história for testada na iteração após a qual foi codificada e bugs forem
encontrados, o programador terá que
pare de trabalhar na nova história, lembre-se de como o código funcionou no último
história da iteração, corrija-a e espere que alguém teste a correção. Existem poucos fatos
no desenvolvimento de software, mas sabemos com certeza que bugs são mais baratos de corrigir
mais cedo eles serão encontrados.
Quando a codificação é constantemente guiada por testes, e os testes acontecem paralelamente

Leia mais sobre
codificação, temos muito mais probabilidade de alcançar o comportamento e fornecer o valor
codificação e
testes no Capítulo que o cliente queria. O teste é uma responsabilidade da equipe. Se sua equipe
18, não compartilha dessa visão, peça a todos que pensem sobre seu foco na qualidade,
“Codificação e testes”. seu desejo de entregar o melhor produto possível e quais etapas eles podem tomar
para garantir que a equipe atinja seus objetivos.
Sinergia entre Práticas

Uma única prática de desenvolvimento ágil, como a integração contínua, pode fazer um
diferença, mas a combinação de múltiplas práticas ágeis é maior do que a
soma das partes. O design orientado a testes, a propriedade coletiva do código e a integração contínua
proporcionam feedback rápido, melhorando continuamente o código
design e a capacidade de entregar valor comercial rapidamente. Automatizar testes é
bom, mas usar testes automatizados para impulsionar o desenvolvimento, seguidos de testes
exploratórios para detectar lacunas ou pontos fracos, é muito melhor.
Algumas práticas não funcionam bem isoladamente. A refatoração é impossível sem testes automatizados.
É possível fazer pequenos lançamentos em estilo mini-cascata e evitar todos os benefícios do
desenvolvimento ágil. Se o seu cliente no local não estiver
com poderes para tomar decisões, seu valor para a equipe é limitado.
As práticas ágeis foram projetadas para se complementarem. Reserve um tempo para entender o
propósito de cada um, considere o que é necessário para aproveitar ao máximo
cada prática e tome decisões ponderadas sobre o que funciona para sua equipe.
FATOR DE SUCESSO 6: COLABORAR COM OS CLIENTES

Um dos maiores valores que os testadores contribuem para as equipes ágeis é ajudar
os clientes esclarecem e priorizam os requisitos, ilustrando os requisitos
com exemplos concretos de comportamento desejado e cenários de usuário, e transformando

esses exemplos em testes executáveis. Os testadores falam o idioma do domínio
o negócio e a linguagem técnica da equipe de desenvolvimento. Nós fazemos
bons facilitadores e tradutores.
Nunca atrapalhe a comunicação direta entre programadores e

clientes. Incentive o máximo de comunicação direta possível. Use o
“Poder dos Três.” Quando os requisitos são ignorados ou mal compreendidos, o cliente, o
programador e o testador precisam trabalhar juntos para obter respostas às perguntas. Faça
com que os clientes conversem em frente a um quadro branco ou virtual
equivalente sempre que necessário. Se os clientes estiverem espalhados pelo campus, pelo
país ou pelo mundo, use todas as ferramentas que encontrar para melhorar a comunicação
e a colaboração. Teleconferências, mensagens instantâneas e wikis
não são um substituto ideal para uma conversa cara a cara, mas são melhores do que enviar
e-mails ou simplesmente não falar.
FATOR DE SUCESSO 7: OLHE PARA O QUADRO GRANDE

Isto é uma generalização, claro, mas descobrimos que os testadores tendem a olhar para
o panorama geral e, geralmente, do ponto de vista do cliente. Programadores
geralmente precisam se concentrar em entregar a história na qual estão trabalhando agora, e
embora possam usar testes para orientá-los, eles precisam se concentrar na implementação
técnica dos requisitos.
Esse ponto de vista geral é uma grande contribuição para a equipe. Orientado a testes
desenvolvimento, bem feito, entrega código sólido que pode, isoladamente, estar livre de
defeitos. E se esse novo recurso causar alguma parte aparentemente não relacionada do
o aplicativo para quebrar? Alguém tem que considerar o impacto para o maior
sistema e trazer isso à atenção da equipe. E se tivermos esquecido alguns
pequeno detalhe que irritará os clientes? A nova IU pode ser perfeita
codificado, mas se a cor de fundo dificultar a leitura do texto, é isso que
o usuário final notará.
Use os quadrantes de testes ágeis como um guia para ajudá-lo a planejar testes que irão
A Parte III explica
cubra todos os ângulos. Use a ideia da pirâmide de teste para garantir um bom ROI do seu
como usar os
Quadrantes de automação de testes. Orientar o desenvolvimento com testes ajuda a garantir que você não
Teste Ágil. sinto falta de algo grande, mas não é perfeito. Use testes exploratórios para aprender
mais sobre como o aplicativo deve funcionar e que direção seu teste precisa tomar. Torne
seus ambientes de teste o mais semelhantes possível à produção, usando dados que
reflitam o mundo real. Seja diligente ao recriar
uma situação de estilo de produção para atividades como testes de carga.
RESUMO 491
É fácil para todos na equipe se concentrarem apenas na tarefa ou na história em questão.

Essa é uma desvantagem de trabalhar em pequenos pedaços de funcionalidade de cada
vez. Ajude sua equipe a dar um passo atrás de vez em quando para avaliar como suas
histórias atuais se enquadram no grande esquema do negócio. Continue se perguntando
como você pode fazer um trabalho melhor para entregar valor real.
RESUMO
O teste e a qualidade são responsabilidade de toda a equipe, mas os testadores trazem
um ponto de vista especial e habilidades únicas. Como testador, sua paixão por entregar
um produto que encante seus clientes o ajudará a superar as frustrações que você e sua
equipe podem encontrar. Não tenha medo de ser um agente de melhoria contínua. Deixe
que os princípios e valores ágeis o guiem enquanto você trabalha com o cliente e as
equipes de desenvolvimento, agregando valor ao longo de cada iteração.
Neste capítulo final, analisamos sete fatores-chave para testes ágeis bem-sucedidos:
1. Use a abordagem de toda a equipe.

2. Adote uma mentalidade de teste ágil.
3. Automatize os testes de regressão.
4. Forneça e obtenha feedback.
5. Construir uma base de práticas essenciais.
6. Colabore com os clientes.
7. Tenha uma visão geral.

GLOSSÁRIO
Este glossário contém as definições dos autores dos termos usados ao longo deste
livro.
Teste de aceitação Os testes de aceitação são testes que definem o valor comercial que cada
história deve oferecer. Eles podem verificar requisitos funcionais ou não funcionais, como
desempenho ou confiabilidade. Embora sejam usados para ajudar a orientar o
desenvolvimento, eles estão em um nível mais alto do que os testes de nível de unidade usados
para design de código no desenvolvimento orientado a testes. Teste de aceitação é um termo
amplo que pode incluir testes voltados para negócios e para tecnologia.
As APIs da interface de programação de aplicativos (API) permitem que outro software

invoque alguma funcionalidade. A API pode consistir em funções, procedimentos ou classes
que suportam solicitações feitas por outros programas.
Build Uma build é o processo de conversão do código-fonte em um artefato implantável que

pode ser instalado para executar o aplicativo. O termo “construir” também se refere ao artefato
implantável.
Componente Um componente é uma parte maior do sistema geral que pode ser implantada
separadamente. Por exemplo, na plataforma Windows, bibliotecas vinculadas dinâmicas
(DLLs) são usadas como componentes, arquivos Java (arquivos JAR) são componentes na
plataforma Java e uma arquitetura orientada a serviços (SOA) usa serviços da Web como
componentes.
Teste de componente Um teste de componente verifica o comportamento de um componente.

Os testes de componentes ajudam no design de componentes, testando interações entre objetos.
Condições de Satisfação As condições de satisfação, também chamadas de condições de

satisfação ou condições de satisfação empresarial, são suposições e decisões fundamentais
tomadas pela equipe do cliente para definir o comportamento desejado do cliente.
493
494 GLOSSÁRIO
o código entregue para uma determinada história. Condições de satisfação são critérios
pelos quais o resultado de uma história pode ser medido. Eles evoluem durante conversas
com o cliente sobre critérios de aceitação de alto nível para cada história.
Discutir as condições de satisfação ajuda a identificar suposições arriscadas e aumenta a
confiança da equipe em escrever e estimar corretamente todas as tarefas para completar a
história.
Teste Orientado ao Contexto O teste orientado ao contexto segue sete princípios,

sendo o primeiro que o valor de qualquer prática depende do seu contexto. Cada novo
projeto e cada nova aplicação podem exigir diferentes formas de abordar um projeto.
Todas as sete práticas podem ser encontradas no site www.context-driven-
testing.com/.
Equipe do cliente A equipe do cliente identifica e prioriza os recursos necessários ao

negócio. No Scrum, esses recursos tornam-se épicos ou temas, que são divididos em
histórias e compõem o backlog do produto. As equipes do cliente incluem todas as partes
interessadas fora da equipe de desenvolvimento, como especialistas em negócios,
especialistas no assunto e usuários finais. Testadores e desenvolvedores trabalham em
estreita colaboração com a equipe do cliente para especificar exemplos de comportamento
desejado para cada história e transformar esses exemplos em testes para orientar o desenvolvimento.
Teste do cliente Um teste do cliente verifica o comportamento de uma fatia ou parte de

uma funcionalidade que é visível para o cliente e está diretamente relacionada a uma
história ou recurso. Os termos “teste voltado para o negócio” e “teste voltado para o cliente”
referem-se ao mesmo tipo de teste que o teste do cliente.
Equipe de Desenvolvimento A equipe de desenvolvimento é a equipe técnica que produz

o software solicitado pela equipe do cliente. Todos os envolvidos no fornecimento de
software são desenvolvedores, incluindo programadores, testadores, especialistas em
banco de dados, administradores de sistema, escritores técnicos, arquitetos, especialistas
em usabilidade e analistas. Essa equipe de desenvolvimento trabalha em conjunto para
produzir o software e agregar valor ao negócio, seja uma equipe co-localizada ou uma
equipe virtual.
Épico Um épico é uma funcionalidade ou recurso descrito pelo cliente e é um item no

backlog do produto. Um épico é dividido em histórias relacionadas que são então
dimensionadas e estimadas. Algumas equipes usam o termo “tema” em vez de épico.
Teste Exploratório O teste exploratório é um teste interativo que combina o design do teste
com a execução do teste e se concentra no aprendizado sobre o aplicativo.
GLOSSÁRIO 495
Consulte o Capítulo 10, “Testes voltados para os negócios que criticam o produto”, para obter
uma definição abrangente de testes exploratórios.
Objeto falso Um objeto falso substitui a funcionalidade do componente do qual depende

uma implementação mais simples. Ele emula o comportamento do componente real do qual
depende, mas é mais fácil de usar para fins de teste.
Recurso Um recurso é uma funcionalidade descrita pelo cliente e é um item do backlog do

produto. Um recurso é dividido em histórias relacionadas que são dimensionadas e
estimadas. No desenvolvimento ágil, os termos “épico” ou “tema” são frequentemente usados
no lugar de “recurso”.
Teste Funcional Os testes funcionais verificam o comportamento esperado do sistema dado

um conjunto de entradas e/ou ações.
Greenfield Projetos Greenfield são novos projetos de desenvolvimento de aplicativos

começando do zero, sem nenhuma base de código existente. Não há restrições, portanto as
equipes de desenvolvimento têm muitas opções à sua disposição.
Ambiente de Desenvolvimento Integrado (IDE) Um Ambiente de Desenvolvimento Integrado,

ou IDE, é um conjunto de ferramentas que suportam programação e testes.
Geralmente inclui um editor, compilador ou depurador intérprete, recursos de refatoração e
ferramentas de automação de construção. Os IDEs geralmente permitem a integração com um
sistema de controle de código-fonte e fornecem suporte específico à linguagem para ajudar
no design do código.
Iteração Uma iteração é um ciclo de desenvolvimento curto, geralmente de uma a quatro

semanas, ao final do qual o código pronto para produção pode ser potencialmente entregue.
Várias iterações, cada uma com a mesma duração, podem ser necessárias para entregar
um tema ou épico inteiro. Na verdade, algumas equipes liberam o código para produção a
cada iteração, mas mesmo que o código não seja lançado, ele estará pronto para
lançamento.
Java Messaging Service (JMS) A API Java Messaging Service (JMS) é um padrão de
mensagens que permite que componentes de aplicativos baseados na Java 2 Platform,
Enterprise Edition (J2EE) criem, enviem, recebam e leiam mensagens.
Sistema legado Um sistema legado é aquele que não possui nenhum (ou poucos) testes de
regressão automatizados. Introduzir alterações no código legado ou refatorá-lo pode ser
arriscado porque não há testes para detectar alterações não intencionais no comportamento
do sistema.
496 GLOSSÁRIO
Extensões de correio da Internet multiuso (MIME) As extensões de correio da Internet

multiuso, ou MIME, estendem o formato do correio da Internet para permitir mensagens não
textuais, corpos de mensagens com várias partes e mensagens e cabeçalhos textuais não-US-ASCII.
Objeto simulado Um objeto simulado simula as respostas de um objeto existente. Ajuda a projetar
e testar interações entre objetos, substituindo um componente real para que um teste possa
verificar suas saídas indiretas.
Product Backlog Product Backlog é um termo Scrum para a lista mestre priorizada de todas as
funcionalidades desejadas no produto. Esse backlog aumenta com o tempo, à medida que a
organização pensa em novos recursos de que pode precisar.
Product Owner Product Owner é um termo Scrum para a pessoa responsável por priorizar o
backlog do produto, ou histórias. Ele ou ela normalmente é alguém com função de marketing ou
um importante especialista em negócios envolvido com desenvolvimento.
Equipe de Garantia de Qualidade (QA) A Garantia de Qualidade, ou QA, pode ser definida como
ações tomadas para garantir a conformidade com um padrão de qualidade. No desenvolvimento
de software, o termo “Equipe de controle de qualidade” é frequentemente usado para se referir à
equipe que faz testes de software. As equipes de teste (consulte Equipe de Teste) fornecem às
partes interessadas informações relacionadas à qualidade do produto de software. Eles realizam
atividades para aprender como o sistema em teste deve se comportar e verificar se ele se comporta
conforme o esperado. No desenvolvimento ágil, essas atividades são totalmente integradas às
atividades de desenvolvimento. Os testadores geralmente fazem parte da equipe de
desenvolvimento junto com todos os demais envolvidos no desenvolvimento do software.
Código de produção Código de produção é o código do sistema que é, ou será, usado na produção,
diferentemente do código escrito para testá-lo. O código de teste invoca ou opera no código de
produção para verificar seu comportamento.
Refatoração Refatoração é alterar o código, sem alterar sua funcionalidade, para torná-lo mais
fácil de manter, mais fácil de ler, mais fácil de testar ou mais fácil de estender.
Teste de Regressão Um teste de regressão verifica se o comportamento do sistema em teste não

mudou. Os testes de regressão geralmente são escritos como testes de unidade para conduzir
testes de codificação ou aceitação para definir o comportamento desejado do sistema. Depois que
os testes são aprovados, eles se tornam parte de um conjunto de testes de regressão, para
proteger contra a introdução de alterações não intencionais. Os testes de regressão devem ser
automatizados para garantir feedback contínuo.
GLOSSÁRIO 497
Release Candidate Um release candidate é uma versão ou compilação do produto que pode
potencialmente ser lançada para produção. O release candidate pode ser submetido a mais
testes ou ser complementado com documentação ou outros materiais.
Retorno sobre o Investimento (ROI) O retorno sobre o investimento, ou ROI, é um termo

emprestado do mundo dos investimentos financeiros e é uma medida da eficiência de um
investimento. O ROI pode ser calculado de diferentes maneiras, mas é basicamente a

diferença entre o ganho de um investimento e o custo desse investimento, dividido pelo custo
desse investimento. Nos testes, o ROI é o benefício obtido com uma atividade de teste, como a
automação de um teste, ponderado em relação ao custo de produção e manutenção desse
teste ou atividade.
SOAP SOAP é um protocolo para troca de mensagens baseadas em XML através de redes,
normalmente usando HTTP/HTTPS. Ele forma a camada base da pilha de protocolos de
serviços da Web, fornecendo uma estrutura básica de mensagens sobre a qual camadas
abstratas podem ser construídas. Um padrão de mensagens SOAP comum é o padrão Remote
Procedure Call (RPC), no qual o nó da rede cliente envia uma mensagem de solicitação ao
nó do servidor e o servidor envia imediatamente uma resposta ao cliente.
História Uma história de usuário é uma breve descrição de uma funcionalidade contada da
perspectiva do usuário que é valiosa para ele ou para a equipe do cliente.
As histórias são tradicionalmente escritas em fichas. O cartão normalmente contém uma descrição
do recurso em uma linha. Por exemplo, “Como comprador, posso colocar itens no meu
carrinho de compras para poder finalizá-los mais tarde” é uma história.
Os cartões só podem ser usados em combinação com conversas subsequentes entre a
equipe do cliente e a equipe de desenvolvimento e alguma verificação de que a história foi
implementada por meio da escrita e execução de testes.
Teste de história Um teste de história define o comportamento esperado do código a ser

entregue pela história. Os testes de história podem ser voltados para os negócios, especificando
os requisitos funcionais, ou voltados para a tecnologia, como testes de segurança ou desempenho.
Esses testes são usados para orientar o desenvolvimento e também para verificar o código
entregue. A maioria dos profissionais ágeis usa o termo “teste de história” como sinônimo de
“teste de aceitação”, embora o termo “teste de aceitação” possa ser usado para testes que
verificam o comportamento em um nível superior ao de uma história.
Story Board O storyboard, também chamado de quadro de tarefas, é usado para rastrear o
trabalho que a equipe realiza durante uma iteração. Cartões de tarefas, que podem ter
cores coordenadas para o tipo de tarefa, são escritos para cada história. Esses cartões,
junto com algum tipo de dica visual, fornecem um mecanismo fácil para ver o status atual do
progresso de uma iteração. Pode usar colunas ou
498 GLOSSÁRIO
adesivos de cores diferentes em cartões para diferentes estados, como “A fazer”, “Trabalho em
andamento”, “Verificar” e “Concluído”. O storyboard pode ser um quadro físico na parede ou um
quadro virtual online.
Tarefa Tarefas são peças de trabalho necessárias para terminar uma história. Uma tarefa pode
ser uma ação necessária para implementar uma pequena parte de uma história, ou pode ser para
construir uma infraestrutura ou testar que abrange mais de uma história. Geralmente deve
representar um dia ou menos de trabalho.
Dívida Técnica Ward Cunningham introduziu pela primeira vez esta metáfora. Quando uma
equipe produz software sem utilizar boas práticas como TDD, integração contínua e refatoração,
ela pode incorrer em dívida técnica. Assim como a dívida financeira, a dívida técnica rende juros
que custarão mais à equipe posteriormente. Às vezes, essa dívida pode valer a pena, como
para aproveitar uma oportunidade repentina de negócio. Normalmente, porém, a dívida técnica
aumenta e diminui a velocidade da equipe. Cada vez menos valor comercial pode ser produzido
em cada iteração porque o código carece de uma rede de segurança de testes de regressão
automatizados ou se tornou difícil de entender e manter.
Teste Duplo Um teste duplo é qualquer objeto ou componente instalado no lugar do

componente real com o propósito expresso de executar um teste. Os duplos de teste incluem
objetos fictícios, objetos simulados, stubs de teste e objetos falsos.
Desenvolvimento Orientado a Testes (TDD) No desenvolvimento orientado a testes, o

programador escreve e automatiza um pequeno teste de unidade antes de escrever o
pequeno trecho de código que fará o teste passar. O código de produção é feito para funcionar
um teste por vez.
Desenvolvimento Test-First No desenvolvimento test-first, os testes são escritos

antecipadamente ao código de produção correspondente, mas o código não é necessariamente
feito para funcionar um teste por vez. Os testes de cliente ou de história podem ser usados no
desenvolvimento de teste inicial, bem como em testes de unidade.
Stub de teste Um stub de teste é um objeto que substitui um componente real necessário ao
sistema em teste por um objeto específico de teste que alimenta entradas indiretas desejadas no
sistema em teste. Isso permite que o teste verifique a lógica independentemente dos outros
componentes.
Equipe de Teste Uma equipe de teste executa atividades que ajudam a definir e posteriormente
verificar o comportamento desejado do sistema em teste. A equipe de teste fornece informações
às partes interessadas sobre a qualidade externa do sistema, os riscos que podem estar presentes
e possíveis estratégias de mitigação de riscos. Em desenvolvimento ágil
GLOSSÁRIO 499
desenvolvimento, estas actividades estão totalmente integradas com as actividades de desenvolvimento.

Os testadores geralmente fazem parte da equipe de desenvolvimento junto com todos os demais
envolvidos no desenvolvimento do software.
Testador Um testador fornece informações às partes interessadas sobre o software que está sendo
desenvolvido. Um testador ajuda os clientes a definir requisitos funcionais e não funcionais e critérios
de qualidade, e ajuda a transformá-los em testes que orientam o desenvolvimento e verificam o
comportamento desejado. Os testadores realizam uma ampla variedade de atividades relacionadas ao
fornecimento de software de alta qualidade, como automação de testes e testes exploratórios. No
desenvolvimento ágil, todos da equipe de desenvolvimento realizam atividades de teste. Os
membros da equipe que se identificam como testadores trabalham em estreita colaboração com outros
membros das equipes de desenvolvedores e clientes.
Tema Um tema é o mesmo que um épico ou recurso. É uma funcionalidade descrita pelo cliente e colocada
no backlog do produto para ser dividida em histórias dimensionadas e estimadas.
Teste de Unidade Um teste de unidade verifica o comportamento de uma pequena parte do sistema
geral. Pode ser tão pequeno quanto um único objeto ou método que é consequência de uma ou mais
decisões de projeto.
Velocidade A velocidade de uma equipe de desenvolvimento é a quantidade de valor que ela entrega em
cada iteração, medida em pontos da história, dias ideais ou horas. Geralmente, apenas histórias concluídas
são incluídas na velocidade. O Velocity é útil para os negócios no planejamento de recursos e lançamentos
futuros. As equipes ágeis usam a velocidade da iteração anterior para ajudar a determinar a quantidade
de trabalho que podem realizar na próxima iteração.
Linguagem de descrição de serviços da Web (WSDL) A linguagem de descrição de serviços da Web

(WDSL) é um formato XML para descrever serviços de rede como um conjunto de terminais operando em
mensagens contendo informações orientadas a documentos ou orientadas a procedimentos.

BIBLIOGRAFIA
LIVROS, ARTIGOS, PAPÉIS E POSTAGENS DE BLOG

Aliança Ágil. “Princípios por trás do Manifesto Ágil”, www.agilemanifesto .org/principles.html,
2001.
Alles, Micah, David Crosby, Carl Erickson, Brian Harleton, Michael Marsiglia, Greg Pattison
e Curt Stienstra. “Presenter First: Organizing Complex GUI Applications for Test-Driven
Development,” Agile 2006, Minneapolis, MN, julho de 2006.
Ambler, Scott. Técnicas de banco de dados ágeis: estratégias eficazes para o

desenvolvedor de software ágil, Wiley, 2003.
Astels, David. Desenvolvimento Orientado a Testes: Um Guia Prático, Prentice Hall, 2003.
BACH, James. “Explicação do teste exploratório”, www.satisfice.com/articles/

et-article.pdf, 2003.
BACH, Jônatas. “Session-Based Test Management”, Revista Software Testing and

Quality Engineering, novembro de 2000, www.satisfice.com/articles/
sbtm.pdf.
Beck, Kent. Programação Extrema Explicada: Abrace a Mudança, Addison-Wesley,

2000.
Beck, Kent e Andres, Cynthia. Explicação da programação extrema: abrace a mudança.

2ª Edição, Addison-Wesley, 2004.
Berczuk, Stephen e Brad Appleton. Padrões de gerenciamento de configuração de

software: trabalho em equipe eficaz, integração prática, Addison-Wesley, 2003.
501
502 BIBLIOGRAFIA
Bolton, Michael. “Testing Without a Map”, Better Software, janeiro de 2005,

www.developsense.com/articles/Testing%20Without%20A%20Map.pdf.
Bos, Erik e Cristo Vriens. “An Agile CMM,” em Extreme Programming and Agile Methods–XP/Agile
Universe 2004, 4th Conference on Extreme Programming and Agile Methods, Calgary,
Canadá, 15–18 de agosto de 2004, Pro-ceedings, ed. Carmen Zannier, Hakan Erdogmus,
Lowell Lindstrom, pp.
129–138, Springer, 2004.
BOUTELLE, Jonathan. “Teste de usabilidade para desenvolvimento ágil”,

www.jonathanboutelle.com/mt/archives/2005/08/usability_testi_1.html, 2005.
Brown, Tito. “A (falta de) teste da espiral da morte”, http://ivory.idyll.org/

blog/mar-08/software-quality-death-spiral.html, 2008.
Buwalda, Hans. “Soap Opera Testing,” Better Software Magazine, fevereiro de 2004,
www.logigear.com/resources/articles_lg/soap_opera_testing.asp.
Clark, Mike. Automação pragmática de projetos: como construir, implantar e monitorar aplicativos
Java, The Pragmatic Programmers, 2004.
Cohn, Mike. Histórias de usuários aplicadas ao desenvolvimento ágil de software, Addison-

Wesley, 2004.
Cohn, Mike. Estimativa e planejamento ágil, Prentice Hall, 2005.
Crispin, Lisa e Tip House. Testando Programação Extrema, Addison-Wesley 2002.
Crispin, Lisa. Artigos “Contratando um testador ágil”, “Uma estratégia de seleção de ferramentas
ágeis para ferramentas de teste da Web”, “Conduzindo a qualidade do software: como o
desenvolvimento orientado a testes afeta a qualidade do software”, http://lisa.crispin.home.att .líquido.
DeMarco, Tom e Timothy Lister. Gerenciando Riscos em Projetos de Software, Dor-set House,
2003.
Derby, Esther e Larsen, Diana. Retrospectivas ágeis: tornando boas equipes excelentes,
Pragmatic Bookshelf, 2006.
Derby, Esther e Rothman, Johanna. Atrás de portas fechadas: segredos de uma grande gestão,
Pragmatic Bookshelf, 2006.
BIBLIOGRAFIA 503
De Souza, Ken. Blog “Um testador em roupas de desenvolvedor”, http://

kendesouza .blogspot.com.
Dustin, Elfriede, Chris Wysopal, Lucas Nelson e Dino Dia Zovi. A arte dos testes de
segurança de software: identificando falhas de segurança de software, Symantec Press,
2006.
Dustin, Elfriede. “Teamwork Tackles the Quality Goal”, Teste e desempenho de software,
Volume 2, Edição 200, março de 2005.
Duvall, Paul, Steve Matyas e Andrew Glover. Integração Contínua: Melhorando a

Qualidade do Software e Reduzindo Riscos, Addison-Wesley, 2007.
Eckstein, Jutta. Desenvolvimento ágil de software em geral: mergulhando nas profundezas,

Casa Dorset, 2004.
Evans, Érico. Design Orientado a Domínio: Enfrentando a Complexidade no Coração do

Software, Addison-Wesley, 2003.
Penas, Michael. Trabalhando Efetivamente com Código Legado, Prentice Hall, 2004.
Freeman, Steve e Nat Pryce. “Objetos simulados”, www.mockobjects.com.
FOWLER, Martin. “Integração Contínua”, http://martinfowler.com/articles/

integração contínua.html, 2006.
FOWLER, Martin. “StranglerApplication”, www.martinfowler.com/bliki/

StranglerApplication.html, 2004.
Fowler, Martin, “Dívida Técnica”, http://martinfowler.com/bliki/

Dívida Técnica.html, 2003.
Gårtner, Markus, Blog, http://blog.shino.de.
Galeno, Roberto. Jogos finais de software: eliminando defeitos, controlando mudanças e

a contagem regressiva para entrega no prazo, Dorset House, 2005.
Ghiorghiu, Grig. “Desempenho versus carga versus teste de estresse”, http://

ágiltesting.blogspot.com/2005/02/performance-vs-load-vs-stress-testing.html,
2005.
Ghirghiu, Grig. Blog "Teste Ágil", http://agiletesting.blogspot.com.

504 BIBLIOGRAFIA
Hagar, Jon. Documentos de teste de software, www.swtesting.com/

hagar_papers_index.html.
HENDRICKSON, Elisabeth. “Desenvolvedores de testes, testadores de desenvolvedores”, http://

testobsessed.com/2007/01/17/tester-developers-developer-testers/, 2007.
HENDRICKSON, Elisabeth. “Folha de dicas de heurística de teste”, http://

testobsessed.com/wordpress/wp-content/uploads/2007/02/
testheuristicscheatsheetv1.pdf, 2007.
HENDRICKSON, Elisabeth. “Ferramentas/Frame-works de automação de teste

compatíveis com Agile”, http://testobsessed.com/2008/04/29/agile-friendly-test-
automation-toolsframeworks, 2008.
Highsmith, Jim. Gerenciamento Ágil de Projetos: Criando Produtos Inovadores,

Addison-Wesley, 2004.
Hunt, Andrew e David Thomas. O programador pragmático: de Journeyman a mestre,

Addison-Wesley, 1999.
Kaner, Cem, James Bach e Bret Pettichord. Lições aprendidas em testes de software,
Wiley, 2001.
Kerth, Norman. Retrospectivas de projetos: um manual para análises de equipes, Dorset

House, 2001.
KNIBERG, Henrik. “Como acompanhar a automação de testes”, http://

blog.crisp.se/henrikkniberg/2008/01/03/1199386980000.html, 2008.
KNIBERG, Henrik. Scrum e XP das trincheiras, Lulu.com, 2007.
Koenig, Dierk, Andrew Glover, Paul King, Guillaume Laforge e Jon Skeet.
Groovy em ação, Manning Publications, 2007.
Kohl, Jonathan. “Man and Machine”, revista Better Software , dezembro de 2007.
Kohl, Jonathan. Blog e artigos, www.kohl.ca/.
LOUVION, Christophe. Blog, www.runningagile.com.

BIBLIOGRAFIA 505
Manns, Mary Lynn e Linda Rising. Mudança destemida: padrões para introdução de novas
ideias, Addison-Wesley, 2004.
MARICK, Brian. Scripting diário com Ruby: para equipes, testadores e você,
Estante Pragmática, 2007.
Marick, Brian, “Meu projeto de teste ágil”, www.exampler.com/old-blog/ 2003/

21/08/, 2003.
MARICK, Brian. “Uma alternativa ao TDD voltado para negócios”, www.exampler .com/
blog/categoria/aa-ftt, 2008.
MARICK, Brian. Blog e artigos sobre testes ágeis, http://exampler.com.
MARCANO, Antônio. Blog, www.testingreflections.com.
Meszaros, Gerard. Padrões de teste XUnit: Código de teste de refatoração, Addison-

Wesley, 2007.
Meszaros, Gerard e Janice Aston. “Adicionando testes de usabilidade a um projeto ágil”,

Agile 2006, Minneapolis, MN, 2006, http://papers.gerardmeszaros.com/AgileUsabilityPaper.pdf.
Meszaros, Gerard, Ralph Bohnet e Jennitta Andrea. “Teste de regressão ágil usando
gravação e reprodução”, XP/Agile Universe 2003, Nova Orleans, LA, 2003, http://
agileregressiontestpaper.gerardmeszaros.com.
Meszaros, Gerard. “Usando Storyotypes para dividir histórias inchadas de XP”, http://
storyotypespaper.gerardmeszaros.com.
Mugridge, Rick e Ward Cunningham. Adequado para desenvolvimento de software: estrutura

para testes integrados, Prentice Hall, 2005.
Newkirk, James e Alexei Vorontsov. Desenvolvimento orientado a testes em Microsoft .NET,

Microsoft Professional, 2004.
Nielsen, Jacob. “Orçamentos de tempo para sessões de usabilidade”, www.useit.com/

alertbox/usability_sessions.html, 2005.
Norte, Dan. “Apresentando o BDD”, http://dannorth.net/introduzindo-bdd, 2006.

506 BIBLIOGRAFIA
Patterson, Kerry, Joseph Gernny, Ben McMillan, Al Switzler e Stephen R.

Covey. Conversas cruciais: ferramentas para conversar quando há muito em jogo,
McGraw-Hill, 2002.
Patton, Jeff. “Teste o software antes de codificar”, StickyMinds.com, agosto de 2006,

www.stickyminds.com/sitewide.asp?Function=edetail&ObjectType=
COL&ObjectId=11104.
Patton, Jeff. “Design e Desenvolvimento Ágil Holístico de Produto”, www.ag-

ileproductdesign.com/blog/agile_product_development.html, 2006.
Pols, Andy. “O Cliente Perfeito”, www.pols.co.uk/archives/category/testing, 2008.
Pettichord, Bret. “Automação de teste de homebrew”, www.io.com/~wazmo/

papéis/homebrew_test_automation_200409.pdf, 2004.
Pettichord, Bret. “Sete etapas para testar o sucesso da automação”, www.io .com/
~wazmo/papers/seven_steps.html, 2001.
Poppendieck, Mary e Tom Poppendieck. Implementando o desenvolvimento de

software enxuto: do conceito ao dinheiro, Addison-Wesley, 2006.
Poppendieck, Mary e Tom Poppendieck. Desenvolvimento de software enxuto: um kit

de ferramentas ágil, Addison-Wesley, 2003.
Rainsberger, JB JUnit Recipes: métodos práticos para testes de programadores,

Publicações Manning, 2004.
Rasmusson, Jonathan. “Introduzindo XP em Projetos Greenfield: Lições Aprendidas”,

IEEE Software, 2003, http://rasmusson.files.wordpress.com/2008/
01/s3021.pdf.
Robbins, Stephen e Tim Judge. Fundamentos do Comportamento Organizacional, 9ª

Edição, Prentice Hall, 2007.
Schwaber, Ken. Gerenciamento Ágil de Projetos com Scrum, Microsoft Press, 2004.
Shore, James e Shane Warden. A Arte do Desenvolvimento Ágil, O'Reilly Media, 2007.
BIBLIOGRAFIA 507
Soni, Mukesh. “Prevenção de defeitos: reduzindo custos e melhorando a qualidade”, iSixSigma,

http://software.isixsigma.com/library/content/c060719b.asp.
Sumrel, Megan. “Caixa de sapatos 'Shout-Out' – Aumentando o moral da equipe”, http://

megansumrell.wordpress.com/2007/08/27/shout-out-shoebox-boosting-team-morale, 2007.
Sutherland, Jeff, Carsten Ruseng Jakobsen e Kent Johnson. “Scrum e CMMI Nível 5:
A Poção Mágica para Guerreiros do Código”, Agile 2007, Washington, DC, 2007, http://
jeffsutherland.com/scrum/
Sutherland-ScrumCMMI6pages.pdf.
Tabaka, Jean. Colaboração explicada: habilidades de facilitação para líderes de projetos de

software, Addison-Wesley, 2006.
Thomas, Mike. “Strangling Legacy Code”, revista Better Software , outubro de 2005, http://
samoht.com/wiki_downloads/StranglingLegacyCodeArticle.pdf.
Tholsen, Mike. “A ascensão dos campeões do cliente”, STAREAST, 7 a 9 de maio de

2008.
Voris, John. Monitores ADEPT AS400 para prototipagem e testes externos,

www.AdeptTesting.org.
Acorde, Bill. “Gráfico de radar XP”, http://xp123.com/xplor/xp0012b/index.shtml, 2001.
VRIENS, Cristo. “Certificando para CMM Nível 2 e ISO9001 com XP@Scrum”, em ADC 2003:
Proceedings of the Agile Development Conference, 25–28 de junho de 2003, Salt Lake City,
UT, EUA, 120–124, IEEE, 2003.
REFERÊNCIAS DE FERRAMENTAS
Estrutura de teste Abbot Java GUI, http://abbot.sourceforge.net/doc/

visão geral.shtml.
Adzik, Gojko. DbFit: Desenvolvimento de banco de dados orientado a testes, http://gojko.net/

fitness/dbfit/.
Falha, Danny. “Lista de ferramentas de teste”, http://testingfaqs.org, 2008.

508 BIBLIOGRAFIA
Canoo WebTest, ferramenta de código aberto para testes automatizados de aplicativos da

Web, http://webtest.canoo.com.
easyb, Estrutura de Desenvolvimento Orientada a Comportamento para a Plataforma

Java, www.easyb.org/.
Fit, Estrutura para Teste Integrado, http://fit.c2.com.
JUnit, Recursos para Desenvolvimento Orientado a Testes, www.junit.org.
JUnitPerf, decoradores de testes JUnit para testes de desempenho e escalabilidade, http://

clarkware.com/software/JUnitPerf.html.
FitNesse, Wiki autônomo totalmente integrado e estrutura de teste de aceitação,

www.fitnesse.org.
Hower, Rick, Informações sobre controle de qualidade de software e ferramentas de teste, www.softwareqatest.com/
qattls1.html.
NUnit, Estrutura de teste unitário para linguagens .NET, http://nunit.org/

index.php.
Ferramentas de teste de software de código aberto, notícias e discussões.

www.opensourcetesting.org/.
RpgUnit, Estrutura de teste de regressão de RPG, www.RPGunit.org.
Selenium, sistema de teste de aplicativos da Web, http://selenium.openqa.org.
soapUI, ferramenta de teste de serviços da Web, www.soapui.org.
Gerenciamento de configuração de origem, http://better-scm.berlios.de.
Subversion, sistema de controle de versão de código aberto, http://subversion.tigris.org/.
Estruturas de testes unitários. http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks.
Watir, Teste de aplicativos da Web em Ruby, http://wtr.rubyforge.org, http://

watircraft. com.
ÍNDICE
Princípios ágeis. Consulte Princípios, para agilidade

Uma ferramenta de teste Abbot testadores
GUI, 127 testes de aceitação. Veja também testes voltados para negócios Testadores ágeis. Veja também Testadores
definição, 501 mentalidade de teste ágil, 482–483
Exemplo de sistema de monitoramento remoto de dados, definição, 4 dar
245 peso igual a todos os membros da equipe, 31
UAT (teste de aceitação do usuário) em comparação contratações, 67–
com 130 69 o que eles são, 19–20
Testes ad hoc, 198 definição de
Adaptabilidade, habilidades e, 39–40 teste ágil, 6
ADEPT (Monitores AS400 para Externos como mentalidade, 20–
Prototipagem e Teste), 117–118 21 o que queremos dizer,
Clientes com maior 4 –7 valores Agile, 3–
clareza falando em uma só voz, 4 FIT IssueTrack da Alcea, 84
373–374 testes Alpha, 466–467 ant,
determinar o tamanho da história, 375– 284 como
376 reunir todos os pontos de vista sobre os ferramenta de
requisitos, 374–375 visão geral construção, 126 compilações contínuas
de, 140–142, 373 Desvantagens e, 175, 291
da preparação antecipada AnthillPro, 126 ANTS Profiler
de, 373 quanto é Pro, 234 Apache JMeter. Consulte
necessário, 372–373 Desenvolvimento ferramentas de teste funcional da camada API
ágil Manifesto ágil e, 3–4 JMeter, 168–170 Fit e FitNesse,
barreiras para. Consulte Barreiras 168–170 visão geral
para adotar a orientação da equipe de desenvolvimento de, 168 testes de serviços da
ágil de, 6 Agile web, 170
Estimating and Planning automação de testes
(Cohn), 331, 332 Manifesto ágil foco nas pessoas, 30 declaração de API, 282 visão geral de,
de, 4 declarações de 205–206 APIs (interfaces de programação de aplicativos),
valor em, 21 501
Appleton, Brad, 124

Aplicativo em teste (AUT), 246
509
510 ÍNDICE
Teste de curva de aprendizado, 266–267

integração de aplicativos com aplicativos externos, código legado e, 269
459 capacidade de manutenção e, 227–228
Exemplo de sistema de monitoramento remoto de dados, testes manuais vs., 258–259
242–243 obstáculos para, 264–265
Abordagem velhos hábitos e, 270
incremental de arquitetura para testes, 114 visão geral de, 255
camadas, 116 atitude dos programadores em relação a,
testes do quadrante 1 e, 99 265–266
escalabilidade e, 104, 221 razões para, 257–258

testáveis, 30, 115, 182, 184, 267 responder à mudança e, 29
monitores AS400 para prototipagem e testes externos ROI e, 264
(ADEPT), 117–118 suposições, cartões de tarefas e, 394–395
ocultas resposta dos testabilidade e, 149–150 testes
testadores ágeis, 25 falhas para como documentação, 263–264
detectar, 32 perguntas Estratégia de automação,
que revelam, 136 cenários de pior práticas de codificação ágil e, 303–304 aplicação
caso e, 334 mentalidade de teste ágil de uma ferramenta por vez, 312–313 ferramentas
de atitude, de geração de dados, 304–305 acesso a
482-483 barreiras para a adoção do banco de dados e, 306–310 design e
desenvolvimento ágil, 48 versus habilidades, 20 manutenção e, 292–294 desenvolvimento, 288–
auditorias, 289 identificação de
conformidade com auditoria requisitos, requisitos de ferramentas , 311–312 implementação,
89–90 316–319 abordagem iterativa,
AUT (aplicativo em teste), 143, 225, 246, 299–300 manter a simplicidade, 298–
317 299 aprender fazendo, 303
Autorização, testes de segurança e, 224 gerenciar testes automatizados,
Principais fatores de sucesso do teste 319 abordagem multicamadas para, 290–
de regressão automatizado, 292 organizar resultados de testes, 322–324
484 candidatos a lançamento e 458 organizar testes , 319–322 visão geral de,
como rede de segurança, 261–262 273 princípios, 298 ferramentas
Listas de testes automatizados, alternativas de planos de testes, de gravação/
353–354 reprodução e, 294,
Fluxo de código 296–297 começando com a área de maior dor,
de automação e, 269 de
implantação, 232 289–290
impulsionando o desenvolvimento com, 262– dedicar tempo para fazer tudo certo, 301–303
263 de testes exploratórios, 201 pirâmide de automação de testes, 276–279
medo de, 269–270 categorias de testes, 274–276
feedback de, 262 seleção de ferramentas, 294–298, 313–316
liberando pessoas para outro trabalho, 259–261 de compreender o propósito dos testes e, 310–311 o que pode
estrutura de teste funcional, 245–247 casa - ser automatizado, 279–285 o que pode ser
teste fabricado, 175 difícil de automatizar,
investimento necessário, 267–268 287–288
ÍNDICE 511
o que não deve ser automatizado, 285–287 abordagem fatores-chave de sucesso, 490–491
de toda a equipe, 300–301 perigo de esquecimento, 148
Ferramentas de automação, 164–177 testes de regressão e 434
Ferramentas de teste funcional da camada API, 168– Bolton, Miguel, 195
170 compilações e 126 Chefe, Erik, 114
Ferramentas de teste de GUI, visão Condições limite
geral 170–176 de, 164–165 Testes de API e, 205
ferramentas de teste em nível de unidade, automação e, 11
165–168 ferramenta de teste de serviços da web, 170 ferramentas de geração de dados e, 304
identificando variações de teste, 410
B escrevendo casos de teste para, 137
Bach, James, 195, 200, 212 Boyer, Erika, 140, 163, 372, 432
Bach, Jônatas, 201 Automação de
Teste de back-end por brainstorming proporcionando melhor trabalho aos testadores,
trás da GUI, 282 testes não 260
UI, 204–205 antes da iteração, 370, 381

Bambu, 126 quadrantes como estrutura para, 253 tempo
Barreiras à adoção do desenvolvimento ágil, 44–49 funções para, 301 testadores, 121
conflitantes ou múltiplas, 45 diferenças técnica de
culturais entre funções, 48–49 falta de treinamento, 45 linha de base de teste de quebra, 363
falta de compreensão dos navegadores, testes de compatibilidade e, 230 limites
conceitos ágeis, de orçamento, 55
45–48 rastreamento de bugs. Consulte Bugs de
perda de identidade, 44-45 rastreamento de
visão geral de, 44 defeitos.
experiências e atitudes passadas, 48 Consulte Automação de

Técnica de compilação de defeitos, 280–282 compilações candidatas
linha de base do teste de quebra de linhas de a lançamento
base, desempenho 363, 235–237 desafiadoras, 473 definição,

Arquivos 501 incremental, 178–179
em lote, aceleração, 118–119 Ferramentas de
processamento 251, automação de compilação, 126, 282 Padrão de

processo de agendamento 345, 182 construção/operação/
BDD (desenvolvimento orientado a comportamento) verificação, 180
ferramenta easyb, 166–168 Ferramentas de compilação,

ferramentas para testes do quadrante 1, 127 126 BuildBeat, 126 Analistas de negócios, 374 função de especialista em negóc
Beck, Kent, 26, 99 acordo sobre requisitos, 428,
Benandro, Marcos, 51 430
Avaliação comparativa, 237 linguagem comum e, 134, 291, 414 na equipe do

Berczuk, Stephen, 124 cliente, demonstração de 6–7
Teste beta, 466–467 iterações e, 443 linguagem de,
Os testadores 291
ágeis de visão geral se Poder de Três e 482 ferramentas
concentram em 23 testes e exemplos de alto nível, 397–402 voltadas para 134

512 ÍNDICE
Testes voltados para Valor comercial
negócios, testes ágeis agregando valor, 31–33

como, 6 quadrantes 2 e 3, 97– como meta de desenvolvimento ágil, 5–8, 69, 454
98 testes voltados para tecnologia em comparação com, métricas e, 75 ciclos
120 testes voltados para negócios, criticando o produto de lançamento e, 3
(Quadrante 3), 189–215 testes função, função, padrão de valor de negócios, 155
de aceitação, 245 testes abordagem de equipe e, 16
de API, 205– 206 Busse, Mike, 106, 235, 284, 313
demonstrações, 191–192 Buwalda, Hans, 193
ferramentas de emulador, 213–
214 testes ponta a ponta, 249– C
250 testes exploratórios, 195–202, 248–249 Dados canônicos, automatizando bancos de dados e,
geração de dados de teste, 212 308–309
testes de GUI, 204 Canoo WebTest
ferramentas de monitoramento, automatizando testes de GUI, 184, 186

212–213 visão geral de, Conjunto de testes de regressão GUI, 291
189–191 relatórios, Testes de fumaça GUI, 300
208–210 testes de cenário, 192– Ferramentas de teste GUI, 174–
195 testes baseados em sessão, 200– 175 testes de organização e,
201 testes de configuração, 211– 320 scripts e, 320
212 ferramentas de Editor XML para, 125
simulador, 213 ferramentas para testes Integração do modelo de maturidade de capacidade
exploratórios, 210–211 testes de (CMMI), 90-91
usabilidade, 202–204 testes de Ferramenta de captura-reprodução, 267
aceitação do usuário , 250 documentação Comemorando os sucessos,
do usuário, 207–208 testes de implementação de mudança e conclusão da
serviços web, 207 testes voltados para negócios, iteração 50–52 e 449–451
equipe de suporte (Quadrante Chandra, Apurva, 377
2), 129–151 clareza avançada, Chang, Tae, 53-54
140–142 testes funcionais automatizados, 245– Mudança
247 linguagem comum e, 134–135 celebrando sucessos, 50–52 dando
condições de satisfação e, 142–143 conclusão, 146– propriedade à equipe, 50
147 impulsionando o introduzindo, 49 não
desenvolvimento com, 129–132 elicitando sendo fácil, 56–57 capacidade
requisitos, 135–140 testes incorporados, de resposta, 28–29 falando
248 abordagem incremental, sobre medos, 49–50
144–146 dilemas de requisitos e, 132– Listas de
134 efeitos em cascata, 143–144 mitigação de verificação de prontidão

riscos e , 147–149 testabilidade para liberação, 474 ferramentas para obter exemplos e requisitos,
e automação, 149–150 kit de 156
ferramentas para. Consulte Teste de serviços IC. Consulte Integração contínua (CI)
da Web do Toolkit (Quadrante 2), 247–248 Fábrica de CI, 126
Impacto nos negócios, 475–476 CMMI (Integração de Modelo de Maturidade
de Capacidade), 90–91
ÍNDICE 513
Co-localização, logística da equipe e, 65-66 com programadores, 413–414

Coaches abordagem de equipe inteira, 15–16
se ajustando à cultura ágil e, 40 curva de Collino, Alessandro, 103, 363
aprendizado e, 266 fornecendo Comunicação
incentivo, 69 desenvolvimento de linguagem comum e, 134–135 com o
habilidades e, 122 treinamento e, cliente, 140, 396–397
45–46 DTS (Sistema de Rastreamento de Defeitos) e,
Cockburn, Alistair, 115 83 facilitando, 23–25, 429–432
entrega de produtos e, 462–463
Automação de código e fluxo de código, tamanho como desafio para, 42–
269 automação e código legado, 269 43 entre equipes, 69–70
estratégia de automação e, 303–304 resultados de testes, 357–358
documentação de, 251 Comparações, automação, 283
padrões, 227 Teste de compatibilidade, 229–230
escrita testável, 115 Automatização de
Cobertura de código, métricas de lançamento, 360–364 testes de
Codificação e testes, 405–441 componentes,
adicionando complexidade, definição 282, função de suporte 501, 5
407 alternativas para lidar com bugs, 424–428 Condições de satisfação, testes
escolhendo quando corrigir bugs, 421–423 voltados para os negócios e, definição 142–
colaborando com programadores, 413–414 lidando 143, 501–502
com bugs, 416–419 decidindo quais Definição de teste orientado
bugs registrar, 420 –421 impulsionando o ao contexto, 502
desenvolvimento e, 406 facilitando a quadrantes e 106–107
comunicação, 429–432 focando em uma história, Processo de construção contínuo
411–412 identificando variações, 410 notificação de falha e, 112 feedback
métricas de iteração, 435–440 e, 119
mídia para registrar bugs, 423– Testes FitNesse e, 357
424 visão geral de, 405 implementação, 114
ferramentas de integração com, 175,
Poder de Três para resolver diferenças de ponto de 311 controle de código-fonte e, 124,
vista, 411 testes o que os testadores podem fazer, 121
de regressão e, 432–434 recursos, 434– Princípio de feedback contínuo, 22
435 avaliação de risco, Princípio de melhoria contínua, 27–28
407–409 como processo Automação de integração contínua
simultâneo, 409–410, (CI), 280–282 como prática
488–489 principal, 486–487 instalabilidade
começando de forma simples, 406, e, 231–232
428–429 conversando com clientes, Exemplo de sistema de monitoramento remoto de dados,
414–415 testes que criticam o produto, 412–413 244 testes em execução e, 111–112
Cohn, Mike, 50, 155, 276, 296, 331, 332 Conversão, migração de dados e, 460–461
Colaboração com Práticas básicas
clientes, 396–397 fatores-chave de codificação e teste como um processo, 488–489
de sucesso, 489–490 integração contínua, 486–487
514 ÍNDICE
Práticas básicas, continuação relacionamento com, 41–42

abordagem incremental, 488 visão revisando testes de alto nível com, 400 falando
geral de, 486 sinergia em uma só voz, 373–374
entre práticas, 489 gerenciamento CVS, controle de código-fonte e, 124
técnico de dívidas, 487–488 ambientes de teste,
487 Coragem, princípios, 25– D
26, 71 Credibilidade, construção, 57 Dados
Criticando o negócio do produto automatização de criação ou configuração, limpeza

enfrentando testes. Consulte 284–285,
Testes voltados para negócios, criticando os testes voltados conversão 461,
para tecnologia do produto (Quadrante 3). Veja planejamento de lançamento
testes voltados para a tecnologia, 459–461 e, 348 escrita de cartões de tarefas e, 392
criticando o produto (Quadrante 4) Testes baseados em dados, 182–183
Feeds de dados, testes, 249

CrossCheck, testando Web Services, 170 Ferramentas de geração de dados, 304–305
CruiseControl, 126, 244, 291 Mudança Migração de dados, automação, 310, 460
cultural, 37. Consulte também Organizações Cunningham, Bancos de
Ward, 106, 168, 506 Expectativas do cliente, dados evitando acesso durante a execução de testes, 306–
impacto nos negócios e, 475– 310 dados canônicos e automação, 308–309
476 suporte à produção, 475 capacidade de manutenção e
228 entrega e atualizações de produtos, 459–461
Teste voltado para o cliente. Consulte testes voltados para dados e automação semelhantes à produção,
negócios Suporte ao cliente, DTS (Defect Tracking 309–310
System) e 82 configurar/destruir dados para cada teste

Equipe do cliente automatizado, 307–308
definição, 502 testando migração de dados, 310
interação entre equipes de clientes e desenvolvedores, 8 De Souza, Ken, 223
visão geral Prazos, escopo e, 340–341
de, 7 Visão geral das
Teste do cliente métricas de defeito, métricas

Teste Alfa/Beta, definição 466–467, de versão 437–440, 364–366
visão geral 502 de, Rastreamento de defeitos, 79–
464 86 DTS (Sistema de Rastreamento de Defeitos), 79–
UAT (teste de aceitação do usuário), 464–466 83 mantendo o foco e, 85–86 visão
Clientes geral de, 79 razões
colaborando com, 396–397, 489–490 considerando para, 79 ferramentas
todos os pontos de vista durante o planejamento da para, 83–85 Sistema
iteração, 388–389 de Rastreamento de Defeitos. Consulte DTS (Sistema de

entregando valor para, 22–23 Rastreamento de Defeitos)
importância da comunicação com, 140, 414–415, 444
demonstração de Alternativas de defeitos para lidar com bugs,
iteração, 191–192, 443–444 participação no 424–428
planejamento de iteração, 384–385 escolhendo quando corrigir bugs, 421–423

ÍNDICE 515
lidar com bugs, 416–419 decidir quais Casos de teste detalhados
bugs registrar, 420–421 mídia para registrar bugs, arte e ciência da escrita, 178 abordagem
423–424 métricas e, 79 geral e, 148–149 design com, 401
TDD (desenvolvimento orientado a testes) e, 490 escrever Interação da equipe

cartões de tarefas e, 391–392 tolerância de desenvolvedores entre clientes e equipes de
zero a bugs, 79, 418–419 desenvolvedores, 8 visão

Entregáveis geral de, 7–8
entregas de “ajuste e acabamento”, 454 Desenvolvimento
não software, 470 visão desenvolvimento ágil, 3–4, 6
geral de, 468–470 condução de testes automatizados, 262–263
Entregando produto condução de testes voltados para negócios,
Testes Alfa/Beta, 466–467 impacto nos 129–132
negócios e 475–476 comunicação e 462– condução de codificação,

463 expectativas do cliente, 475 testes 406 ciclos de testes pós-desenvolvimento,
com clientes, 464 conversão de dados 467–468
e atualizações de banco de Picos de desenvolvimento, 381

dados, 459–461 resultados finais, 468–470 jogo final, 456–457 Equipe de desenvolvimento, ferramenta
instalação testes, 461–462 de comparação 502, 283
integração com aplicativos Equipes distribuídas, 431–432
externos, 459 testes não funcionais e sistemas de rastreamento de defeitos e

458–459 visão geral de, 453 empacotamento, 474–475 82 logística física, 66 testes
tempo de planejamento para testes, 455–456 on-line de alto nível para, 399 storyboards
ciclos de testes pós- on-line para, 357 respostas a
desenvolvimento, 467–468 mudanças, 29 ferramentas
suporte à produção, 475 aceitação de baseadas em software para obter exemplos e requisitos e,
lançamento critérios, 470–473 gerenciamento de 163–164
liberação, 470, 474 lançamento Documentação de
de produto, 470 ambiente de teste e 458 testes testes automatizados como fonte de, 263–264
de candidatos a lançamento, 458 problemas e correções, 417

relatórios, 208–210 de
código de teste, 251
testes como,
UAT (teste de aceitação do usuário), 464–466 e se 402 documentação do usuário, 207–208
não estiver pronto, 463–464 o que torna Cozimento
um produto, 453–455 saber quando uma história está pronta, 104–105

Demonstrações/demonstrações multicamadas, 471–472
de uma iteração, 443–444 valor Impulsionando o desenvolvimento com testes. Veja TDD
para os clientes, 191–192 (desenvolvimento orientado a testes)
Implantação, automação, 280–282 DTS (Sistema de Rastreamento de Defeitos), 80–83
Estratégia benefícios de, 80–82
de automação de projeto e, 292–294 projeto escolha de mídia para registrar bugs, 424
com testes em mente, 115–118 documentação de problemas e correções, 417
516 ÍNDICE
DTS (Sistema de Rastreamento de Defeitos), continuação Testes executáveis, 406

registrando bugs e, 420 Atividades, características e
motivos para não usar, 82–83 habilidades de teste exploratório (TE) (Hagar),
Dymond, Robin, xxx 198–200
Análise dinâmica, ferramentas de teste de segurança, 225 atributos do testador exploratório,

201–202
automação de, 201
Ferramenta de desenvolvimento orientada por comportamento E easyb, 165–168 definição, 502–503 jogo
EasyMock, 127 final e, 457 explicado
Eclipse, 125, 316 (Bolton), 195–198 testes manuais e,
Casos 280 ferramentas de
extremos identificando variações, monitoramento, 212 visão
410 sem tempo para isso, 112 geral de, 26, 195
começando simples e depois adicionando complexidade, Exemplo de sistema de monitoramento remoto de dados,
406–407 248–249
casos de teste para, testes baseados em sessão e, 200–201
137 sistema embarcado, exemplo de monitoramento remoto configuração, 211–
de dados, 248 212 simuladores e emuladores, 212–213 testes
capacitação, de equipes, 44 que criticam o produto, 412–413 ferramentas para,
ferramentas de emulador, 213– 210–212 ferramentas
214 testes para geração de dados de teste, 212 o que
ágeis de jogo final, não deve ser automatizado, 286 Qualidade
91 iteração, 14 externa, definição de testes voltados para negócios, 99.131
entrega de produto e, 456–457 equipes
lançamento e, 327 externas, 43.457 Extreme
ponta a ponta testes finais, 249– Programming. Veja XP (Programação Extrema)
250 Prazer, princípio de, 31
Ambiente, ambiente de teste, 347–348 Épico. Consulte Programação Extrema Explicada (Beck),
também definição de temas, 26
502 recursos
tornando-se, 502 iterações em, F
76, 329 planejamento, 252 Comunicação cara a cara, 23–25
ePlan Services, Testes de failover, 232
Inc., xli, 267 Erros, teste manual e, Fracasso, coragem para aprender, 25
259 Estimando o tamanho da história, Objetos falsos, 115, 118, 306, 502–503
332–338 eValid, 234 Padrões baseados Tolerância a falhas, entrega do produto e, 459
em eventos, Temer
padrões de design de teste, 181 Everyday Scripting with Ruby barreiras à automação, 269–270 mudanças
for Teams, Testers, and You (Marick), 297, 303 Desenvolvimento e, 49–50
orientado a exemplos, 378–380 Mudança Destemida (Manns and Rising), 121
Exemplos para elicitar requisitos, 136–137 Penas, Michael, 117, 288
ferramentas Características
para elicitar exemplos e requisitos, defeitos vs., definição 417–

418, 502–503 com foco
155–156 no valor, 341
ÍNDICE 517
Fornecendo testando a camada de banco de dados

testes automatizados de feedback, 262 com 284 histórias de
princípios de feedback contínuo, 22 testes, 395 requisitos de rastreabilidade e
abordagens iterativas e 299–300 fatores- 88 testes de aceitação do usuário,
chave de sucesso, 484–486 testes 295 wikis e 186
de gerenciamento para, 323–324 Carne, Patrick, 377, 440
Testes do quadrante 1 e, 118–119 Teste de cenário
Entregáveis de “ajuste e acabamento”, 454 de diagramas de fluxo e 194–195
Fit (Estrutura para Teste Integrado), ferramentas para obter exemplos e requisitos,
134–135 160–163
Ferramentas de teste funcional da camada API, Fowler, Martin, 117

pirâmide de testes de automação 168–169 e 278 Estrutura para Teste Integrado. Consulte Fit
FIT IssueTrack, Alcea, 83–84 (Estrutura para Teste Integrado)
Vantagens Frameworks, 90–93 ftptt,
do FitNesse, 163 234 analistas
Ferramentas de teste funcional da camada API, 169– funcionais, 386 problemas de
170 automatizando testes funcionais com, 30, compatibilidade de
145 testes funcionais e, 230 definição,
testes voltados para negócios com, 154, 178 502–503 testes ponta a
colaboração e, 164 ponta, 249–250 camadas, 246
compilações contínuas e, 119, 357 testes não
verificação de dados com, 287 funcionais comparados com, 225 exemplo de sistema
doçura e, 472 incentivo de monitoramento remoto de dados,
ao uso de, 122 exemplos e, 245–247
136, 169 feedback e, 323-324

regras de análise de arquivo G
ilustradas com, 205 testes funcionais por trás da Galeno, Bob, 455–456, 471
GUI, 291, Gärtner, Markus, 395, 476
300 Equipes geograficamente dispersas
scripts desenvolvidos internamente e, lidando com, 376–378
305 JUnit em comparação com, facilitando a comunicação e,
299 palavras-chave ou palavras de ações para 431–432
automatizar testes, Gheorghiu, Grig, 225–226, 234
182–183 testes manuais vs. automatizados, Glover, André, 166
210 demandas de memória de, Teste de código de
306 testes de organização e, 319–320 projetos Greenfield e,
visão geral de, 168–170 definição 116, 502–503
testes remotos e, 432 lista Estratégia de automação GUI (interface
“iniciar, parar, continuar”, 446 suporte gráfica do usuário) e, 293 fluxo de
para ferramentas de controle de código-fonte, código e, 269 padrões,
320 227
pirâmide de automação de teste e, 278 Testes de fumaça GUI
cartões de teste e, 389–390 Canoo WebTest e, 300

casos de teste como documentação, 402 compilações contínuas e, 119
projeto e manutenção de teste, 292 métricas de defeitos, 437
518 ÍNDICE
Ferramentas de teste de GUI, 170–176 EU
Canoo Web Test, 174–175 IBM Rational ClearCase, 124

ferramentas de automação de teste “caseiras”, Definição de IDEs (ambientes de desenvolvimento
175 integrados), 502–503
ferramentas de teste de código aberto, ferramentas de análise de
visão geral 172 de, 170–171 log, 212 ferramentas para testes do quadrante
ferramentas de gravação/reprodução, 171–172 1, 124–126
Rubi com Watir, 172-174 testes de “ilidade” testes de
Selênio, 174 compatibilidade, 229–230 testes de
Teste de GUI instalabilidade, 231–232 testes de
Teste de API, 205–206 interoperabilidade, 228–229 testes de
automação, 282–283, 295–296 pirâmide manutenção, 227–228 testes de confiabilidade,
de teste de automação e, 278 230–231, 250–251 testes de segurança, 223–227
Testes de fumaça da GUI, 119, 300, Impacto, em todo o sistema, 342
437 visão geral de, 204 Implementando Desenvolvimento Lean de Software: De
Teste de serviço da Web, 207 Conceito para dinheiro (Poppendieck), 74, 416
Abordagem de
H melhoria para melhoria de processos, 448–449 princípio
Agar, João, 198 de melhoria contínua, 27–28 ideias para melhoria a
partir de retrospectivas,
Compatibilidade de hardware 447–449
e, 229 custos de ambientes de teste, Desenvolvimento incremental
487 testes funcionais e, 230 construindo testes de forma incremental, 178–
investimentos em automação e, 267 179 como prática central,
ambiente de produção e, 310 escalabilidade 488 testes de “ilidades” e,
e, 233 infraestrutura de 232 fatias finas, pequenos pedaços, 144–
teste, 319 testes de instalação 146 testes tradicionais versus ágeis, 12–13
de produtos, 462 Cartões de índice, registro de bugs, 423
Hendrickson, Elisabeth, 203, 315–316 A infraestrutura
Casos de teste de alto nível, 397–402 Testes do quadrante 1,

modelos, 398–399 visão infraestrutura de teste 111–
geral de, 397–398 revisão 112, planos de teste 319 e
com clientes, 400 revisão com testes de instalabilidade 346–347,
programadores, testes de instalação 231–232,
400–401 ambientes de desenvolvimento integrado 461–462.
casos de teste como documentação, 402 Consulte IDEs (ambientes de
Contratação de um testador, 67-69 desenvolvimento integrados)
Holzer, Jason, 220, 448 Interoperabilidade de
Ferramenta de teste caseira testes de integração e, 229
ferramentas de automação, 314 produtos e aplicativos externos, 459 IntelliJ IDEA,
Ferramentas de teste GUI, 125 Qualidade interna
175 resultados de medindo a qualidade
teste, 323 httperf, 234 interna do código, 99 atendendo aos padrões da
Hudson, 126 equipe, 366
ÍNDICE 519
Testes do quadrante 1 e, ITIL (Infraestrutura de Tecnologia da Informação

velocidade 111 e, 112 Biblioteca), 90-91
Teste de interoperabilidade, 228–229
Investimento, necessidade de automação, J.
267–268 JComporte-se, 165

Estratégia JConsole, 234
de automação de iteração e definição 299– Testes
300, demonstração 502– de linha de base de desempenho JMeter,
503, vida útil de um 235 testes de desempenho, 223, 234, 313
testador 443–444 e 327 Definição de JMS (Java Messaging
atividades de pré-iteração. Consulte Atividades de pré- Service), integração 502–
iteração 503 com aplicativos externos e,
priorizando histórias e, 338 revisão, 243
415, 435–437 testes testando feeds de dados e, 249

tradicionais versus ágeis, 12–13 Início da JProfiler, 234
iteração, 383–403 colaboração JUnit
com clientes, 396–397 considerando todos os pontos FitNesse como alternativa para TDD, 299 testes
de vista, 385–389 controlando a carga de funcionais, 176 ferramentas

trabalho, 393 testes e exemplos de de teste de carga, 234–235
alto nível, 397–402 planejamento de iteração, 383– ferramentas de teste de unidade, 126,
384 detalhes do projeto de 165, 291 JUnitPerf,

aprendizagem, 384–385 visão geral de, 383 234 desenvolvimento Just in time, 369. Consulte
histórias testáveis, também Pré - atividades de iteração
393–396 escrever cartões de
tarefas, 389–392 K
Métricas de iteração, 435–440 Principais fatores de

métricas de defeito, 437–440 sucesso mentalidade de teste ágil, 482–
medindo o progresso com, 435–437 visão 483 automação de testes de regressão, 484
geral de, 435 utilidade abordagem geral, 490–491 codificação e
de, 439–440 teste como um processo, 488–489 colaboração com
Planejamento de iteração clientes, 489–490 integração contínua (CI), 486–487
considerando todos os pontos de vista, 385–389 feedback, 484–486 base de práticas básicas, 486
controlando a carga de trabalho, abordagem incremental
393 aprendendo detalhes do projeto, 384– (fatias finas, pequenos pedaços), 488 visão
385 visão geral de, 383–384 geral de, 481 sinergia entre práticas, 489 gerenciamento
escrevendo cartões de tarefas, 389–392 técnico de
Reunião de revisão de iteração, 415 dívidas, 487–488
Conclusão da iteração, 443–451 ambientes de teste, 487 abordagem de
celebrando sucessos, 449–451 equipe inteira, 482
demonstração de iteração, 443–444
ideias para melhoria, 447–449 retrospectivas,
444–445 exercício “iniciar, Testes baseados em palavras-chave, 182–183
parar, continuar” para retrospectivas, 445–447 Rei, José, 176

Base de conhecimento, ETED, 80–81
520 ÍNDICE
Kohl, Jonathan, 201, 204, 211 Automação de

Rei, Dierk, 320 teste manual vs., 258–259
perigo de, 289
eu
Marcano, Antony, 83, 426
Linguagem, necessidade de comum, 134-135 Marick, Brian, 5, 24, 97, 134, 170, 203, 303 Martin,
Arquitetura em camadas, 116 Micah, 169 Martin,
Medições enxutas, métricas, 74–75 Robert C., 169 Matrizes
Estratégia testes de
de automação de aprendizagem e alto nível e, 398–399 matrizes de
princípio de melhoria contínua 303, 27 texto, 350–353 Maven, 126
Curva de aprendizado, automação e, 266–267, 303 McMahon,
Código legado, 269 Chris, 260 Tempo médio
Resgate de código legado (Feathers), 117 entre falhas, testes de confiabilidade,
Sistemas legados 230
ccde, 269 Tempo médio até falha, testes de confiabilidade, 230
definição, 502–503 Mídia, para registrar bugs, 423–424
registro de bugs e, 421
testes, 117 Demonstrações de reuniões, 71,
Lições aprendidas em testes de software (Pettichord), 192 geograficamente dispersas, 376
485 início de iteração, 372
Sessões de lições aprendidas, 383. Consulte planejamento de iteração, 23–24, 244, 331, 384, 389
também revisão de iteração, 71, 415
Retrospectivas Processos leves, pré-planejamento, 370–372
73–74 Planos de testes leves, planejamento de lançamento,
350 Testes de carga. Consulte Testes de desempenho e 338, 345 retrospectiva,
carga LoadRunner, 447 agendamento,
234 LoadTest, 70 processo de dimensionamento
234 Logística, física, 65–66 e, 336–337 em pé, 177,
Ferramenta LogWatch, 429, 462 participação da equipe
212 Perda de identidade, medo das equipes de e, 32 planejamento de teste, 263
controle de qualidade, 44–45 Louvion, Christophe, 63 Vazamentos de memória, 237–238
Teste de gerenciamento de memória, 237–238
M Meszaros, Gerald, 99, 111, 113, 138, 146, 182, 204,
Teste de manutenibilidade, 227–228 291, 296, 430
Gestão, 52–55 clareza Métricas, cobertura
avançada e, 373–374 mudança de código 74–79, comunicação
cultural e, 52–54 visão geral de, 360–364 de, 77–78 métricas de
52 fornecimento defeito, 364–366, 437–440 métricas de
de métricas para, 440 iteração, 435–440 justificando o
Mudanças investimento em automação, 268 medições
culturais dos gerentes, 52–54 enxutas, 74–75 visão geral de,
como influenciar os testes, 122–123 falar 74 aprovação
a língua do gerente, 55 testes, 358–360 razões
Manns, Mary Lynn, 121–122 para rastrear defeitos, 52, 75–77, 82
ÍNDICE 521
métricas de lançamento, 358 Nessus, scanner de vulnerabilidade, 226 .NET

ROI e, 78–79 o que Memory Profiler, 234 NetBeans, 125
não fazer, 77 NetScout, 235
Gráficos de radar XP, 47–48 testes não
Marcos, celebrando sucessos, 449–450 funcionais. Consulte também testes

MIME (correio multiuso da Internet voltados para a tecnologia, criticando o produto
Extensões), (Quadrante 4) entrega do
504 testando feeds produto e, 458–459 testes funcionais
de dados e, 249 comparados com, 225 requisitos, 218–219 quando
Mapas mentais, 156-158 executar, 222 Norte, Dan, 165
Pense nos NSpec, 165 NUnit, 126, 165
testes ágeis como, 20–21
fatores-chave de sucesso, 482–483
pró-ativos, 369–370
Fenômeno “mini-cachoeira”, 46–47
Definição de O
objetos simulados, Oleszkiewicz, Jakub, 418

504 alívio de risco e 459 Testes únicos, 286–287
ferramentas para implementação, 127 Ferramentas de código aberto
testes unitários e 114 ferramentas ágeis de teste de código aberto,

Maquetes automação 172–175 e 314–315
facilitando a comunicação e 430 testes de alto Ferramentas de teste de GUI, 172
nível e 398–399 histórias e 380 IDEs, 124–125

ferramentas para OpenWebLoad, 234
obter exemplos e requisitos, Sistemas operacionais (SOs), testes de compatibilidade e, 230
160
Desenvolvimento orientado por modelo, 398 Organizações, 37–44

Modelos desafios de desenvolvimento ágil, 35 culturas
de qualidade, 90–93 conflitantes, 43 relacionamentos
Exemplo de modelagem de UI, 399 com clientes e, 41–42 visão geral de, 37–38
Ferramentas de monitoramento, 212–213, 235 filosofia de qualidade, 38–
Abordagem multicamadas, estratégia de automação, 40 tamanho e, 42–43 ritmo

290–292 sustentável de testes
Extensões multifuncionais de correio da Internet e, 40–41 equipe empoderamento, 44
(MIME),
504 testando feeds SOs (sistemas operacionais), testes de compatibilidade e, 230
de dados e, 249
Propriedade, dando propriedade à equipe, 50
N
Convenções de nomenclatura, 227 P
Nantes, 126 Embalagem, entrega do produto e, 474–475

Navegação, testes de usabilidade e, 204 Revisão de código de
Comporte-se, 165 programação em pares e
NeoLoad, 234 227 desenvolvedores treinados, 61
522 ÍNDICE
Programação em pares, IDEs Poder dos Três

continuados e, especialista em negócios e,
abordagem de equipe 125 e, 482 encontrar uma linguagem comum,
244 testes em 430 boa comunicação e, 33.490 resolução
pares, 413 testes de aprovação, métricas de de problemas e, 24 resolver
lançamento, diferenças de ponto de vista, 401, 411 abordagem de
358–360 toda a equipe e, 482
PerfMon, 235 Perforce, 124 Automação Pragmática de Projetos, 260
automação de testes Atividades de pré-iteração, 369–382
de desempenho e clareza antecipada, 373
carga, 283 linhas de base, 235–237 testes de benefícios de trabalhar em histórias antecipadamente,
gerenciamento de 370–372
memória, 237– 238 visão geral clientes falando a uma só voz, 373–374 determinando
de, 234 entrega de produto e, o tamanho da história, 375–376
458 testes de escalabilidade, avaliando a quantidade de preparação antecipada
233–234 ambiente de necessária, 372–373
teste, 237 ferramentas exemplos, 378–380
para, 234–235 quando executar, 223 reunindo todos os pontos de vista sobre
quem realiza o teste, 220–221 os requisitos, 374–375
equipe geograficamente dispersa e,
Desempenho, recompensas e, 70–71 376–378
Perigos de esquecer o panorama visão geral de 369

geral, 148 mentalidade priorização de defeitos, 381
policial de qualidade, 39 a crise de mentalidade pró-ativa, 369–370
testes, 416 aguardando a construção de terça- recursos, 381
feira, 280 você não faz realmente estratégias de teste e 380–381
parte da Reunião de pré-planejamento, 370–372
equipe, 32 Perkins, Steve, 156, Princípios, práticas de
159, 373 ferramentas de geração de automação de codificação ágil, 303–
dados PerlClip, 305 ferramentas 304 abordagem iterativa, 299–300
para geração de dados de teste, 212 manter a simplicidade, 298–
Teste de personalidade, 202–204 Pettichord, Bret, 299 aprender fazendo, 303
175, 264, 485 Desenvolvimento visão geral de, 298
faseado e reservar tempo para fazer certo, 301–303
fechado, 73– abordagem de toda a equipe, 300–301
74, 129 Logística física, 65–66 Avanço Princípios, para testadores ágeis
de planejamento, 43 iteração. Consulte Planejamento feedback contínuo, 22 melhoria
de lançamento/tema de contínua, 27–28 coragem, 25–26 entrega
planejamento de iteração. Consulte Teste de de valor ao cliente,
planejamento de 22–23 prazer, 31 comunicação face a face,
lançamento. Consulte PMO de planejamento de testes 23–25 mantendo
(Project Management Office), 440 Pols, a simplicidade, 26–27 visão geral de , 21–22
Andy, 134 padrão de portas
e adaptadores (Cockburn), 115 testes pós-desenvolvimento, 467–468 bugs pós-iteração, 421 Pounder, 234
ÍNDICE 523
foco nas pessoas, 30 treinamento, 61

receptivos às mudanças, 28–29 auto- cartões de tarefas de escrita e 391
organizados, 29–30 Priorizando Escritório de gerenciamento de projetos (PMO), 440
defeitos, 381 Priorizando histórias, projetos, exemplo PAS, 176–177 protótipos
338–340 Mentalidade proativa, 369– acessíveis
370 Valor comercial do produto, 31–33 como linguagem comum, 134 maquetes e 160 em
entrega. papel, 22, 138–139, 380,
Consulte Entrega de testes 400, Papel 414 vs. tipo Mágico de Oz, 275 UI
de produto que criticam (Q3 e Q4), 101–104 (interface do usuário), 107 Pulse, 126
o que torna um produto, 453–455 Proprietário do ferramenta de teste de unidade
produto PyUnit para
Python, 126
considerando todos os pontos de vista durante o planejamento
da iteração, 386–389 Q
definição, 504 Definição de QA (garantia de

planejamento da iteração e, 384 qualidade), 504 em
Funções do Scrum, 141, 373 cargos, 31 equipes
ferramentas voltadas para, 134 independentes de QA, 60
Produção intercambiáveis com “teste”, 59 abordagem
registrando bugs e, suporte de equipe inteira, 39 trabalhando
421, 475 em equipes tradicionais, 9 Quadrante 1.
Pirâmide de teste de Consulte Testes voltados para a tecnologia, equipe de
automação de código de produção e, 277–278 suporte ( Quadrante 1)
definição, 504 Quadrante 2. Consulte Testes voltados para negócios,
entregando valor para, 70 equipe de suporte (Quadrante 2)
programadores escrevendo, 48 Quadrante 3. Veja testes voltados para empresas, criticando o
controle de código fonte e, 434 produto (Quadrante 3)
sincronização com teste, 322 desenvolvimento Quadrante 4. Veja testes voltados para a tecnologia,
de teste primeiro e, 113 testes de suporte, criticando o produto (Quadrante 4)
303–304 Quadrantes
Dados semelhantes à produção, automatização de bancos categorias de teste de automação, 274–276

de dados e, 309–310 voltados para negócios (2º e 3º trimestre), 97–
Desenvolvimento profissional, 57 98 testes orientados ao contexto e, 106–108 crítica
Ferramentas de perfil, 234 do produto (3º e 4º trimestre), 104 gerenciamento de
Atitude dos dívida técnica, 106 visão geral de, 97–98
programadores em relação à automação, 265–266 como guia de planejamento,
testes gerais, 397 colaboração 490 propósito do teste e, 97

com, 413–414 considerando todos os resumo do quadrante 1, 99 resumo
pontos de vista durante o planejamento da iteração, 387– do quadrante 2, 99–100 resumo do
389 facilitando a quadrante 3, 101–102 resumo do
comunicação e, 429–430 revisando testes de alto nível quadrante 4, 102–104 responsabilidade
com, proporção testador-desenvolvedor de 400–401 , compartilhada e, 105–106 conclusão da
66–67 testadores em comparação com história e, 104–105
4, 5
524 ÍNDICE
Quadrantes, suporte contínuo Liberar candidatos
à equipe (1º e 2º trimestre), 100–101 tecnologia voltada compilações desafiadoras de release candidate,
(1º e 4º trimestre), 97–98 473
Papel do definição, 505
cliente de qualidade no estabelecimento de padrões de testes, 458

qualidade, 26 Cobertura de código
modelos, 90-93 filosofia organizacional em relação a, de métricas de liberação,

38–40 métricas de defeito 360–364,
Garantia da Qualidade. Consulte QA (garantia de qualidade) visão geral 364–366
Mentalidade policial de qualidade, 57 de, 358 testes aprovados, 358–360

perguntas, para obter requisitos, Notas de versão, 474
135–136 Planejamento de liberação, 329–367
visão geral de, 329
R priorização e, 338–340 propósito
Gráficos de radar, XP, 47–48 de, 330–331 escopo, 340–
Rasmusson, Jonathan, 11 344 dimensionamento
Estratégia de automação de e, 332–337 alternativas de
ferramentas de gravação/reprodução e, 294, 296–297 plano de teste, 350–354 planejamento de
Ferramentas de teste de GUI, 171–172 teste, 345–350 visibilidade e,
Teste de recuperação, 459 354 –366
Testes de redundância, 232 Visão geral dos testes
Reed, David, 171, 377 de confiabilidade de 230–231
Definição de Exemplo de sistema de monitoramento remoto de dados,

refatoração, 504 250–251
Suporte a IDEs, 124–126 Exemplo de sistema de monitoramento remoto de dados

Suíte de regressão, 434 testes de aceitação, 245
Testes de regressão, 432–434 aplicação, 242–243 aplicação
testes de regressão automatizados como rede de segurança, de quadrantes de teste, 252–253 estrutura
261–262 de teste funcional automatizado, 245–247
automatizando como fator de sucesso, 484

verificando o panorama geral, 434 documentação de código de teste,
definição, 504 testes 251 testes incorporados, 248
exploratórios e, 212 mantendo a testes ponta a ponta, 249–250
construção “verde”, 433 mantendo a testes exploratórios, 248–249 visão

construção rápida, 433–434 registrando bugs geral de, 242 testes
e, 420 suíte de regressão e, de confiabilidade, 250–251 relatórios

434 candidatos a lançamento e, de resultados de testes, 251
458 equipe e processo, 243–244 testes
Critérios de feeds de dados , 249 testes
de aceitação de lançamento, 470–473 unitários, 244–245 testes
jogo final, 327, 456–457 de aceitação do usuário, 250 serviços

gerenciamento, 474 web, 247–248
entrega do produto, 470 e se Membro remoto da equipe. Veja equipes geograficamente

não estiver pronto, 463–464 dispersas
ÍNDICE 525
Tarefas repetitivas, automação, 284 Rogers, Paulo, 242, 310, 388, 398
Automação de ROI (retorno sobre o
Documentação de relatórios e, 208–210 investimento) e, 264
Exemplo de sistema de monitoramento remoto de dados, definição, 505
251 medição enxuta e, 75 métricas e,
Repositório, 124 78–79 falando a linguagem
Abordagem de do gerente, 55
testes voltados para o negócio de requisitos, 130 Função, função, padrão de valor comercial, 155
documentação de, 402 coleta
de todos os pontos de vista sobre requisitos, Funções conflitantes ou múltiplas, 45
374–375 como elicitar, 135– diferenças culturais entre, 48–49 equipe do
140 não funcionais, 218–219 cliente, 7 equipe de
dilemas, 132–134 ferramentas desenvolvedores, 7–8
para elicitar exemplos e interação de, 8
requisitos, Unidade RPG, 118
155–156 Rspec, 165, 318
Recursos Teste Ruby::Unidade, 170
completando histórias e, 381 Teste funcional Ruby
contratando testador ágil, 67–69 com Watir, 247
visão geral de, 66 Teste de GUI, 285
proporção testador-desenvolvedor, 66– identificando defeitos com, 212
67 testes e, 434–435 palavras-chave ou palavras de ação para automatizar
Tempo de resposta testes, 182
API, 411 visão geral de, 172–174
testes de carga e 234–235 metas automação de teste com, 186
mensuráveis e 76 serviços da RubyMock, 127
web e 207 Regras, gerenciamento de bugs e, 425
Retrospectivas de
melhoria contínua e, 28 ideias para melhoria, S
447–449 planejamento de iteração e, 383 Testes de segurança,

visão geral de, 444–445 melhoria de 232 Santos, Rafael, 448
processo e, 90 exercícios Condições de satisfação. Consulte Condições de
de “iniciar, parar e continuar”, satisfação
Teste de escalabilidade, 233–234

445–447 Teste de cenário, 192–193
Retorno do investimento. Veja o ROI (retorno sobre o diagramas de fluxo e, 194–195 visão
investimento) geral de, 192–195 testes de
Recompensas, desempenho e, 70–71 novela, 193
Ferramentas de teste de unidade de cliente Escopo, 340–344
rico, 127 Rising, Linda, 121– definição de testes voltados para o negócio,
122 134 prazos e cronogramas e, 340–341 foco no
Análise de risco de risco, 198, 286, 290, 345– valor, 341–342 visão geral de, 340
346 avaliação de risco, 407–409 impacto em todo o
mitigação de teste, 147–149 sistema, 342
526 ÍNDICE
Escopo, planos de teste Responsabilidade compartilhada, 105–106

contínuos e, 345 Caixa de sapatos Shout-Out, 450
envolvimento de terceiros e, 342–344 “Mostre-me”, colaboração com programadores,

Aumento do escopo, 385, 412 413–414
Scripts Simplicidade,
que automatizam comparações, 283 como automação e, 298–299 codificação,
ferramentas de automação, 297 406 registro de
scripts de conversão, 461 bugs e, 428–429 princípio de “manter
ferramentas de geração de dados, a simplicidade”, 26–27 Ferramentas do simulador,
305 testes exploratórios e, 211–212 testes incorporados
Scrum e, 248 visão geral de, 213 Tamanho,
função de proprietário do produto, 141, 373 organizacional, 42–43
Exemplo de sistema de monitoramento remoto de dados, Dimensionamento de histórias, 332 –

244 337 exemplo de, 334–337 como
revisões de sprint, 444 fazer, 332–333 visão geral
Scrum Master de, 332 papel do
abordagem para melhoria de processos, 448–449 testador em, 333–334
dimensionamento de histórias e, 336– adaptabilidade de habilidades e,
337 redação de cartões de tarefas e, 391 39–40
SDD (desenvolvimento orientado a testes de história) vs. atitude, 20 princípio de

identificando variações, 410 visão melhoria contínua,
geral de, 262–263
desenvolvimento de teste primeiro e, 263 27
testes de serviços da web e, 170 quem realiza testes e, 220–221

Abordagem externa Pequenos pedaços, desenvolvimento incremental,
de testes de segurança dos invasores, 225 visão 144–146
geral de, 223–227 SABÃO
conhecimento especializado necessário para, 220 definição, 505 testes

Selênio de desempenho e, 223, 234
Ferramentas de teste GUI, 174– Testes de novela, 193
175 implementação de automação, 316–318 definição
ferramentas de código aberto, de soapUI, 505
163 automação de teste com, 186, 316 testes de desempenho e 223, 234 testes de
Auto-organização serviços da Web, 170–171
princípios, 29–30 Teste SOAT, 234
equipes auto-organizadas, 69 Ferramentas baseadas em software, 163
Teste baseado em sessão, 200–201 Padrões de gerenciamento de configuração de software:

Trabalho em equipe eficaz, integrações práticas
Automação de configuração, (Berczuk e Appleton), 124
284–285 testes exploratórios, 211–212 Jogos Finais de Software (Galen), 471
Recursos compartilhados Benefícios de controle de
acesso a, 43 código-fonte de, 255
especialistas como, 301 visão geral de, 123–124
tarefas de redação e, 390 ferramentas para, 124, 320

ÍNDICE 527
Conformidade com SOX, 469 estratégias de teste e, 380–381

Fale com uma só voz, clientes, 373–374 testáveis, 393–396
Especialização, 220-221 tratando bugs como, 425

Velocidade como meta, 112 gráficos de
Spikes, desenvolvimento e teste, 381 burndown de storyboards, 429
Planilhas, definição, 505–506
planilhas de teste, 353 exemplos, 356–357

ferramentas para obter exemplos e requisitos, online, 357, 384
159 físicos, 356
Revisões de sprint, 444. Consulte também Demos/ adesivos e, 355
demonstrações tarefas, 222, 355 , 436
SQL*Loader, 460 Teste virtuais, 357, 384, 393
de estabilidade, 28 trabalhos em andamento,

Ambiente de teste, 458 Reuniões 390 auditorias
stand-up, 177, 429, 462 Manutenção de de cartões de
padrões e, história e, 89 lidando com bugs e, 424–425
227 modelos de qualidade e, 90– planejamento de iteração e, 244
93 “Iniciar, parar, continuar” narrativas de histórias em, 409
exercício, retrospectivas, desenvolvimento orientado a testes de histórias.
445–447 Consulte SDD (desenvolvimento orientado a testes de história)
Análise estática, ferramentas de teste de segurança, Aplicativo Strangler (Fowler), 116–117 Automação de
rosca de aço 225, desenvolvimento incremental, 144, 338, estratégia.
345 Consulte Planejamento de teste de estratégia de
histórias. Veja também testes voltados para negócios automação versus estratégia de teste, 86–87
benefícios de trabalhar antes das iterações, 370– estratégias de teste, 380–381
372 brevidade de, 129– Estratégia, para escrever testes
130 testes voltados para o construindo testes de forma incremental, 178–179
negócio como, 130 determinar o planejamento de iteração e, 372
tamanho da história, 375–376 focar em manter os testes aprovados, 179
uma história durante a codificação, visão geral de, 177–178
411–412 design de teste padrões, 179–183
identificar variações, 410 saber testabilidade e 183–185 Teste
quando uma história está pronta, de estresse. Consulte Teste de carga do
104–105 Subversion (SVN), 124, 320 Fatores
registrar bugs e, 420–421 modelos de sucesso. Consulte os principais fatores de
e, 380 priorizar, 338–340 sucesso Sucessos, celebrando
recursos e, 381 escopo e, a implementação da mudança e, encerramento
340 dimensionamento. da iteração 50–52 e, 449–451 Sumrell,
Consulte Megan, 365, 450 Ritmo sustentável,
Dimensionamento de histórias de testes, 40–41, 303 SVN (Subversion), 124, 320
começando de forma simples, SWTBot GUI ferramenta de teste, 127
133, 406 testes de história Sinergia, entre práticas, 489 Sistema,
definidos, 505 impacto em todo o impacto da história em todo o sistema, 342

sistema, 342 planos de teste e 345
528 ÍNDICE
T logística, 59
tail-f, 212 resolução de problemas e, 123
Tartaglia, Coni, 439, 454, 470, 473 Quadros de Exemplo de sistema de monitoramento remoto de dados,
tarefas. Consulte Storyboards Cartões de 243-244
tarefas responsabilidade compartilhada e, 105–106
automatizando testes e, 394–395 planejamento tradicional, 9–10 usando
de iteração e, 389–392 entrega de produto e, testes para apoiar os quadrantes 1 e 2,

462–463 Tarefas completando tarefas de 100–101
teste, abordagem de toda a equipe. Consulte Abordagem de
415–416 definição, 505–506 TDD equipe inteira
(desenvolvimento orientado trabalhando em equipes ágeis, 10–12
a testes) Desmontagem, para testes, 307–308
condução de testes automatizados, 262–263 Dívida técnica
defeitos e, definição defeitos como, 418

490, visão geral 506 definição, 506
de, 5 gerenciamento, 106, 487–488
Desenvolvimento de teste primeiro em comparação com, Visão geral dos testes voltados
113–114 para a tecnologia de, 5
testes de unidade e, 111, 244–245 Quadrantes 1 e 4, 97–98
Equipe Cidade, 126 Testes voltados para a tecnologia, criticando o produto

Estrutura da equipe, 59–65 (Quadrante 4), linhas de base
equipes de projetos ágeis, 64–65 217–239, 235–237
equipes de controle de qualidade codificação e testes e, 412–413 testes de

independentes, 60 integração de testadores em projetos ágeis, compatibilidade, 229–230 testes de
61–63 visão geral instalabilidade, 231–232 testes de
de, 59 estrutura funcional tradicional versus estrutura interoperabilidade, 228–229 testes de
ágil, 64 manutenção, 227–228 testes de gerenciamento
Equipes de memória, 237 –238 visão geral de, 217–219 testes
automação como esforço de equipe, 484 de desempenho e carga, 234
construindo, 69–71 ferramentas de desempenho e teste de carga,

comemorando o sucesso, 50–52 co- 234–235 testes de confiabilidade, 230–231, 250–251 testes de
localizados, 65–66 escalabilidade, 233–234 testes de segurança, 223–
controlando a carga de trabalho e, 393 227 ambiente de teste e, 237 quando
clientes, 7 usar, 222–223 quem realiza o
desenvolvedores, teste, 220–222
7–8 capacitando, 44
facilitando a comunicação e, 429–432 geograficamente
dispersos , 376–378, 431–432 dando peso igual a todos os Testes voltados para a tecnologia, equipe de suporte
membros da equipe, 31 dando propriedade a, 50 (Quadrante 1)
contratando testadores ágeis ferramentas de
para, 67–69 interação entre equipes de construção, 126 projetando com testes em mente, 115–
clientes e desenvolvedores, 8 planejamento de iteração e, 384– 118 facilidade de realizar tarefas, 114–115
385 IDEs para suporte de
infraestrutura 124–126, 111–112

ÍNDICE 529
visão geral de, 109–110 Alternativas de plano de teste, 350-354

propósito de, 110–111 Planejamento de testes, 345–350
controle de código-fonte, 123–124 listas de testes automatizados, alternativas de planos de testes,
velocidade como benefício de, 112– 353–354
114 feedback oportuno, 118–119 infraestrutura e, 346–347 visão geral

kit de ferramentas de, 86, 345 razões para
para, 123 ferramentas de teste escrever, 345–346 ambiente de teste
de unidade, 126–127 e, 347–348 alternativas de plano de teste,
testes de unidade, 244–245 o que fazer se a equipe não 350–354 planos de teste, amostra leve
realizar esses de plano de teste 350, 351 estratégia
testes, 121–123 onde/quando parar, 119–121 de teste vs., 86– 88
Abordagem multicamadas da rastreabilidade e 88 tipos de
pirâmide de automação de testes para automação e, testes e 346 por onde
290–291 começar, 345 comunicação
visão geral de, 276-279 de resultados de testes,
metáfora dos três porquinhos, 278 357–358
Teste por trás da IU, 282 organização, 322–324 planejamento

Casos de teste de liberação e 349–350
adicionando complexidade, 407 habilidades de teste. Consulte picos de
como documentação, 402 teste de habilidades, 381
desenvolvimento orientado a exemplos, 379 planilhas de teste,

identificando variações, 410 353 iterações de estratégia
começando simples, 406 de teste,
Cobertura de teste (e/ou cobertura de código), atividades de pré-iteração e,
360–364 380–381
Padrões de projeto de teste, 179-183 plano de teste vs., 86–88

Padrão Construir/Operar/Verificar, 180 testes definição de
baseados em dados e palavras-chave, stubs de teste, 506

182–183 integração com aplicativos externos e,
visão geral de 179 459
padrões de gênese de teste (Veragen), 179 testes de unidade e, 127
padrões baseados em tempo, atividades e eventos, 181 Equipes de teste, 506–507. Consulte também ferramentas de
definição de teste do Teams. Veja também Kits de ferramentas
duplas de teste, Funcional da camada API, 168–170

506 arquiteturas em camadas e 116 testes exploratórios, 210–211 gerando
desenvolvimento orientado a testes. Veja TDD (desenvolvimento dados de teste com, 212
orientado a testes) Testes de GUI, 170–176
Ambientes de teste, 237, 487 Definição produzidos em casa, 175
de desenvolvimento de teste produzidos em casa, 314

primeiro, 506 TDD IDEs, 124–126
(desenvolvimento orientado a testes) comparado com, 113– testes de desempenho, 234–235 testes
114 Gerenciamento de segurança, 225 testes
de testes, 186 Kit de em nível de unidade, 126–127, 165–168 testes
ferramentas de gerenciamento de testes (Quadrante 2), 186 de serviços da web, 170

530 ÍNDICE
Tipos de proporção testador-desenvolvedor, 66–

teste alfa/beta, 466–467 67 escrevendo cartões de tarefas e,
exploratório. Consulte Teste exploratório (ET) funcional. 391 Declaração de direitos do testador,
Consulte GUI de teste funcional. Consulte 49–50
integração de teste de GUI, Testando codificação e teste simultaneamente, 409–410
carga 229, 459. Consulte completando tarefas de teste, 415–416
Desempenho de teste de identificando variações, 410
carga. Consulte Confiabilidade de testes de desempenho gerenciando, 320–322
e carga, organizando resultados de testes , 322–324
230–231, 250–251 segurança, 220, testes de organização, 319–322
223–227 estresse. Consulte tempo de planejamento para, 455–
Unidade de teste de carga. 456 ciclos de pós-desenvolvimento, 467–468
Consulte Usabilidade de quadrantes. Consulte Candidatos
teste de unidade. Consulte Teste de de lançamento dos Quadrantes,
usabilidade, teste de aceitação do usuário. Consulte 458 avaliação de risco e, 407–409 ritmo
UAT (teste de aceitação do usuário) sustentável de, 40–41 tradicional

Estratégia de redação de testes. Veja Estratégia, para escrever vs. ágil, 12–15 transparência de
testes testes, 321–322 Testes no contexto
Testabilidade, 183–185
testes automatizados vs. manuais do quadrante 2, 185 testes orientados ao contexto e, definição 106–
automação e, 149–150 design de 108, 502 ferramenta
código e design de teste e, 184–185 visão geral de, 183 de teste GUI TestNG, 127 testes
de histórias, 393–396 que nunca falham, 286 matrizes
testadores de texto, 350–353 The Grinder,
234 Themes. Consulte
agregando valor, 12 também Definição de planejamento de

testadores ágeis, 4, 19–20 lançamento, 507
mentalidade de teste ágil, 20–21 priorizando histórias e, 339 escrevendo

automação permitindo foco em trabalhos mais cartões de tarefas e, 392 Fatias finas,
importantes, 260 colaboração desenvolvimento incremental e, 338 Testes de compatibilidade
com clientes, 396–397 considerando todos os pontos de terceiros e,
de vista durante o planejamento da iteração, 386–389 230 planejamento de lançamento e, 342–
controlando a carga de 344 software, 163 Tholfsen, Mike, 203
trabalho e, 393 definição, 507 facilitação Thomas, Mike,
da comunicação, 116, 194 Metáfora dos três
429–430 feedback e 486 contratação de testadores porquinhos, 278 Cronogramas,

ágeis, 67–69 como escopo e, 340–341 Toolkit (Quadrante 1)
influenciar os testes, 121–122 ferramentas de construção, 126 IDEs, 124–
integração de testadores em projetos ágeis, 126 visão geral de, 123
controle de código-
61–63 fonte, 123–124
iterações e, 327 facilitando ferramentas de teste
o trabalho, 114–115 histórias de de unidade, 126– 127
dimensionamento, 333–334
ÍNDICE 531
Kit de ferramentas (quadrante 2) monitoramento, 212–213 código
Ferramentas de teste funcional da camada API, 168–170 aberto, 172, 314–315 testes de
ferramentas de automação, 164–165 desempenho, 234–235 para proprietários de
testes de construção incremental, 178–179 listas de produtos e especialistas de negócios, 134 testes de segurança, 225
verificação, 156 simuladores, 213 baseados
diagramas de fluxo, 160–163 em software, 163
Ferramentas de teste GUI, 170–176 testes de nível de unidade,
mantêm os testes aprovados, 179 126–127, 165– 168 fornecedor/comercial, 315–316
mapas mentais, 156–158 ferramenta de teste de serviço web, 170
modelos, 160
ferramentas baseadas em software, Ferramentas, automação
163 planilhas, 159 ágil, 316 aplicando uma
estratégias para escrever testes, 177–178 padrões de ferramenta por vez, 312–313 fabricado em casa, 175
design de teste, 179–183 gerenciamento de desenvolvido em casa, 314
testes , 186 testabilidade e 183– identificando requisitos de
185 estratégia de ferramentas, 153– ferramentas, 311–312 código aberto, 314–315 selecionando,
155 ferramentas para obter 294–298 fornecedores, 315–316
exemplos e requisitos, Rastreabilidade DTS e, 82

155–156 matrizes, 86 planejamento
ferramentas de teste em nível de unidade, 165–168 de testes e, 88

Ferramenta de teste de serviço da Web, 170 Rastreamento,
Ferramentas de emulador do tarefas de teste e
Toolkit (Quadrante 3), 213–214 status, 354–357 Processos
ferramentas de monitoramento, 212–213 tradicionais, transição. Ver

ferramentas de simulador,
213 testes de aceitação do usuário, 250 Transição de processos tradicionais para ágeis Equipes
Linhas de base do kit de tradicionais, 9–10 Testes tradicionais
ferramentas (quadrante 4), versus ágeis, 12–15 Treinamento como entrega,
235–237 ferramentas de teste de desempenho e carga, 234–235 469 falta de,

Ferramentas 45 Transição de processos
Ferramentas de teste funcional da camada API, 168–170 tradicionais
automação, 164–165 geração para ágeis, 73–93 rastreamento de defeitos. Consulte Rastreamento de
de dados, 304–305 rastreamento de defeitos do processo existente e, 88–92 medições
defeitos, 83–85 exemplos e enxutas, 74–75 processos leves e, 73–74
requisitos de obtenção, 155–156, 159–163 ferramentas métricas e, 74–79 visão geral de, 73
de emulador, 213–214 planejamento de testes. Consulte Planejamento

testes exploratórios, 210– 211 de teste
gerando dados de teste, 212
Ferramentas de teste GUI, 170–176
fabricadas em casa, 175 EM
desenvolvidas em casa, 314 Ciclos de testes pós-desenvolvimento UAT

IDEs, 124–126 testes (teste de aceitação do usuário), 467–468 entrega do produto e
de carga, 234–235 464–466

532 ÍNDICE
UAT (teste de aceitação do usuário), continuado no V
quadrante 3, 102, Vaage, Carol, 330

planejamento de lançamento para, 331, 346
Exemplo de sistema de monitoramento remoto de dados, Agregação de valor,
250 31–33 entrega ao cliente, 22–23 foco
no plano de teste, em, 341–342 testadores
351 experimentando novos recursos e 102 somando, 12 Valores,
escrevendo na reunião inicial da iteração, 372 UI ágil, 3–4. Veja também Princípios, para agilidade
(interface do usuário). Consulte também estratégia de automação testadores
GUI (interface Variações, codificação e testes e, 410

gráfica do usuário) e modelagem 293 e Automação
ferramentas de teste de de velocidade e, 255, 484 taxa de
unidade 399, 165–168. Veja também por ferramentas de esgotamento e, 79 impacto

unidade individuais no banco de dados, 228 defeitos
ferramentas de desenvolvimento orientadas a comportamento, e, 487 definição, 507
lista 166–168, visão maximização, 370
geral 126–127 de, 165 ritmo sustentável de
automação de testes e, 41 demorando para fazer certo, 301
testes unitários, 282 dívida técnica e, 106, 313, 418, 506
BDD (desenvolvimento orientado a comportamento), definição
165–168, 507 Ferramentas
métricas e, 76 de automação de fornecedores, 315–316
funções de suporte de, 5 TDD ferramenta de captura e reprodução, 267
(teste desenvolvimento orientado) e, 111 testes voltados IDEs, 125
para a tecnologia, 120 ferramentas planejamento e 342–344

para testes do quadrante 1, 126–127 testes de ferramentas de controle de código-fonte,
usabilidade, 202–204 verificação 124 trabalhando com, 142, 349

de aplicativos de concorrentes, 204 navegação e, 204 visão Veragen, Pierre, 76, 163, 179, 295, 363, 372,
geral de, 202 necessidades 444
de usuários e testes Controle de versão, 123–124, 186. Consulte também
de personalidade, 202 –204 o que não deve ser Pontos de vista de controle
automatizado, 285–286 Casos de uso, 398 Testes de de código-fonte. Consulte também Panorama
aceitação do geral considerando todos os pontos de vista durante o
usuário. Consulte UAT (teste de aceitação do usuário) planejamento da iteração,
385–389 reunindo todos os pontos de vista em
Documentação do usuário, 207–208 relação aos requisitos, 374–
Interface do usuário (IU). Consulte também Estratégia de 375 Potência de Três e, 411
automação usando vários pontos de vista na obtenção de
GUI (interface gráfica do usuário) e 293 requisitos, 137–138
modelagem e 399 História Visibilidade, 354–366
do usuário. Consulte História cobertura de código, 360–364
Cartão de história do usuário. Consulte o comunicar resultados de testes, 357–358 métricas
cartão de história Histórias de usuários aplicadas de defeitos, 364–366 número de
ao desenvolvimento ágil de software (Cohn), 155 testes aprovados, 358–360

ÍNDICE 533
visão geral de 354 responsabilidade compartilhada e, 105–106

métricas de lançamento, formação de equipe e, 69
358 tarefas de teste de rastreamento e status, 354–357 estrutura de equipe e, 59–62 para
Estúdio Visual, 125 automação de testes, 270
Voris, João, 117 gerenciamento de testes e, 322
equipe multifuncional tradicional em comparação com, 64
EM valor dos
Abordagem em cascata, para o desenvolvimento membros da equipe e, 70
desenvolvimento ágil comparado com, 12–13 fenômeno Wiki
de “mini-cascata”, 46–47 sucessos de, 112 planos como ferramenta de comunicação,

de teste e, 346 Watir 164 documentação gráfica de exemplos,
(teste de aplicativos da 398–399
Web em Ruby), 163, 172–174, 320. Consulte também Ruby maquetes, 160, 380
com descrição de serviços da Web Watir Idioma requisitos, 402 listas de
(WSDL), verificação de histórias e 156
507 casos de teste,
Automação de testes de 372 rastreabilidade e, 88

serviços da Web, Wilson-Welsh, Patrick, 278 Testes
visão geral 282 de, 207 do Mágico de Oz, 138–139 Diagramas de
Exemplo de sistema de monitoramento remoto de dados, fluxo de trabalho, 398 Trabalhando
247–248 efetivamente com código legado (penas) , 117 , 288 Carga de
ferramentas para, 170-171 trabalho,
WebLoad, 234 393 Piores cenários,
Whelan, Declan, 321 136, 334 Escrevendo testes, estratégia
Desenvolvimento para. Veja Estratégia, para escrever testes WSDL (Web
baseado em exemplos de quadros brancos, Services
379 facilitação de comunicação, 430 Description Language),
modelagem, 399 507
diagrama de planejamento,
371 revisão de testes de alto nível com programadores, X
400–401 XP (Programação Extrema)
alternativas de plano de teste, 353–354 equipe ágil abraçando, 10–11 coragem
Abordagem de equipe inteira, 325 como valor central em, 25 xUnit, 126–
vantagens de, 26 127
desenvolvimento ágil vs. tradicional, 15–16 estratégia

de automação e, 300–301 limites de orçamento E
e, 55 encontrar prazer no Yakich, Joe, 316

trabalho e, 31 fatores-chave de sucesso,
482.491 emparelhando testadores COM
com programadores, 279 Tolerância zero a bugs, 79, 418–419

Agile Testing - A Practical Guide For Testers and Agile Teams (Lisa Crispin and Janet Gregory) - 281-573

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Agile Testing - A Practical Guide For Testers and Agile Teams (Lisa Crispin and Janet Gregory) - 281-573

Enviado por

Direitos autorais:

Formatos disponíveis

Machine Translated by Google

Código de teste A Equipe e o Processo

Resumo do quadrante: Testes unitários

Testando feeds de dados Automação Funcional

Testes ponta a ponta Criticando o Automação Serviços web

No Capítulo 6, apresentamos os quadrantes de teste e, nos capítulos seguintes,

REVISÃO DOS QUADRANTES DE TESTE Acabamos

242 CAPÍTULO 12 RESUMO DOS QUADRANTES DE TESTE

Quadrantes de testes ágeis

Testes de história Testando usabilidade

Testes unitários Teste de desempenho e carga

Figura 12-1 Quadrantes de Teste Ágil

UM EXEMPLO DE TESTE DE SISTEMA

resolve o problema de monitoramento remoto de poços de produção de petróleo e gás. A

A Figura 12-2 mostra a arquitetura do sistema de Monitoramento Remoto de Dados. Os

UM EXEMPLO DE TESTE DE SISTEMA 243

Servidor de aplicação Usuário administrador

Figura 12-2 Arquitetura do sistema de monitoramento remoto de dados

variedade de protocolos para se comunicar com o dispositivo de medição. Esses dados de

A equipe consistia de quatro programadores de software, dois programadores de firmware,

244 CAPÍTULO 12 RESUMO DOS QUADRANTES DE TESTE

práticas, incluindo programação em pares e TDD. A equipe do cliente usou

Scrum foi usado como mecanismo de relatório externo para a organização e

A integração contínua através do CruiseControl forneceu construções constantes para

TESTES QUE CONDUZEM O DESENVOLVIMENTO

Os testes que direcionaram o desenvolvimento incluíram testes de unidade e testes de aceitação.

A equipe de teste automatizou os testes de aceitação o mais rápido possível, geralmente no

A estrutura de teste funcional automatizado

246 CAPÍTULO 12 RESUMO DOS QUADRANTES DE TESTE

A terceira e superior camada, Camada 3, era a camada de teste e continha os dados

Login ('Janet', 'Senha')

Camada 3 – Camada de Teste

Camada 2 – Camada de acesso à página

Camada 1 – Controlador IE (Watir)

Figura 12-3 Camadas de teste funcional

Os testes funcionais usaram Ruby com Watir para controlar o DOM no

A equipe demonstrou o cliente de teste aos clientes, que decidiram usar

248 CAPÍTULO 12 RESUMO DOS QUADRANTES DE TESTE

maneira, e os clientes puderam testar os serviços da web entregues a

CRÍTICA DO PRODUTO COM

CRÍTICA DO PRODUTO COM TESTES DE NEGÓCIOS 249

testes exploratórios efetivos sejam feitos sem gastar muito tempo

Testando feeds de dados

Conforme mostrado na Figura 12-2, os dados do sistema estão disponíveis em um JMS

Os e-mails foram enviados automaticamente quando foram encontradas condições de alarme.

Os testes ponta a ponta

Os testes ponta a ponta foram complicados pela resposta imprevisível do

250 CAPÍTULO 12 RESUMO DOS QUADRANTES DE TESTE

Testes de aceitação do usuário

Não podemos enfatizar suficientemente a importância de trabalhar com o cliente. Até

inacessível, especialmente no inverno. O simulador desenvolvido para testar o sistema embarcado

A abordagem adotada para a documentação é apresentada nesta seção.

Documentando o código de teste

A documentação do código de teste ajudou a documentar os testes e fazer

Relatando os resultados do teste

252 CAPÍTULO 12 RESUMO DOS QUADRANTES DE TESTE

USANDO OS QUADRANTES DE TESTE ÁGIL

Invista em uma arquitetura de teste que acomode a complexidade do sistema

Combinações de ferramentas de negócios comuns, como planilhas e scripts de testes

Esta página foi intencionalmente deixada em branco

Esta página foi intencionalmente deixada em branco

POR QUE QUEREMOS

O teste manual demora muito