Syllabus CTFL - AT

International Software Testing Qualifications Board
Certified Tester
Foundation Level Extension
Syllabus Agile Tester
Verso 2014br
Comisso Internacional para Qualificao de Teste de Software
Traduo realizada pela TAG01 - Documentao do BSTQB

baseada na verso 2014 do Certified Tester Foundation Level
Syllabus Agile Tester Extended do ISTQB.
Brazilian Software Testing Qualifications Board
Copyright Comisso Internacional para Qualificao de Teste de Software (doravante denominado

ISTQB).
Certified Tester
Foundation Level Syllabus Agile Tester
Grupo de Trabalho do Foundation Level Extension Agile Tester: Rex Black (Presidente), Bertrand Cornanguer
(Vice-Presidente), Gerry Coleman (Lder dos Objetivos de Aprendizagem), Debra Friedenberg (Lder de
Exame), Alon Linetzki (Lder de Resultados de Negcios e de Marketing), Tauhida Parveen (Editor), e Leo
van der Aalst (Lder de Desenvolvimento).
Autores: Rex Black, Anders Claesson, Gerry Coleman, Bertrand Cornanguer, Istvan Forgacs, Alon Linetzki,
Tilo Linz, Leo van der Aalst, Marie Walsh, e Stephan Weber.
Revisores internos: Mette Bruhn-Pedersen, Christopher Clements, Alessandro Collino, Debra Friedenberg,
Kari Kakkonen, Beata Karpinska, Sammy Kolluru, Jennifer Leger, Thomas Mueller, Tuula Pkknen, Meile
Posthuma, Gabor Puhalla, Lloyd Roden, Marko Rytknen, Monika Stoecklein-Olsen, Robert Treffny, Chris
Van Bael e Erik van Veenendaal; 2013-2014.
Certified Tester
Histrico de Revises
Verso
Data
Observao
Syllabus v0.1
26JUL2013
Sees autnomas
Syllabus v0.2
16JSET2013
Comentrios da avaliao WG em v01 incorporado
Syllabus v0.3
20OUT2013
Comentrios da avaliao WG em v02 incorporado
Syllabus v0.7
16DEZ2013
Comentrios da avaliao Alpha em v03 incorporado
Syllabus v0.71
20DEZ2013
Atualizaes de grupo de trabalho em v07
Syllabus v0.9
30JAN2014
Verso Beta
Syllabus 2014
31MAIO2014
Verso GA
Certified Tester
Sumrio
Histrico de Revises..................................................................................................................3
Agradecimentos ..........................................................................................................................6
0.
Introduo a este Syllabus ........................................................................................7
0.1
Finalidade deste Documento .............................................................................................. 7
0.2
Viso Geral ........................................................................................................................ 7
0.3
Objetivos de aprendizagem examinveis............................................................................ 7
Desenvolvimento do Software gil 150 mins. .....................................................8
1.
1.1
Os Fundamentos do Desenvolvimento de Software gil ................................................... 9
1.1.1 Desenvolvimento do Software gil e do Manifesto gil ................................................... 9

1.1.2 Abordagem da Equipe Inteira........................................................................................... 10
1.1.3 Feedback Inicial e Frequente............................................................................................ 11
1.2
Aspectos de Abordagens gil .......................................................................................... 11
1.2.1 Abordagens de Desenvolvimento do Software gil ......................................................... 11

1.2.2 Criao Colaborativa da Estria do Usurio .................................................................... 13
1.2.3 Retrospectivas .................................................................................................................. 14
1.2.4 Integrao Contnua ......................................................................................................... 14
1.2.5 Planejamento de Iterao e Lanamento .......................................................................... 16
2.
Princpios Fundamentais do Teste gil, Prticas e Processos - 105 mins. ............18

2.1
As Diferenas entre os Testes em abordagens tradicionais e no gil ............................... 19
2.1.1 Atividades de Teste e Desenvolvimento .......................................................................... 19

2.1.2 Produtos de Trabalho do Projeto ...................................................................................... 20
2.1.3 Nveis de Teste ................................................................................................................. 21
2.1.4 Gesto de Testes e configurao ...................................................................................... 22
2.1.5 Opes Organizacionais para Teste Independente ........................................................... 22
2.2
Status de Teste em Projetos gil ...................................................................................... 23
2.2.1 Comunicao do Status, Progresso de Teste e Qualidade de Produto .............................. 23

2.2.2 Gesto de Risco de Regresso com Evoluo dos Casos de Teste Manuais e Automatizado 24
2.3
Funo e Habilidades de um Testador em uma equipe gil ............................................. 25
2.3.1 Habilidades do Testador do gil ...................................................................................... 25

2.3.2 Funo de um Testador em uma equipe do gil .............................................................. 26
3.
Tcnicas, Ferramentas e Mtodos de Teste gil - 480 min. ..................................27

3.1
Mtodos de Teste do gil ................................................................................................ 28
3.1.1 Desenvolvimento Orientado para Teste, Desenvolvimento Orientado para Teste de Aceitao e
Desenvolvimento Orientado para o Comportamento ................................................................... 28
Certified Tester
3.1.2 Pirmide de Teste ............................................................................................................. 29
3.1.3 Quadrantes de Teste, Nveis de Teste e Tipos de Teste .................................................... 29
3.1.4 A Funo de um Testador ................................................................................................ 30
3.2
Avaliao de Riscos de Qualidade e Estimativa do Esforo de Teste .............................. 31
3.2.1 Avaliar os riscos de qualidade em projetos geis ............................................................. 31

3.2.2 Estimativa do Esforo de Teste Com Base no Contedo e Risco ..................................... 32
3.3
Tcnicas nos Projetos geis .............................................................................................. 33
3.3.1 Critrios de aceitao e cobertura adequada, e outras informaes para Testes ............... 33
3.3.2 Desenvolvimento Orientado para o Teste de Aceitao ................................................... 36
3.3.3 Projeto de Teste Funcional e No Funcional de Caixa Preta ............................................ 36
3.3.4 Teste Exploratrio e Teste do gil ................................................................................... 37
3.4
Ferramentas em Projetos geis ......................................................................................... 38
3.4.1 Ferramentas de Gesto e Rastreamento de Tarefas .......................................................... 39

3.4.2 Ferramentas de comunicao e compartilhamento de informaes .................................. 39
3.4.3 Desenvolvimento do Software e Ferramentas de Distribuio ......................................... 40
3.4.4 Ferramentas de Gerenciamento de Configurao ............................................................. 40
3.4.5 Projeto de teste, Ferramentas de Implementao e Execuo ........................................... 40
3.4.6 Ferramentas de Computao Nuvem e Virtualizao ....................................................... 41
4.
Referncias .............................................................................................................42
4.1
Normas ............................................................................................................................. 42
4.2
Documentos ISTQB ......................................................................................................... 42
4.3
Livros ............................................................................................................................... 42
4.4
Terminologia do gil ....................................................................................................... 43
4.5
Outras Referncias ........................................................................................................... 43
ndice
44
Certified Tester
Agradecimentos
Este documento foi produzido por uma equipe do Grupo de Trabalho ISTQB Foundation Level.
A equipe Agile Extension agradece a equipe de reviso e os Conselhos Nacionais por suas sugestes e
contribuies.
Na poca, o Syllabus Foundation Level Agile Extension foi concludo, o Grupo de Trabalho Agile Extension
apresentou a seguinte associao: Rex Black (Presidente), Bertrand Cornanguer (Vice-Presidente), Gerry
Coleman (Lder dos Objetivos de Aprendizagem), Debra Friedenberg (Lder de Exame), Alon Linetzki (Lder
de Resultados de Negcios e de Marketing), Tauhida Parveen (Editor), e Leo van der Aalst (Lder de
Desenvolvimento).
Autores: Rex Black, Anders Claesson, Gerry Coleman, Bertrand Cornanguer, Istvan Forgacs, Alon Linetzki,
Tilo Linz, Leo van der Aalst, Marie Walsh, e Stephan Weber.
Revisores internos: Mette Bruhn-Pedersen, Christopher Clements, Alessandro Collino, Debra Friedenberg,
Kari Kakkonen, Beata Karpinska, Sammy Kolluru, Jennifer Leger, Thomas Mueller, Tuula Pkknen, Meile
Posthuma, Gabor Puhalla, Lloyd Roden, Marko Rytknen, Monika Stoecklein-Olsen, Robert Treffny, Chris
Van Bael e Erik van Veenendaal; .
A equipe agradece tambm as seguintes pessoas dos Conselhos Nacionais e da comunidade de especialistas
gil, que participaram da reviso, comentrio e votao da Foundation Agile Extension Syllabus: Dani Almog,
Richard Berns, Stephen Bird, Monika Bgge, Afeng Chai, Josephine Crawford, Tibor Csndes, Huba Demeter,
Arnaud Foucal, Cyril Fumery, Kobi Halperin, Inga Hansen, Hanne Hinz, Jidong Hu, Phill Isles, Shirley Itah,
Martin Klonk, Kjell Lauren, Igal Levi, Rik Marselis, Johan Meivert, Armin Metzger, Peter Morgan, Ninna
Morin, Ingvar Nordstrom, Chris O'Dea, Klaus Olsen, Ismo Paukamainen, Nathalie Phung, Helmut Pichler,
Salvatore Reale, Stuart Reid, Hans Rombouts, Petri Silynoja, Soile Sainio, Lars-Erik Sandberg, Dakar
Shalom, Jian Shen, Marco Sogliani, Lucjan Stapp, Yaron Tsubery, Sabine Uhde, Stephanie Ulrich, Tommi
Vlimki, Jurian Van de Laar, Marnix Van den Ent, Antnio Vieira Melo, Wenye Xu, Ester Zabar, Wenqiang
Zheng, Peter Zimmerer, Stevan Zivanovic, and Terry Zuo.
Este documento foi formalmente aprovado para liberao pela Assembleia Geral da ISTQB em 31 de maio
de 2014.
Certified Tester
0. Introduo a este Syllabus

0.1 Finalidade deste Documento
Este programa constitui a base para a Qualificao do Teste de Software Internacional no Nvel Fundamental
para o Testador gil. O ISTQB fornece este programa da seguinte forma:
Para Conselhos Nacionais, para traduzir em seu idioma local e credenciar prestadores de treinamento.
Conselhos Nacionais podem adaptar o programa s suas necessidades lingusticas especficas e
modificar as referncias para se adaptar s suas publicaes locais.
Para Conselhos de Exame, para derivar questes do exame em seu idioma local adaptado para os
objetivos de aprendizagem para cada programa.
Para prestadores de treinamento, para a produo de material didtico e determinar os mtodos de
ensino adequados.
Para os candidatos certificao, para se preparar para o exame (como parte de um curso de formao
ou de forma independente).
Para a comunidade internacional de software e sistemas de engenharia, para o avano da profisso de
software e testes de sistemas, e como base para livros e artigos.
O ISTQB pode permitir que outras entidades possam utilizar este programa para outros fins, desde que busque
e obtenha permisso prvia por escrito.
0.2 Viso Geral

O documento Viso Geral do Foundation Level Agile Tester [ISTQB_FA_OVIEW] inclui as seguintes
informaes:
Resultados de negcios para o programa

Resumo para o programa
Relaes entre os programas
Descrio dos nveis cognitivos (nveis K)
Apndices
0.3 Objetivos de aprendizagem examinveis

Os Objetivos de aprendizagem apoiam os Resultados do Negcio e so utilizados para criar o exame para a
obteno da certificao Certified Tester Foundation LevelAgile Tester. Em geral, todas as partes deste
programa so examinveis em um nvel K1. Ou seja, o candidato ir reconhecer, lembrar e recordar um termo
ou conceito. Os objetivos de aprendizagem especficos a nveis K1, K2 e K3 so mostrados no incio do
captulo pertinente.
Certified Tester
1. Desenvolvimento do Software gil 150 mins.

Palavras-chave.
Manifesto gil, desenvolvimento de software gil, modelo de desenvolvimento incremental, modelo de
desenvolvimento iterativo, ciclo de vida do software, automao de testes, base em testes, desenvolvimento
orientado a testes, orculo de teste, estria do usurio
Objetivos de aprendizagem para Desenvolvimento do Software gil

1.1 Os Fundamentos do Desenvolvimento do Software gil
FA-1.1.1 (K1) Relembrar o conceito bsico de desenvolvimento do software gil baseado no manifesto gil
FA-1.1.2 (K2) Compreender as vantagens da abordagem de equipe inteira
FA-1.1.3 (K2) Compreender os benefcios do feedback inicial e frequente
1.2 Aspectos de abordagens do gil
FA-1.2.1 (K1) Relembrar abordagens de desenvolvimento do software gil
FA-1.2.2 (K3) Escrever estrias de usurios testveis em colaborao com os desenvolvedores e os
representantes de negcio
FA-1.2.3 (K2) Compreender como as retrospectivas podem ser utilizadas como um mecanismo para a melhoria
de processos em Projetos geis
FA-1.2.4 (K2) Compreender o uso e propsito de integrao contnua
FA-1.2.5 (K1) Conhecer as diferenas entre planejamento de iterao e de liberao, e como um testador
agrega valor em cada uma dessas atividades
Certified Tester
1.1 Os Fundamentos do Desenvolvimento de Software gil
Um testador em um projeto gil vai trabalhar de forma diferente do que um testador trabalhando em um
projeto tradicional. Os testadores devem compreender os valores e princpios que sustentam os projetos do
gil, e como os testadores so parte integrante de uma abordagem de equipe inteira junto aos desenvolvedores
e representantes de negcio. Os membros de um projeto do gil se comunicam entre si com antecedncia e
com frequncia, o que ajuda na remoo de defeitos precoces e desenvolvimento de um produto de qualidade.
1.1.1 Desenvolvimento do Software gil e do Manifesto gil

Em 2001, um grupo de indivduos, representando as metodologias de desenvolvimento de software leves mais
utilizados, acordou um conjunto comum de valores e princpios que ficou conhecido como o Manifesto para
Desenvolvimento do Software gil ou o Manifesto gil [Agilemanifesto]. O Manifesto gil contm quatro
declaraes de valores:
Indivduos e interaes sobre processos e ferramentas

Software funcionando sobre documentao mais abrangente
Colaborao com o cliente sobre negociao de contratos
Resposta s mudanas sobre seguimento de um plano
O Manifesto gil argumenta que, embora os conceitos direita tenham valor, os da esquerda tm maior valor.
Indivduos e Interaes
O desenvolvimento do modelo gil muito centrado em pessoas. Equipes de pessoas desenvolvem o software,
e atravs de uma comunicao contnua e interao, ao invs de uma dependncia de ferramentas ou
processos, que as equipes podem trabalhar de forma mais eficaz.
Software Funcionando
A partir da perspectiva do cliente, o software funcionando muito mais til e valioso do que a documentao
excessivamente detalhada e fornece uma oportunidade para dar o feedback rpido equipe de
desenvolvimento. Alm disso, por ser um software funcionando, embora com funcionalidade reduzida, est
disponvel muito antes no ciclo de vida de desenvolvimento, o desenvolvimento gil pode conferir vantagem
significativa no time-to-market. O desenvolvimento gil , portanto, especialmente til em mudanas rpidas
de ambientes de negcios onde os problemas e/ou solues no so esclarecidos, ou onde a empresa pretende
inovar em novos domnios de problemas.
Colaborao do Cliente
Os clientes muitas vezes encontram grande dificuldade em especificar o sistema que eles precisam. Colaborar
diretamente com o cliente aumenta a probabilidade de compreender exatamente o que o cliente requer. Embora
celebrar contratos com os clientes seja importante, trabalhar em colaborao regular e prxima com eles pode
trazer mais sucesso para o projeto.
Resposta Mudana
A mudana inevitvel em projetos de software. O ambiente em que a empresa opera, a legislao, atividade
concorrente, avanos tecnolgicos e outros fatores podem ter grandes influncias sobre o projeto e seus
objetivos. Estes fatores devem ser acomodados pelo processo de desenvolvimento. Como tal, ter flexibilidade
nas prticas de trabalho para aceitar a mudana mais importante do que simplesmente aderir rigidamente a
um plano.
Princpios
Os valores fundamentais do Manifesto gil so capturados em doze princpios:
Nossa maior prioridade satisfazer o cliente atravs do desenvolvimento avanado e contnuo de

software de valor.
Certified Tester
Acolhimento aos requisitos de mudana, mesmo no final do desenvolvimento. Os processos geis

asseguram mudana para uma vantagem competitiva do cliente.
Desenvolver software funcionando com frequncia, em intervalos de algumas semanas a alguns meses,
com preferncia para a escala de tempo mais curta.
Empresrios e desenvolvedores devem trabalhar juntos diariamente durante o projeto.
Criar projetos em torno de indivduos motivados. Providenciar a eles o ambiente e suporte que eles
precisam, e confiar neles para realizar o trabalho.
O mtodo mais eficiente e eficaz de transmitir informaes para e dentro de uma equipe de
desenvolvimento a conversa face-a-face.
Software funcionando a principal medida de progresso.
Os processos geis promovem desenvolvimento sustentvel. Os patrocinadores, desenvolvedores e
usurios devem ser capazes de manter um ritmo constante indefinidamente.
Ateno contnua excelncia tcnica e bom design intensifica a agilidade.
Simplicidade-a arte de maximizar a quantidade de trabalho no realizado- essencial.
As melhores arquiteturas, requisitos e projetos emergem de equipes auto organizadas.
Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz, e ento afina e ajusta seu
comportamento em conformidade.
As diferentes Metodologias geis proporcionam prticas prescritivas para colocar esses valores e princpios
em ao.
1.1.2 Abordagem da Equipe Inteira

A abordagem de equipe inteira, que envolve a todos com o conhecimento e as habilidades necessrias para
garantir o sucesso do projeto. A equipe inclui representantes do cliente e de outras partes interessadas de
negcios, que determinam as caractersticas do produto. A equipe deve ser relativamente pequena; equipes
bem sucedidas tm sido observadas com apenas trs pessoas e no mximo nove. O ideal que toda a equipe
compartilhe o mesmo espao de trabalho, pois a co-localizao facilita fortemente a comunicao e a interao.
A abordagem da equipe inteira suportada atravs das reunies dirias (ver Seo 2.2.1), envolvendo todos os
membros da equipe, onde o progresso do trabalho comunicado, e quaisquer impedimentos ao progresso so
realados. A abordagem da equipe inteira promove uma dinmica de equipe mais eficaz e eficiente.
O uso de uma abordagem da equipe inteira para desenvolvimento do produto um dos principais benefcios
do desenvolvimento gil. Seus benefcios incluem:
Melhorar a comunicao e colaborao dentro da equipe

Ativar os vrios conjuntos de habilidades dentro da equipe para serem aproveitados em benefcio do
projeto
Promover qualidade na responsabilidade de cada elemento
A equipe inteira responsvel pela qualidade nos projetos geis. A essncia da abordagem de equipe inteira
reside nos testadores, desenvolvedores e os representantes das empresas que trabalham juntos em todas as
etapas do processo de desenvolvimento. Os testadores vo trabalhar em estreita colaborao com os
desenvolvedores e representantes das empresas para garantir que os nveis de qualidade desejados sejam
alcanados. Isso inclui apoiar e colaborar com os representantes de negcio para ajud-los a criar testes de
aceitao adequados, trabalhando com desenvolvedores para chegar a acordo sobre a estratgia de teste, e
decidir sobre as abordagens de automao de testes. Os testadores podem, portanto, transferir e ampliar o
conhecimento de testes para outros membros da equipe e influenciar o desenvolvimento do produto.
A equipe inteira est envolvida em consultas ou reunies em que as caractersticas do produto so apresentadas,
analisadas ou estimadas. O conceito que envolve testadores, desenvolvedores e representantes de negcio em
todas as discusses conhecido como o poder dos trs [Crispin08].
10
Certified Tester
1.1.3 Feedback Inicial e Frequente
Os projetos geis tm iteraes curtas, permitindo a equipe do projeto receber feedback avanado e contnuo
sobre a qualidade do produto durante todo o ciclo de desenvolvimento. Uma forma de prover feedback rpido
pela integrao contnua (ver Seo 1.2.4).
Quando as abordagens de desenvolvimento sequenciais so utilizadas, muitas vezes o cliente no v o produto
at que o projeto esteja quase concludo. Nesse ponto, muitas vezes tarde demais para a equipe de
desenvolvimento tratar eficazmente todos os problemas que o cliente pode ter. Ao receber o frequente feedback
do cliente no decorrer do projeto, as equipes geis podem incorporar a maioria das novas alteraes no processo
de desenvolvimento do produto. O feedback avanado e frequente ajuda o foco da equipe quanto s
funcionalidades com o valor comercial mais elevado ou risco associado, e esses so desenvolvidos
primeiramente para o cliente. Da mesma forma, ajuda a gerenciar melhor a equipe, pois a capacidade da equipe
transparente para todos. Por exemplo, qual volume de trabalho podemos realizar em um sprint ou iterao?
O que poderia nos ajudar a avanar mais rpido? O que nos impede de fazer isso?
Os benefcios do feedback inicial e frequente incluem:
Evitar mal-entendidos nos requisitos, que somente podem ser detectados tardiamente no ciclo de
desenvolvimento, quando so mais caros para se reparar.
Esclarecer solicitaes de funcionalidades dos clientes, tornando-os disponveis antecipadamente para
uso do cliente. Desta maneira, o produto reflete melhor o que o cliente quer.
Descobrir (via integrao contnua), isolar e resolver os problemas de qualidade mais cedo.
Providenciar informaes para a equipe gil quanto sua produtividade e capacidade de
desenvolvimento.
Promover fluxo de projeto consistente.
1.2 Aspectos de Abordagens gil

Existe uma srie de abordagens gil em uso nas organizaes. Prticas comuns nas organizaes mais geis
incluem criao colaborativa da estria do usurio, retrospectivas, integrao contnua e planejamento para
cada iterao, bem como para a liberao total. Esta subseo descreve algumas das abordagens gil.
1.2.1 Abordagens de Desenvolvimento do Software gil

Existem vrias abordagens gil, sendo que cada qual implementa os valores e princpios do Manifesto gil de
maneiras diferentes. Neste programa, trs representantes de abordagens gil so considerados: Extreme
Programming (XP), Scrum, e Kanban.
Extreme Programming
Extreme Programming (XP), originalmente introduzido por Kent Beck [Beck04], uma abordagem gil para
desenvolvimento de software descrito por certos valores, princpios e prticas de desenvolvimento.
XP engloba cinco valores para orientar o desenvolvimento: comunicao, simplicidade, feedback, coragem e
respeito.
XP descreve um conjunto de princpios como diretrizes adicionais: humanidade, economia, benefcio mtuo,
auto similaridade, aperfeioamento, diversidade, reflexo, fluxo, oportunidade, redundncia, falha, qualidade,
primeiros passos e responsabilidade assumida.
XP descreve treze prticas principais: sentar-se juntos, a equipe inteira, espao de trabalho informativo,
trabalho energizado, programao em pares, estrias, ciclo semanal, ciclo trimestral, folga, elaborao de dez
minutos, integrao contnua, programao do teste primeiro e design incremental.
A maioria das abordagens de desenvolvimento do software gil em uso hoje so influenciados pelo XP e seus
valores e princpios. Por exemplo, as equipes geis que seguem o Scrum frequentemente incorporam as prticas
XP.
11
Certified Tester
Scrum
Scrum uma estrutura de gesto gil, que contm os seguintes instrumentos e prticas constituintes
[Schwaber01]:
Sprint: Scrum divide um projeto em iteraes (chamadas sprints) de durao fixa (geralmente duas a
quatro semanas).
Incremento do produto: Cada sprint resulta em um produto potencialmente libervel/entregvel
(chamado de incremento).
Backlog do Produto: O proprietrio do produto gerencia uma lista priorizada de itens de produtos
planejados (chamada backlog do produto). O backlog do produto evolui de sprint para sprint (chamado
refinamento de backlog).
Backlog do Sprint: No incio de cada sprint, a equipe Scrum seleciona um conjunto de itens de
prioridade mais elevada (o chamado backlog de sprint) do backlog do produto. Uma vez que a equipe
Scrum, e no o proprietrio do produto, seleciona os itens a serem realizados no sprint, a seleo
referida como sendo o princpio da atrao e no o princpio do impulso.
Definio de Pronto: Para verificar se h produto potencialmente libervel no final de cada sprint, a
equipe Scrum discute e define critrios adequados para a concluso do sprint. A discusso aprofunda
a compreenso da equipe dos itens do backlog e os requisitos do produto.
Timeboxing: Apenas as tarefas, requisitos ou funcionalidades que a equipe espera concluir no Sprint
fazem parte do backlog do sprint. Se a equipe de desenvolvimento no consegue terminar uma tarefa
em um sprint, as caractersticas de produtos associadas so removidas do Sprint e a tarefa restituda
ao backlog do produto. Timeboxing no se aplica apenas s tarefas, mas em outras situaes (por
exemplo, no incio e fim das reunies).
Transparncia: A equipe de desenvolvimento descreve e atualiza os status de sprint em uma base
diria, em reunio convocada em Scrum diariamente. Isso faz com que o contedo e o andamento do
sprint atual, incluindo resultados, sejam visveis para a equipe, gesto e todas as partes interessadas.
Por exemplo, a equipe de desenvolvimento pode mostrar o status de sprint em um quadro branco.
Scrum define trs funes:
Scrum Master: garante que as prticas e regras do Scrum sejam implementadas e seguidas, e resolve
quaisquer violaes, questes de funcionalidades, ou outros impedimentos que possam impedir a
equipe de seguir as prticas e regras. Esta pessoa no o lder da equipe, mas um treinador.
Proprietrio do Produto: representa o cliente, e gera, mantm e prioriza o backlog do produto. Esta
pessoa no o lder da equipe.
Equipe de Desenvolvimento: Desenvolver e testar o produto. O time auto organizado: No h lder
da equipe, pois a equipe toma as decises. A equipe tambm multifuncional (ver Seo 2.3.2 e Seo
3.1.4).
O Scrum (em oposio ao XP) no dita tcnicas de desenvolvimento de software especficos (por exemplo, o
primeiro teste de programao). Alm disso, o Scrum no fornece orientao sobre como o teste deve ser
realizado em um projeto Scrum.
Kanban
Kanban [Anderson13] uma abordagem de gesto que s vezes utilizada nos projetos geis. O objetivo geral
visualizar e otimizar o fluxo de trabalho em uma cadeia de valor agregado. Kanban utiliza trs instrumentos
[Linz14]:
Quadro Kanban: A cadeia de valor a ser gerenciada visualizada por um quadro de Kanban. Cada
coluna mostra uma estao, que um conjunto de atividades relacionadas, por exemplo,
desenvolvimento ou teste. Os itens a serem produzidos ou tarefas a serem processadas so
simbolizados por bilhetes se movendo da esquerda para a direita atravs do quadro por meio das
estaes.
Limite do Trabalho em Andamento: O volume de tarefas ativas paralelas estritamente limitado. Este
controlado pelo nmero mximo de passagens permitidas para uma estao e/ou globalmente para o
12
Certified Tester
quadro. Sempre que uma estao tem capacidade livre, o trabalhador tira um bilhete da estao
antecessora.
Tempo de espera: Kanban utilizado para otimizar o fluxo contnuo de tarefas, minimizando o tempo
de espera (mdia) para concluir o fluxo de valor.
Kanban apresenta algumas semelhanas com Scrum. Em ambos os quadros, visualizar as tarefas ativas (por
exemplo, em um quadro branco pblico) fornece transparncia de contedo e andamento das tarefas. Tarefas
no agendadas esto aguardando em um backlog e so transferidas para o quadro Kanban, assim que surge um
novo espao (capacidade de produo) disponvel.
Iteraes ou sprints so opcionais no Kanban. O processo de Kanban permite liberar seu item de entregas por
item, e no como parte de uma liberao. O Timeboxing como um mecanismo de sincronizao portanto,
opcional, diferentemente do Scrum, que sincroniza todas as tarefas em um sprint.
1.2.2 Criao Colaborativa da Estria do Usurio

Especificaes ineficientes so muitas vezes uma das principais razes para o fracasso do projeto. Problemas
de especificao podem resultar da falta de insight dos usurios sobre as suas verdadeiras necessidades,
ausncia de uma viso global do sistema, funcionalidades redundantes ou contraditrios, e outras falhas de
comunicao. No desenvolvimento gil, estrias de usurios so escritas para capturar os requisitos a partir
das perspectivas de desenvolvedores, testadores e representantes de negcio. Em desenvolvimento sequencial,
esta viso comum de uma funcionalidade realizada atravs de anlises formais aps a elaborao dos
requisitos; no desenvolvimento gil, esta viso compartilhada realizada atravs de revises informais
frequentes enquanto os requisitos esto sendo elaborados.
As estrias do usurio devem abordar caractersticas funcionais e no-funcionais. Cada estria inclui critrios
de aceitao para essas caractersticas. Esses critrios devem ser definidos em colaborao entre os
representantes de negcio, desenvolvedores e testadores. Eles oferecem aos desenvolvedores e testadores uma
viso ampliada da caracterstica que os representantes de negcio vo validar. Uma equipe gil considera uma
tarefa concluda quando um conjunto de critrios de aceitao foi atendido.
Normalmente, a perspectiva nica do testador ir melhorar a estria do usurio, identificando detalhes ausentes
ou requisitos no-funcionais. Um testador pode contribuir, formulando perguntas abertas aos representantes
de negcio sobre a estria do usurio, propondo formas de testar a estria do usurio, e confirmar os critrios
de aceitao.
A autoria colaborativa da estria do usurio pode usar tcnicas como brainstorming e mapas mentais. O
testador pode usar a tcnica INVEST [INVEST]:
Independente
Negocivel
Valioso
Estimvel
Pequeno (Small)
Testvel
De acordo com o conceito 3C [Jeffries00], uma estria de usurio a conjuno de trs elementos:
Carto: O carto o meio fsico que descreve uma estria de usurio. Ele identifica a exigncia, sua
criticidade, desenvolvimento esperado e durao do teste, e os critrios de aceitao para essa estria.
A descrio deve ser precisa, uma vez que ser utilizada no backlog do produto.
Conversacional: A conversa explica como o software ser usado. A conversa pode ser documentada
ou verbal. Os testadores, tendo um ponto de vista diferente em relao aos desenvolvedores e
representantes de negcio [ISTQB_FL_SYL], gera um elemento contributivo valioso para a troca de
ideias, opinies e experincias. A conversa comea durante a fase de planejamento de lanamento e
continua quando a estria programada.
13
Certified Tester
Confirmao: Os critrios de aceitao, discutidos na conversa, so utilizados para confirmar que a

estria foi realizada. Estes critrios de aceitao podem se estender por vrias estrias de usurios.
Ambos os testes positivos e negativos devem ser utilizados para abranger os critrios. Durante a
confirmao, vrios participantes desempenham a funo de um testador. Estes podem incluir
desenvolvedores, bem como especialistas com foco em desempenho, segurana, interoperabilidade e
outras caractersticas de qualidade. Para confirmar a realizao de uma estria, os critrios de aceitao
definidos devem ser testados e atendidos.
As equipes geis variam em termos de como eles documentam estrias de usurios. Independentemente da
abordagem adotada para documentar estrias de usurio, a documentao deve ser concisa, suficiente e
necessria.
1.2.3 Retrospectivas
No desenvolvimento gil, uma retrospectiva uma reunio realizada no final de cada iterao para discutir o
que foi bem sucedido, o que poderia ser melhorado e como incorporar as melhorias e preservar os xitos em
iteraes futuras. Retrospectivas abrangem temas como processo, pessoas, organizaes, relacionamentos e
ferramentas. Reunies retrospectivas regularmente realizadas, quando ocorrem atividades de acompanhamento
adequadas, so fundamentais para a auto-organizao e melhoria contnua de desenvolvimento e testes.
As retrospectivas podem resultar em decises de melhoria relacionadas com o teste, focadas na eficincia do
teste, produtividade do teste, qualidade do caso de teste e satisfao da equipe. Eles tambm podem abordar a
capacidade de teste dos aplicativos, estrias de usurios, funcionalidades ou interfaces do sistema. Anlise de
causa raiz de defeitos podem conduzir testes e desenvolvimento de melhorias. Em geral, as equipes devem
implementar apenas algumas melhorias em cada iterao. Isto permite a melhoria contnua a um ritmo
sustentado.
O tempo e a organizao da retrospectiva, depende do mtodo gil especfico seguido. Representantes de
negcio e da equipe assistem cada retrospectiva como participantes, enquanto o facilitador organiza e dirige a
reunio. Em alguns casos, as equipes podem convidar outros participantes para a reunio.
Os testadores devem desempenhar um papel importante nas retrospectivas. Os testadores so parte da equipe
e promovem sua perspectiva nica [ISTQB_FL_SYL], Seo 1.5. O teste ocorre em cada sprint e contribui
vitalmente para o sucesso. Todos os membros da equipe, testadores e no-testadores, podem fornecer
informaes sobre as atividades de teste e no-teste.
As retrospectivas devem ocorrer dentro de um ambiente profissional caracterizado pela confiana mtua. Os
atributos de uma retrospectiva de sucesso so os mesmos do que qualquer outro comentrio, conforme
discutido no programa Foundation Level [ISTQB_FL_SYL], Seo 3.2.
1.2.4 Integrao Contnua

O desenvolvimento de um incremento de produto requer software confivel integrado, atuando no final de
cada sprint. A Integrao contnua aborda este desafio atravs da fuso de todas as alteraes feitas no software
e integrao de todos os componentes alterados regularmente, pelo menos uma vez por dia. Gesto da
configurao, compilao, compilao de software, implementao e testes so envolvidos em um nico
processo repetitivo e automatizado. Visto que os desenvolvedores integram o seu trabalho constantemente,
constroem constantemente, e testam constantemente, os defeitos no cdigo so detectados mais rapidamente.
Na sequncia da codificao dos desenvolvedores, depurao e check-in de cdigo em um repositrio de
cdigo-fonte comum, um processo de integrao contnua composto pelas seguintes atividades
automatizadas:
Anlise esttica de cdigo: execuo de anlise esttica de cdigo e relatrios de resultados

Compilao: compilar e ligar o cdigo, gerando os arquivos executveis
Teste da unidade: executar os testes de unidade, verificando a cobertura de cdigo e relatando os
resultados dos testes
14
Certified Tester
Implantar: instalar o projeto em um ambiente de teste

Teste de integrao: executar os testes de integrao e relatar os resultados
Relatrio (dashboard): postar o status de todas essas atividades em um local publicamente visvel ou
status de e-mail visvel para a equipe
Um processo de construo e teste automatizado ocorre em uma base diria e detecta erros de integrao de
modo antecipado e rpido. A integrao contnua permite que os testadores geis realizem testes automatizados
regularmente, em alguns casos, como parte do prprio processo de integrao contnua, e enviar feedback
rpido para a equipe sobre a qualidade do cdigo. Estes resultados de testes so visveis para todos os membros
da equipe, especialmente quando os relatrios automatizados so integrados no processo. Teste de regresso
automatizada pode ser contnuo ao longo da iterao. Testes de regresso automatizados abrangem a maior
funcionalidade possvel, incluindo estrias de usurios desenvolvidos nas iteraes anteriores. Boa cobertura
nos testes de regresso automatizados ajuda no desenvolvimento (e teste) de grandes sistemas integrados.
Quando o teste de regresso automatizado, os testadores geis so livres para concentrar seus testes manuais
em novas funcionalidades, mudanas implementadas, e teste de confirmao de correes de defeitos.
Alm de testes automatizados, as organizaes que utilizam integrao contnua normalmente utilizam
ferramentas de desenvolvimento para implementar o controle de qualidade contnuo. Alm de realizar os testes
unitrios e de integrao, tais ferramentas podem realizar testes dinmicos e estticos adicionais, medida e
desempenho do perfil, extrato e formato de documentao a partir do cdigo-fonte, e facilitar os processos de
garantia de qualidade manuais. Esta aplicao contnua de controle de qualidade tem por objetivo melhorar a
qualidade do produto, bem como reduzir o tempo de desenvolvimento do mesmo, substituindo a prtica
tradicional de aplicao de controle da qualidade aps completar todo o desenvolvimento.
As ferramentas de desenvolvimento podem ser ligadas a ferramentas de implantao automtica, que podem
buscar o desenvolvimento adequado da integrao contnua ou desenvolver o servidor e implant-lo em um ou
mais de um desenvolvimento, teste, estgio, ou at mesmo ambientes de produo. Isso reduz os erros e atrasos
associados confiana na equipe especializada ou programadores para instalar os lanamentos nesses
ambientes.
A integrao contnua pode fornecer os seguintes benefcios:
Permite a deteco mais precoce e anlise mais fcil da causa raiz de problemas de integrao e
mudanas conflitantes
D o feedback regular da equipe de desenvolvimento se o cdigo estiver funcionando
Mantm a verso do software que est sendo testado dentro de um dia da verso que est sendo
desenvolvida
Reduz o risco de regresso associado com a reconstruo do cdigo do desenvolvedor devido ao rpido
reteste da base de cdigo aps cada pequeno conjunto de alteraes
Promove confiana de que o trabalho de desenvolvimento de cada dia fundamentado em uma base
slida
Realiza progresso em direo a concluso do incremento do produto visvel, encorajando
desenvolvedores e testadores
Elimina os riscos de programao associados integrao do big-bang
Fornece disponibilidade constante de software executvel em todo o sprint para fins de teste,
demonstrao ou de educao
Reduz as atividades de teste manuais repetitivas
Fornece feedback rpido sobre as decises tomadas para melhorar a qualidade e os testes
No entanto, a integrao contnua tem seus riscos e desafios:
Ferramentas de integrao contnua devem ser introduzidas e mantidas

O processo de integrao contnua deve ser definido e estabelecido.
A automao de teste exige funcionalidades adicionais e pode ser complexa para estabelecer
A cobertura completa de teste essencial para alcanar vantagens de teste automatizado
15
Certified Tester
As equipes, por vezes, confiam excessivamente nos testes da unidade e realizam muito pouco do teste
de sistema e de aceitao.
A integrao contnua requer o uso de ferramentas, incluindo ferramentas para testes, ferramentas para
automatizar o processo de construo e ferramentas para controle de verso.
1.2.5 Planejamento de Iterao e Lanamento

Como mencionado no programa Foundation Level [ISTQB_FL_SYL], o planejamento uma atividade em
curso, e este o caso nos ciclos de vida gil. Nos ciclos de vida gil, dois tipos de planejamento ocorrem,
planejamento de lanamento e planejamento de iterao.
O planejamento de liberao foca o lanamento de um produto, muitas vezes, alguns meses antes do incio de
um projeto. O planejamento do lanamento define e redefine o backlog do produto, e pode envolver o
refinamento de estrias de usurios maiores em uma coleo de estrias menores. O planejamento do
lanamento fornece a base para uma abordagem de teste e plano de teste que abrange todas as iteraes. Planos
de lanamento so de alto nvel.
No planejamento de lanamento, os representantes das empresas estabelecem e priorizam as estrias de
usurios para o lanamento, em colaborao com a equipe (ver Seo 1.2.2). Com base nessas estrias de
usurios, riscos associados a projetos e qualidade so identificados, e uma estimativa de esforo de alto nvel
desenvolvida (ver Seo 3.2).
Os testadores so envolvidos no planejamento do lanamento e, especialmente, agregar valor nas seguintes
atividades:
Definir estrias de usurios testveis, incluindo critrios de aceitao

Participao no projeto e anlise do risco da qualidade
Estimativa de esforo de teste associado s estrias do usurio
Definir os nveis de testes necessrios
Planejar o teste para o lanamento
Aps a realizao do planejamento de lanamento, o planejamento de iterao para a primeira iterao

iniciado. O planejamento de iterao foca o final de uma nica iterao e est relacionado ao backlog da
iterao.
No planejamento de iterao, a equipe seleciona estrias de usurio do backlog de liberao priorizados,
elabora estrias de usurios, realiza uma anlise de risco para as estrias de usurios e estima o trabalho
necessrio para cada estria de usurio. Se uma estria de usurio demasiado vago e tenta esclarecer que
falhou, a equipe pode se recusar a aceit-lo e utilizar a prxima estria de usurio baseada na prioridade. Os
representantes de negcio devem responder s perguntas da equipe sobre cada estria, de modo que a equipe
possa entender o que eles devem implementar e como testar cada estria.
O nmero de estrias selecionadas baseado na velocidade da equipe estabelecida e no tamanho estimado de
estrias de usurios selecionadas. Aps a finalizao do contedo da iterao, as estrias de usurios so
divididas em tarefas, que sero realizadas pelos membros apropriados da equipe.
Os testadores so envolvidos no planejamento de iterao, e especialmente, agregar valor nas seguintes
atividades:
Participar da anlise de risco detalhada de estrias de usurios

Determinar a testabilidade das estrias de usurios
Criar testes de aceitao para estrias de usurios
Dividir estrias de usurios em tarefas (particularmente tarefas de teste)
Estimativa de esforo de teste para todas as tarefas de teste
Identificar os aspectos funcionais e no funcionais do sistema a ser testado
Apoiar e participar em automao de testes em vrios nveis de testes
16
Certified Tester
Planos de lanamento podem mudar medida que o projeto avana, incluindo alteraes em estrias de
usurios individuais no backlog do produto. Estas alteraes podem ser desencadeadas por fatores internos ou
externos. Os fatores internos incluem capacidade de desenvolvimento, velocidade e questes tcnicas. Os
fatores externos incluem a descoberta de novos mercados e oportunidades, novos concorrentes, ou ameaas de
negcios que podem mudar os objetivos de lanamento e/ou prazos. Alm disso, os planos de iterao podem
mudar durante uma iterao. Por exemplo, uma estria de usurio particular, que foi considerado relativamente
simples durante a estimativa pode ser mais complexo do que o esperado.
Essas mudanas podem ser um desafio para os testadores. Os testadores devem compreender o panorama do
lanamento para fins de planejamento de teste, e devem ter uma base de teste e orculo de teste adequado em
cada iterao para fins de desenvolvimento de teste, como discutido no programa Foundation Level
[ISTQB_FL_SYL], Seo 1.4. As informaes solicitadas devem estar disponveis com antecedncia para o
testador, e ainda a mudana deve ser adotada de acordo com os princpios geis. Este dilema requer decises
cuidadosas sobre as estratgias de teste e documentao de teste. Para saber mais sobre desafios de testes geis,
ver [Black09], captulo 12.
O planejamento de lanamento e iterao deve abordar o plano de teste, bem como o planejamento de
atividades de desenvolvimento. Questes relacionadas com o ensaio especfico a abordar incluem:
O escopo dos testes, a extenso dos testes para as reas de escopo, os objetivos de teste, e as razes
para tais decises.
Os membros da equipe que realizaro as atividades de teste.
O ambiente de teste e dados de teste necessrios, quando eles so necessrios, e se quaisquer
acrscimos ou alteraes no ambiente de teste e/ou dados ocorrero antes ou durante o projeto.
O tempo, sequenciamento, dependncias e pr-requisitos para as atividades de teste funcional e nofuncional (por exemplo, a frequncia de realizao de testes de regresso, cujos funcionalidades
dependem de outras funcionalidades ou dados de teste, etc), incluindo a forma como as atividades de
teste se relacionam e dependem das atividades de desenvolvimento.
O projeto e riscos da qualidade a serem abordados (ver Seo 3.2.1).
Alm disso, a maior estimativa de esforo da equipe deve ter em considerao o tempo e o esforo necessrios
para completar as atividades de testes necessrios.
17
Certified Tester
2. Princpios Fundamentais do Teste gil, Prticas e Processos 105 mins.

Palavras-chave.
Elaborar teste de verificao, item de configurao, gesto da configurao
Objetivos de Aprendizado para Princpios Fundamentais do Teste gil, Prticas e Processos

2.1 As Diferenas entre os Testes em abordagens tradicionais e do gil
FA-2.1.1 (K2) Descrever as diferenas entre as atividades de teste em projetos geis e projetos no
geis.
FA-2.1.2 (K2) Descrever como as atividades de desenvolvimento e teste so integradas nos projetos geis
FA-2.1.3 (K2) Descrever a funo dos testes independentes em projetos geis
2.2 Status de testes em Projetos geis
FA-2.2.1 (K2) Descrever as ferramentas e tcnicas utilizadas para comunicar o status de teste em um projeto
gil, incluindo a evoluo de teste e qualidade do produto
FA-2.2.2 (K2) Descrever o processo de evoluo de testes em vrias iteraes e explicar por que a automao
de teste importante para gerir o risco de regresso em projetos geis
2.3 Funo e Habilidades de um Testador em uma equipe gil
FA-2.3.1 (K2) Compreender as habilidades (pessoas, domnio e teste) de um testador em uma equipe gil
FA-2.3.2 (K2) Compreender a funo de um testador na equipe gil
18
Certified Tester
2.1 As Diferenas entre os Testes em abordagens tradicionais e no gil
Conforme descrito no programa Foundation Level [ISTQB_FL_SYL] e em [Black09], atividades de teste esto
relacionadas com as atividades de desenvolvimento e, portanto, o teste varia em diferentes ciclos de vida. Os
testadores devem compreender as diferenas entre os testes em modelos de ciclo de vida tradicionais
(sequencial, por exemplo, tais como o modelo V ou interativo, tais como RUP) e ciclos de vida gil, a fim de
trabalhar de forma eficaz e eficiente. Os modelos geis diferem quanto o modo pelo qual as atividades de teste
e desenvolvimento so integradas, os produtos do projeto de trabalho, os nomes, critrios de entrada e sada
utilizados para vrios nveis de testes, o uso de ferramentas, e como o teste independente pode ser efetivamente
utilizado.
Os testadores devem se lembrar de que as organizaes variam consideravelmente em sua implementao de
ciclos de vida. O desvio dos ideais de ciclos de vida gil (ver Seo 1.1) pode representar personalizao
inteligente e adaptao das prticas. A capacidade de adaptar-se ao contexto de um dado projeto, incluindo as
prticas de desenvolvimento de software seguidas, na verdade um fator chave de sucesso para os testadores.
2.1.1 Atividades de Teste e Desenvolvimento

Uma das principais diferenas entre os ciclos de vida tradicionais e os ciclos de vida gil a ideia de iteraes
muito curtas, cada iterao resultando em um software que oferece funcionalidades de valor para as partes
interessadas. No incio do projeto, h um perodo de planejamento de lanamento. Isto seguido por uma
sequncia de iteraes. No incio de cada iterao, h um perodo de planejamento de iterao. Aps o
estabelecimento do escopo da iterao, as estrias de usurios selecionadas so desenvolvidas, integrados com
o sistema, e testados. Estas iteraes so altamente dinmicas, com o desenvolvimento, integrao e atividades
de teste que ocorrem ao longo de cada iterao, e com paralelismo e sobreposio considerveis. Atividades
de teste ocorrem durante toda a iterao, e no como uma atividade final.
Testadores, desenvolvedores e as partes interessadas do negcio tm uma funo nos testes, assim como com
os ciclos de vida tradicionais. Os desenvolvedores executam testes de unidade conforme eles desenvolvem as
funcionalidades das estrias de usurios. Testadores testam essas funcionalidades. As partes interessadas
tambm testam as estrias durante a implementao. As partes interessadas podem usar casos de teste escritos,
mas tambm podem simplesmente experimentar e usar a funcionalidade, a fim de fornecer um feedback rpido
para a equipe de desenvolvimento.
Em alguns casos, as iteraes de amadurecimento ou de estabilizao ocorrem periodicamente para resolver
quaisquer defeitos remanescentes e outras formas de dvida tcnica. No entanto, a melhor prtica que
nenhuma funcionalidade seja considerada feito at que tenha sido integrado e testado com o sistema
[Goucher09]. Outra boa prtica tratar defeitos remanescentes da iterao anterior, no incio da prxima
iterao, como parte do backlog para a iterao (referido como "corrigir bugs em primeiro lugar"). No entanto,
alguns queixam-se que esta prtica resulta numa situao em que o trabalho total a ser feito na iterao
desconhecido, e que vai ser mais difcil estimar quando as funcionalidades restantes podem ser realizadas. No
final da sequncia de iteraes, pode haver um conjunto de atividades de lanamento para obter o software
pronto para entrega, embora em alguns casos, ocorra a liberao no fim de cada iterao.
Quando o teste baseado em risco usado como uma das estratgias de teste, uma anlise de risco de alto nvel
ocorre durante o planejamento do lanamento, com testadores muitas vezes conduzindo tal anlise. No entanto,
os riscos especficos de qualidade associados a cada iterao so identificados e avaliados no planejamento da
iterao. Esta anlise de risco pode influenciar a sequncia de desenvolvimento, assim como a prioridade e
profundidade do teste para as funcionalidades. Da mesma forma, influencia a estimativa do esforo de teste
necessrio para cada funo (ver Seo 3.2).
Em algumas prticas geis (por exemplo, Extreme Programming), o emparelhamento usado. O
emparelhamento pode envolver testadores trabalhando juntos em pares para testar a funcionalidade. O
emparelhamento tambm pode envolver um testador atuando em colaborao com um desenvolvedor para
desenvolver e testar uma funcionalidade. O emparelhamento pode ser difcil quando a equipe de teste est
19
Certified Tester
distribuda, mas os processos e as ferramentas podem ajudar a viabilizar o emparelhamento distribudo. Para
obter mais informaes sobre o trabalho distribudo, ver [ISTQB_ALTM_SYL], Seo 2.8.
Os testadores tambm podem servir como treinadores de teste e qualidade dentro da equipe, compartilhando
conhecimentos de teste e apoiando o trabalho de garantia de qualidade dentro da equipe. Isto promove um
senso de responsabilidade coletiva na qualidade do produto.
A automao em todos os nveis de testes ocorre em muitas equipes geis, e isso pode significar que os
testadores gastam mais tempo na criao, execuo, monitoramento e manuteno de testes automatizados e
em resultados. Devido ao pesado uso da automao de testes, uma percentagem mais elevada do teste manual
nos projetos geis tende a ser feita usando tcnicas baseadas em experincia e defeitos, tais como ataques de
software, testes exploratrios, e suposio de erro (ver [ISTQB_ALTA_SYL], Sees 3.3 e 3.4 e
[ISTQB_FL_SYL], Seo 4.5). Enquanto os desenvolvedores se concentram na criao de testes de unidade,
os testadores devem se concentrar na criao de testes de integrao, sistema e integrao de sistemas
automatizados. Isto leva a uma tendncia das equipes geis em favorecer os testadores com uma slida
formao tcnica e background de automao de testes.
Um princpio fundamental gil que pode ocorrer mudana durante o projeto. Portanto, uma documentao
do produto de trabalho leve favorecida nos projetos geis. Mudanas nas funcionalidades existentes tm
implicaes de teste, especialmente implicaes de teste de regresso. O uso de testes automatizados uma
forma de gerenciar o volume de esforo de teste associado com a mudana. No entanto, importante que a
taxa de variao no exceda a capacidade da equipe do projeto de lidar com os riscos associados a essas
mudanas.
2.1.2 Produtos de Trabalho do Projeto

Os produtos de trabalho do projeto de interesse imediato para testadores geis tipicamente se enquadram em
trs categorias:
1.
2.
3.
Produtos de trabalho orientados para negcios que descrevem o que necessrio (por exemplo, requisitos
de especificaes) e como us-los (por exemplo, a documentao do usurio)
Produtos de trabalho de desenvolvimento que descrevem como o sistema construdo (por exemplo,
diagramas de banco de dados entidade-relacionamento), que, na verdade, implementam o sistema (por
exemplo, cdigo), ou que avaliam peas individuais de cdigo (por exemplo, testes de unidade
automatizados)
Produtos de trabalho de teste que descrevem como o sistema testado (por exemplo, estratgias de teste
e planos), que realmente testam o sistema (por exemplo, testes manuais e automatizados), ou que
apresentam os resultados do teste (por exemplo, painis de teste, conforme discutido na seo 2.2.1)
Em um projeto tpico gil, uma prtica comum evitar a produo de grandes volumes de documentao. Ao
contrrio, o foco mais em ter um software funcionando em conjunto com os testes automatizados que
demonstrem o cumprimento das exigncias. Este incentivo para reduzir a documentao se aplica apenas
documentao que no atribui valor ao cliente. Em um projeto gil bem sucedido, estabelece-se um equilbrio
entre o aumento da eficincia atravs da reduo de documentao e fornecimento de documentao suficiente
para apoiar as atividades de negcios, testes, desenvolvimento e manuteno. A equipe deve tomar uma
deciso durante o planejamento do lanamento sobre quais produtos de trabalho so necessrios e qual o nvel
necessrio de documentao do produto do trabalho.
Os tpicos produtos de trabalho orientados para o negcio nos projetos geis incluem estrias de usurios e
critrios de aceitao. Estrias de usurios so o formulrio gil de especificaes de requisitos, e devem
explicar como o sistema deve se comportar em relao a uma funcionalidade nica coerente ou funo. Uma
estria de usurio deve definir uma funcionalidade suficientemente pequeno para ser concludo em uma nica
iterao. Coletas maiores de funcionalidades relacionados, ou uma coleta de sub-funcionalidades que
compem uma nica caracterstica complexa, podem ser referidas como "picos". picos podem incluir
estrias de usurios para diferentes equipes de desenvolvimento. Por exemplo, uma estria de usurio pode
descrever o que necessrio no nvel API (middleware), enquanto uma outra estria descreve o que
20
Certified Tester
necessrio ao nvel UI (aplicativo). Essas coletas podem ser desenvolvidas atravs de uma srie de sprints.
Cada pico e suas estrias de usurios devem ter critrios de aceitao associados.
Produtos tpicos de trabalho do desenvolvedor em projetos gil incluem cdigo. Desenvolvedores geis
tambm muitas vezes criam testes de unidade automatizados. Estes testes podem ser criados aps o
desenvolvimento do cdigo. Em alguns casos, no entanto, os desenvolvedores criam testes de modo
incremental antes que cada parte do cdigo seja escrita, afim de proporcionar um modo de verificao, uma
vez que aquela parte do cdigo seja escrita, se funciona como o esperado. Embora esta abordagem seja referida
como primeiro teste ou desenvolvimento orientado a testes, na realidade, os testes so mais uma forma de
especificaes de projeto de baixo nvel executveis, ao invs de testes [Beck02].
Produtos tpicos de trabalho do testador em projetos gil incluem testes automatizados, bem como documentos
como planos de teste, catlogos de risco de qualidade, testes manuais, relatrios de defeitos e logs de resultados
de testes. Os documentos so capturados da forma mais leve possvel, o que muitas vezes ocorre com estes
documentos nos ciclos de vida tradicionais. Os testadores tambm vo produzir mtricas de teste ao partir de
relatrios de defeitos e logs de resultados de testes, e novamente, h uma nfase em uma abordagem leve.
Em algumas implementaes geis, especialmente reguladas, segurana crtica, projetos e produtos
distribudos ou altamente complexos, necessria uma maior formalizao desses produtos de trabalho. Por
exemplo, algumas equipes transformam estrias de usurios e critrios de aceitao em mais especificaes
de requisitos formais. Relatrios de rastreabilidade vertical e horizontal podem ser preparados para atender os
auditores, regulamentos e outros requisitos.
2.1.3 Nveis de Teste

Nveis de teste so atividades de teste que so logicamente relacionadas, muitas vezes, pela maturidade ou
integridade do item em teste.
Nos modelos do ciclo de vida sequencial, os nveis de teste so geralmente definidos de modo que os critrios
de sada de um nvel sejam parte dos critrios de entrada para o prximo nvel. Em alguns modelos iterativos,
esta regra no se aplica. Os nveis de teste se sobrepem. Especificao de requisitos, especificao de design
e atividades de desenvolvimento podem sobrepor-se com os nveis de teste.
Em alguns ciclos de vida geis, a sobreposio ocorre porque as mudanas nos requisitos, projeto e cdigo
podem acontecer a qualquer momento em uma iterao. Embora o Scrum, em tese, no permite alteraes nas
estrias de usurios aps o planejamento da iterao, na prtica, essas mudanas ocorrem ocasionalmente.
Durante uma iterao, qualquer estria de usurio geralmente progride sequencialmente atravs das seguintes
atividades de teste:
Teste de unidade, normalmente feito pelo desenvolvedor

Teste de aceitao da funcionalidade, que s vezes dividido em duas atividades:
o Testes de verificao de funcionalidades, que muitas vezes automatizado, podem ser feitos
por desenvolvedores ou testadores, e envolve testes contra os critrios de aceitao da estria
do usurio
o Testes de validao de funcionalidades, que normalmente manual e pode envolver
desenvolvedores, testadores e partes interessadas que trabalham de forma colaborativa para
determinar se a funcionalidade est apta para uso, para melhorar a visibilidade dos progressos
realizados, e receber feedback real das partes interessadas.
Alm disso, h muitas vezes um processo paralelo de testes de regresso que ocorre em toda a iterao. Tratase de reexecutar os testes de unidade automatizados e testes de verificao da funcionalidade da iterao atual
e iteraes anteriores, geralmente atravs de uma estrutura de integrao contnua.
Em alguns projetos geis, pode haver um nvel de teste do sistema, uma vez que se inicia a primeira estria de
usurio pronto para tais testes. Isso pode envolver a execuo de testes funcionais, bem como testes nofuncionais de desempenho, confiabilidade, usabilidade, e outros tipos de teste pertinentes.
21
Certified Tester
As equipes geis podem empregar diversas formas de testes de aceitao (usando o termo conforme explicado
no programa Foundation Level [ISTQB_FL_SYL]). Testes alfa Internos e testes beta externos podem ocorrer,
quer no final de cada iterao, aps a concluso de cada iterao, ou aps uma srie de iteraes. Testes de
aceitao do usurio, testes de aceitao operacionais, testes de aceitao de regulamentao e testes de
aceitao do contrato tambm podem ocorrer, ou no final de cada iterao, aps a concluso de cada iterao,
ou aps uma srie de iteraes.
2.1.4 Gesto de Testes e configurao

Os projetos geis frequentemente envolvem o uso pesado de ferramentas automatizadas para desenvolver,
testar e gerenciar o desenvolvimento de software. Os desenvolvedores usam ferramentas para anlise esttica,
testes unitrios e de cobertura de cdigo. Os desenvolvedores verificam continuamente o cdigo e os testes da
unidade em um sistema de gerenciamento de configurao, utilizando estruturas automatizadas de
desenvolvimento e teste. Estas estruturas permitem a integrao contnua do novo software com o sistema,
com a anlise esttica e testes de unidade realizados repetidamente conforme o novo software verificado em
[Kubaczkowski].
Estes testes automatizados tambm podem incluir testes funcionais nos nveis de integrao e de sistema. Tais
testes automatizados funcionais podem ser criados usando chicotes funcionais de teste, interface de usurio
open-source, ferramentas de teste funcionais, ou ferramentas de negcio, e podem ser integrados com os testes
automatizados executados como parte da estrutura de integrao contnua. Em alguns casos, devido durao
dos testes funcionais, os testes funcionais so separados dos testes de unidade e executados com menos
frequncia. Por exemplo, os testes de unidade podem ser executados cada vez que um novo software
verificado, enquanto os testes funcionais mais longos so executados apenas por alguns dias.
Um dos objetivos dos testes automatizados confirmar que o projeto est funcionando e instalvel. Se algum
teste automatizado falhar, a equipe deve corrigir o defeito subjacente a tempo para a prxima verificao do
cdigo. Isto requer um investimento em relatrios de teste em tempo real para fornecer uma boa visibilidade
em resultados de testes. Essa abordagem ajuda a reduzir os ciclos caros e ineficientes de "projetar-instalarfalhar-reprojetar-reinstalar" que pode ocorrer em muitos projetos tradicionais, uma vez que as mudanas que
ocasionam a falha no projeto do software na instalao so detectadas rapidamente.
As ferramentas automatizadas de teste e projeto ajudam a gerir o risco de regresso associado mudana
frequente que muitas vezes ocorre nos projetos geis. No entanto, a excessiva dependncia de teste de unidade
automatizada isolada para administrar esses riscos pode ser um problema, pois o teste de unidade muitas vezes
tem limitado a eficcia de deteco de defeitos [Jones11]. Os testes automatizados nos nveis de integrao e
de sistema tambm so necessrios.
2.1.5 Opes Organizacionais para Teste Independente

Como discutido no programa Foundation Level [ISTQB_FL_SYL], os testadores independentes so muitas
vezes mais eficazes na deteco de defeitos. Em algumas equipes geis, os desenvolvedores criam muitos dos
testes na forma de testes automatizados. Um ou mais testadores podem ser embutidos dentro da equipe,
realizando muitas das tarefas de teste. No entanto, dada a posio desses testadores dentro da equipe, h um
risco de perda de independncia e avaliao objetiva.
Outras equipes geis mantm equipes de teste totalmente separadas e independentes, e atribuem testadores sob
demanda durante os dias finais de cada sprint. Isso pode preservar a independncia, e esses testes podem
fornecer uma avaliao objetiva e imparcial do software. No entanto, as presses de tempo, a falta de
compreenso das novas funcionalidades do produto e problemas de relacionamento com as partes interessadas
e desenvolvedores muitas vezes levam a problemas com essa abordagem.
Uma terceira opo ter uma equipe de teste separada e independente onde os testadores so designados para
as equipes geis em uma base de longo prazo, no incio do projeto, permitindo-lhes manter a sua independncia
ao adquirir um bom entendimento do produto e das relaes fortes com outros membros da equipe. Alm disso,
a equipe de teste independente pode ter testadores especializados fora das equipes geis para trabalhar em
22
Certified Tester
atividades independentes de longo prazo e/ou iterao, tais como o desenvolvimento de ferramentas de teste
automatizado, a realizao de teste no funcional, criar e apoiar ambientes de teste e de dados, e realizao de
nveis de teste que pode no se encaixar bem em um sprint (por exemplo, teste de integrao do sistema).
2.2 Status de Teste em Projetos gil

A mudana ocorre rapidamente nos projetos gil. Esta mudana significa que o status do teste, o progresso de
teste e a qualidade do produto evoluem constantemente, e os testadores devem elaborar maneiras de obter essas
informaes para a equipe, para que possam tomar decises para se manterem no caminho certo para a
concluso de cada iterao. Alm disso, a mudana pode afetar as funcionalidades existentes de iteraes
anteriores.
Portanto, os testes manuais e automatizados devem ser atualizados para lidar eficazmente com risco de regresso.
2.2.1 Comunicao do Status, Progresso de Teste e Qualidade de Produto

As equipes geis progridem tendo o software funcionando no final de cada iterao. Para determinar quando
a equipe estar trabalhando com o software, eles precisam monitorar o progresso de todos os itens de trabalho
na iterao e lanamento. Os testadores nas equipes geis utilizam vrios mtodos para registrar o progresso e
o status do teste, incluindo os resultados dos testes de automao, progresso das tarefas de teste e estrias
sobre o quadro de tarefas geis e grficos burndown que mostram o progresso da equipe. Estes podem ento
ser comunicados ao resto da equipe, usando a mdia, como painis de wiki e e-mails do tipo painel, bem como
verbalmente durante as reunies. Equipes geis podem usar ferramentas que geram automaticamente relatrios
de status com base em resultados de testes e progresso da tarefa, que por sua vez atualizam dashboards e emails no estilo wiki. Este mtodo de comunicao rene tambm as mtricas do processo de teste, que podem
ser utilizadas na melhoria do processo. A comunicao do status de teste em tal modo automatizado tambm
libera o tempo dos testadores para se concentrar na concepo e execuo de mais casos de teste.
As equipes podem usar grficos de burndown para acompanhar o progresso em todo o lanamento e em
cada iterao. Um grfico burndown [Crispin08] representa o volume de trabalho a ser realizado contra o
tempo alocado para o lanamento ou iterao.

Para fornecer uma representao visual instantnea e detalhada do status atual de toda a equipe, incluindo
o status de teste, as equipes podem usar quadros de tarefas geis. Os cartes de estria, tarefas de
desenvolvimento, tarefas de teste e outras tarefas criadas durante o planejamento da iterao (ver Seo 1.2.5)
so capturados no quadro de tarefas, muitas vezes utilizando cartes de cores coordenadas para determinar o
tipo de tarefa. Durante a iterao, o progresso gerido atravs do movimento dessas tarefas em todo o quadro
de tarefas em colunas tais como trabalho a fazer, trabalho em andamento, verificar e trabalho realizado.
Equipes geis podem utilizar ferramentas para manter seus cartes de estria e quadros de tarefas geis, que
podem automatizar dashboards e atualizaes de status.
As tarefas de teste no quadro de tarefas se relacionam com os critrios de aceitao definidos para os estrias
de usurios. Como scripts de automao de teste, testes manuais e testes exploratrios para uma tarefa de teste
atingem um status de passagem, a tarefa passa para a coluna trabalho realizado do quadro de tarefas. A equipe
inteira analisa o status do quadro de tarefas regularmente, muitas vezes durante as reunies dirias, para
assegurar que as tarefas esto se movendo em todo o quadro a um ritmo aceitvel. Se alguma tarefa (incluindo
tarefas de teste) no estiver se movendo ou estiver se movendo muito lentamente, a equipe comenta e aborda
todas as questes que possam estar bloqueando o progresso dessas tarefas.
A reunio diria inclui todos os membros da equipe geis, incluindo testadores. Nessa reunio, eles comunicam
seu status atual. A agenda de cada membro [Guia do gil Alliance]:
O que voc concluiu desde a ltima reunio?

O que voc planeja concluir at a prxima reunio?
O que voc est bloqueando o seu caminho?
23
Certified Tester
Quaisquer problemas que possam bloquear o progresso dos testes so comunicados durante as reunies dirias,
para que toda a equipe esteja ciente dos problemas e possa resolv-los em conformidade.
Para melhorar a qualidade geral do produto, muitas equipes geis realizam pesquisas de satisfao dos clientes
para receber feedback sobre se o produto atende as expectativas dos clientes. As equipes podem utilizar outras
mtricas semelhantes s capturadas em metodologias de desenvolvimento tradicionais, tais como taxas de
aprovao/reprovao de teste, taxas de deteco de defeitos, resultados de teste de confirmao e regresso,
densidade de defeitos, defeitos detectados e corrigidos, cobertura de requisitos, cobertura de riscos, cobertura
de cdigo, e rotatividade do cdigo para melhorar a qualidade do produto.
Como acontece com qualquer ciclo de vida, as mtricas capturadas e relatadas devem ser relevantes e ajudam
na tomada de decises. As mtricas no devem ser utilizadas para premiar, punir ou afastar quaisquer membros
da equipe.
2.2.2 Gesto de Risco de Regresso com Evoluo dos Casos de Teste Manuais e
Automatizado
Em um projeto gil, assim que cada iterao concluda, o produto cresce. Por conseguinte, no mbito dos
testes, tambm aumenta. Juntamente com o teste das alteraes no cdigo na iterao atual, os testadores
tambm precisam verificar se alguma regresso foi introduzida nas funcionalidades que foram desenvolvidos
e testados em iteraes anteriores. O risco de introduzir uma regresso no desenvolvimento gil alto, devido
ao cdigo extenso (linhas de cdigo adicionadas, modificadas ou apagadas de uma verso para outra). Visto
que responder mudana um princpio chave gil, as mudanas tambm podem ser feitas em funcionalidades
anteriormente desenvolvidos para atender s necessidades comerciais. A fim de manter a velocidade sem
incorrer em um grande volume de dvida tcnica, fundamental que as equipes invistam em automao de
testes em todos os nveis de teste o mais cedo possvel. Tambm fundamental que todos os ativos de teste,
tais como testes automatizados, casos de teste manuais, dados de teste e outros artefatos de teste sejam
mantidos atualizados com cada iterao. altamente recomendvel que todos os ativos de teste sejam mantidos
em uma ferramenta de gesto de configurao, a fim de permitir o controle de verso, para assegurar a
facilidade de acesso por todos os membros da equipe, e para apoiar as alteraes necessrias devido mudana
de funcionalidade e ainda preservar a informao histrica dos ativos de teste.
Como a repetio completa de todos os testes raramente possvel, especialmente em projetos geis com
cronograma apertado, os testadores precisam alocar tempo em cada iterao para rever casos de teste manuais
e automatizados de iteraes anteriores e atuais para selecionar casos de teste que podem ser candidatos ao
teste de regresso, e para retirar casos de teste que no so mais relevantes. Testes escritos em iteraes
anteriores para verificar funcionalidades especficos podem ter pouco valor em iteraes posteriores devido a
alteraes de funcionalidades ou novas funcionalidades que alteram a forma como essas funcionalidades
anteriores se comportam.
Ao rever os casos de teste, os testadores devem considerar a adequao para automao. A equipe precisa
automatizar o mximo de testes possveis de iteraes anteriores e atuais. Isso permite que os testes de
regresso automatizados reduzam o risco de regresso com menos esforo do que os testes de regresso manual
exigiriam. Este esforo de teste de regresso reduzido libera os testadores para testar mais a fundo novos
funcionalidades e funes na iterao atual.
fundamental que os testadores tenham a capacidade de identificar rapidamente e atualizar os casos de teste
a partir de iteraes e/ou verses anteriores que so afetadas pelas alteraes feitas na iterao atual. Definir
como a equipe projeta, escreve e armazena casos de teste deve ocorrer durante o planejamento do lanamento.
Boas prticas para a modelagem de teste e implementao precisam ser aprovadas no incio e aplicadas de
forma consistente. Os prazos mais curtos para testes e a mudana constante em cada iterao ir aumentar o
impacto do projeto de teste e das prticas de implementao ineficientes.
Uso de automao de teste, em todos os nveis de teste, permite que equipes geis forneam feedback rpido
sobre a qualidade do produto. Testes automatizados bem escritos fornecem um documento vivo da
funcionalidade do sistema [Crispin08]. Ao verificar os testes automatizados e os resultados dos testes
24
Certified Tester
correspondentes no sistema de gerenciamento de configurao, em conformidade com a verso do produto, as
equipes geis podem rever a funcionalidade testada e os resultados do teste de uma determinada configurao
a qualquer momento.
Testes de unidade automatizados so executados antes que o cdigo fonte seja marcado na linha principal do
sistema de gesto de configurao para garantir que as alteraes de cdigo no prejudiquem o
desenvolvimento do software. Para reduzir prejuzos no desenvolvimento, que podem retardar o progresso de
toda a equipe, o cdigo no deve ser verificado, a menos que todos os testes de unidade automatizados sejam
aprovados. Os resultados do teste de unidade automatizados fornecem feedback imediato quanto ao cdigo e
a qualidade do projeto, mas no quanto qualidade do produto.
Testes de aceitao automatizados so executados regularmente, como parte da integrao contnua completa
do projeto do sistema. Estes testes so executados com referncia um projeto do sistema completo, pelo
menos diariamente, mas geralmente no so realizados com cada verificao do cdigo, pois eles levam mais
tempo para executar do que os testes de unidade automatizados e podem atrasar a verificao do cdigo Os resultados dos testes de aceitao automatizados fornecem feedback sobre a qualidade do produto em
relao a regresso desde a ltima compilao, mas no fornecem status da qualidade geral do produto.
Os testes automatizados podem ser executados de forma contnua em relao ao sistema. Um subconjunto
inicial de testes automatizados para cobrir a funcionalidade crtica do sistema e pontos de integrao deve ser
criado imediatamente aps uma nova compilao ser implantada no ambiente de teste. Estes testes so
comumente conhecidos como testes de verificao de compilao. Os resultados dos testes de verificao de
compilao vo fornecer um feedback instantneo sobre o software aps a implantao, para que as equipes
no percam tempo testando uma configurao instvel.
Os testes automatizados contidos no conjunto de testes de regresso so geralmente executados como parte da
compilao principal diria no ambiente de integrao contnua, e novamente quando uma nova compilao
implantada no ambiente de teste. Quando um teste de regresso automatizado falha, a equipe interrompe as
atividades e investiga as razes da falha do teste. O teste pode ter falhado devido a alteraes funcionais
legtimas na iterao atual; neste caso, a estria de teste e/ou usurio pode precisar ser atualizado para refletir
os novos critrios de aceitao. Alternativamente, o teste pode ter que ser retirado se outro teste foi compilado
para cobrir as modificaes. No entanto, se o teste falhou devido a um defeito, uma boa prtica para a equipe
corrigir o defeito antes de avanar com novas funcionalidades.
Alm da automao de teste, as seguintes tarefas de teste tambm podem ser automatizadas:
Gerao de dados de teste

Carregamento dos dados de teste nos sistemas
Implantao de compilaes para os ambientes de teste
Restaurao de um ambiente de teste (por exemplo, os arquivos de dados do banco de dados ou site)
para uma linha de base
Comparao das sadas de dados
A automao destas tarefas reduz a sobrecarga e permite que a equipe tenha tempo para desenvolver e testar
novos funcionalidades.
2.3 Funo e Habilidades de um Testador em uma equipe gil

Em uma equipe gil, testadores devem colaborar estreitamente com todos os outros membros da equipe e com
as partes interessadas. Isso tem uma srie de implicaes em termos das habilidades que um testador deve ter
e as atividades que eles realizam em uma equipe gil.
2.3.1 Habilidades do Testador do gil

Os testadores geis devem ter todas as habilidades mencionadas no programa Foundation Level
[ISTQB_FL_SYL]. Alm dessas habilidades, um testador em uma equipe do gil deve ser competente em
25
Certified Tester
automao de testes, desenvolvimento orientado a testes, aceitao desenvolvimento orientado a aceitao,
caixa branca, caixa-preta, e testes baseados em experincia.
Como as metodologias do gil dependem muito da colaborao, comunicao e interao entre os membros
da equipe, bem como das partes interessadas fora da equipe, os testadores em uma equipe do gil devem ter
boas habilidades interpessoais. Os testadores nas equipes do gil devem:
Ser positivos e orientados para soluo com os membros da equipe e partes interessadas
Mostrar pensamento crtico e ctico orientado para a qualidade, sobre o produto
Ativamente adquirir informaes das partes interessadas (ao invs de confiar inteiramente em
especificaes escritas)
Avaliar com preciso e relatar os resultados dos testes, o progresso de teste e qualidade do produto
Trabalhar efetivamente para definir estrias de usurios testveis, especialmente os critrios de
aceitao, com representantes dos clientes e partes interessadas
Colaborar dentro da equipe, trabalhando em pares com os programadores e outros membros da equipe
Responder mudana rapidamente, incluindo alterao, adio ou melhora dos casos de teste
Planejar e organizar o seu prprio trabalho.
Crescimento contnuo de competncias, incluindo o crescimento de habilidades interpessoais, essencial para

todos os testadores, incluindo aqueles das equipes do gil.
2.3.2 Funo de um Testador em uma equipe do gil

A funo de um testador em uma equipe gil inclui atividades que geram e fornecem feedback, no s no
status de teste, progresso de teste e qualidade do produto, mas tambm na qualidade do processo. Alm das
atividades descritas em outra parte deste programa, essas atividades incluem:
Compreender, implementar e atualizar a estratgia de teste

Medir e informar a cobertura do teste em todas as dimenses de cobertura aplicveis
Garantir o uso adequado de ferramentas de teste
Configurar, utilizar e gerenciar ambientes de teste e dados de teste
Relatar defeitos e trabalhar com a equipe para resolv-los
Treinar outros membros da equipe em aspectos relevantes de testes
Assegurar que as tarefas de teste adequadas sejam programadas durante lanamento e planejamento
de iterao
Colaborar ativamente com desenvolvedores e partes interessadas para esclarecer requisitos,
especialmente em termos de testabilidade, consistncia e completude
Participar ativamente de retrospectivas da equipe, sugerindo e implementando melhorias
Dentro de uma equipe do gil, cada membro da equipe responsvel pela qualidade do produto e desempenha
um papel na execuo de tarefas relacionadas com o teste.
As organizaes geis podem detectar alguns riscos organizacionais relacionados com o teste:
Os testadores trabalham to estreitamente com os desenvolvedores que eles perdem a mentalidade

testador apropriado
Os testadores se tornam tolerantes ou ausentes sobre prticas ineficientes, ineficazes, ou de baixa
qualidade na equipe
Os testadores no podem manter o ritmo com as alteraes realizadas em iteraes com limitaes de
tempo. Para mitigar esses riscos, as organizaes podem considerar variaes para preservar a
independncia discutida na Seo 2.1.5.
26
Certified Tester
3. Tcnicas, Ferramentas e Mtodos de Teste gil - 480 min.

Palavras-chave.
Critrios de aceitao, testes exploratrios, testes de desempenho, risco do produto, risco de qualidade, testes
de regresso, abordagem de teste, grfico de teste, estimativa de teste, automao de execuo do teste,
estratgia de teste, desenvolvimento orientado a testes, estrutura de teste da unidade
Objetivos de Aprendizado dos Mtodos de Teste do gil, Tcnicas e Ferramentas

3.1 Mtodos de Teste do gil
FA-3.1.1 (K1) Relembrar os conceitos de desenvolvimento orientado a testes, desenvolvimento orientado para
teste, e desenvolvimento orientado a comportamento
FA-3.1.2 (K1) Relembrar os conceitos da pirmide de teste
FA-3.1.3 (K2) Resumir os quadrantes de teste e suas relaes com os nveis de testes e tipos de testes
FA-3.1.4 (K3) Para um determinado projeto do gil, praticar a funo de um testador em uma equipe Scrum
3.2 Avaliao de Riscos de Qualidade e Estimativa do Esforo de Teste
FA-3.2.1 (K3) Avaliar os riscos de qualidade em um projeto do gil
FA-3.2.2 (K3) Estimar o esforo do teste com base no contedo da iterao e os riscos da qualidade
3.3 Tcnicas nos Projetos geis
FA-3.3.1 (K3) Interpretar as informaes relevantes para apoiar as atividades de teste
FA-3.3.2 (K2) Explicar s partes interessadas da empresa como definir critrios de aceitao testveis
FA-3.3.3 (K3) Dado a estria do usurio, descrever casos de teste de desenvolvimento orientado para teste de
aceitao
FA-3.3.4 (K3) Para o comportamento funcional e no-funcional, descrever casos de teste usando a caixa preta
tcnicas de projeto de teste com base em determinadas estrias de usurios
FA-3.3.5 (K3) Realizar teste exploratrio para apoiar o teste de um projeto do gil
3.4 Ferramentas em Projetos geis
FA-3.4.1 (K1) Relembrar diferentes ferramentas disponveis para testadores de acordo com sua finalidade e
atividades nos projetos geis
27
Certified Tester
3.1 Mtodos de Teste do gil
Existem certas prticas de teste que podem ser seguidas em todos os projetos de desenvolvimento (gil ou
no) para produzir produtos de qualidade. Estas incluem descrever testes com antecedncia, para expressar um
comportamento adequado, com foco na preveno precoce do defeito, deteco e remoo, e garantir que os
tipos de teste corretos sejam realizados no momento certo e como parte do nvel correto de teste. Os
profissionais do gil visam introduzir essas prticas mais cedo. Os testadores nos projetos geis desempenham
um papel fundamental na orientao do uso dessas prticas de testes em todo o ciclo de vida.
3.1.1 Desenvolvimento Orientado para Teste, Desenvolvimento Orientado para Teste

de Aceitao e Desenvolvimento Orientado para o Comportamento
Desenvolvimento orientado para teste, desenvolvimento orientado para teste de aceitao, e desenvolvimento
orientado para o comportamento so trs tcnicas complementares em uso entre as equipes do gil para
realizar testes entre os vrios nveis de teste. Cada tcnica um exemplo de um princpio fundamental de teste,
o benefcio de teste e atividades de CQ, uma vez que os testes so definidos antes que o cdigo seja escrito.
Desenvolvimento Orientado para Teste
O desenvolvimento orientado para teste (TDD) usado para desenvolver cdigo guiado por casos de testes
automatizados. O processo de desenvolvimento orientado para testes :
Adicionar um teste que captura o conceito do programador do funcionamento desejado de uma

pequena parte do cdigo
Realizar o teste, o qual falhar uma vez que o cdigo no existe
Escrever o cdigo e realizar o teste em um loop estreito at o teste ser aprovado
Refatorar o cdigo aps a aprovao do teste, reexecutar o teste para garantir a continuidade da
aprovao do cdigo refatorado
Repetir esse processo para a prxima pequena parte do cdigo, realizando os testes anteriores, bem
como os testes adicionados
Os testes escritos so principalmente ao nvel de unidade e so focados no cdigo, embora os testes tambm
possam ser escritos nos nveis de integrao ou de sistema. Desenvolvimento orientado para teste adquiriu sua
popularidade atravs de Extreme Programming [Beck02], mas tambm utilizado em outras metodologias do
gil e as vezes em ciclos de vida sequenciais. Ele ajuda os desenvolvedores a focar em resultados esperados
claramente definidos. Os testes so automatizados e so utilizados na integrao contnua.
Desenvolvimento Orientado para o Teste de Aceitao
O desenvolvimento orientado para o teste de aceitao (ATDD) [Adzic09] define critrios e testes de aceitao
durante a criao de estrias de usurios (ver Seo 1.2.2). Desenvolvimento orientado para teste de aceitao
uma abordagem colaborativa que permite que todas as partes interessadas compreendam como o componente
de software tem que se comportar e o que os desenvolvedores, testadores e as partes interessadas precisam
para garantir esse comportamento. O processo de desenvolvimento orientado para o teste de aceitao
desenvolvimento explicado na Seo 3.3.2.
O desenvolvimento orientado para aceitao cria testes reutilizveis para teste de regresso. Ferramentas
especficas apoiam a criao e execuo de tais testes, muitas vezes dentro do processo de integrao contnua.
Estas ferramentas podem se conectar a dados e servios de camadas de aplicao, que permite que os testes
sejam realizados no nvel do sistema ou aceitao. Desenvolvimento orientado para teste de aceitao permite
a resoluo rpida de defeitos e validao de comportamento da funcionalidade. Ele ajuda a determinar se os
critrios de aceitao so cumpridos para a funcionalidade.
Desenvolvimento orientado para o comportamento
Desenvolvimento orientado para o comportamento (BDD) [Chelimsky10] permite que um desenvolvedor se
concentre em testar o cdigo com base no comportamento esperado do software. Como os testes so baseados
28
Certified Tester
no comportamento exibido do software, os testes so geralmente mais fceis de entender para outros membros
da equipe e partes interessadas.
Estruturas especficas de desenvolvimento orientado a comportamento podem ser utilizadas para definir os
critrios de aceitao com base no formato dado/quando/depois:
Dado algum contexto inicial, quando ocorre um evento, em seguida assegurar alguns resultados.
A partir desses requisitos, a estrutura de desenvolvimento orientado para o comportamento gera um cdigo
que pode ser usado por desenvolvedores para criar casos de teste. Desenvolvimento orientado para o
comportamento ajuda o desenvolvedor a colaborar com outras partes interessadas, incluindo os testadores,
para definir testes de unidade acurados focados nas necessidades comerciais.
3.1.2 Pirmide de Teste

Um sistema de software pode ser testado em diferentes nveis. Nveis de teste tpicos so, a partir da base da
pirmide para o topo, unidade, integrao, sistema e aceitao (ver [ISTQB_FL_SYL], Seo 2.2). A pirmide
de teste enfatiza um grande nmero de testes para os nveis mais baixos (base da pirmide) e, conforme o
desenvolvimento se move para nveis superiores, o nmero de testes diminui (topo da pirmide). Normalmente,
os testes de unidade e nvel de integrao so automatizados e so criados usando ferramentas baseadas em
API. Nos nveis de sistema e de aceitao, os testes automatizados so criados usando as ferramentas baseadas
em GUI. O conceito de pirmide teste baseado no princpio de testes de controle de qualidade e testes (ou
seja, a eliminao de defeitos o mais cedo possvel no ciclo de vida).
3.1.3 Quadrantes de Teste, Nveis de Teste e Tipos de Teste

Quadrantes de teste, definidos por Brian Marick [Crispin08], alinhar os nveis de teste com os tipos de testes
apropriados na metodologia do gil. O modelo de quadrantes de teste e suas variantes ajuda a assegurar que
todos os tipos de testes importantes e os nveis de teste sejam includos no ciclo de vida de desenvolvimento.
Este modelo tambm fornece uma maneira de diferenciar e descrever os tipos de testes a todas as partes
interessadas, incluindo desenvolvedores, testadores e representantes de negcio.
Nos quadrantes de teste, os testes podem ser um negcio (usurio) ou tecnologia (desenvolvedor). Alguns
testes apoiam o trabalho realizado pela equipe do gil e confirmam o comportamento do software. Outros
testes podem verificar o produto. Os testes podem ser totalmente manuais, totalmente automatizados, uma
combinao de manual e automatizado ou manual, mas apoiados por ferramentas. Os quatro quadrantes de
teste so como se segue:
O Quadrante Q1 nvel da unidade, voltado para tecnologia e apoia os desenvolvedores. Este

quadrante contm testes de unidade. Estes testes devem ser automatizados e includos no processo de
integrao contnua.
O Quadrante Q2 nvel do sistema, voltado para negcios, e confirma o comportamento do produto.
Este quadrante contm testes funcionais, exemplos, testes de estria, prottipos de experincia do
usurio, e simulaes. Estes testes verificam os critrios de aceitao e podem ser manuais ou
automatizados. Eles so muitas vezes criados durante o desenvolvimento da estria do usurio e,
assim, melhorar a qualidade das estrias. Eles so teis na criao de sutes de teste automatizados de
regresso.
O Quadrante Q3 o nvel de aceitao do sistema ou do usurio, voltado para o negcio, e contm
testes que criticam o produto, utilizando cenrios e dados realistas. Este quadrante contm testes
exploratrios, cenrios, fluxos de processos, testes de usabilidade, teste de aceitao do usurio, testes
alfa e teste beta. Estes testes so muitas vezes manuais e orientados para o usurio.
O Quadrante Q4 o nvel de aceitao operacional ou do sistema, orientado para tecnologia, e contm
testes que criticam o produto. Este quadrante contm desempenho, carga, estresse e testes de
escalabilidade, testes de segurana, manuteno, gesto de memria, compatibilidade e
interoperabilidade, migrao de dados, infraestrutura, e testes de recuperao. Estes testes so muitas
vezes automatizados.
29
Certified Tester
Durante uma determinada iterao, os testes de algum ou todos os quadrantes podem ser necessrios. Os
quadrantes de teste se aplicam a testes dinmicos ao invs de testes estticos.
3.1.4 A Funo de um Testador

Ao longo deste programa, foi feita referncia geral a mtodos e tcnicas do gil, e a funo de um testador de
dentro de vrios ciclos de vida do gil. Esta subseo analisa especificamente a funo de um testador em um
projeto seguindo um ciclo de vida do Scrum [Aalst13].
Trabalho em equipe
Trabalho em equipe um princpio fundamental no desenvolvimento do gil. O gil enfatiza a abordagem da
equipe inteira composta por desenvolvedores, testadores e os representantes de negcio que trabalham juntos.
A seguir esto as melhores prticas organizacionais e comportamentais nas equipes Scrum:
Multifuncional: Cada membro da equipe traz um conjunto diferente de habilidades para a equipe. A
equipe trabalha em conjunto na estratgia de teste, planejamento de testes, especificao de teste,
execuo de testes, avaliao de teste, e o relato dos testes de relatrios.
Auto-organizao: A equipe pode consistir apenas de desenvolvedores, mas, como mencionado na
Seo 2.1.5, o ideal que haja um ou mais testadores.
Co-localizado: Os testadores se renem com os desenvolvedores e o proprietrio do produto.
Colaborativo: Os testadores colaboram com seus membros da equipe, outras equipes, as partes
interessadas, o proprietrio do produto, e o Scrum Master.
Capacitado: As decises tcnicas de projeto e teste so tomadas pela equipe como um todo
(desenvolvedores, testadores e Scrum Master), em colaborao com o proprietrio do produto e outras
equipes, se necessrio.
Comprometido: O testador tem o compromisso de questionar e avaliar o comportamento e as
caractersticas do produto em relao s expectativas e necessidades dos clientes e usurios.
Transparente: Desenvolvimento e progresso de testes visvel no quadro de tarefas do gil (ver Seo
2.2.1).
Credibilidade: O testador deve garantir a credibilidade da estratgia de testes, sua implementao e
execuo, caso contrrio, as partes interessadas no vo confiar nos resultados do teste. Isso muitas
vezes feito atravs do fornecimento de informaes s partes interessadas sobre o processo de teste.
Aberto ao feedback: O feedback um aspecto importante para ser bem sucedido em qualquer projeto,
especialmente em projetos geis. Retrospectivas permitem que as equipes aprendam com os sucessos
e com os fracassos.
Resiliente: Os testes devem ser capazes de responder mudana, como todas as outras atividades nos
projetos geis.
Estas melhores prticas maximizam a probabilidade de testes bem-sucedidos nos projetos Scrum.
Sprint Zero
Sprint Zero a primeira iterao do projeto, onde muitas atividades de preparao ocorrem (ver Seo 1.2.5).
O testador colabora com a equipe nas seguintes atividades durante esta iterao:
Identificar o escopo do projeto (ou seja, o backlog do produto)

Criar uma arquitetura inicial do sistema e prottipos de alto nvel
Planejar, adquirir e instalar as ferramentas necessrias (por exemplo, para gerenciamento de testes,
gerenciamento de defeitos, automao de testes e integrao contnua)
Criar uma estratgia de teste inicial para todos os nveis de teste, abordando (entre outros tpicos)
escopo de teste, riscos tcnicos, tipos de teste (ver Seo 3.1.3) e metas de cobertura
Realizar uma anlise de risco inicial de qualidade (ver Seo 3.2.1)
Definir mtricas de teste para medir o processo de teste, o progresso dos testes no projeto, e a qualidade
do produto
Especificar a definio de "realizado"
30
Certified Tester
Criar o quadro de tarefas (ver Seo 2.2.1)

Definir quando continuar ou interromper o teste antes de entregar o sistema para o cliente
Sprint zero define o rumo que o teste precisa alcanar e como o teste precisa alcan-lo ao longo dos sprints.
Integrao
Nos projetos geis, o objetivo agregar valor para o cliente em uma base contnua (de preferncia em cada
sprint). Para permitir isso, a estratgia de integrao deve considerar a concepo e teste. Para permitir uma
estratgia de teste contnua para a funcionalidade e caractersticas apresentadas, importante identificar todas
as dependncias entre as funes e caractersticas subjacentes.
Planejamento de Teste
Visto que o teste est totalmente integrado na equipe do gil, o planejamento do teste deve comear durante
a sesso do planejamento de lanamento e ser atualizado durante cada sprint. Planejamento de teste para o
lanamento e cada sprint deve abordar as questes discutidas na Seo 1.2.5.
O planejamento do Sprint resulta em um conjunto de tarefas a serem inseridas no quadro de tarefas, onde cada
tarefa deve ter a durao de um ou dois dias de trabalho. Alm disso, quaisquer questes relacionadas a testes
devem ser monitoradas para manter um fluxo constante de testes.
Prticas de Teste do gil
Muitas prticas podem ser teis para testadores em uma equipe Scrum, algumas das quais incluem:
Empilhamento: Dois membros da equipe (por exemplo, um testador e um desenvolvedor, dois

testadores, ou um testador e um proprietrio do produto) se renem em uma estao de trabalho para
realizar um teste ou outra tarefa sprint.
Projeto de teste incremental: Os casos de teste e grficos so gradualmente desenvolvidos de estrias
de usurios e outras bases de testes, comeando com testes simples e passando para testes mais
complexos.
Mapeamento Mental: Mapeamento Mental uma ferramenta til no teste [Crispin08]. Por exemplo,
os testadores podem usar o mapeamento mental para identificar quais sesses de teste realizar, para
mostrar estratgias de teste, e para descrever os dados de teste.
Estas prticas so suplementares s outras prticas discutidas neste programa e no captulo 4 do programa
Foundation Level [ISTQB_FL_SYL].
3.2 Avaliao de Riscos de Qualidade e Estimativa do Esforo de Teste

Um objetivo tpico de testes em todos os projetos, gil ou tradicionais, reduzir o risco de problemas de
qualidade do produto a um nvel aceitvel antes do lanamento. Testadores em projetos geis podem usar os
mesmos tipos de tcnicas utilizadas em projetos tradicionais para identificar riscos de qualidade (ou riscos de
produtos), avaliar o nvel de risco associado, estimar o esforo necessrio para reduzir suficientemente esses
riscos, e depois mitigar esses riscos atravs de projeto de teste, implementao e execuo. No entanto, dadas
as iteraes curtas e a taxa de mudana em projetos geis, so necessrias algumas adaptaes dessas tcnicas.
3.2.1 Avaliar os riscos de qualidade em projetos geis

Um dos muitos desafios em testes a seleo, alocao e priorizao adequadas das condies de teste. Isso
inclui determinar o volume adequado de esforo para alocar a fim de cobrir cada condio com testes, e
sequenciar as provas resultantes de modo a otimizar a eficcia e eficincia do trabalho de teste a ser feito. A
identificao dos riscos, anlise e estratgias de mitigao de risco podem ser utilizadas pelos testadores nas
equipes do gil para ajudar a determinar um nmero aceitvel de casos de teste a serem realizados, embora
muitas restries e variveis que interagem possam exigir comprometimentos.
Nos projetos geis, anlise de risco da qualidade ocorre em dois lugares.
31
Certified Tester
O risco a possibilidade de um resultado ou evento negativo ou indesejvel. O nvel de risco detectado
atravs da avaliao da probabilidade de ocorrncia do risco e do impacto do risco. Quando o efeito primrio
do problema potencial a qualidade do produto, os potenciais problemas so chamados de riscos de qualidade
e riscos do produto. Quando o efeito primrio do problema potencial sobre o sucesso do projeto, problemas
potenciais so referidos como riscos do projeto ou planejamento de riscos [Black07] [vanVeenendaal12].
Planejamento do lanamento: representantes de negcio que conhecem as funcionalidades no

lanamento fornecem uma viso geral de alto nvel dos riscos, e toda a equipe, incluindo o
testador(res), podem auxiliar na identificao e avaliao de riscos.
Planejamento de iterao: toda a equipe identifica e avalia os riscos de qualidade.
Exemplos de riscos de qualidade para um sistema incluem:
Clculos incorretos em relatrios (um risco funcional relacionado com acurcia)

Resposta lenta a entrada do usurio (um risco no funcional relacionados com a eficincia e tempo de
resposta)
Dificuldade na compreenso de telas e campos (um risco no funcional relacionado com a usabilidade
e inteligibilidade)
Como mencionado anteriormente, uma iterao comea com o planejamento da iterao, que culmina em
tarefas estimadas em um quadro de tarefa. Estas tarefas podem ser priorizadas em parte com base no nvel de
risco de qualidade associado s mesmas. Tarefas associadas a riscos mais elevados devem comear mais cedo
e envolvem mais esforo de teste. Tarefas associadas a riscos menores devem comear mais tarde e envolvem
menos esforo de teste.
Um exemplo de como o processo de anlise de risco de qualidade em um projeto do gil pode ser realizado
durante o planejamento da iterao descrito nas seguintes etapas:
1. Reunir os membros da equipe do gil, incluindo o testador (es)
2. Listar todos os itens do backlog da iterao atual (por exemplo, em um quadro de tarefa)
3. Identificar os riscos de qualidade associados a cada item, considerando-se todas as caractersticas
relevantes de qualidade
4. Avaliar cada risco identificado, que inclui duas atividades: categorizar o risco e determinar o seu nvel
de risco com base no impacto e na probabilidade de defeitos
5. Determinar a extenso do teste proporcional ao nvel de risco.
6. Escolher a tcnica de teste apropriada para mitigar cada risco, com base no risco, nvel de risco, e a
caracterstica de qualidade pertinente.
O testador ento projeta, implementa e executa testes para mitigar os riscos. Isso inclui a totalidade de
funcionalidades, comportamentos, caractersticas de qualidade e atributos que afetam cliente, usurio e
satisfao das partes interessadas.
Ao longo do projeto, a equipe deve manter-se consciente de informaes adicionais que podem alterar o
conjunto de riscos e/ou o nvel de risco associado a riscos de qualidade conhecidos. Ajuste peridico da anlise
de risco de qualidade, que resulta em adaptaes dos testes, deve ocorrer. Os ajustes incluem a identificao
de novos riscos, reavaliar o nvel de riscos existentes e avaliar a eficcia das atividades de mitigao de risco.
Os riscos de qualidade tambm podem ser atenuados antes do incio da execuo do teste. Por exemplo, se os
problemas com as estrias dos usurios so detectados durante a identificao do risco, a equipe do projeto
pode rever completamente as estrias dos usurios como uma estratgia de mitigao.
3.2.2 Estimativa do Esforo de Teste Com Base no Contedo e Risco

Durante o planejamento de lanamento, a equipe do gil estima o esforo necessrio para completar o
lanamento. A estimativa aborda tambm o esforo de teste. A tcnica de estimativa comum utilizada nos
projetos geis o pquer do planejamento, uma tcnica baseada no consenso. O proprietrio do produto ou
cliente l uma estria de usurio para os avaliadores. Cada avaliador tem um baralho de cartas com valores
semelhantes para a sequncia de Fibonacci (ou seja, 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, ...) ou qualquer outra
32
Certified Tester
progresso de escolha (por exemplo, os tamanhos da camisa que variam de extra pequeno a extra-extragrande). Os valores representam o nmero de pontos da estria, dias de esforo, ou outras unidades nas quais
a equipe estima. A sequncia de Fibonacci recomendada, pois os nmeros na sequncia refletem que a
incerteza cresce proporcionalmente com o tamanho da estria. A estimativa alta significa geralmente que a
estria no bem compreendida ou deve ser dividida em vrias estrias menores.
Os estimadores discutem a funcionalidade e fazem perguntas sobre o proprietrio do produto, conforme
necessrio. Aspectos como desenvolvimento e esforo de teste, complexidade da estria e escopo dos testes
desempenham um papel fundamental na estimativa. Portanto, aconselhvel incluir o nvel de risco de um
item de backlog, alm da prioridade especificada pelo proprietrio do produto, antes do incio da sesso de
planeamento de pquer. Quando a funcionalidade amplamente discutida, cada estimador seleciona
privativamente uma carta para representar a sua estimativa. Todos os cartes so ento revelados ao mesmo
tempo. Se todos os estimadores selecionaram o mesmo valor, este se torna a estimativa. Caso contrrio, os
estimadores discutem as diferenas nas estimativas depois que a rodada de pquer repetida, at que seja
alcanado um acordo, seja por consenso ou pela aplicao de regras (por exemplo, usar a mediana, use a maior
pontuao) para limitar o nmero de rodadas de pquer. Essas discusses garantem uma estimativa confivel
do esforo necessrio para completar itens de backlog do produto solicitados pelo proprietrio do produto e
ajudam a melhorar o conhecimento coletivo do que tem que ser feito [Cohn04].
3.3 Tcnicas nos Projetos geis

Muitas das tcnicas de teste e nveis de testes que se aplicam a projetos tradicionais tambm podem ser
aplicadas nos projetos geis. No entanto, nos projetos geis, existem algumas consideraes especficas e
variaes de tcnicas de teste, terminologias e documentao que devem ser consideradas.
3.3.1 Critrios de aceitao e cobertura adequada, e outras informaes para Testes

Os projetos geis descrevem requisitos iniciais como estrias de usurio em um backlog priorizado no incio
do projeto. Os requisitos iniciais so curtos e geralmente seguem um formato pr-definido (ver Seo 1.2.2).
Os requisitos no funcionais, tais como usabilidade e desempenho tambm so importantes e podem ser
especificados como estrias exclusivas de usurios, ou ligados a outras estrias de usurios funcionais. Os
requisitos no funcionais podem seguir um formato pr-definido ou padro, como [ISO25000], ou uma norma
especfica do setor.
As estrias de usurios servem como uma base importante de teste. Outras bases de teste possveis incluem:
Experincia de projetos anteriores

Funes, funcionalidades e caractersticas de qualidade do sistema existentes
Cdigo, arquitetura, e design
Perfis de usurio (contexto, configuraes de sistema e comportamento do usurio)
Informaes sobre defeitos de projetos existentes e anteriores
Categorizao de defeitos em uma taxonomia de defeito
Normas aplicveis (por exemplo, [DO-178B] para software de aviao)
Riscos da qualidade (ver Seo 3.2.1)
Durante cada iterao, os desenvolvedores criam cdigo que implementa as funes e funcionalidades
descritos nas estrias de usurios, com as caractersticas de qualidade relevantes, e esse cdigo verificado e
validado atravs de testes de aceitao. Para ser testvel, os critrios de aceitao devem abordar os seguintes
tpicos relevantes [Wiegers13]:
Comportamento funcional: O comportamento observvel externamente com as aes do usurio como

entrada operam sob certas configuraes.
Caractersticas de qualidade: Como o sistema executa o comportamento especificado. As
caractersticas tambm podem ser chamadas de atributos de qualidade ou requisitos no funcionais.
Caractersticas comuns da qualidade so desempenho, confiabilidade, usabilidade, etc
33
Certified Tester
Cenrios (casos de uso): Uma sequncia de aes entre um ator externo (muitas vezes um usurio) e
o sistema, a fim de realizar uma tarefa ou objetivo de negcio especfico.
Regras de negcios: Atividades que s podem ser executadas no sistema sob certas condies
definidas por procedimentos e restries externas (por exemplo, os procedimentos utilizados por uma
companhia de seguros para lidar com reclamaes de seguros).
Interfaces externas: Descries das conexes entre o sistema a ser desenvolvido e o mundo exterior.
Interfaces externas podem ser divididas em diferentes tipos (interface do usurio, interface com outros
sistemas, etc).
Restries: Qualquer projeto e restrio de implementao que restrinja as opes para o
desenvolvedor. Aparelhos com software embutido muitas vezes devem respeitar as restries fsicas,
tais como tamanho, peso e conexes de interface.
Definies de dados: O cliente pode descrever o formato, tipo de dados, valores permitidos e valores
padro para um item de dados na composio de uma estrutura de dados de negcios complexos (por
exemplo, o CEP em um endereo de correio dos EUA).
Alm das estrias de usurios e seus critrios de aceitao associados, outras informaes relevantes para o
testador, incluindo:
Como se espera que o sistema atue e seja utilizado

As interfaces do sistema, que podem ser utilizadas/acessadas para testar o sistema
Se o atual suporte de ferramenta suficiente
Se o testador tem conhecimento e habilidade suficiente para realizar os testes necessrios
Os testadores, muitas vezes, descobrem a necessidade de informaes adicionais (por exemplo, a cobertura de
cdigo) ao longo das iteraes e devem trabalhar em colaborao com o resto dos membros da equipe do gil
para obter estas informaes. As informaes relevantes desempenham um papel fundamental para determinar
se uma atividade especfica pode ser considerada realizada. Este conceito da definio de pronto crucial nos
projetos geis e aplica-se em uma srie de maneiras diferentes, como discutido nas seguintes subsees.
Nveis de Teste
Cada nvel de teste tem sua prpria definio de pronto. A lista a seguir d exemplos que podem ser relevantes
para os diferentes nveis de teste.
Teste da unidade:
100% de cobertura de deciso, sempre que possvel, com revises cuidadosas de todos os caminhos
inviveis
Anlise esttica realizada em todo o cdigo
Defeitos importantes no resolvidos (classificados com base na prioridade e gravidade)
No conhecida nenhuma dvida tcnica inaceitvel restante no projeto e no cdigo [Jones11]
Todos os cdigos, testes de unidade, e resultados de unidade de teste avaliados
Todos os testes de unidade automatizados
Caractersticas importantes esto dentro dos limites acordados (por exemplo, desempenho)
Teste de integrao
Todos os requisitos funcionais testados, incluindo os testes positivos e negativos, com o nmero de
testes com base no tamanho, complexidade e riscos
Todas as interfaces entre as unidades testadas
Todos os riscos de qualidade cobertos de acordo com a medida acordada de testes
No h defeitos importantes no solucionados (priorizados de acordo com o risco e importncia)
Todos os defeitos encontrados so relatados
Todos os testes de regresso automatizados, sempre que possvel, com todos os testes automatizados
armazenados em um repositrio comum
34
Certified Tester
Teste de sistema
Testes completos de estrias de usurios, funcionalidades e funes

Todos os usurios cobertos
As caractersticas mais importantes de qualidade do sistema cobertas (por exemplo, desempenho,
robustez, fiabilidade)
Testes realizados em um ambiente de produo, incluindo todo o hardware e software para todas as
configuraes de suporte, na medida do possvel
Todos os riscos de qualidade cobertos de acordo com a medida acordada de testes
Todos os testes de regresso automatizados, sempre que possvel, com todos os testes automatizados
armazenados em um repositrio comum
Todos os defeitos encontrados so relatados e possivelmente resolvidos
No h defeitos importantes no solucionados (priorizados de acordo com o risco e importncia)
Estria do Usurio
A definio de pronto para estrias de usurios pode ser determinada pelos seguintes critrios:
As estrias de usurios selecionados para a iterao so completas, compreendidas pela equipe, e com
critrios de aceitao detalhados e testveis
Todos os elementos da estria do usurio so especificados e avaliados, incluindo os testes de
aceitao da estria do usurio, foram concludos
Tarefas necessrias para implementar e testar as estrias de usurios selecionados foram identificadas
e estimados pela equipe
Funcionalidade
A definio de pronto para funcionalidades, que pode se estender por vrias estrias de usurios ou picos,
pode incluir:
Todas as estrias de usurios que o constituem, com os critrios de aceitao, so definidos e

aprovados pelo cliente
O projeto est completo, sem nenhuma dvida tcnica conhecida
O cdigo est completo, sem dvidas tcnicas conhecidas ou refatorao inacabada
Os testes de unidade foram realizados e alcanaram o nvel de cobertura definida
Testes de integrao e testes do sistema para a funcionalidade foram realizados de acordo com os
critrios de cobertura definidos
Nenhum grande defeito deve ser corrigido
Documentao de funcionalidades est completa, o que pode incluir notas de lanamento, manuais do
usurio e funes de ajuda online
Iterao
A definio de pronto para a iterao pode incluir o seguinte:
Todas as funcionalidades para a iterao esto prontos e so testados individualmente de acordo com
os critrios de nvel de funcionalidade
Todos os defeitos no crticos que no podem ser corrigidos dentro dos limites da iterao adicionados
ao backlog do produto e priorizados
Integrao de todas as funcionalidades para a iterao concluda e testada
Documentao escrita, avaliada e aprovada
Neste ponto, o software potencialmente destacvel, pois a iterao foi concluda com xito, mas nem todas
as iteraes resultam em um lanamento.
Lanamento
A definio de pronto para um lanamento, que pode se estender por vrias iteraes, podem incluir as
seguintes reas:
35
Certified Tester
Cobertura: Todos os elementos da base de teste relevantes para todo o contedo do lanamento foi
coberto por testes. A adequao da cobertura determinada pelo que novo ou alterado, sua
complexidade e tamanho, e os riscos associados de fracasso.
Qualidade: A intensidade de defeito (por exemplo, quantos defeitos so encontrados por dia ou por
transao), a densidade de defeitos (por exemplo, o nmero de defeitos encontrados em comparao
com o nmero de estrias de usurios, esforo e/ou atributos de qualidade), o nmero estimado de
permanncia dos defeitos esto dentro dos limites aceitveis, as consequncias de defeitos no
resolvidos e restantes (por exemplo, a gravidade e de prioridade) so compreendidas e aceitveis, o
nvel residual de risco associado a cada um dos riscos identificados qualidade compreendido e
aceitvel.
Tempo: Se a data de entrega pr-determinada foi cumprida, as consideraes comerciais associadas ao
lanamento e no lanamento devem ser consideradas.
Custo: O custo do ciclo de vida estimado deve ser usado para calcular o retorno sobre o investimento
para o sistema de entrega (ou seja, o custo de desenvolvimento e manuteno calculada deve ser
consideravelmente menor do que as vendas totais esperadas do produto). A maior parte do custo do
ciclo de vida vem muitas vezes da manuteno aps o lanamento do produto, devido ao nmero de
defeitos que escapam produo.
3.3.2 Desenvolvimento Orientado para o Teste de Aceitao

O desenvolvimento orientado para o teste de aceitao uma abordagem de teste primeiro. Os casos de teste
so criados antes de implementar a estria do usurio. Os casos de teste so criados pela equipe do gil,
incluindo o desenvolvedor, o testador, e os representantes de negcio [Adzic09] e podem ser manuais ou
automatizados. A primeira etapa uma oficina de especificao, onde a estria do usurio analisada, discutida
e escrita por desenvolvedores, testadores e representantes de negcio. Quaisquer insuficincias, ambiguidades
ou erros na estria do usurio so corrigidos durante este processo.
A prxima etapa criar os testes. Isto pode ser feito pela equipe, em conjunto ou individualmente pelo testador.
Em qualquer caso, uma pessoa independente, tal como um representante comercial, valida os testes. Os testes
so exemplos que descrevem as caractersticas especficas da estria do usurio. Estes exemplos ajudaro a
equipe a implementar a estria de usurio corretamente. Uma vez que os exemplos e testes so os mesmos,
estes termos so usados alternadamente. O trabalho comea com exemplos bsicos e questes abertas.
Normalmente, os primeiros testes so os testes positivos, confirmando o comportamento correto, sem
condies de exceo ou erro, que incluem a sequncia de atividades executadas, se tudo correr conforme
esperado. Aps a realizao dos testes do caminho positivo, a equipe deve escrever testes do caminho negativo
e abranger os atributos no funcionais, bem como (por exemplo, desempenho, usabilidade). Os testes so
expressos de tal forma que as partes interessadas sejam capazes de compreender, contendo frases em
linguagem natural que envolvem as pr-condies necessrias, se for o caso, as entradas e as sadas
relacionadas.
Os exemplos devem cobrir todas as caractersticas da estria do usurio e no devem ser adicionados estria.
Isto significa que no deve existir um exemplo que descreva um aspecto da estria do usurio no documentado
na estria em si. Alm disso, dois exemplos no devem descrever as mesmas caractersticas da estria do
usurio.
3.3.3 Projeto de Teste Funcional e No Funcional de Caixa Preta

Nos testes do gil, muitos testes so criados por testadores simultaneamente com atividades de programao
dos desenvolvedores. Assim como os desenvolvedores realizam a programao com base nas estrias de
usurios e critrios de aceitao, os testadores criam testes baseados em estrias de usurios e seus critrios de
aceitao. (Alguns testes, tais como os testes exploratrios e alguns outros testes baseados na experincia, so
criados mais tarde, durante a realizao do teste, conforme explicado na Seo 3.3.4.) Os testadores podem
aplicar tcnicas tradicionais de projeto de teste da caixa preta, tais como partio de equivalncia, anlise do
valor limite, tabelas de deciso, e teste de transio de estado para criar estes testes. Por exemplo, a anlise do
36
Certified Tester
valor limite pode ser utilizada para selecionar os valores de teste quando um cliente limitado no nmero de
itens que escolherem para compra.
Em muitas situaes, os requisitos no funcionais podem ser documentados como estrias de usurio. Tcnicas
de projeto de teste caixa preta (como anlise de valor limite) tambm podem ser utilizadas para criar testes
para caractersticas de qualidade no funcionais. A estria de usurio pode conter requisitos de desempenho
ou confiabilidade. Por exemplo, uma determinada execuo no pode exceder um limite de tempo, ou um
nmero de operaes no pode ser inferior a um determinado nmero de vezes.
Para obter mais informaes sobre o uso das tcnicas de projeto do teste da caixa preta, consulte o programa
Foundation Level [ISTQB_FL_SYL] e o programa Advanced Test Analyst Level [ISTQB_ALTA_SYL].
3.3.4 Teste Exploratrio e Teste do gil

O teste exploratrio importante em projetos geis, devido ao pouco tempo disponvel para anlise do teste e
as informaes limitadas sobre as estrias de usurios. A fim de alcanar os melhores resultados, o teste
exploratrio deve ser combinado com outras tcnicas baseadas na experincia como parte de uma estratgia
de teste reativo, misturado com outras estratgias de testes, tais como testes de anlise baseada no risco, testes
baseados em requisitos analticos, testes baseados em modelo, e testes reversos de regresso. As estratgias de
teste e a mistura da estratgia de teste so discutidas no programa Foundation Level [ISTQB_FL_SYL].
Em testes exploratrios, o projeto de teste e realizao do teste ocorrem ao mesmo tempo, guiado por um
grfico de teste preparado. Um grfico de teste fornece as condies de teste para cobrir durante uma sesso
de testes timeboxed. Durante o teste exploratrio, os resultados dos testes mais recentes guiam o prximo teste.
As mesmas tcnicas de caixa branca e caixa preta podem ser utilizadas para projetar os testes, na realizao de
testes pr-concebidos.
Um grfico de teste pode incluir as seguintes informaes:
Ator: usurio a que se destina o sistema

Objetivo: o tema do grfico, incluindo o objetivo especfico que o ator pretende atingir, ou seja, as
condies de teste
Configurao: o que precisa ser posto em prtica, a fim de iniciar a realizao do teste
Prioridade: importncia relativa deste grfico, com base na prioridade da estria do usurio associado
ou o nvel de risco
Referncia especficas (por exemplo, estria de usurio), riscos ou outras fontes de informao
Dados: todos os dados que so necessrios para elaborar o grfico
Atividades: uma lista de ideias do que o ator pode querer fazer com o sistema (por exemplo, "Fazer
logon no sistema como um super usurio") e o que seria interessante testar (ambos os testes positivos
e negativos)
Notas Oracle: como avaliar o produto para determinar os resultados corretos (por exemplo, captar o
que acontece na tela e comparar com o que est escrito no manual do usurio)
Variaes: aes alternativas e avaliaes para complementar as ideias descritas nas atividades
Para gerenciar o teste exploratrio, um mtodo chamado gesto de testes baseado em sesso pode ser usado.
Uma sesso definida como um perodo ininterrupto de teste que pode durar de 60 a 120 minutos. Sesses de
testes incluem o seguinte:
Sesso de pesquisa (para aprender como ele funciona)

Sesso de anlise (avaliao da funcionalidade ou caractersticas)
Cobertura profunda (casos laterais, cenrios, as interaes) A qualidade dos testes depende da capacidade dos
testadores em fazer perguntas pertinentes sobre o que testar. Exemplos incluem o que se segue:
O que mais importante para saber mais sobre o sistema?

De que forma o sistema pode falhar?
O que acontece se?
37
Certified Tester
O que deve acontecer quando?

As necessidades dos clientes, requisitos e expectativas so cumpridas?
possvel instalar o sistema (e remover se necessrio) em todos os caminhos de atualizao com
suporte?
Durante a execuo do teste, o testador usa a criatividade, a intuio, cognio e habilidade para encontrar
possveis problemas com o produto. O testador tambm precisa ter bom conhecimento e compreenso do
software em teste, o domnio do negcio, como o software usado, e como determinar quando o sistema falha.
Um conjunto de heurstica pode ser aplicado durante o teste. A heurstica pode orientar o testador em como
realizar os testes e avaliar os resultados [Hendrickson]. Os exemplos incluem:
Limites
CRUD (Criar, Ler, Atualizar, Deletar)
Variaes de configurao
Interrupes (por exemplo, fazer logoff, desligar, ou reiniciar)
importante para o testador documentar o processo, tanto quanto possvel. Caso contrrio, seria difcil voltar
atrs e ver como um problema no sistema foi detectado. A lista a seguir fornece exemplos de informaes que
podem ser teis ao documento:
Cobertura de teste: quais dados de entrada foram utilizados, quanto foi coberto, e quanto ainda resta a
ser testado
Notas de avaliao: observaes durante os testes, sistema de execuo e funcionalidade em teste
parece estar estvel, os defeitos foram detectados, o que est previsto como a prxima etapa, de acordo
com as observaes atuais, e qualquer outra lista de ideias
Lista de risco/estratgia: quais riscos foram cobertos e quais permanecem entre os mais importantes,
ser a estratgia inicial ser seguida, pois no precisa de quaisquer mudanas
Questes, perguntas e anomalias: qualquer comportamento inesperado, alguma dvida sobre a eficcia
da abordagem, qualquer preocupao com as ideias/tentativas de teste, ambiente de teste, dados de
teste, a incompreenso da funo, script de teste ou o sistema em teste
Comportamento atual: registro do comportamento real do sistema que precisa ser salvo (por exemplo,
vdeo, capturas de tela, arquivos de dados de sada)
As informaes registradas devem ser capturadas e/ou resumidas em alguma forma de ferramentas de status
de gesto (por exemplo, ferramentas de gerenciamento de teste, ferramentas de gerenciamento de tarefas, o
quadro de tarefas), de uma forma que facilite para as partes interessadas a compreenso do status atual de todos
os testes que foram realizados.
3.4 Ferramentas em Projetos geis

Ferramentas descritas no programa Foundation Level [ISTQB_FL_SYL] so relevantes e utilizadas pelos
testadores nas equipes do gil. Nem todas as ferramentas so usadas da mesma maneira e algumas ferramentas
tm mais relevncia para projetos geis do que em projetos tradicionais. Por exemplo, embora as ferramentas
de gerenciamento de teste, ferramentas de gerenciamento de requisitos e ferramentas de gerenciamento de
incidentes (ferramentas de rastreio de defeito) possam ser utilizadas por equipes do gil, algumas equipes do
gil optam por uma ferramenta inclusiva (por exemplo, gesto do ciclo de vida do aplicativo ou gesto de
tarefas) que fornece funcionalidades relevantes para o desenvolvimento do gil, tais como quadros de tarefas,
grficos burndown e estrias de usurios. Ferramentas de gerenciamento de configurao so importantes para
testadores em equipes do gil, devido ao elevado nmero de testes automatizados em todos os nveis e
necessidade de armazenar e gerenciar os artefatos de testes automatizados associados.
Alm das ferramentas descritas no programa Foundation Level [ISTQB_FL_SYL], os testadores nos projetos
geis tambm pode utilizar as ferramentas descritas nas subsees a seguir. Estas ferramentas so usadas por
toda a equipe para garantir a colaborao de equipe e compartilhamento de informaes, que so fundamentais
para as prticas do gil.
38
Certified Tester
3.4.1 Ferramentas de Gesto e Rastreamento de Tarefas
Em alguns casos, as equipes do gil usam quadros de estria/tarefas fsicas (por exemplo, quadro branco,
corkboard) para gerenciar e rastrear estrias de usurios, testes e outras tarefas ao longo de cada sprint. Outras
equipes vo usar software de gerenciamento de ciclo de vida e gerenciamento de tarefas, incluindo quadros
eletrnicas de tarefa. Essas ferramentas servem para os seguintes fins:
Registrar estrias e suas tarefas de desenvolvimento e teste relevantes, para garantir que nada seja
perdido durante um sprint
Capturar estimativas dos membros da equipe em suas tarefas e calcular automaticamente o esforo
necessrio para implementar uma estria, para apoiar sesses de planejamento de iterao eficientes
Tarefas de desenvolvimento associados e tarefas de teste com a mesma estria, para fornecer um
quadro completo do esforo da equipe necessria para implementar a estria
Agregar desenvolvedores e atualizaes de testadores ao status da tarefa ao conclurem o seu trabalho,
fornecendo um resumo calculado atual do status de cada estria, a iterao e o lanamento global.
Fornecer uma representao visual (atravs de mtricas, grficos e dashboards) do estado atual de cada
estria de usurio, a iterao e o lanamento, permitindo que todas as partes interessadas, incluindo as
pessoas em equipes geograficamente distribudas, verificar rapidamente o status
Integrao com ferramentas de gerenciamento de configurao, o que pode permitir o registro
automtico de verificaes do cdigo e realizaes das tarefas, e, em alguns casos, atualizaes de
status automatizado para tarefas.
3.4.2 Ferramentas de comunicao e compartilhamento de informaes

Alm de e-mails, documentos e comunicao verbal, as equipes do gil muitas vezes usam trs tipos adicionais
de ferramentas para apoiar a comunicao e o compartilhamento de informaes: wikis, mensagens
instantneas e compartilhamento de desktop.
Wikis permitem que as equipes desenvolvam e compartilhem uma base de conhecimento online sobre vrios
aspectos do projeto, incluindo o seguinte:
Diagramas de funcionalidades do produto, discusses sobre as funcionalidades, diagramas de

prottipos, fotos de discusses do quadro branco e outras informaes
Ferramentas e/ou tcnicas para o desenvolvimento e teste teis por outros membros da equipe
Mtrica, grficos e dashboards sobre o status do produto, o que especialmente til quando o wiki
integrado com outras ferramentas, tais como o desenvolvimento do servidor e o gerenciamento de
tarefas, uma vez que a ferramenta pode atualizar o status do produto automaticamente
As conversas entre os membros da equipe, semelhantes a mensagens instantneas e e-mail, mas de
uma forma que compartilhada com todos os outros na equipe
Mensagens instantneas, teleconferncia de udio e vdeo ferramentas de chat oferecem os seguintes

benefcios:
Permite a comunicao direta em tempo real entre os membros da equipe, em especial equipes
distribudas
Envolve equipes distribudas em reunies dirias
Reduz contas de telefone atravs do uso de tecnologia de voz sobre IP, eliminando restries de custo
que podem reduzir a comunicao do membro da equipe em ambientes distribudos
Compartilhamento de desktop e ferramentas de captura fornecem os seguintes benefcios:
Em equipes distribudas, demonstraes de produtos, revises de cdigo, e at mesmo

emparelhamento podem ocorrem
Captura de demonstraes de produtos, no final de cada iterao, que podem ser enviadas para o wiki
da equipe
39
Certified Tester
Essas ferramentas devem ser utilizadas para complementar e ampliar, e no substituir, a comunicao face-aface em equipes do gil.
3.4.3 Desenvolvimento do Software e Ferramentas de Distribuio

Como discutido anteriormente neste programa, a compilao diria e implantao de software uma prtica
fundamental nas equipes do gil. Isso requer o uso de ferramentas de integrao contnua e compilao de
ferramentas de distribuio. Os usos, os benefcios e os riscos dessas ferramentas foram descritos
anteriormente na Seo 1.2.4.
3.4.4 Ferramentas de Gerenciamento de Configurao

Nas equipes do gil, as ferramentas de gerenciamento de configurao podem ser utilizadas no s para
armazenar o cdigo fonte e testes automatizados, como tambm os testes manuais e outros produtos de trabalho
de teste so frequentemente armazenados no mesmo repositrio do cdigo-fonte do produto. Isto permite a
rastreabilidade entre os quais verses do software foram testadas com quais verses especficas de testes, e
permite a mudana rpida sem perda de informaes histricas. Os principais tipos de sistemas de controle de
verso incluem sistemas de controle de fonte centralizada e sistemas de controle de verso distribuda. O
tamanho da equipe, estrutura, localizao e necessidades de integrao com outras ferramentas ir determinar
qual sistema de controle de verso ideal para um projeto especfico do gil.
3.4.5 Projeto de teste, Ferramentas de Implementao e Execuo

Algumas ferramentas so teis para os testadores do gil em pontos especficos do processo de teste de
software. Embora a maioria destas ferramentas no sejam novas ou especficas para o gil, elas fornecem
funcionalidades importantes devido rpida mudana dos projetos geis.
Ferramentas de projeto de teste: O uso de ferramentas, tais como mapas mentais, se tornaram mais
populares para projetar e definir rapidamente os testes para uma nova funcionalidade.
Ferramentas de gesto de casos de teste: O tipo de ferramentas de gesto de caso de teste utilizado no gil
pode ser parte da ferramenta de gesto do ciclo de vida do aplicativo ou gesto de tarefa de toda a equipe.
Ferramentas para preparao e gerao de dados de teste: Ferramentas que geram dados para preencher
um banco de dados de um aplicativo so muito benficas quando um grande volume de dados e
combinaes de dados necessrio para testar o aplicativo. Essas ferramentas tambm podem ajudar a
redefinir a estrutura de banco de dados conforme o produto sofre alteraes durante um projeto do gil e
refatora os scripts para gerar os dados. Isso permite a atualizao rpida de dados de teste conforme as
mudanas ocorrem. Algumas ferramentas de preparao de dados de teste utilizam fontes de dados de
produo tais como matria-prima e utilizam scripts para remover os dados sensveis ou torn-los
annimos. Outras ferramentas de preparao de dados de teste podem ajudar a validar grandes entradas ou
sadas de dados.
Ferramentas de carga de dados de teste: Depois que os dados foram gerados para teste, eles precisam ser
carregados no aplicativo. A entrada manual de dados muitas vezes demorada e sujeita a erros, mas as
ferramentas de carga de dados esto disponveis para tornar o processo confivel e eficiente. Na verdade,
muitas das ferramentas geradoras de dados incluem um componente de carga de dados integrados. Em
outros casos, grandes volumes de carga, utilizando os sistemas de gesto de base de dados tambm
possvel.
Ferramentas de execuo de testes automatizados: Existem ferramentas de execuo de teste que so mais
alinhadas com o teste do gil. Ferramentas especficas esto disponveis em ambas as vias comerciais e
opensource para apoiar as abordagens do primeiro teste, tais como desenvolvimento orientado para
comportamento, desenvolvimento orientado para testes e desenvolvimento orientado para teste de
aceitao. Essas ferramentas permitem que os testadores e pessoal de negcios expressem o comportamento
do sistema esperado em tabelas ou linguagem natural usando palavras-chave.
40
Certified Tester
Ferramentas de teste exploratrio: Ferramentas que captam e registram atividades realizadas em um
aplicativo durante uma sesso de teste exploratrio so benficas para o testador e desenvolvedor, pois
registram as aes tomadas. Isso til quando um defeito encontrado, pois as aes tomadas antes da
falha ocorrida foram captadas e podem ser utilizadas para relatar o defeito para os desenvolvedores.
Registro das etapas realizadas em uma sesso de teste exploratrio pode vir a ser benfico se o teste for,
em ltima anlise, includo no conjunto de testes automatizados de regresso.
3.4.6 Ferramentas de Computao Nuvem e Virtualizao

A virtualizao permite que um nico recurso fsico (servidor) opere como muitos recursos separados,
menores. Quando as mquinas virtuais ou instncias de nuvem so utilizadas, as equipes tm um maior nmero
de servidores disponveis para desenvolvimento e testes. Isso pode ajudar a evitar atrasos associados espera
de servidores fsicos. Provisionamento de um novo servidor ou restaurao de um servidor mais eficiente
com recursos de snapshot incorporado na maioria das ferramentas de virtualizao. Algumas ferramentas de
gerenciamento de teste atualmente utilizam tecnologias de virtualizao para fotografar servidores no
momento em que uma falha for detectada, permitindo que os testadores compartilhem a foto com os
desenvolvedores que esto investigando a falha.
41
Certified Tester
4. Referncias
4.1 Normas
[DO-178B] RTCA/FAA DO-178B, Software Considerations in Airborne Systems and Equipment

Certification, 1992
[ISO25000] ISO/IEC 25000:2005, Software Engineering - Software Product Quality Requirements
and Evaluation (SQuaRE), 2005
4.2 Documentos ISTQB
[ISTQB_ALTA_SYL]
[ISTQB_ALTM_SYL]
[ISTQB_FA_OVIEW]
[ISTQB_FL_SYL]
ISTQB Advanced Level Test Analyst Syllabus, Version 2012

ISTQB Advanced Level Test Manager Syllabus, Version 2012
ISTQB Foundation Level Agile Tester Overview, Version 1.0
ISTQB Foundation Level Syllabus, Version 2011
4.3 Livros
[Aalst13] Leo van der Aalst and Cecile Davis, "TMap NEXT in Scrum," ICT-Books.com, 2013.
[Adzic09] Gojko Adzic, "Bridging the Communication Gap: Specification by Example and Agile
Acceptance Testing," Neuri Limited, 2009.
[Anderson13] David Anderson, "Kanban: Successful Evolutionary Change for Your Technology
Business," Blue Hole Press, 2010.
[Beck02] Kent Beck, "Test-driven Development: By Example," Addison-Wesley Professional, 2002.
[Beck04] Kent Beck and Cynthia Andres, "Extreme Programming Explained: Embrace Change, 2e"
Addison-Wesley Professional, 2004.
[Black07] Rex Black, "Pragmatic Software Testing," John Wiley and Sons, 2007.
[Black09] Rex Black, "Managing the Testing Process: Practical Tools and Techniques for Managing
Hardware and Software Testing, 3e," Wiley, 2009.
[Chelimsky10] David Chelimsky et al, "The RSpec Book: Behavior Driven Development with Rspec,
Cucumber, and Friends," Pragmatic Bookshelf, 2010.
[Cohn04] Mike Cohn, "User Stories Applied: For Agile Software Development," Addison-Wesley
Professional, 2004.
[Crispin08] Lisa Crispin and Janet Gregory, "Agile Testing: A Practical Guide for Testers and Agile
Teams," Addison-Wesley Professional, 2008.
[Goucher09] Adam Goucher and Tim Reilly, editors, "Beautiful Testing: Leading Professionals
Reveal How They Improve Software," O'Reilly Media, 2009.
[Jeffries00] Ron Jeffries, Ann Anderson, and Chet Hendrickson, "Extreme Programming Installed,"
Addison-Wesley Professional, 2000.
[Jonesll] Capers Jones and Olivier Bonsignour, "The Economics of Software Quality," AddisonWesley Professional, 2011.
[Linz14] Tilo Linz, "Testing in Scrum: A Guide for Software Quality Assurance in the Agile World,"
Rocky Nook, 2014.
[Schwaber01] Ken Schwaber and Mike Beedle, "Agile Software Development with Scrum," Prentice
Hall, 2001.
[vanVeenendaal12] Erik van Veenendaal, "The PRISMA approach", Uitgeverij Tutein Nolthenius,
2012.
[Wiegers13] Karl Wiegers and Joy Beatty, "Software Requirements, 3e," Microsoft Press, 2013.
42
Certified Tester
4.4 Terminologia do gil
Palavras-chave que so encontrados no Glossrio ISTQB Glossrio so identificadas no incio de cada
captulo. Para termos comuns do gil, contamos com os seguintes recursos da Internet que fornecem
definies.
http://guide.agilealliance.org/
http://whatis.techtargetcom/glossary
http://www.scrumalliance.org/
Convidamos os leitores a verificar esses sites caso eles no estejam familiarizados com os termos relacionados
ao gil neste documento. Estes links estavam ativos no momento de lanamento deste documento.
4.5 Outras Referncias

As referncias a seguir apontam para informaes disponveis na internet e em outros locais. Mesmo que essas
referncias tenham sido verificadas no momento da publicao deste programa, o ISTQB no se responsabiliza
se as referncias no estiverem mais disponveis.
[Guia Agile Alliance] Vrios contribuintes, HYPERLINK "http://guide.Agilealliance.org/".

[Agilemanifesto] Vrios contribuintes, HYPERLINK "http://www.agilemanifesto.org".
[Hendrickson]: Elisabeth Hendrickson, "Desenvolvimento orientado para teste de aceitao",
testobsessed.com/2008/12/acceptance-test-driven-development-atdd-an-overview.
[INVEST] Bill Wake, "Investir em boas estrias e tarefas inteligentes" xp123.com/articles/invest- ingood-stories-and-smart-tasks.
[Kubaczkowski] Greg Kubaczkowski e Rex Black, "Misso a possibilidade de," www.rbcsus.com/images/documents/Mission Made-Possible.pd
43
Certified Tester
ndice
abordagem de equipe inteira, 8, 9, 10
gerenciamento de testes, 33
abordagem de teste, 16, 29, 38
gesto de caso de teste, 43
Anlise de causa raiz, 14
grficos burndown, 24, 41
automao, 8, 10, 16, 17, 19, 21, 24, 25, 26, 27, 29, 33
Incremento, 12
backlog do produto, 12, 14, 16, 17, 33, 35, 38
Integrao contnua, 15
Backlog do Produto, 12
INVEST, 13, 45
Backlog do Sprint, 12
Kanban, 11, 12, 13, 44
base de conhecimento, 42
Manifesto gil, 4, 8, 9, 11
ciclo de vida, 8, 9, 20, 22, 25, 30, 31, 32, 38, 41, 43
planejamento de iterao, 8, 16, 17, 20, 27, 41
Cobertura, 38, 40
Planejamento de iterao, 34
conceito 3C, 14
planejamento de lanamento, 14, 16, 17, 20, 33, 35
controle de verso, 16, 25, 42
planejamento de liberao, 16
critrios de aceitao, 13, 14, 16, 21, 22, 24, 26, 27, 29, 30, 31,
36, 37, 39
planejamento do teste, 33
Critrios de aceitao, 5, 29, 35

Definio de Pronto, 12
Desenvolvimento orientado para o comportamento, 31
Desenvolvimento orientado para teste, 30, 45
Desenvolvimento orientado para teste de aceitao, 30, 45
pquer do planejamento, 35
Proprietrio do Produto, 12
quadrantes de teste, 29, 31, 32
requisitos no-funcionais, 13
Retrospectivas, 4, 14, 32
doze princpios, 9
risco, 11, 16, 17, 19, 20, 22, 23, 24, 25, 29, 33, 34, 35, 37, 38,
39, 40
emparelhamento, 20, 42
Scrum Master, 12, 32
Estria, 4, 13, 37
Sprint, 12, 32, 33
estria do usurio, 8, 11, 13, 22, 29, 31, 37, 38, 39, 40
Teste da unidade, 15, 36
estrias, 8, 12, 13, 14, 15, 16, 17, 20, 21, 22, 24, 27, 29, 30,
31, 33, 35, 36, 37, 38, 39, 41, 45
Teste de integrao, 15, 37
feedback inicial, 8, 11
Teste de sistema, 37
ferramentas de gerenciamento de configurao, 41, 42
testes automatizados, 15, 21, 22, 23, 25, 26, 30, 31, 37, 41, 42,
43
ferramentas de gerenciamento de tarefas, 41
testes de verificao, 22, 26
ferramentas de gerenciamento de teste, 41, 43
testes dinmicos, 15, 32
44

Syllabus CTFL - AT

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

Syllabus CTFL - AT

Enviado por

Direitos autorais:

Formatos disponíveis

International Software Testing Qualifications Board

Traduo realizada pela TAG01 - Documentao do BSTQB

Brazilian Software Testing Qualifications Board

Copyright Comisso Internacional para Qualificao de Teste de Software (doravante denominado

Comentrios da avaliao WG em v01 incorporado

Comentrios da avaliao WG em v02 incorporado

Comentrios da avaliao Alpha em v03 incorporado

Atualizaes de grupo de trabalho em v07

Finalidade deste Documento .............................................................................................. 7

Viso Geral ........................................................................................................................ 7

Objetivos de aprendizagem examinveis............................................................................ 7

Desenvolvimento do Software gil 150 mins. .....................................................8

Os Fundamentos do Desenvolvimento de Software gil ................................................... 9

1.1.1 Desenvolvimento do Software gil e do Manifesto gil ................................................... 9

Aspectos de Abordagens gil .......................................................................................... 11

1.2.1 Abordagens de Desenvolvimento do Software gil ......................................................... 11

Princpios Fundamentais do Teste gil, Prticas e Processos - 105 mins. ............18

As Diferenas entre os Testes em abordagens tradicionais e no gil ............................... 19

2.1.1 Atividades de Teste e Desenvolvimento .......................................................................... 19

Status de Teste em Projetos gil ...................................................................................... 23

2.2.1 Comunicao do Status, Progresso de Teste e Qualidade de Produto .............................. 23

Funo e Habilidades de um Testador em uma equipe gil ............................................. 25

2.3.1 Habilidades do Testador do gil ...................................................................................... 25

Tcnicas, Ferramentas e Mtodos de Teste gil - 480 min. ..................................27

Mtodos de Teste do gil ................................................................................................ 28

Avaliao de Riscos de Qualidade e Estimativa do Esforo de Teste .............................. 31

3.2.1 Avaliar os riscos de qualidade em projetos geis ............................................................. 31

Tcnicas nos Projetos geis .............................................................................................. 33

Ferramentas em Projetos geis ......................................................................................... 38

3.4.1 Ferramentas de Gesto e Rastreamento de Tarefas .......................................................... 39

Documentos ISTQB ......................................................................................................... 42

Terminologia do gil ....................................................................................................... 43

Outras Referncias ........................................................................................................... 43

0. Introduo a este Syllabus

0.2 Viso Geral

Resultados de negcios para o programa

0.3 Objetivos de aprendizagem examinveis

1. Desenvolvimento do Software gil 150 mins.

Objetivos de aprendizagem para Desenvolvimento do Software gil

1.1.1 Desenvolvimento do Software gil e do Manifesto gil

Indivduos e interaes sobre processos e ferramentas

Nossa maior prioridade satisfazer o cliente atravs do desenvolvimento avanado e contnuo de

Acolhimento aos requisitos de mudana, mesmo no final do desenvolvimento. Os processos geis

1.1.2 Abordagem da Equipe Inteira

Melhorar a comunicao e colaborao dentro da equipe

1.2 Aspectos de Abordagens gil

1.2.1 Abordagens de Desenvolvimento do Software gil

Scrum define trs funes:

1.2.2 Criao Colaborativa da Estria do Usurio

Confirmao: Os critrios de aceitao, discutidos na conversa, so utilizados para confirmar que a

1.2.4 Integrao Contnua

Anlise esttica de cdigo: execuo de anlise esttica de cdigo e relatrios de resultados

Implantar: instalar o projeto em um ambiente de teste

No entanto, a integrao contnua tem seus riscos e desafios:

Ferramentas de integrao contnua devem ser introduzidas e mantidas

1.2.5 Planejamento de Iterao e Lanamento

Definir estrias de usurios testveis, incluindo critrios de aceitao

Aps a realizao do planejamento de lanamento, o planejamento de iterao para a primeira iterao

Participar da anlise de risco detalhada de estrias de usurios

2. Princpios Fundamentais do Teste gil, Prticas e Processos 105 mins.

Objetivos de Aprendizado para Princpios Fundamentais do Teste gil, Prticas e Processos

2.1.1 Atividades de Teste e Desenvolvimento

2.1.2 Produtos de Trabalho do Projeto