Syllabus CTFL 2011br

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

na verso 2011 do Certified Tester Foundation Level Syllabus do
ISTQB.
Brazilian Software Testing Qualifications Board
Certified Tester
Copyright 2011, aos autores da atualizao 2011 (Thomas Muller (chair), Debra Friedenberg e o ISTQB
WG Foundation Level)
Copyright 2010, aos autores da atualizao 2010 (Thomas Muller (chair), Armin Beer, Martin Klonk e
Rahul Verma)
Copyright 2007, aos autores da atualizao 2007 (Thomas Muller (chair), Dorothy Graham, Debra
Friedenberg e Erik van Veendendal)
Copyright 2005, aos autores (Thomas Muller (chair), Rex Black, Sigrid Eldh, Dorothy Graham, Klaus
Olsen, Maaret Pyhjrvi, Geoff Thompson e Erik van Veendendal).
Todos os direitos reservados.
Os autores que esto transferindo o copyright para a Comisso Internacional para Qualificao de Teste de
Software (aqui chamado de ISTQB). Os autores (como os atuais proprietrios copyright) e ISTQB (como os
futuros proprietrios copyright) concordam com as seguintes condies de uso:
1) Qualquer treinamento individual ou por meio de companhia pode usar este syllabus como a base para
treinamento se os autores e o ISTQB forem reconhecidos como a fonte original e proprietrios dos direitos
sob o syllabus e, com a condio de que qualquer publicao tais como cursos e treinamentos, pode fazer
meno ao syllabus somente aps obter autorizao oficial para utilizao do material de treinamento por
uma comisso nacional reconhecida pela ISTQB.
2) Qualquer indivduo ou grupo de indivduos pode utilizar este syllabus como base para artigos, livros ou
outros textos derivados se, os autores e o ISTQB forem reconhecidos como a fonte original e proprietrios
dos direitos do syllabus;
3) Qualquer comisso nacional reconhecida pelo ISTQB poder traduzir este syllabus e licenci-lo (ou
traduzir parcialmente) para outras partes.
Verso 2011br
Agosto 2011
Pgina 2 de 77
Certified Tester
Histrico de Revises
Verso
Data
Observao
BSTQB 2011br
Agosto-2011
Ver Apendice E Notas da Verso
BSTQB 2007br
Agosto-2007
Traduo para portugus do Brasil
ISTQB 2007
Maio-2007
Certified Tester Foundation Level Syllabus

Maintenance Release see Apendix E
ISTQB 2005
Julho-2005
Certified Tester Foundation Level Syllabus
ASQF V2.2
Julho-2003
ASQF Syllabus Foundation Level Version 2.2 Lehrplan,

Grundlagen des Softwaretestens
ISEB V2.0
Fevereiro-1999
ISEB Software Testing Foundation Syllabus V2.0

25 February 1999
Verso 2011br
Agosto 2011
Pgina 3 de 77
Certified Tester
ndice
Agradecimentos .......................................................................................................................... 7
Introduo do Syllabus ............................................................................................................... 8
Objetivo deste documento ................................................................................................................... 8
CTFL (Certified Tester Foundation Level) ......................................................................................... 8
Objetivos de aprendizagem / nveis de conhecimento ........................................................................ 8
O Exame 8
Autorizao ......................................................................................................................................... 8
Nvel de Detalhe.................................................................................................................................. 9
Como este syllabus est organizado .................................................................................................... 9
1.
Fundamentos do Teste (K2) ................................................................................... 10

Objetivos de estudo para os fundamentos do teste ............................................................................ 10
1.1
Porque necessrio testar? (K2) ....................................................................................... 11
1.1.1 Contexto dos sistemas de software (K1) ........................................................................... 11
1.1.2 Causas dos defeitos de software (K2) ............................................................................... 11
1.1.3 Funo do teste no desenvolvimento, manuteno e operao de software (K2). ............ 11
1.1.4 Teste e qualidade (K2) ...................................................................................................... 11
1.1.5 Quanto teste suficiente? (K2) ......................................................................................... 12
1.2
O que teste? (K2) ........................................................................................................... 13
1.3
Os sete Princpios do Teste (K2)....................................................................................... 14
1.4
Fundamentos do Processo de Teste (K1) .......................................................................... 15
1.4.1 Planejamento e controle do teste (K1) .............................................................................. 15
1.4.2 Anlise e modelagem do Teste (K1) ................................................................................. 15
1.4.3 Implementao e execuo de teste (K1) .......................................................................... 16
1.4.4 Avaliao do critrio de sada e relatrio (K1) ................................................................. 16
1.4.5 Atividades de encerramento de teste (K1) ........................................................................ 16
1.5
A Psicologia do Teste (K2) ............................................................................................... 18
1.6
Cdigo de tica ................................................................................................................. 19
2.
Teste durante o ciclo de vida do software (K2) ..................................................... 20

2.1
2.1.1
2.1.2
2.1.3
2.2
2.2.1
2.2.2
2.2.3
2.2.4
2.3
2.3.1
2.3.2
2.3.3
2.3.4
2.4
3.
Modelos de Desenvolvimento de Software (K2) .............................................................. 21

Modelo V (K2) .................................................................................................................. 21
Modelos iterativos de desenvolvimento (K2) ................................................................... 21
Teste dentro de um modelo de ciclo de vida (K2) ............................................................ 21
Nveis de Teste (K2) ......................................................................................................... 23
Teste de Componente (K2) ............................................................................................... 23
Teste de Integrao (K2) ................................................................................................... 23
Teste de Sistema (K2) ....................................................................................................... 24
Teste de Aceite (K2) ......................................................................................................... 24
Tipos de Teste: o alvo do teste .......................................................................................... 26
Teste de Funo (Teste funcional) (K2) ........................................................................... 26
Teste de caractersticas do produto de software (testes no funcionais) (K2) .................. 26
Teste de estrutura/arquitetura do software (teste estrutural) (K2)..................................... 27
Teste relacionado a mudanas (teste de confirmao e regresso) (K2) ........................... 27
Teste de Manuteno ........................................................................................................ 28
Tcnicas Estticas (K2) .......................................................................................... 29

3.1
3.2
3.2.1
3.2.2
3.2.3
Reviso e o Processo de Teste (K2) .................................................................................. 30

Processo de Reviso (K2) ................................................................................................. 31
Fases de uma reviso formal (K1) .................................................................................... 31
Papis e responsabilidades (K1) ....................................................................................... 32
Tipos de reviso (K2)........................................................................................................ 32
Verso 2011br
Agosto 2011
Pgina 4 de 77
Certified Tester
3.2.4 Fatores de sucesso para as revises (K2) .......................................................................... 33
3.3
Anlise Esttica por Ferramentas (K2) ............................................................................. 34
4.
Tcnica de Modelagem de Teste (K3) ................................................................... 35

4.1
4.2
4.3
4.3.1
4.3.2
4.3.3
4.3.4
4.3.5
4.4
4.4.1
4.4.2
4.4.3
4.5
4.6
5.
Gerenciamento de Teste (K3) ................................................................................ 43

5.1
5.1.1
5.1.2
5.2
5.2.1
5.2.2
5.2.3
5.2.4
5.2.5
5.2.6
5.3
5.3.1
5.3.2
5.3.3
5.4
5.5
5.5.1
5.5.2
5.6
6.
Organizao do Teste (K2) ............................................................................................... 45

A organizao e o teste independente (K2)....................................................................... 45
Tarefas do lder de teste e dos testadores (K1) ................................................................. 45
Organizao do Teste (K2) ............................................................................................... 47
Planejamento de Teste (K2) .............................................................................................. 47
Atividades no Planejamento de testes (K2) ...................................................................... 47
Critrio de Entrada (K2) ................................................................................................... 47
Critrio de Sada (K2) ....................................................................................................... 48
Estimativa do teste (K2).................................................................................................... 48
A Estratgia do Teste, Abordagem de teste (K2) ............................................................. 48
Controle e Monitorao do Progresso do Teste (K2)........................................................ 50
Monitorao do Progresso do Teste (K1) ......................................................................... 50
Relatrio do teste (K2) ...................................................................................................... 50
Controle do Teste (K2) ..................................................................................................... 50
Gerenciamento de Configurao (K2) .............................................................................. 52
Riscos e Teste (K2) ........................................................................................................... 53
Riscos no Projeto (K2) ...................................................................................................... 53
Riscos do Produto (K2) ..................................................................................................... 53
Gerenciamento de Incidente (K3) ..................................................................................... 55
Ferramentas de Suporte a Teste (K2) ..................................................................... 57

6.1
6.1.1
6.1.2
6.1.3
6.1.4
6.1.5
6.1.6
6.1.7
6.1.8
6.2
6.2.1
6.2.2
6.3
7.
Identificando as condies de testes e projetando os casos de testes (K3) ....................... 36

Categorias das tcnicas de modelagem de teste (K2) ....................................................... 37
Tcnicas baseadas em especificao ou Caixa-Preta (K3)................................................ 38
Partio de Equivalncia (K3) .......................................................................................... 38
Anlise do Valor Limite (K3) ........................................................................................... 38
Tabela de Deciso (K3)..................................................................................................... 38
Teste de transio de estados (K3) .................................................................................... 39
Teste de Caso de Uso (K2) ............................................................................................... 39
Tcnicas baseadas em estrutura ou Caixa-Branca (K3) .................................................... 40
Teste e Cobertura de Sentena (K3) ................................................................................. 40
Teste e Cobertura de Deciso (K3) ................................................................................... 40
Outras tcnicas baseadas na estrutura (K1)....................................................................... 40
Tcnicas baseadas na experincia (K2)............................................................................. 41
Escolhendo as tcnicas de teste (K2) ................................................................................ 42
Tipos de Ferramentas de Teste (K2) ................................................................................. 58

Ferramentas de suporte a teste (K2) .................................................................................. 58
Classificao das Ferramentas de Teste (K2) ................................................................... 58
Ferramentas para gerenciamento do teste (K1) ................................................................. 59
Ferramentas de suporte para teste esttico (K1) ............................................................... 59
Ferramenta de suporte para especificao de teste(K1) .................................................... 60
Ferramenta de suporte para execuo e registro (K1) ....................................................... 60
Ferramenta de performance e monitorao (K1) .............................................................. 61
Ferramenta de suporte para reas de aplicaes especficas (K1) .................................... 61
Uso Efetivo das Ferramentas: Riscos e Benefcios em potenciais (K2) ........................... 62
Potenciais benefcios e riscos de ferramentas de suporte ao teste (K1) ............................ 62
Consideraes especiais para alguns tipos de ferramentas (K1) ....................................... 62
Implementando uma Ferramenta na Organizao (K1) .................................................... 64
Referncias ............................................................................................................. 65
Verso 2011br
Agosto 2011
Pgina 5 de 77
Certified Tester
Apndice A Syllabus Background ......................................................................................... 66
Apndice B Objetivos de estudo/Nveis de Conhecimento ................................................... 68
Apndice C Regras aplicadas ao ISTQB Fundation Syllabus ............................................... 70
Apndice D Observao aos provedores de treinamentos. .................................................... 72
Appendix E Release Notes..................................................................................................... 73
Apncide F ndice Remissivo ................................................................................................ 75
Verso 2011br
Agosto 2011
Pgina 6 de 77
Certified Tester
Agradecimentos
International Software Testing Qualifications Board Working Party Foundation Level: Thomas Muller
(Diretor), Dorothy Graham, Debra Friedenberg e Erik van Veendendal. A comisso principal agradece a
equipe de reviso (Hans Schaefer, Stephanie Ulrich, Meile Posthuma, Andrers Petterson e Wonil Knon) e
todas as comisses nacionais para as sugestes deste syllabus.
International Software Testing Qualifications Board Working Party Foundation Level: Thomas Muller
(Diretor), Rex Black, Sigrid Eldh, Dorothy Graham, Klaus Olsen, Maaret Pyhjrvi, Geoff Thompson e Erik
van Veendendal. A comisso principal agradece a equipe de reviso e todas as comisses nacionais para as
sugestes deste syllabus.
Agradecimentos especiais para (ustria) Anastasios Kyriakopoulos, (Dinamarca) Klaus Olsen, Christine
Rosenbeck-Larsen, (Alemanha) Matthias Daigl, Uwe Hehn, Tilo Linz, Horst Pohlmann, Ina Schieferdecker,
Sabine Uhde, Stephanie Ulrich, (ndia) Vipul Kocher, (Israel) Shmuel Knishinsky, Ester Zabar, (Sucia)
Anders Claesson, Mattias Nordin, Ingvar Nordstrm, Stefan Ohlsson, Kennet Osbjer, Ingela Skytte, Klaus
Zeuge, (Sua) Armin Born, Sandra Harries, Silvio Moser, Reto Muller, Joerg Pietzsch, (Reino Unido) Aran
Ebbett, Isabel Evans, Julie Gardiner, Andrew Goslin, Brian Hambling, James Lyndsay, Helen Moore, Peter
Morgan, Trevor Newton, Angelina Samaroo, Shane Saunders, Mike Smith, Richard Taylor, Neil Thompson,
Pete Williams, (Estados Unidos) Dale Perry.
Verso 2011br
Agosto 2011
Pgina 7 de 77
Certified Tester
Introduo do Syllabus
Objetivo deste documento
Este syllabus forma a base de conhecimento para a Qualificao Internacional de Teste de Software no nvel
Foundation. O International Software Testing Qualifications Board (ISTQB) disponibiliza o syllabus s
comisses nacionais para que elas autorizem os fornecedores de treinamento e tambm derivem as questes
do exame em suas lnguas locais. Os fornecedores de treinamento produziro o material de curso e
determinaro os mtodos de ensino apropriados para certificao, e o syllabus ajudar os candidatos em sua
preparao para o exame. Informaes histricas e conceituais do syllabus podem ser encontradas no apndice
A.
CTFL (Certified Tester Foundation Level)

A qualificao CTFL (Certified Tester Foundation Level) voltada para qualquer pessoa envolvida em teste
de software. Isto inclui pessoas em funes especficas de teste como: testadores, analistas, engenheiros,
consultores, gerentes, usurios que realizam teste de aceite e desenvolvedores de software. Este nvel de
qualificao tambm apropriado para qualquer profissional que queira adquirir uma base de compreenso
sobre teste de software, como gerentes de projetos, gerentes de qualidade, gerentes de desenvolvimento de
software, analistas de negcios, diretores de TI e consultores. Aqueles que alcanarem a Certificao estaro
aptos a buscar um nvel mais alto de qualificao em teste de software.
Objetivos de aprendizagem / nveis de conhecimento

Os seguintes nveis cognitivos so considerados para cada sesso neste syllabus:
K1: relembrar.
K2: entender.
K3: aplicar.
K4: analisar.
Maiores detalhes e exemplos dos objetivos de estudo so dados no Apndice B.
Todos os termos listados abaixo do tpico Termos devem ser relembrados (K1), mesmo que no forem
explicitamente mencionados nos objetivos de estudo.
O Exame
O exame CTFL ser baseado neste syllabus. Respostas para as questes do exame podem requerer o uso do
material baseado em mais de uma sesso do syllabus. Todas as sesses do syllabus podero ser contempladas
no exame.
O exame composto por questes de mltipla escolha.
Exames podem ser efetuados como parte de um treinamento certificado ou no. Um treinamento realizado por
uma entidade certificada pelo BSTQB no pr-requisito para a participao de um exame.
Autorizao
Provedores de treinamentos que utilizam o syllabus como referncia em seus cursos podem ser autorizados
por uma comisso nacional (board) reconhecida pelo ISTQB. Os procedimentos de autorizao podem ser
obtidos a partir de uma comisso (board) ou grupo que realiza a autorizao. Um curso autorizado
reconhecido em conformidade com este syllabus, sendo permitida a realizao de um exame do ISTQB como
parte do curso.
Maiores detalhes para os fornecedores de treinamento so dados no Apndice D.
Verso 2011br
Agosto 2011
Pgina 8 de 77
Certified Tester
Nvel de Detalhe
O nvel de detalhe do syllabus permite que o treinamento e o exame sejam feitos internacionalmente e de
forma consistente. Com foco em alcanar estes objetivos, o syllabus consiste de:
Objetivos de instruo geral descrevendo as intenes do syllabus.
Uma lista de informaes para o treinamento, incluindo uma descrio e referncias a fontes
adicionais, se necessria.
Objetivos de estudos para cada rea de conhecimento, descrevendo os resultados do conhecimento
aprendido e das metas a serem atingidas.
Uma lista de termos que os estudantes precisam estar aptos a relembrar e compreender.
Uma explicao dos conceitos principais a serem ensinados, incluindo as fontes, como a literatura
aceita ou padres.
O contedo do syllabus no uma descrio completa da rea de conhecimento de teste de software; ele
reflete o nvel de detalhe coberto no treinamento para o nvel fundamental.
Como este syllabus est organizado

H seis captulos principais. O ttulo no nvel mais alto acompanhado pelos nveis de aprendizagem cobertos
pelo captulo e pelo tempo de estudo para cada captulo. Por exemplo:
2. Teste durante o ciclo de vida do software (K2)
115 minutos
Mostra que o captulo 2 tem objetivos de estudos de K1 (assumido quando um nvel maior demonstrado) e
K2 (mas no K3) e est dimensionado para levar 115 minutos para cobrir o estudo do captulo.
Cada captulo composto de sees. Cada seo tambm tem os objetivos de aprendizagem e o tempo
necessrio para estudo. Subsees que no tm um tempo determinado so includas no tempo da seo.
Verso 2011br
Agosto 2011
Pgina 9 de 77
Certified Tester
1. Fundamentos do Teste (K2)
155 minutos
Objetivos de estudo para os fundamentos do teste

Os objetivos identificam o que voc estar apto a fazer aps o trmino de cada mdulo.
1.1
Porque necessrio testar? (K2)
LO-1.1.1
LO-1.1.2
LO-1.1.3
LO-1.1.4
LO-1.1.5
1.2
O que teste? (K2)
LO-1.2.1
LO-1.2.2
LO-1.2.3
1.3
Explicar os sete princpios do teste. (K2)
Fundamentos do processo de teste (K1)
LO-1.4.1
1.5
Recordar os objetivos comuns do teste. (K1)

Exemplificar os objetivos do teste em diferentes fases do ciclo de vida de um software. (K2)
Diferenciar teste de depurao de cdigo (K2)
Princpios gerais do teste (K2)
LO-1.3.1
1.4
Descrever com exemplos, a maneira com que o defeito no software pode causar danos a pessoas,
companhias ou ambientes. (K2)
Distinguir entre a causa raiz do defeito e seus efeitos. (K2)
Justificar a necessidade de testar utilizando exemplos. (K2)
Descrever porque teste parte da garantia da qualidade e dar exemplos de como o teste contribui
para atingir um nvel de qualidade superior. (K2)
Explicar e comparar termos como erro, defeito, dano, falha e seus termos correspondentes
engano e bug usando exemplos. (K2)
Recordar as cinco atividades fundamentais de teste e suas respectivas no planejamento do teste.

(K1)
A psicologia do teste (K2)
LO-1.5.1
LO-1.5.2
Recordar que o sucesso do teste influenciado por fatores psicolgicos (K1)

Diferenciar a forma de pensar dos testadores e dos desenvolvedores. (K2)
Verso 2011br
Agosto 2011
Pgina 10 de 77
Certified Tester
1.1 Porque necessrio testar? (K2)
20 minutos
Termos
Bug, defeito, erro, falha, dano, engano, qualidade, risco.
1.1.1 Contexto dos sistemas de software (K1)

Sistemas de software tornam-se cada vez mais parte do nosso dia-a-dia, desde aplicaes comerciais (ex.:
bancos) at produtos de consumo (ex.: carros). A maioria das pessoas j teve alguma experincia com um
software que no funcionou como esperado. Softwares que no funcionam corretamente podem levar a muitos
problemas, incluindo financeiro, tempo e reputao das empresas. Podendo, inclusive, chegar a influenciar na
integridade das pessoas.
1.1.2 Causas dos defeitos de software (K2)

O ser humano est sujeito a cometer um erro (engano), que produz um defeito (falha, bug), no cdigo, em
um software ou sistema ou em um documento. Se um defeito no cdigo for executado, o sistema falhar ao
tentar fazer o que deveria (ou, em algumas vezes, o que no deveria), causando uma falha. Defeitos no
software, sistemas ou documentos resultam em falhas, mas nem todos os defeitos causam falhas.
Os defeitos ocorrem porque os seres humanos so passveis de falha e porque existe presso no prazo,
cdigos complexos, complexidade na infraestrutura, mudanas na tecnologia e/ou muitas interaes de
sistema.
Falhas tambm podem ser causadas por condies do ambiente tais como: radiao, magnetismo, campos
eletrnicos e poluio, que podem causar falhas em software embarcado (firmware) ou influenciar a execuo
do software pela mudana das condies de hardware.
1.1.3 Funo do teste no desenvolvimento, manuteno e operao de software (K2).

Rigorosos testes em sistemas e documentaes podem reduzir os riscos de ocorrncia de problemas no
ambiente operacional, e contribui para a qualidade dos sistemas de software se os defeitos encontrados forem
corrigidos antes de implantados em produo.
O teste de software pode tambm ser necessrio para atender requisitos contratuais ou legais ou determinados
padres de mercado.
1.1.4 Teste e qualidade (K2)

Com a ajuda do teste possvel medir a qualidade do software em termos de defeitos encontrados, por
caractersticas e requisitos funcionais ou no funcionais do software (confiabilidade, usabilidade, eficincia,
manutenibilidade e portabilidade). Para mais informaes sobre testes no funcionais veja o Capitulo 2. Para
mais informaes sobre caractersticas do software, veja Software Engineering Software Product Quality
(ISO 9126).
O resultado da execuo dos testes pode representar confiana na qualidade do software caso sejam
encontrados poucos ou nenhum defeito. Um teste projetado adequadamente e cuja execuo no encontra
defeitos reduz o nvel de riscos em um sistema. Por outro lado, quando os testes encontram defeitos, a
qualidade do sistema aumenta quando estes so corrigidos.
Verso 2011br
Agosto 2011
Pgina 11 de 77
Certified Tester
Projetos anteriores devem prover lies aprendidas. Atravs do entendimento da causa raiz dos defeitos
encontrados em outros projetos, os processos podem ser aprimorados de modo a prevenir reincidncia de erros
e, consequentemente, melhorar a qualidade dos sistemas futuros.
Testes devem ser integrados como uma das atividades de garantia da qualidade (ex.: juntamente aos padres
de desenvolvimento, treinamento e anlise de defeitos).
1.1.5 Quanto teste suficiente? (K2)

Para decidir quanto teste suficiente, deve-se levar em considerao o nvel do risco, incluindo risco tcnico,
do negcio e do projeto, alm das restries do projeto como tempo e oramento. (Risco ser discutido com
mais detalhes no Captulo 5)
O teste deve prover informaes suficientes aos interessados (stakeholders) para tomada de deciso sobre a
distribuio do software ou sistema, para as prximas fases do desenvolvimento ou implantao nos clientes.
Verso 2011br
Agosto 2011
Pgina 12 de 77
Certified Tester
1.2 O que teste? (K2)
30 minutos
Termos
Depurao de cdigo, requisito, reviso, caso de teste, objetivo do teste.
Conceito
Uma viso comum do processo de teste de que ele consiste apenas da fase de execuo, como executar o
programa. Esta, na verdade, uma parte do teste, mas no contempla todas as atividades do teste.
Existem atividades de teste antes e depois da fase de execuo. Por exemplo: planejamento e controle, escolha
das condies de teste, modelagem dos casos de teste, checagem dos resultados, avaliao do critrio de
concluso, gerao de relatrios sobre o processo de teste e sobre sistema alvo e encerramento ou concluso
(ex.: aps a finalizao de uma fase de teste). Teste tambm inclui reviso de documentos (incluindo o cdigo
fonte) e anlise esttica.
Testes dinmicos e estticos podem ser usados para atingir objetivos similares e proveem informaes para
melhorar o sistema a ser testado e o prprio processo de teste.
Testes podem possuir objetivos diferentes:
Encontrar defeitos.
Ganhar confiana sobre o nvel de qualidade
Prover informaes para tomada de deciso.
Prevenir defeitos.
O processo mental de projetar testes de forma antecipada no ciclo de vida (verificando a base de teste atravs
da modelagem de teste) pode ajudar a prevenir defeitos que poderiam ser introduzidos no cdigo. A reviso de
documentos (ex.: requisitos) tambm ajuda a prevenir defeitos que possam aparecem no cdigo.
No processo de teste, diferentes pontos de vista levam a diferentes objetivos. Por exemplo, no teste feito em
desenvolvimento (teste de componente, integrao e de sistemas), o principal objetivo pode ser causar o maior
nmero de falhas possveis, de modo que os defeitos no software possam ser identificados e resolvidos. No
teste de aceite o objetivo principal pode ser confirmar se o sistema est funcionando conforme o esperado, ou
seja, prover a confiabilidade de que esteja de acordo com o requisito. Em alguns casos o principal objetivo do
teste pode ser avaliar a qualidade do software (no com a inteno de encontrar defeitos), para prover
informaes sobre os riscos da implantao do sistema em um determinado momento aos gestores. Os testes
de manuteno podem ser usados para verificar se no foram inseridos erros durante o desenvolvimento de
mudanas. Durante os testes operacionais, o principal objetivo pode ser avaliar caractersticas como
confiabilidade e disponibilidade.
Depurao de cdigo e teste so atividades diferentes. Testes podem demonstrar falhas que so causadas por
defeitos. Depurao de cdigo a atividade de desenvolvimento que identifica a causa de um defeito, repara o
cdigo e checa se os defeitos foram corrigidos corretamente. Depois feito um teste de confirmao por um
testador para certificar se a falha foi eliminada. As responsabilidades de cada atividade so bem distintas:
testadores testam e desenvolvedores depuram.
O processo de teste e suas atividades so explicados na seo 1.4.
Verso 2011br
Agosto 2011
Pgina 13 de 77
Certified Tester
1.3 Os sete Princpios do Teste (K2)
35 minutos
Termos
Teste exaustivo
Princpios
Alguns princpios foram sugeridos ao longo dos ltimos 40 anos, oferecendo um guia geral para o processo de
teste como um todo.
Princpio 1 Teste demonstra a presena de defeitos

O teste pode demonstrar a presena de defeitos, mas no pode provar que eles no existem. O Teste reduz a
probabilidade que os defeitos permaneam em um software, mas mesmo se nenhum defeito for encontrado,
no prova que ele esteja perfeito.
Princpio 2 Teste exaustivo impossvel

Testar tudo (todas as combinaes de entradas e pr-condies) no vivel, exceto para casos triviais. Em
vez do teste exaustivo, riscos e prioridades so levados em considerao para dar foco aos esforos de teste.
Princpio 3 Teste antecipado

A atividade de teste deve comear o mais breve possvel no ciclo de desenvolvimento do software ou sistema
e deve ser focado em objetivos definidos.
Princpio 4 Agrupamento de defeitos

Um nmero pequeno de mdulos contm a maioria dos defeitos descobertos durante o teste antes de sua
entrega ou exibe a maioria das falhas operacionais.
Princpio 5 Paradoxo do Pesticida

Pode ocorrer de um mesmo conjunto de testes que so repetidos vrias vezes no encontrarem novos defeitos
aps um determinado momento. Para superar este paradoxo do pesticida, os casos de testes necessitam ser
frequentemente revisado e atualizado. Um conjunto de testes novo e diferente precisa ser escrito para exercitar
diferentes partes do software ou sistema com objetivo de aumentar a possibilidade de encontrar mais erros.
Princpio 6 Teste depende do contexto

Testes so realizados de forma diferente conforme o contexto. Por exemplo, softwares de segurana crtica so
testados diferentemente de um software de comrcio eletrnico.
Princpio 7 A iluso da ausncia de erros

Encontrar e consertar defeitos no ajuda se o sistema construdo no atende s expectativas e necessidades dos
usurios.
Verso 2011br
Agosto 2011
Pgina 14 de 77
Certified Tester
1.4 Fundamentos do Processo de Teste (K1)
35 minutos
Termos
Teste de confirmao, reteste, critrio de sada, incidente, teste de regresso, base de teste, condio de teste,
cobertura de teste, dados de teste, execuo de teste, registro de teste, plano de teste, estratgia de teste,
poltica de teste, sute de teste, relatrio consolidado de teste, testware.
Conceito
A parte mais visvel do teste a execuo. Mas para se obter eficcia e eficincia, os planos de teste precisam
conter o tempo a ser gasto no planejamento dos testes, modelagem dos casos de testes e preparao da
execuo e avaliao de resultados.
O processo de teste bsico consiste das seguintes atividades:
Planejamento e controle
Anlise e modelagem
Implementao e execuo
Avaliao dos critrios de sada e relatrios
Atividades de encerramento de teste
Apesar de serem apresentadas sequencialmente, as atividades durante o processo podem sobrepor-se ou
acontecer de forma concorrente. Adaptando essas atividades principais dentro do contexto do sistema e do
projeto quando necessrio.
1.4.1 Planejamento e controle do teste (K1)

O planejamento de teste a atividade que consiste em definir os objetivos e especificar as atividades de forma
a alcan-los.
O controle do teste a constante atividade que consiste em comparar o progresso atual contra o que foi
planejado, reportando o status e os desvios do plano. Ele envolve ainda a tomada de aes necessrias para
alcanar a misso e objetivos do projeto. Para um controle efetivo, o teste dever ser monitorado durante todo
o projeto. O planejamento do teste leva em considerao o retorno de informaes das atividades de
monitorao e controle.
As tarefas de Planejamento e Controle esto definidas no Captulo 5
1.4.2 Anlise e modelagem do Teste (K1)

A anlise e a modelagem de teste so atividades onde os objetivos gerais do teste so transformados em
condies e modelos de teste tangveis.
A anlise e a modelagem de teste so compostas pelas seguintes atividades principais:
Revisar a base de testes (como requisitos, nvel de integridade do software1 (nvel de risco), arquitetura,
modelagem, interfaces).
Avaliar a testabilidade dos requisitos e do sistema.
Grau em que o software cumpre ou deve cumprir um conjunto e / ou caractersticas de sistema baseadas em software (por
exemplo: a complexidade do software, avaliao de risco, o nvel de segurana, desempenho, confiabilidade ou custo) que
so definidos para refletir a importncia do software para seus stakeholders.
Verso 2011br
Agosto 2011
Pgina 15 de 77
Certified Tester
Identificar e priorizar as condies ou requisitos de testes e dados de testes baseados na anlise dos itens
de teste, na especificao, no comportamento e na estrutura.
Projetar e priorizar os casos de testes de alto nvel.
Identificar as necessidades de dados para teste suportando as condies e casos de teste
Planejar a preparao do ambiente de teste e identificar a infraestrutura e ferramentas necessrias.
Criar uma rastreabilidade bidirecional entre os requisitos e os casos de teste.
1.4.3 Implementao e execuo de teste (K1)

A implementao e execuo do teste a atividade onde os procedimentos ou os scripts de teste so
especificados pela combinao dos casos de teste em uma ordem particular, incluindo todas as outras
informaes necessrias para a execuo do teste, o ambiente preparado e os testes so executados.
A implementao e execuo de teste so compostas pelas seguintes atividades principais:
Finalizar, implementar e priorizar os casos de teste (incluindo a identificao dos dados para teste).
Desenvolver e priorizar os procedimentos de teste, criar dados de teste e, opcionalmente, preparar o
ambiente para teste e os scripts de testes automatizados.
Criar sutes de teste a partir dos casos de teste para uma execuo de teste eficiente.
Verificar se o ambiente est preparado corretamente.
Verificar e atualizar a rastreabilidade bidirecional entre a base de teste e os casos de teste.
Executar os casos de teste manualmente ou utilizando ferramentas de acordo com a sequncia planejada.
Registrar os resultados da execuo do teste e anotar as caractersticas e verses do software em teste,
ferramenta de teste e testware.
Comparar resultados obtidos com os resultados esperados.
Reportar as discrepncias como incidentes e analis-los a fim de estabelecer suas causas (por exemplo,
defeito no cdigo, em algum dado especfico de teste, na documentao de teste ou uma execuo de
inadequada do teste).
Repetir os testes como resultado de aes tomadas para cada discrepncia. Por exemplo, re-execuo de
um teste que falhou previamente quando da confirmao de uma correo (teste de confirmao),
execuo de um teste corrigido e/ou execuo de testes a fim de certificar que os defeitos no foram
introduzidos em reas do software que no foram modificadas, ou que a correo do defeito no
desvendou outros defeitos (teste de regresso).
1.4.4 Avaliao do critrio de sada e relatrio (K1)

Avaliao do critrio de sada a atividade onde a execuo do teste avaliada mediante os objetivos
definidos. Deve ser feito para cada nvel de teste (ver seo 2.2)
A avaliao do critrio de sada composta pelas seguintes atividades principais:
Checar os registros de teste (logs) mediante o critrio de encerramento especificado no planejamento de
teste.
Avaliar se so necessrios testes adicionais ou se o critrio de sada especificado deve ser alterado.
Elaborar um relatrio de teste resumido para os interessados (stakeholders).
1.4.5 Atividades de encerramento de teste (K1)

Na atividade de encerramento de teste so coletados os dados de todas as atividades para consolidar a
experincia, testware, fatos e nmeros. Por exemplo, quando um software lanado, um projeto de teste
completado (ou cancelado), um marco do projeto foi alcanado, ou a implantao de um demanda de
manuteno foi completada.
Verso 2011br
Agosto 2011
Pgina 16 de 77
Certified Tester
As atividades de encerramento de teste so compostas pelas seguintes atividades principais:
Checar quais entregveis planejados foram realmente entregues
Fechar os relatrios de incidentes, ou levantar os registros de mudana que permaneceram abertos.
Documentar o aceite do sistema.
Finalizar e arquivar o testware, o ambiente de teste e infraestrutura de teste para o reuso.
Entregar o testware para a manuteno da organizao.
Analisar as lies aprendidas para se determinar as mudanas necessrias para futuros releases e
projetos.
Utilizar as informaes coletadas para melhorar a maturidade de teste
Verso 2011br
Agosto 2011
Pgina 17 de 77
Certified Tester
1.5 A Psicologia do Teste (K2)
25 minutos
Termos
Suposio de erro, Teste independente
Conceito
A forma de pensar utilizada enquanto se est testando e revisando diferente da utilizada enquanto se est
analisando e desenvolvendo. Com a sua forma de pensar, os desenvolvedores esto aptos a testarem seus
prprios cdigos, mas a separao desta responsabilidade para um testador tipicamente feita para ajudar a
focalizar o esforo e prover benefcios adicionais, como uma viso independente, profissional e treinada de
recursos de teste. Teste independente pode ser considerado em qualquer nvel de teste.
Certo grau de independncia (evitando a influncia do autor) muitas vezes representa uma forma eficiente de
encontrar defeitos e falhas. Independncia no significa simplesmente uma substituio, tendo em vista que os
desenvolvedores podem encontrar defeitos no cdigo de maneira eficiente. Nveis de independncia podem
ser definidos como:
Teste elaborado por quem escreveu o software que ser testado (baixo nvel de independncia).
Teste elaborado por outra(s) pessoa(s) (por exemplo, da equipe de desenvolvimento).
Teste elaborado por pessoa(s) de um grupo organizacional diferente (ex.: equipe independente de teste).
Teste elaborado por pessoa(s) de diferentes organizaes ou empresas (terceirizada ou certificada por
um rgo externo).
Pessoas e projetos so direcionados por objetivos. Pessoas tendem a alinhar seus planos com os objetivos da
gerncia e outros envolvidos (stakeholders) para, por exemplo, encontrar defeitos ou confirmar que o
software funciona. Desta forma, importante ter objetivos claros do teste.
Identificar falhas durante o teste pode ser considerado uma crtica contra o produto e o autor (responsvel pelo
produto). Teste , nestes casos, visto como uma atividade destrutiva, apesar de ser construtiva para o
gerenciamento do risco do produto. Procurar por falhas em um sistema requer curiosidade, pessimismo
profissional, um olhar crtico, ateno ao detalhe, comunicao eficiente com os profissionais do
desenvolvimento e experincia para encontrar erros.
Se os erros, defeitos ou falhas so comunicados de uma forma construtiva, podem-se evitar constrangimentos
entre as equipes de teste, analistas e desenvolvedores, tanto na reviso quanto no teste.
O testador e o lder da equipe de teste precisam ter boa relao com as pessoas para comunicar informaes
slidas sobre os defeitos, progresso e riscos de uma forma construtiva. A informao do defeito pode ajudar o
autor do software ou documento a ampliar seus conhecimentos. Defeitos encontrados e resolvidos durante o
teste trar ganho de tempo e dinheiro, alm de reduzir os riscos.
Problemas de comunicao podem ocorrer, especialmente se os testadores forem vistos somente como
mensageiros de ms notcias ao informar os defeitos. De qualquer forma, existem formas de melhorar a
comunicao e o relacionamento entre os testadores e os demais:
Comear com o esprito de colaborao, ao invs de disputa (conflitos), onde todos tm o mesmo
objetivo para alcanar a melhor qualidade do sistema.
Comunicar os erros encontrados nos produtos de uma forma neutra, dar foco no fato sem criticar a
pessoa que o criou, por exemplo, escrevendo objetivamente o relatrio de incidentes.
Tentar compreender como a pessoa se sente ao receber a notcia e interpretar sua reao.
Confirmar que a outra pessoa compreendeu o que voc relatou e vice-versa.
Verso 2011br
Agosto 2011
Pgina 18 de 77
Certified Tester
1.6 Cdigo de tica
10 minutos
O envolvimento em teste de software permite que pessoas conheam informaes confidenciais e

privilegiadas. Um cdigo de tica necessrio, entre outros motivos, para garantir que a informao no
usada de forma inapropriada. Reconhecendo o cdigo de tica para engenheiros da ACM e IEEE, o ISTQB
estabelece o seguinte cdigo de tica:
PBLICO Testadores certificados devem atuar consistentemente com o interesse pblico.
CLIENTE E EMPREGADOR Testadores certificados devem agir da melhor forma para os interesses de
seus clientes e empregadores, consistente com o interesse pblico.
PRODUTO Testadores certificados devem garantir que os entregveis que eles fornecem (produtos e
sistemas que eles testam) correspondem aos mais altos padres profissionais possveis.
JULGAMENTO Testadores certificados devem manter integridade e independncia em seu julgamento
profissional.
GERENCIAMENTO Gerentes e lderes de teste certificados devem se submeter e promover uma
abordagem tica ao gerenciamento do teste de software.
PROFISSO Testadores certificados devem promover a integridade e reputao da profisso,
consistentemente com o interesse pblico.
COLEGAS Testadores certificados devem ser agradveis e incentivadores com seus colegas, e promoverem
a cooperao com os desenvolvedores de software.
INDIVDUO Testadores certificados devem praticar um aprendizado vitalcio em considerao prtica de
sua profisso e devem promover uma abordagem tica nessa prtica.
Referncias
1.1.5 Black, 2001, Kaner, 2002
1.2 Beizer, 1990, Black, 2001, Myers, 1979
1.3 Beizer, 1990, Hetzel, 1998, Myers, 1979
1.4 Hetzel, 1998
1.4.5 Black, 2001, Craig, 2002
1.5 Black, 2001, Hetzel, 1998
Verso 2011br
Agosto 2011
Pgina 19 de 77
Certified Tester
2. Teste durante o ciclo de vida do software (K2)
115 minutos
Objetivos de estudo para o teste durante o ciclo de vida do software

Os objetivos identificam o que voc ser capaz de fazer aps a finalizao de cada mdulo.
2.1
Modelos de desenvolvimento de software (K2)
LO-2.1.1
LO-2.1.2
LO-2.1.3
2.2
Nveis de Teste (K2)
LO-2.2.1
2.3
Comparar os diferentes nveis de teste: principais objetivos, objetos tpicos de teste, alvos de
teste (ex.: funcional ou estrutural), produtos de trabalho, pessoas que testam tipos de defeitos e
falhas a serem identificadas. (K2)
Tipos de teste: os alvos do teste (K2)
LO-2.3.1
LO-2.3.2
LO-2.3.3
LO-2.3.4
LO-2.3.5
2.4
Compreender as relaes entre o desenvolvimento, atividades de teste e produtos de trabalho

durante o ciclo de desenvolvimento, dando exemplos baseados em projetos e caractersticas de
produtos e contexto (K2).
Reconhecer o fato do modelo de desenvolvimento de software precisar ser adaptado ao contexto
do projeto e s caractersticas do produto. (K1)
Rever as caractersticas de bons testes em qualquer modelo de ciclo de vida (K1).
Comparar quatro tipos de teste de software (funcional, no funcional, estrutural e relativo

mudana) atravs de exemplos. (K2)
Reconhecer que os testes funcionais e estruturais ocorrem em qualquer nvel de teste. (K1)
Identificar e descrever o tipo de teste no funcional baseado em requisito no funcional. (K2)
Identificar e descrever os tipos de teste baseados na anlise da estrutura ou arquitetura do
sistema. (K2)
Descrever o propsito do teste de confirmao e regresso. (K2)
Teste de Manuteno (K2)
LO-2.4.1
LO-2.4.2
LO-2.4.3
Comparar teste de manuteno (testar um sistema existente) com o teste em uma nova aplicao
segundo os critrios: tipo de teste, disparadores de testes (triggers) e quantidade de teste. (K2).
Identificar as razes teste de manuteno (modificao, migrao e retirada). (K1)
Descrever as funes do teste de regresso e da anlise de impacto na manuteno. (K2)
Verso 2011br
Agosto 2011
Pgina 20 de 77
Certified Tester
2.1 Modelos de Desenvolvimento de Software (K2)
35 minutos
Termos
Software comercial de prateleira (COTS - Commercial Off the Shelf), modelo de desenvolvimento
incremental, validao, verificao, Modelo V.
Conceito
No existe teste isolado; a atividade de teste est intimamente relacionada com as atividades de
desenvolvimento do software. Modelos de ciclo de vida de desenvolvimento diferentes necessitam de
abordagens diferentes para testar.
2.1.1 Modelo V (K2)

Apesar das variaes do Modelo V, um tipo comum deste modelo usa quatro nveis de teste correspondentes a
quatro nveis de desenvolvimento.
Os quatro nveis usados no syllabus so:
Teste de Componente (unidade);
Teste de Integrao;
Teste de Sistema;
Teste de Aceite;
Na prtica, um Modelo V, pode ter mais, menos ou diferentes nveis de desenvolvimento e teste, dependendo
do projeto e do produto. Por exemplo, pode haver teste de integrao de componentes aps o teste de um
componente, e teste de integrao de sistemas aps o teste de sistemas.
Produtos de trabalho de software (como cenrio de negcios ou casos de uso, especificao de requisitos,
documentos de modelagem e cdigo) produzidos durante o desenvolvimento muitas vezes so a base do teste
em um ou mais nvel de teste. Alguns exemplos de referncias para produtos de trabalho genricos: CMMI
(Capability Maturity Model Integration) ou os Software life cycle processes IEEE/IEC 12207. Verificao e
validao (e modelagem antecipada de teste) podem ser executadas durante a elaborao destes produtos de
trabalho.
2.1.2 Modelos iterativos de desenvolvimento (K2)

Desenvolvimento iterativo o processo que estabelece os requisitos, modelagem, construo e teste de um
sistema, realizada como uma srie de desenvolvimentos menores. Exemplos desenvolvimento iterativo:
prototipagem, desenvolvimento rpido de aplicao (RAD), Rational Unified Process (RUP) e modelos geis
de desenvolvimento. O produto resultante de uma iterao pode ser testado em vrios nveis como parte do
seu desenvolvimento. Um incremento, adicionado a outros desenvolvidos previamente, forma um sistema
parcial em crescimento, que tambm deve se testado. Teste de regresso tem sua importncia aumentada a
cada iterao. Verificao e validao podem ser efetuadas a cada incremento.
2.1.3 Teste dentro de um modelo de ciclo de vida (K2)

Os itens abaixo indicam as caractersticas para um bom teste para qualquer modelo de ciclo de vida:
Para todas as atividades do desenvolvimento h uma atividade de teste correspondente.
Cada nvel de teste tem um objetivo especfico daquele nvel.
Verso 2011br
Agosto 2011
Pgina 21 de 77
Certified Tester
A anlise e modelagem do teste para um dado nvel de teste devem comear durante a atividade de
desenvolvimento correspondente.
Testadores devem se envolver na reviso de documentos o mais cedo possvel utilizando as primeiras
verses disponveis ao longo ciclo de desenvolvimento.
Nveis de teste podem ser combinados ou reorganizados dependendo da natureza do projeto ou arquitetura do
sistema. Por exemplo, para a integrao de um pacote (COTS), em um sistema, o cliente pode fazer o teste de
integrao em nvel de sistema (ex.: integrao da infraestrutura ou outros sistemas, implantao do sistema) e
teste de aceite (funcional e/ou no funcional, teste de usurio e/ou operacional).
Verso 2011br
Agosto 2011
Pgina 22 de 77
Certified Tester
2.2 Nveis de Teste (K2)
60 minutos
Termos
Alfa Teste, Beta Teste, teste de componente (tambm conhecido como teste de unidade, mdulo ou teste de
programa), controlador (driver), teste no campo, requisitos funcionais, integrao, teste de integrao,
requisitos no funcionais, testes de robustez, simulador (stub), teste de sistema, nvel de teste,
desenvolvimento dirigido teste, ambientes de teste, teste de aceite do usurio.
Conceito
Para cada nvel de teste, os seguintes aspectos podem ser identificados: seus objetivos genricos, os produtos
de trabalho utilizados como referncia para derivar os casos de testes (ex.: base do teste), o objeto do teste (o
que est sendo testado), defeitos e falhas tpicas a se encontrar, testes (harness) e ferramentas de suporte e
abordagens e responsabilidades especficas.
2.2.1 Teste de Componente (K2)

Teste de componentes procura defeitos e verifica o funcionamento do software (ex.: mdulos, programas,
objetos, classes, etc.) que so testveis separadamente. Pode ser feito isolado do resto do sistema, dependendo
do contexto do ciclo de desenvolvimento e do sistema. Controladores (drivers) e simuladores (stubs)
podem ser usados.
Teste de componente pode incluir teste de funcionalidade e caractersticas especficas no funcionais tais
como comportamento dos recursos (ex.: falta de memria) e testes de robustez, alm de teste estrutural
(cobertura de cdigo). Casos de teste so derivados dos produtos de trabalho como, por exemplo,
especificao de componente, modelagem do software ou modelo de dados.
Tipicamente, teste de componente ocorre com acesso ao cdigo que est sendo testado e no ambiente de
desenvolvimento, assim como um framework de teste de unidade ou ferramenta de depurao debugging.
Na prtica, envolve o programador do cdigo. Defeitos so normalmente corrigidos assim que so
encontrados sem registrar formalmente os incidentes.
Uma abordagem no teste de componente consiste em preparar e automatizar os casos de testes antes de
codificar. Isto chamado de abordagem de teste antecipado ou desenvolvimento dirigido a teste. Esta
abordagem essencialmente iterativa e baseada em ciclos de elaborao de casos de testes. medida que
so construdas e integradas pequenas partes do cdigo, so executados testes de componente at que eles
passem.
2.2.2 Teste de Integrao (K2)

Teste de integrao caracterizado por testar as interfaces entre os componentes, interaes de diferentes
partes de um sistema, como o sistema operacional, arquivos, hardware ou interfaces entre os sistemas.
Pode haver mais que um nvel de teste de integrao, que pode ser utilizado em objetos de teste de tamanho
variado. Por exemplo:
Teste de integrao de componente testa interaes entre componentes de software e realizado aps o
teste de componente.
Teste de integrao de sistemas testa interao entre diferentes sistemas e pode ser realizado aps o teste
de sistema. Neste caso a rea de desenvolvimento pode controlar apenas um lado da interface, de forma
que mudanas podem causar instabilidades. Processos de negcios implementados como fluxogramas
Verso 2011br
Agosto 2011
Pgina 23 de 77
Certified Tester
podem envolver uma srie de sistemas. Problemas relacionados a mltiplas plataformas podem ser
significativos.
Quanto maior o escopo da integrao, maior a dificuldade de isolar as falhas para componentes ou sistemas
especficos, fato que pode representar um aumento no risco.
Estratgias sistemticas de integrao podem ser baseadas na arquitetura do sistema (top-down e bottom-up),
funes, sequncias de processamento de transaes, entre outros aspectos do sistema ou componente.
Visando reduzir o risco de encontrar defeitos tardiamente, a integrao deve, preferencialmente, ser
incremental e no big bang.
Teste de caractersticas no funcionais especficas (por exemplo, performance) pode ser includo nos testes de
integrao.
A cada estgio da integrao, os testadores concentram somente na integrao propriamente. Por exemplo, o
mdulo A est sendo integrado com o mdulo B o foco a comunicao entre os mdulos, no suas
funcionalidades. Tanto testes funcionais quanto estruturais podem ser utilizados.
Idealmente, os testadores devem compreender a arquitetura e influenciar no planejamento da integrao. Se o
teste de integrao for planejado antes que os componentes ou sistemas estejam prontos, eles podem ser
preparados visando um teste mais eficiente.
2.2.3 Teste de Sistema (K2)

Teste de sistema se refere ao comportamento de todo do sistema / produto definido pelo escopo de um projeto
ou programa de desenvolvimento.
No teste de sistema, o ambiente de teste deve corresponder o mximo possvel ao objetivo final, ou o ambiente
de produo, para minimizar que os riscos de falhas especficas de ambiente no serem encontradas durante o
teste.
Testes de sistemas podem ser baseados em especificao de riscos e/ou de requisitos, processos de negcios,
casos de uso, dentre outras descries de alto nvel do comportamento, interaes e recursos do sistema.
Teste de sistema deve tratar requisitos funcionais e no funcionais do sistema. Os requisitos podem estar como
um texto ou diagramas. Testadores devem tambm lidar com requisitos incompletos ou no documentados.
Teste de sistema em requisitos funcionais deve inicialmente utilizar a tcnica baseada em especificao mais
apropriada (caixa-preta) de acordo com a caracterstica do sistema a ser testado. Por exemplo, uma tabela de
deciso pode ser criada por combinaes de efeitos descritos em regras de negcio. A seguir, tcnica baseada
na estrutura (caixa-branca) pode ser utilizada para avaliar a eficcia do teste com respeito ao elemento
estrutural, assim como estrutura do menu ou pgina web. (Ver Captulo 4.)
Uma equipe de teste independente frequentemente responsvel pelo teste de sistema.
2.2.4 Teste de Aceite (K2)

Teste de aceite frequentemente de responsabilidade do cliente ou do usurio do sistema; os interessados
(stakeholders) tambm podem ser envolvidos.
O objetivo do teste de aceite estabelecer a confiana no sistema, parte do sistema ou uma caracterstica no
especfica do sistema. Procurar defeitos no o principal foco do teste de aceite. Teste de aceite pode avaliar a
disponibilidade do sistema para entrar em produo, apesar de no ser necessariamente o ltimo nvel de teste.
Por exemplo, teste de integrao em larga escala pode vir aps o teste de aceite de um sistema.
Verso 2011br
Agosto 2011
Pgina 24 de 77
Certified Tester
O teste de aceite pode ser realizado em mais de um nico nvel de teste, por exemplo:
Um pacote (COTS) de software ter um teste de aceite quando instalado ou integrado.
Teste de aceite de usabilidade de um componente pode ser feito durante o teste de componente.
Teste de aceite de uma nova funcionalidade pode vir antes do teste de sistema.
As formas de teste de aceite incluem tipicamente os seguintes:
Teste de Aceite de Usurio

Normalmente verifica se o sistema est apropriado para o uso por um usurio com perfil de negcio.
Teste Operacional de Aceite

O aceite do sistema pelo administrador dos sistemas inclui:
Teste de Backup/Restore.
Recuperao de Desastre.
Gerenciamento de Usurio.
Tarefas de manuteno.
Checagens peridicas de vulnerabilidades de segurana.
Teste de aceite de contrato e regulamento

Teste de aceite de contrato realizado verificando-se algum critrio de aceite incluso em contrato na produo
de software encomendado. O critrio de aceite deve ser definido quando o contrato assinado. Teste de aceite
de regulamento quando se verifica a necessidade de adeso a algum regulamento de acordo com outras
normas (ex.: segurana, governamental, legislao).
Alfa e Beta Teste (ou teste no campo)

Desenvolvedores de softwares comerciais ou pacotes, muitas vezes precisam obter um feedback de clientes
em potencial existente no mercado antes que o software seja colocado venda comercialmente. Alfa Teste
feito no site da organizao em que o produto foi desenvolvido. Beta Teste, ou teste no campo, feito pelas
pessoas em suas prprias localidades. Ambos os testes so feitos pelos clientes em potencial e no pelos
desenvolvedores do produto.
Organizaes podem utilizar outros termos como Teste de Aceite de Fbrica e Teste de Aceite no site, para
sistemas que so testados antes e aps terem sido movidos ao site do cliente.
Verso 2011br
Agosto 2011
Pgina 25 de 77
Certified Tester
2.3 Tipos de Teste: o alvo do teste
40 minutos
Termos
Teste caixa-preta, cobertura de cdigo, teste funcional, teste de interoperabilidade, teste de carga, teste de
manutenibilidade, teste de performance, teste de portabilidade, teste de regresso, teste de confiabilidade, teste
de segurana, teste baseado em especificao, teste de estresse, teste estrutural, teste de usabilidade, teste
caixa-branca.
Conceito
Um grupo de atividades de teste pode ser direcionado para verificar o sistema (ou uma parte do sistema) com
base em um motivo ou alvo especfico.
Cada tipo de teste tem foco em um objetivo particular, que pode ser o teste de uma funcionalidade, a ser
realizada pelo software; uma caracterstica da qualidade no funcional, tal como a confiabilidade ou
usabilidade, a estrutura ou arquitetura do software ou sistema; ou mudanas relacionadas, ex.: confirmar que
os defeitos foram solucionados (teste de confirmao) e procurar por mudanas inesperadas (teste de
regresso).
Modelos do software podem ser elaborados e/ou usados no teste estrutural ou funcional. Por exemplo, para o
teste funcional, um diagrama de fluxo de processo, um diagrama de transio de estados ou uma especificao
do programa, e para teste estrutural um diagrama de controle de fluxo ou modelo de estrutura do menu.
2.3.1 Teste de Funo (Teste funcional) (K2)

As funes que um sistema, subsistema ou componente devem realizar podem ser descritas nos seguintes
produtos de trabalho: especificao de requisitos; casos de uso, especificao funcional, ou podem no estar
documentados. As funes representam o que o sistema faz.
Testes funcionais so baseados em funes (descritas nos documentos ou compreendidas pelos testadores), e
devem ser realizados em todos os nveis de teste (ex.: teste de componente deve ser baseado na especificao
do componente).
Tcnicas baseadas em especificao podem ser utilizadas para derivar as condies de teste e casos de testes a
partir da funcionalidade do software ou sistema (Ver Captulo 4). Teste funcional considera o comportamento
externo do software (teste caixa-preta).
Um tipo de teste funcional, o teste de segurana, investiga as funes (ex.: um firewall) relacionados
deteco de ameaa de vrus ou de aes mal intencionadas.
2.3.2 Teste de caractersticas do produto de software (testes no funcionais) (K2)

Testes no funcionais incluem, mas no se limita a: teste de performance; teste de carga; teste de estresse;
teste de usabilidade; teste de interoperabilidade; teste de manutenibilidade; teste de confiabilidade e teste de
portabilidade. o teste de como o sistema trabalha.
Testes no funcionais podem ser realizados em todos os nveis de teste. O termo teste no funcional descreve
que o teste executado para medir as caractersticas que podem ser quantificadas em uma escala varivel,
como o tempo de resposta em um teste de performance. Estes testes podem ser referenciados a um modelo de
qualidade como definido na norma Engenharia de Software Qualidade de Produto de Software (ISO
9126).
Verso 2011br
Agosto 2011
Pgina 26 de 77
Certified Tester
2.3.3 Teste de estrutura/arquitetura do software (teste estrutural) (K2)
Teste estrutural (caixa-branca) pode ser feito em todos os nveis de testes. Recomenda-se utilizar as tcnicas
estruturais aps as tcnicas baseadas em especificao, j que ela auxilia a medio da eficincia do teste
atravs da avaliao da cobertura de um tipo de estrutura.
Cobertura a extenso que uma estrutura foi exercitada por um conjunto de testes, expresso como uma
porcentagem de itens cobertos. Se a cobertura no atinge 100%, ento mais testes devem ser construdos a fim
de testar aqueles itens que no foram contemplados para, desta forma, aumentar a cobertura. Tcnicas de
cobertura so discutidas no Captulo 4.
Em todos os nveis de teste, mas especialmente no teste de componente e teste de integrao de componentes,
ferramentas podem ser usadas para medir a cobertura do cdigo dos elementos assim como as declaraes ou
decises. Teste estrutural deve ser baseado na arquitetura do sistema, como uma hierarquia de chamadas.
Teste de estrutura tambm pode ser aplicado no sistema, integrao de sistema ou nvel de teste de aceite (por
exemplo, para modelos de negcios ou estrutura de menu).
2.3.4 Teste relacionado a mudanas (teste de confirmao e regresso) (K2)

Quando um defeito detectado e resolvido, o software pode ser retestado para confirmar que o defeito original
foi realmente removido. Isto chamado de teste de confirmao. Depurar (resolver defeitos) uma atividade
do desenvolvimento, e no uma atividade do teste.
Teste de regresso o teste repetido de um programa que j foi testado, aps sua modificao, para descobrir
a existncia de algum defeito introduzido ou no coberto originalmente como resultado da mudana. Estes
defeitos podem estar no software ou em um componente, relacionado ou no ao software. realizado quando
o software, ou seu ambiente modificado. A quantidade de teste de regresso baseada no risco de no se
encontrar defeitos no software que estava funcionando previamente.
Os testes devem ser repetveis se forem utilizados nos teste de confirmao e para suportar o teste de
regresso.
Teste de regresso pode ser realizado em todos os nveis de teste, e se aplicam aos testes funcionais, no
funcionais e estruturais. Testes de regresso so executados muitas vezes e geralmente desenvolve-se
vagarosamente, o que faz com que seja um forte candidato automao.
Verso 2011br
Agosto 2011
Pgina 27 de 77
Certified Tester
2.4 Teste de Manuteno
15 minutos
Termos
Anlise de impacto, teste de manuteno
Conceito
Uma vez desenvolvido, um sistema pode ficar ativo por anos ou at mesmo dcadas. Durante este tempo o
sistema e seu ambiente podem ser corrigidos, modificados ou completados. Teste de manuteno realizado
no mesmo sistema operacional e iniciado por modificaes, migraes ou retirada de software ou sistema.
Alguns exemplos de modificaes incluem melhorias planejadas (ex.: baseadas em releases), mudanas
corretivas e emergenciais, alm de mudanas de ambiente, como atualizao em sistema operacional ou banco
de dados, e correes (patches) para expor e encontrar vulnerabilidades do sistema operacional.
Teste de manuteno por migrao (ex.: de uma plataforma a outra) pode incluir testes operacionais do novo
ambiente tanto quanto a mudana de software.
Teste de manuteno para retirada de um sistema pode incluir o teste de migrao de dados, ou arquivamento
se longos perodos de reteno de dados forem necessrios.
Alm de testar o que foi alterado, o teste de manuteno inclui teste de regresso massivo para as partes do
sistema que no foram testadas. O escopo do teste de manuteno est relacionado ao risco da mudana, o
tamanho do sistema existente e o tamanho da mudana. Dependendo da mudana, o teste de manuteno pode
ser feito em todos ou alguns nveis, e em todos ou alguns tipos de testes.
A determinao de como um sistema pode ser afetado por mudanas chamado de anlise de impacto, e pode
ser usado para ajudar a decidir quantos testes de regresso sero realizados.
Teste de manuteno pode se tornar uma tarefa complicada se as especificaes estiverem desatualizadas ou
incompletas.
Referncias
2.1.3 CMMI, Craig, 2002, Hetzel, 1998, IEEE 12207
2.2 Hetzel, 1998
2.2.4 Copeland, 2004, Myers, 1979
2.3.1 Beizer, 1990, Black, 2001, Copeland, 2004
2.3.2 Black, 2001, ISO 9126
2.3.3 Beizer, 1990, Copeland, 2004, Hetzel, 1998
2.3.4 Hetzel, 1998, IEEE 829
2.4 Black, 2001, Craig, 2002, Hetzel, 1998, IEEE 829
Verso 2011br
Agosto 2011
Pgina 28 de 77
Certified Tester
3. Tcnicas Estticas (K2)
60 minutos
Objetivos de estudo para tcnicas estticas

Os objetivos identificam o que voc dever aprender para completar cada mdulo.
3.1
Reviso e o processo de teste (K2)
LO-3.1.1
LO-3.1.2
LO-3.1.3
3.2
Processo de Reviso (K2)
LO-3.2.1
LO-3.2.2
LO-3.2.3
3.3
Reconhecer os produtos de trabalho que podem ser examinados pelas diferentes tcnicas
estticas (K1).
Descrever a importncia e o valor das tcnicas estticas para a avaliao dos produtos de
trabalhos. (K2)
Explicar a diferena entre as tcnicas dinmicas e estticas, considerando objetivos, tipos de
defeitos a serem identificados, e o papel dessas tcnicas dentro do ciclo de vida do software.
(K2)
Relembrar as fases, funes e responsabilidades de um processo tpico de reviso (K1).

Explicar as diferenas entre os tipos de reviso: reviso informal, reviso tcnica,
acompanhamento (walkthrough) e inspees. (K2)
Explicar os fatores de sucesso das revises (K1).
Ferramentas de anlise estticas (K2)
LO-3.3.1
LO-3.3.2
LO-3.3.3
Recordar os defeitos mais comuns e erros identificados pela anlise esttica e compar-los com a
reviso e teste dinmico. (K1)
Listar os benefcios mais comuns da anlise esttica. (K1)
Listar defeitos de cdigo e modelagem mais comuns que podem ser identificados por
ferramentas de anlise esttica. (K1)
Verso 2011br
Agosto 2011
Pgina 29 de 77
Certified Tester
3.1 Reviso e o Processo de Teste (K2)
15 minutos
Termos
Teste dinmico, Teste esttico.
Contedo
Ao contrrio dos testes dinmicos, as tcnicas de teste esttico no pressupem a execuo do software que
est sendo testado. Elas so manuais (reviso) ou automatizadas (anlise esttica).
Reviso uma maneira de testar o produto de software (incluindo o cdigo) e pode ser realizada bem antes da
execuo do teste dinmico. Defeitos detectados durante as revises o mais cedo possvel no ciclo de vida do
software so muitas vezes mais barato do que aqueles detectados e removidos durante os testes (ex.: defeitos
encontrados nos requisitos).
Uma reviso pode ser feita inteiramente como uma atividade manual, mas h tambm ferramentas de suporte.
A principal atividade manual examinar o produto de trabalho e fazer os comentrios sobre ele. Qualquer
software pode ser revisado, incluindo a especificao de requisitos, diagramas, cdigo, plano de teste,
especificao de teste, casos de teste, script de teste, manual do usurio ou pginas web.
Os benefcios das revises incluem a deteco e correo antecipada de defeitos, ganho no desenvolvimento
em termos de produtividade, reduo do tempo no desenvolvimento, reduo do custo e tempo de teste, menos
defeitos e melhoria na comunicao. A reviso pode encontrar omisses, por exemplo, nos requisitos, que no
so normalmente encontrados no teste dinmico.
Revises, anlises estticas e testes dinmicos tm os mesmos objetivos identificar defeitos. Eles so
complementares: as diferentes tcnicas podem encontrar diferentes tipos de defeitos eficazmente e
eficientemente. Em contraste com o teste dinmico, revises encontram defeitos ao invs de falhas.
Os defeitos mais facilmente encontrados durante revises do que em testes dinmicos so: desvios de padres,
defeitos de requisitos, defeitos de modelagem, manutenibilidade insuficientemente e especificao incorreta
de interfaces.
Verso 2011br
Agosto 2011
Pgina 30 de 77
Certified Tester
3.2 Processo de Reviso (K2)
25 minutos
Termos
Critrio de entrada, reviso formal, reviso informal, inspeo, mtricas, moderador, reviso em par, revisor,
redator, reviso tcnica, acompanhamento (walkthrough).
Contedo
As revises variam de muito informais para muito formais (ex.: bem estruturadas e reguladas). A formalidade
do processo de reviso relacionada a fatores como a maturidade do processo de desenvolvimento, requisitos
legais e reguladores ou a necessidade de acompanhamento de auditoria.
O modo como uma reviso conduzida depende do seu objetivo (ex.: encontrar defeitos, obter compreenso,
discusso ou decises por um consenso).
3.2.1 Fases de uma reviso formal (K1)

Uma reviso formal normalmente possui as seguintes fases principais:
Planejamento:
Definir os critrios de reviso.
Selecionar a equipe.
Alocar as funes.
Definir os critrios de entrada e de sada para os diversos tipos de reviso formal (ex.: inspeo).
Selecionar quais as partes dos documentos ser visto.
Checar os critrios de entrada (para diversos tipos de reviso formal).
Kick-off:
Distribuir os documentos.
Explicar os objetivos, processos e documentos para os participantes.
Preparao individual:
Anlise da documentao para a reunio de reviso.
Anotar os defeitos em potenciais, questes e comentrios.
Reunio de reviso:
Discusso ou registro, com resultados documentados ou anotaes (para os tipos de revises mais
formais).
Anotar os defeitos, fazer recomendaes para o tratamento de defeitos ou tomar decises sobre os
defeitos.
Examinar, avaliar e registrar questes durante as reunies de acompanhamento.
Retrabalho:
Resolver defeitos encontrados, tipicamente feitos pelo autor.
Registrar os status atuais dos defeitos (para revises formais).
Acompanhamento:
Checar se os defeitos foram encaminhados.
Obter mtricas.
Checar os critrios de sada (para tipos de revises formais).
Verso 2011br
Agosto 2011
Pgina 31 de 77
Certified Tester
3.2.2 Papis e responsabilidades (K1)
Uma tpica reviso formal inclui as funes abaixo:
Gerente: toma deciso durante a realizao da reviso, aloca tempo nos cronogramas de projeto e
determina se o objetivo da reviso foi atingido.
Moderador: a pessoa que lidera a reviso do documento ou conjunto de documentos, incluindo o
planejamento da reviso, e o acompanhamento aps a reunio. Se necessrio, o moderador mediar
entre os vrios pontos de vista e muitas vezes quem responder pelo sucesso da reviso.
Autor: a pessoa que escreveu ou que possui a responsabilidade pelos documentos que sero
revisados.
Revisores: indivduos com conhecimento tcnico ou de negcio (tambm chamados inspetores), que,
aps a preparao necessria, identificam e descrevem os defeitos encontrados no produto em reviso.
Revisores podem ser escolhidos para representar diferentes funes e perspectivas no processo de
reviso, e parte integrante de qualquer reunio de reviso.
Redator: documenta todo o contedo da reunio, problemas e itens em aberto que foram identificados
durante a reunio.
Olhando os documentos de diferentes perspectivas e usando check-lists, tornamos a reviso mais eficaz e
eficiente. Por exemplo, um check-list baseado em perspectivas tais como a do usurio, desenvolvedor,
testador, operador, ou um check-list tpico de problemas de requisitos pode ajudar a descobrir problemas
no detectados anteriormente.
3.2.3 Tipos de reviso (K2)

Um nico documento pode ser objeto para mais de uma reviso. Se mais de um tipo de reviso for usado, a
ordem pode variar. Por exemplo, uma reviso informal pode ser conduzida antes de uma reviso tcnica, ou
uma inspeo pode ser executada em uma especificao de requisitos antes de um acompanhamento com
clientes. As principais caractersticas, opes e propsitos dos tipos de reviso comumente so:
Reviso informal:
No existe processo formal.
Pode haver programao em pares ou um lder tcnico revisando a modelagem e o cdigo.
A documentao opcionalmente.
A importncia pode variar dependendo do revisor.
Principal propsito: uma forma de obter algum benefcio a um baixo custo.
Acompanhamento:
Reunio conduzida pelo autor.
Cenrios, grupos de discusso, exerccios prticos.
Sesses sem restrio de tempo.
Opcionalmente h uma reunio preparatria dos revisores.
Opcionalmente, relatrios de reviso e lista de defeitos encontrados so preparados.
Opcionalmente h um redator.
Na prtica pode variar de informal para muito formal.
Principal propsito: aprendizagem, obteno de entendimento e encontrar defeitos.
Revises tcnicas:
Documentado, processo de deteco de defeito definido que inclui colegas especialistas ou tcnicos
com a participao opcional da gerncia.
Pode ser feito por um colega sem a participao da gerncia.
Verso 2011br
Agosto 2011
Pgina 32 de 77
Certified Tester
Idealmente so conduzidas por um moderador treinado (que no seja o autor).
Reunio preparatria dos revisores.
Opcionalmente usa check-lists.
Elaborao de um relatrio de reviso, que inclui a lista de defeitos encontrados, se o produto de
software corresponde s suas exigncias e, quando apropriado, recomendaes relacionadas com as
descobertas.
Na prtica, pode variar de informal para muito formal.
Principais propsitos: discusso, tomada de decises, avaliar alternativas, encontrar defeitos, resolver
problemas tcnicos e checar a conformidade da padronizao das especificaes.
Inspeo :
Conduzida pelo moderador (que no seja o autor).
Geralmente uma anlise por pares.
Papis definidos.
Utilizao de mtricas.
Processo formal baseado em regras e utilizao de check-list.
Entrada especificada e critrios de sada para a aceitao do produto de software.
Reunio de preparao.
Relatrio de inspeo, lista de defeitos encontrados;
Processo de acompanhamento formal.
Opcionalmente, ter aperfeioamento do processo e um leitor.
Principal propsito: encontrar defeitos.
Acompanhamento, revises tcnicas e inspees podem ser executados dentro de um grupo de pessoas no
mesmo nvel organizacional. Este tipo de reviso chamado de reviso por pares.
3.2.4 Fatores de sucesso para as revises (K2)

Os fatores de sucesso para as revises incluem:
Cada reviso tem um objetivo claramente definido.
A pessoa adequada para os objetivos da reviso deve ser envolvida.
Testadores so valorizados como revisores que contribuem para a reviso e aprendizado sobre o
produto o que lhes permite preparar os testes facilmente.
Defeitos encontrados so encorajados e expressados objetivamente.
Deve-se lidar com os problemas pessoais e aspectos psicolgicos (ex.: fazer com que a reunio seja
uma experincia positiva para o autor).
A anlise conduzida em uma atmosfera de confiana, o resultado no ser utilizado para a avaliao
dos participantes.
Tcnicas de reviso so aplicadas de forma a combinar com o tipo e nvel do software e revisores.
Caso necessrio, check-lists ou papis so utilizados para aumentar a eficincia na identificao de
defeitos.
Treinamento um item importante para as tcnicas de reviso, especialmente para as tcnicas formais,
assim como as inspees.
Gerenciamento importante para um bom processo de reviso (ex.: incorporando o tempo adequado
para as atividades de reviso nos cronogramas de projetos).
H uma nfase em aprender e aprimorar o processo.
Verso 2011br
Agosto 2011
Pgina 33 de 77
Certified Tester
3.3 Anlise Esttica por Ferramentas (K2)
20 minutos
Termos
Compilador, complexidade, controle de fluxo, fluxo de dados, anlise esttica.
Conceito
O objetivo da anlise esttica encontrar defeitos no cdigo fonte do software e na modelagem. Anlise
esttica feita sem a execuo do software examinado pela ferramenta; j o teste dinmico executa o
software. Anlise esttica pode localizar defeitos que so dificilmente encontrados em testes. Como as
revises, a anlise esttica encontra defeitos ao invs de falhas. Ferramentas de anlise esttica analisam o
cdigo do programa (ex.: fluxo de controle e fluxo de dados), gerando, como sada, arquivos do tipo HTML e
XML, por exemplo.
Os benefcios da anlise esttica so:
Deteco de defeitos antes da execuo do teste.
Conhecimento antecipado sobre aspectos suspeitos no cdigo ou programa atravs de mtricas, por
exemplo, na obteno de uma medida da alta complexidade.
Identificao de defeitos dificilmente encontrados por testes dinmicos.
Deteco de dependncias e inconsistncias em modelos de software, como links perdidos.
Aprimoramento da manutenibilidade do cdigo e construo.
Preveno de defeitos, se as lies forem aprendidas pelo desenvolvimento.
Defeitos mais comuns descobertos por ferramentas de anlise esttica incluem:
Referncia a uma varivel com valor indefinido.
Inconsistncias entre as interfaces dos mdulos e componentes.
Variveis que nunca so usadas ou impropriamente declaradas.
Cdigo morto.
Falta de lgica ou lgica errada (loops infinitos).
Construes excessivamente complicadas.
Violao de padres de programao.
Vulnerabilidade na segurana.
Violao de sintaxe e de modelos.
Ferramentas de anlises estticas so tipicamente usadas por desenvolvedores (checando regras pr-definidas
ou padres de programao) antes e durante o teste de componente e de integrao e por projetistas durante a
modelagem do software. Ferramenta de anlise esttica pode produzir um grande nmero de mensagens de
advertncias que precisam ser gerenciadas para permitir o uso mais efetivo da ferramenta.
Compiladores podem oferecer algum suporte para a anlise esttica, incluindo o clculo de mtricas.
Referncias
3.2 IEEE 1028
3.2.2 Gilb, 1993, van Veenendaal, 2004
3.2.4 Gilb, 1993, IEEE 1028
3.3 Van Veenendaal, 2004
Verso 2011br
Agosto 2011
Pgina 34 de 77
Certified Tester
4. Tcnica de Modelagem de Teste (K3)
255 minutos
Objetivos de estudo para Tcnicas de Modelagem de Teste

Os objetivos identificam o que voc dever aprender para completar cada mdulo.
4.1
Identificar as condies de testes e os casos de testes (K3)
LO-4.1.1
LO-4.1.2
LO-4.1.3
LO-4.1.4
4.2
Categorias de tcnicas de modelagem de teste (K2)
LO-4.2.1
LO-4.2.2
4.3
LO-4.3.2
LO-4.3.3
LO-4.4.3
LO-4.4.4
Descrever o conceito e a importncia da cobertura de cdigo. (K2)

Explicar o conceito da cobertura de deciso ou de comandos, demonstrando que estes conceitos
podem ser utilizados em outros nveis de testes alm do teste de componente (ex.: Teste de
regras de negcios em nvel de sistema). (K2)
Criar casos de testes de um dado fluxo de controle utilizando as seguintes tcnicas: Teste de
Sentena e Teste de Deciso.
Avaliar a abrangncia da cobertura de sentena e deciso para a completude com respeito a
critrios de sada definidos. (K3)
Tcnicas baseadas em experincia (K2)
LO-4.5.1
LO-4.5.2
4.6
Montar os casos de teste de um dado software utilizando as seguintes tcnicas: Partio de

Equivalncia, Anlise de Valores Limite, Tabela de Deciso e Diagrama de Transio (K3)
Compreender os principais objetivos de cada uma das quatro tcnicas, qual nvel e tipo de teste
mais adequado para se utiliz-las e como a cobertura poder ser medida. (K2)
Compreender o conceito de Teste de Caso de Uso e seus benefcios. (K2)
Tcnicas baseadas em estrutura interna do software ou caixa-branca (K3)
LO-4.4.1
LO-4.4.2
4.5
Rever as razes de por que tanto a abordagem de casos testes baseada em especificao (caixa
preta) quanto baseada em estrutura interna do software (caixa branca) so importantes, e listar as
tcnicas mais comuns de cada uma. (K1)
Explicar as caractersticas e diferenas entre as tcnicas de teste baseada em especificao,
baseada em estrutura e baseada em experincia. (K2)
Tcnicas baseada em especificao ou caixa-preta (K3)
LO-4.3.1
4.4
Diferenas entre especificao de Planos de Teste, Casos de Testes e procedimentos de Teste.

(K2)
Comparar os termos: Condies do Teste, Caso de Teste e Procedimento de Teste. (K2)
Avaliar a qualidade dos Casos de Teste em termos de clara rastreabilidade aos requisitos e
resultados esperados. (K2)
Traduzir Casos de Testes em uma especificao de procedimento de teste bem estruturada em
um nvel de detalhe relevante para conhecimento dos testadores. (K3)
Rever as razes para se construir os casos de testes com base na intuio, experincia e
conhecimento dos defeitos. (K1)
Comparar a tcnica baseada em experincia com as baseadas em especificao. (K2)
Escolhendo tcnicas de teste (K2)
LO-4.6.1
Classificar as tcnicas de modelagem de teste de acordo com o contexto, base de teste, modelos e
caractersticas de software (K2)
Verso 2011br
Agosto 2011
Pgina 35 de 77
Certified Tester
4.1 Identificando as condies de testes e projetando os casos
de testes (K3)
15 minutos
Termos
Especificao de caso de teste, modelagem de teste, cronograma de execuo do teste, especificao de
procedimento de teste, script de teste e rastreabilidade.
Conceito
O processo pode ser realizado de diferentes maneiras, desde informalmente sem muitos dados ou
documentao, at um processo muito formal (como o que ser descrito ainda nesta seo). O nvel de
formalidade depende do contexto do teste, o que inclui a organizao, maturidade do processo de teste e
desenvolvimento, restries de tempo e as pessoas envolvidas.
Durante a anlise de teste, a documentao base de teste analisada de maneira a determinar o que testar (ex.:
identificar as condies de teste). A condio do teste definida como um item ou evento que pode ser
verificado por um ou mais casos de testes (ex.: uma funo, transao, caracterstica de qualidade ou elemento
estrutural).
Estabelecer a rastreabilidade das condies de testes de volta at as especificaes e requisitos permitem
analisar o impacto quando os requisitos mudam e, a cobertura de requisitos a ser determinada por um conjunto
de testes. Durante a modelagem do teste, o detalhamento da abordagem de teste ser implementado com base
entre outras consideraes nos riscos identificados. (Ver mais informaes de anlise de riscos no Captulo
5)
Durante a modelagem de teste, os casos de teste e os dados de teste so especificados e criados. Um caso de
teste consiste de um conjunto de valores de entrada, pr-condies de execuo, resultados esperados e pscondies de execuo, desenvolvidos para cobrir certas condies de teste. O Standard for Software Test
Documentation (IEEE 829-1998) descreve o contedo da especificao da modelagem de teste (contendo as
condies de teste) e a especificao de caso de teste.
Resultados esperados devem ser produzidos como parte da especificao de um caso de teste e inclui as
sadas, mudana de dados e status, e qualquer outra consequncia do teste. Se o resultado esperado no for
definido, um resultado plausvel, porm errado, pode ser interpretado como correto. O resultado esperado deve
ser definido antes da execuo do teste.
Durante a implementao do teste os casos de teste so desenvolvidos, implementados, priorizadas e
organizadas na especificao de procedimento de teste (IEEE STD 829-1998). O procedimento de teste
especifica a sequncia de aes para a uma execuo de teste. Se os testes so executados por uma ferramenta,
a sequncia de aes especificada por um script automatizado (que um procedimento de teste
automatizado).
Os vrios e scripts de testes automatizados formam uma sequncia de execuo de teste que define a ordem
em que os procedimentos, e/ou os scripts automatizados sero executados e quem os executar. A sequncia
de execuo de teste considera alguns fatores como testes de regresso, priorizao, dependncias tcnicas e
lgicas.
Verso 2011br
Agosto 2011
Pgina 36 de 77
Certified Tester
4.2 Categorias das tcnicas de modelagem de teste (K2)
15 minutos
Termos
Tcnicas caixa-preta, tcnicas baseadas em experincia, tcnicas de modelagem de teste, tcnicas caixabranca.
Conceito
O propsito da tcnica de modelagem de teste identificar as condies e os casos de testes.
Classificar testes como caixa-preta ou caixa-branca uma diferenciao clssica. Tcnicas caixa- preta,
(tambm chamadas de tcnicas baseadas em especificao) so uma forma de derivar e selecionar as
condies e casos de testes baseados na anlise da documentao. Isto inclui testes funcionais e no
funcionais, para um componente ou sistema sem levar em considerao a sua estrutura interna. Tcnicas de
caixa branca (tambm chamadas de tcnicas estruturais ou baseadas em estrutura) so baseadas na estrutura
interna de um componente ou sistema.
Algumas tcnicas se encaixam claramente em uma nica categoria; outras tm elementos de mais de uma
categoria.
Este syllabus considera tcnicas baseadas em especificao ou tcnicas baseadas em experincia como
tcnicas caixa-preta e tcnicas baseadas em estrutura como tcnicas caixa-branca.
Caractersticas comuns das tcnicas baseadas em especificao:
Modelos, formais ou informais, so utilizados para especificao de um problema a ser resolvido, o
software ou seu componente.
Os casos de testes podem ser derivados sistematicamente destes modelos.
Caractersticas comuns das tcnicas baseadas em estrutura:
Informaes sobre como o software construdo utilizada para derivar os casos de testes. Por exemplo,
cdigo e informaes detalhadas de modelagem.
A extenso da cobertura do software pode ser medida pelos casos de testes. Alm disto, os casos de
testes podem ser derivados sistematicamente para aumentar a cobertura.
Caractersticas comuns de tcnicas baseada em experincia:
Conhecimento e experincia de pessoas so utilizados para derivar os casos de testes.
Conhecimento de testadores, desenvolvedores, usurios, outros interessados (stakeholders) responsveis
pelo software, seu uso e ambiente.
Conhecimento sobre defeitos provveis e sua distribuio.
Verso 2011br
Agosto 2011
Pgina 37 de 77
Certified Tester
4.3 Tcnicas baseadas em especificao ou Caixa-Preta (K3) 120 minutos
Termos
Anlise de valores limites, teste de tabela de deciso, partio de equivalncia, teste de transio de estados,
teste de caso de uso.
4.3.1 Partio de Equivalncia (K3)

Na Partio de Equivalncia, as entradas do software ou sistema so divididas em grupos que tenham um
comportamento similar, podendo ser tratados da mesma forma. Parties (ou classes) de equivalncia podem
ser encontradas em dados vlidos e invlidos (por exemplo, valores que deveriam ser rejeitados). Parties
podem tambm ser identificadas para valores de sadas, valores internos e valores relacionados a tempo, (antes
e aps um evento) e para parmetros de interface (durante teste de integrao). Testes podem ser elaborados
para cobrir as parties. Partio de Equivalncia aplicvel a todos os nveis de testes.
A Partio de Equivalncia pode ser usada para atingir a cobertura dos valores de entrada e sada. Pode ser
aplicada em uma entrada manual, interface entrada de sistema ou como parmetro de interface num teste de
integrao.
4.3.2 Anlise do Valor Limite (K3)

O comportamento nos limites de uma partio de equivalncia onde existe maior probabilidade de estar
incorreto. Portanto, limites so reas onde testes esto mais propensos a indicar defeitos. Os valores limites de
uma partio so seu mximo e seu mnimo. Um valor limite para uma partio vlida um valor limite
vlido. O limite de partio invlida um valor limite invlido. Testes podem ser projetados para cobrir tanto
valores invlidos como vlidos. Quando os casos de testes so projetados, um valor em cada limite
escolhido.
Anlise do valor limite pode ser aplicada em todos os nveis de teste. relativamente fcil aplic-la, sua
capacidade de encontrar defeitos alta e especificaes detalhadas podem ser teis em sua elaborao.
Esta tcnica muitas vezes considerada uma extenso da partio de equivalncia e pode ser aplicada para
entradas manuais como, por exemplo, em escalas de tempo ou tabela de limites. Valores limites podem
tambm ser usados para selecionar dados de testes.
4.3.3 Tabela de Deciso (K3)

A tabela de deciso considerada uma boa alternativa para capturar requisitos de sistemas que contm
condies lgicas e para documentar o comportamento interno do sistema. Elas podem ser utilizadas para
registrar regras de negcio complexas a serem implementadas. A especificao analisada e as condies e
aes do sistema so identificadas. As condies de entrada e aes so declaradas de uma forma que possam
ser entendidas, como verdadeiras ou falsas (Booleano). A tabela de deciso contm as condies que
disparam as aes, muitas vezes combinaes verdadeiras e falsas para todas as condies de entrada, e aes
resultantes para cada combinao de condies. Cada coluna da tabela corresponde a uma regra de negcio
que define uma nica combinao de condies que resulta na execuo de aes associadas com aquela
regra. A cobertura padro comumente usada em uma tabela de deciso ter no mnimo um teste por coluna
cobrindo todas as combinaes de condies apresentadas.
O grande ganho na utilizao da tabela de deciso que ela cria combinaes de condies que geralmente
no foram exercitadas durante os testes. Pode ser aplicada a todas as situaes quando a execuo do software
depende de muitas decises lgicas.
Verso 2011br
Agosto 2011
Pgina 38 de 77
Certified Tester
4.3.4 Teste de transio de estados (K3)
Um sistema pode exibir respostas diferentes dependendo da sua condio atual ou de estado anterior. Neste
caso, o comportamento do sistema pode ser representado como um diagrama de transio de estados. Permite
ao testador visualizar o software em termos de estados, transies entre estados, as entradas ou eventos que
disparam as mudanas de estado (transio) e as aes que podem resultar daquelas transies.
Os estados do sistema, ou objetos em teste, so isolados, identificveis e finitos. Uma tabela de estado exibe a
relao entre estados e entradas, e pode destacar possveis transies invlidas.
Os testes podem ser construdos para cobrir uma sequncia tpica de status, cobrir todos os estados, exercitar
todas as transies, exercitar uma sequncia especfica de transies ou testar transies invlidas.
Teste de transio de status muito utilizada em softwares industriais embarcados e automaes tcnicas em
geral. No entanto, a tcnica tambm adequada para modelar um objeto de negcio tendo estado especfico
ou para testar fluxos de telas de dilogos (exemplo: aplicao de internet e cenrios de negcios).
4.3.5 Teste de Caso de Uso (K2)

Testes podem ser especificados a partir de casos de uso ou cenrios de negcios. Um caso de uso descreve
interaes entre os atores (usurios e o sistema) que produz um resultado relevante para um usurio do
sistema. Cada caso de uso tem pr-condies, que precisam ser garantidas para que o caso de uso funcione
com sucesso. Cada caso de uso finalizado com uma ps-condio que representa os resultados observados e
o estado final do sistema aps o trmino do caso de uso. Um caso de uso normalmente tem um cenrio mais
comum (mais provvel), e algumas vezes ramificaes.
Caso de uso descreve o fluxo de processo de um sistema baseado nas suas possibilidades de utilizao. Os
casos de testes derivados de casos de uso so muito teis na descoberta de defeitos no fluxo do processo
durante a utilizao do sistema no mundo real. Casos de uso muitas vezes so tratados como cenrios, e teis
para construir testes de aceite com a participao do usurio final. Eles podem ajudar a descobrir defeitos de
integrao causados pela interao e interferncia de diferentes componentes, que testes individuais de
componentes podem no ter detectado.
Verso 2011br
Agosto 2011
Pgina 39 de 77
Certified Tester
4.4 Tcnicas baseadas em estrutura ou Caixa-Branca (K3)
60 minutos
Termos
Cobertura de cdigo, cobertura de deciso, cobertura de sentena, teste baseado em estrutura.
Conceito
Teste de estrutura ou caixa-branca baseado na estrutura do software ou sistema, como veremos nos
exemplos que seguem abaixo:
Nvel de Componente: a estrutura o prprio cdigo, ex.: comandos, decises e desvios.
Nvel de Integrao: a estrutura pode ser uma rvore de chamadas (um diagrama em que um mdulo
chama outros mdulos).
Nvel de Sistema: A estrutura pode ser uma estrutura de menu, processos de negcios ou estruturas das
pginas Web.
Nesta seo h basicamente duas tcnicas de cobertura de cdigo baseados em comandos e decises sero
discutidas. Para teste de deciso, um diagrama de controle de fluxo pode ser utilizado para visualizar as
alternativas de cada deciso.
4.4.1 Teste e Cobertura de Sentena (K3)

No teste de componente, cobertura de sentena avaliada pela porcentagem de sentenas executveis que
foram exercitadas por um conjunto de casos de testes. No teste de sentenas derivam-se casos de teste para
executar sentenas especficas, normalmente para se aumentar a cobertura.
4.4.2 Teste e Cobertura de Deciso (K3)

Cobertura de deciso, tambm chamada de teste de ramificao, avaliada pela porcentagem dos resultados
da deciso (por exemplo, as opes de Verdadeiro ou Falso de uma expresso condicional - IF) que
foram exercitados em um conjunto de casos de teste. No teste de deciso derivam-se os casos de testes para
executar decises especficas, normalmente para se aumentar a cobertura.
Teste de deciso uma forma de teste de controle de fluxo, j que ele gera um fluxo especfico atravs dos
pontos de decises. A cobertura de deciso mais eficiente que a cobertura de sentenas: 100% da cobertura
de deciso garante 100% da cobertura de sentena, mas no vice-versa.
4.4.3 Outras tcnicas baseadas na estrutura (K1)

Existem formas mais detalhadas de cobertura estrutural alm da cobertura de deciso, por exemplo, cobertura
de condies e cobertura de mltiplas condies.
O conceito de cobertura tambm pode ser aplicado a outros nveis de teste (teste de integrao) no qual, as
porcentagens de mdulos, componentes ou classes so exercitadas por um conjunto de casos de teste. Por
exemplo, poderia express-las como cobertura de mdulos, componentes ou classes.
Normalmente utilizada uma ferramenta para dar o suporte de teste de estrutura do cdigo.
Verso 2011br
Agosto 2011
Pgina 40 de 77
Certified Tester
4.5 Tcnicas baseadas na experincia (K2)
30 minutos
Termos
Teste exploratrio, ataque (de falha).
Conceito
Os testes baseados na experincia so testes derivados da intuio e conhecimento dos testadores atravs de
sua experincia em aplicaes e tecnologia similares. Quando usado para aumentar a tcnica sistemtica,
testes intuitivos podem ser teis para identificar testes especficos que no so facilmente identificados pelas
tcnicas formais, especialmente quando aplicado aps ter estabelecido o processo mais formal. No entanto
esta tcnica pode produzir amplas variedades e graus de eficincia, dependendo da experincia do testador.
Possivelmente a tcnica mais amplamente aplicada a de supor (adivinhar) onde esto os erros. Uma
abordagem estruturada da tcnica de deduo de erros enumerar uma lista de possveis erros e construir
testes com objetivo de atacar/cobrir estes erros. Esta abordagem sistemtica chamada de ataque de falha.
Estas listas de defeitos e falhas podem ser construdas com base na experincia, dados de defeitos/falhas
disponveis e do conhecimento comum de como o software falha.
Teste exploratrio ocorre simultaneamente modelagem, execuo e registro de teste, e baseia-se nos
objetivos de teste, onde realizado em um tempo predefinido. uma abordagem muito usual, em locais onde
a especificao rara ou inadequada e existe grande presso por conta de prazo, ou para
aprimorar/complementar um teste mais formal. Pode servir como uma checagem do processo de teste,
assegurando que os defeitos mais importantes sejam encontrados.
Verso 2011br
Agosto 2011
Pgina 41 de 77
Certified Tester
4.6 Escolhendo as tcnicas de teste (K2)
15 minutos
Termos
No h.
Conceito
A escolha de qual tcnica utilizar depender de uma srie de fatores, incluindo o tipo de sistema, padres,
clientes, requisitos contratuais, nvel do risco, tipos de riscos, objetivos do teste, documentao disponvel,
conhecimento dos testadores, tempo, dinheiro, ciclo de desenvolvimento, modelo de caso de uso e uma
experincia prvia do tipo de defeitos encontrados.
Algumas tcnicas so mais facilmente aplicadas em certas situaes e nveis de teste, j outras so aplicveis a
todos os nveis.
Ao criar casos de teste, os testadores geralmente usam uma combinao de tcnicas de teste, incluindo
regras de processo e tcnicas de data-driven para garantir uma cobertura adequada do objeto em teste.
Referncias
4.1 Craig, 2002, Hetzel, 1998, IEEE 829
4.2 Beizer, 1990, Copeland, 2004
4.3.1 Copeland, 2004, Myers, 1979
4.3.2 Copeland, 2004, Myers, 1979
4.3.3 Beizer, 1990, Copeland, 2004
4.3.5 Copeland, 2004
4.5 Kaner, 2002
4.6 Beizer, 1990, Copeland, 2004
Verso 2011br
Agosto 2011
Pgina 42 de 77
Certified Tester
5. Gerenciamento de Teste (K3)
180 minutos
Objetivos de aprendizado para o gerenciamento de teste

Os objetivos identificam o que voc ser capaz de fazer aps a finalizao de cada mdulo.
5.1
Organizao do Teste (K2)
LO-5.1.1
LO-5.1.2
LO-5.1.3
LO-5.1.4
5.2
Reconhecer a importncia e independncia do teste. (K1)

Listar as vantagens e desvantagem de uma equipe de teste independente em uma organizao.
(K2)
Reconhecer os diferentes membros a serem consideradas para criar uma equipe de teste. (K1)
Rever as tarefas tpicas de um testador e lder de teste. (K1)
Planejamento e estimativa do Teste (K2)
LO-5.2.1
LO-5.2.2
Reconhecer os diferentes nveis e objetivos do planejamento do teste. (K1)

Sumarizar o propsito e o contedo de um plano de teste, especificao da modelagem e os
procedimentos do teste de acordo com Standard for Software Test Documentation (IEEE 829).
(K2)
LO-5.2.3
Diferenciar entre aproximaes conceituais do teste, tais como analtico, baseado em modelo,
metdico, dinmico/heurstico e regresso. (K2)
LO-5.2.4
Diferenciar entre o assunto do planejamento do teste para um sistema e para a execuo

programada do teste (K2)
LO-5.2.5
Programar a execuo do teste para um conjunto de casos do teste, considerando a priorizao, e

dependncias tcnicas e lgicas. (K3)
Listar as tarefas de preparao e execuo de teste que precisam ser planejadas. (K1)
Rever os fatores tpicos que influenciam o esforo de teste. (K1)
Diferenciar duas estimativas com diferentes abordagens: baseada em mtricas e baseada em
especialistas. (K2)
Reconhecer / justificar um critrio de sada para um nvel de teste especfico e grupos de casos
de testes (ex.: para um teste de integrao, teste de aceite ou testes de usabilidade). (K2)
LO-5.2.6
LO-5.2.7
LO-5.2.8
LO-5.2.9
5.3
Controle e Monitorao do progresso do Teste (K2)
LO-5.3.1
LO-5.3.2
LO-5.3.3
5.4
Gerenciamento de Configurao (K2)
LO-5.4.1
5.5
Rever as mtricas comuns usadas para monitorar a preparao e execuo do teste. (K1)
Compreender e interpretar as mtricas de teste de um relatrio ou controle de teste (ex.: nmero
de defeitos encontrados, corrigidos e testes que passaram e falharam). (K2)
Sumarizar o objetivo e o contedo do relatrio de teste sumarizado de acordo com o Standard
for Software Test Documentation (IEEE 829). (K2)
Sumarizar como a gerncia de configurao pode servir de suporte ao teste. (K2)
Riscos e Teste (K2)
LO-5.5.1
LO-5.5.2
LO-5.5.3
Descrever o risco como um possvel problema que pode ameaar a realizao do projeto. (K2)
Relembrar que os riscos so determinados pela possibilidade (de acontecer) e o impacto (dano
resultante se ele acontecer). (K1)
Distinguir entre o risco do projeto e risco do produto (K2)
Verso 2011br
Agosto 2011
Pgina 43 de 77
Certified Tester
LO-5.5.4
LO-5.5.5
5.6
Reconhecer um risco de produto e de projeto tpico. (K1)

Descrever, utilizando exemplos, como a anlise e gerenciamento de risco podem ser utilizados
para planejar os testes. (K2)
Gerenciamento de Incidente (K3)
LO-5.6.1
LO-5.6.2
Reconhecer o contedo do relatrio de incidente do Standard for Software Test

Documentation (IEEE 829). (K1)
Preparar um relatrio de incidente cobrindo a observao de uma falha durante os testes. (K3)
Verso 2011br
Agosto 2011
Pgina 44 de 77
Certified Tester
5.1 Organizao do Teste (K2)
30 minutos
Termos
Testador, lder de teste, gerente de teste
5.1.1 A organizao e o teste independente (K2)

A eficcia na procura por defeitos por testes e reviso pode ser aperfeioada utilizando-se testadores
independentes. As opes para independncias so:
Nenhum testador independente. Os desenvolvedores testam seu prprio cdigo.
Testadores independentes provenientes da equipe de desenvolvimento.
Equipe de teste independente ou grupo dentro da organizao, reportando a um gerente de projeto ou
diretor executivo.
Testadores independentes da organizao do negcio, dos usurios e da rea de TI.
Especialistas em teste independente para um objetivo especfico de teste, como testes de usabilidade,
segurana ou certificao (quem certifica se o software est em conformidade com as normas e
padres).
Equipe de teste terceirizada ou independente da organizao.
Para projetos longos, complexos e crticos, normalmente melhor ter vrios nveis de teste, com algum ou
todos os nveis efetuados por equipes independentes de teste. A equipe de desenvolvimento pode participar do
teste, especialmente para os testes de baixo nvel, mas sua falta de objetividade muitas vezes limita a
efetividade do teste. A equipe independente de teste deve ter a autoridade para requisitar e definir os processos
de teste e suas regras, mas os testadores teriam que exercer estas funes somente sob um claro
gerenciamento.
Os benefcios da independncia da equipe de testes so:
Testadores independentes conseguem enxergar outros defeitos e so imparciais.
Um testador independente capaz de verificar concepes pessoais criadas durante a especificao e
implementao de um sistema.
As desvantagens incluem:
Isolamento da equipe de desenvolvimento (se for tratado com independncia total).
Equipe pode se tornar um gargalo, considerando-se o ltimo ponto de controle.
Os desenvolvedores podem perder o senso da responsabilidade pela qualidade.
A atividade do teste deve ser realizada por pessoas com uma funo especfica de teste, ou pode ser feita por
algum em outra funo, assim como gerente de projeto, gerente de qualidade, desenvolvedores, especialistas
no negcio, suporte de infraestrutura ou operaes em TI.
5.1.2 Tarefas do lder de teste e dos testadores (K1)

Neste syllabus, so abordadas duas funes: lder de teste e testador. As atividades feitas por pessoas nestas
funes dependem do contexto do produto e projeto da organizao.
Algumas vezes o lder de teste chamado de gerente ou coordenador de teste. A funo do lder pode ser
efetuada por um gerente: de projeto, de desenvolvimento, da qualidade ou at mesmo por um gerente de um
grupo de teste. Em projetos longos podem existir duas posies: Lder do Teste e Gerente de Teste.
Verso 2011br
Agosto 2011
Pgina 45 de 77
Certified Tester
Normalmente, o lder responsvel pelo planejamento, monitorao e controle d as atividades de testes e
tarefas como as definidas na seo 1.4.
As tarefas tpicas de um lder so:
Coordenar a estratgia de teste e planejar com o gerente de projetos e outros envolvidos.
Escrever ou revisar uma estratgia de teste para o projeto e uma poltica de teste para a empresa.
Contribuir com perspectiva do teste para outras atividades, como o planejamento de integrao.
Planejar os testes considerando o contexto e compreendendo os riscos, incluindo a escolha da
abordagem do teste, estimativa de tempo, esforo, custo, aquisio de recursos, definio de nveis e
ciclos de testes, definio de objetivos e planejamento da gesto de incidente.
Iniciar a especificao, preparao, implementao e execuo dos testes e monitorar o controle da
execuo.
Adaptar o planejamento baseado nos resultados e progresso do teste (algumas vezes documentado em
relatrio de andamento) e tomar aes necessrias para resolver problemas.
Preparar o gerenciamento de configurao do testware para facilitar a rastreabilidade.
Introduzir mtricas para medir o progresso do teste e avaliar a qualidade do teste e do produto.
Decidir o que pode ser automatizado, em que grau e como.
Escolher ferramenta de apoio e organizar treinamento para seus usurios (testadores).
Decidir sobre a implementao do ambiente de teste.
Montar um relatrio com base nas informaes obtidas durante o teste.
As tarefas tpicas de um testador podem incluir:
Revisar e contribuir no planejamento dos testes.
Analisar, revisar e avaliar os requisitos de usurios, especificaes e modelos para testabilidade.
Criar especificao de teste.
Configurar o ambiente de teste (muitas vezes com a coordenao do administrador de sistemas e
redes).
Preparar e adquirir dados para os testes.
Implementar os testes em todos os nveis, execuo, registro, avaliao dos resultados e documentar os
desvios dos resultados esperados.
Utilizar ferramenta de administrao, gesto e monitorao de teste se necessrio.
Automatizar testes (esta tarefa pode ser efetuada pelo desenvolvedor ou por um especialista em
automao).
Medir a performance dos componentes e sistemas (se aplicvel).
Rever os testes desenvolvidos por outras pessoas.
As pessoas que trabalham na anlise, construo, tipos especficos de teste ou automao podem se
especializar nestas funes. Dependendo do nvel do teste e do risco relacionado ao produto e o projeto,
pessoas diferentes podem ocupar a funo do testador, mantendo algum grau de independncia.
Tipicamente, testadores em nvel de componente e integrao so desenvolvedores, testadores em nvel de
aceite podem ser os especialistas no negcio ou usurio final e testadores para o nvel de teste operacional
podem ser os prprios operadores.
Verso 2011br
Agosto 2011
Pgina 46 de 77
Certified Tester
5.2 Organizao do Teste (K2)
50 minutos
Termos
Abordagem de teste, estratgia de teste
5.2.1 Planejamento de Teste (K2)

Esta seo trata dos objetivos do planejamento do teste dentro do desenvolvimento e implementao dos
projetos. O planejamento pode ser documentado em um plano de teste mestre ou de projeto separado em
vrios planos de testes para diferentes nveis, assim como teste de aceite ou teste de sistemas. A essncia dos
documentos de planejamento de teste coberta pelo Standard for Software Test Documentation (IEEE 829).
O planejamento influenciado pela poltica de teste da organizao, o escopo, objetivo, riscos, obstculos,
crticas e disponibilidade de recursos. Quanto maior for o projeto e o progresso do planejamento dos testes,
mais informaes estaro disponveis e mais detalhes podem ser includos no plano.
Planejamento do teste uma atividade contnua realizada durante todo o processo do ciclo de vida do
software. O retorno (feedback) da atividade do teste utilizado para identificar riscos de mudanas, para que
ajustes no planejamento sejam efetuados.
5.2.2 Atividades no Planejamento de testes (K2)

As atividades no planejamento do teste podem incluir:
Determinao do escopo e risco, identificando os objetivos do teste.
Definio completa da abordagem do teste (estratgia de teste), incluindo a definio do nvel de
testes, dos critrios de entrada e sada.
Integrao e coordenao da atividade de teste no ciclo de vida do software (aquisio, fornecimento,
desenvolvimento, operao e manuteno).
Tomar a deciso sobre o que testar, quais as funes executaro as atividades de teste, quando e como
as atividades podem ser realizadas, como o resultados dos testes sero avaliados e quando parar o teste
(critrio de sada).
Programar as atividades de anlise e planejamento dos testes
Programar a implementao, execuo e validade dos testes.
Designar recursos para as diferentes tarefas definidas.
Definir o nvel de detalhe, estrutura e modelos para a documentao dos testes.
Escolher mtricas para monitorar, controlar a preparao e execuo do teste, resolver defeitos e
apontar os riscos.
Configurar o nvel de detalhe para os procedimentos de teste de forma a prover informaes suficientes
para que o suporte possa reproduzir o incidente.
5.2.3 Critrio de Entrada (K2)

Os critrios de entrada definem quando comear um teste, no incio de um nvel de teste ou quando um
conjunto de testes est pronto para execuo.
Os critrios de entrada podem ser constitudos de:
Disponibilidade do ambiente de teste.
Preparao da ferramenta de no ambiente de teste.
Verso 2011br
Agosto 2011
Pgina 47 de 77
Certified Tester
Disponibilidade de cdigo a ser testado.
Disponibilidade dos dados de teste.
5.2.4 Critrio de Sada (K2)

Os critrios de sada definem quando parar de testar, no final de um nvel de teste ou quando um conjunto de
testes realizados atingiu um objetivo especfico.
Os critrios de encerramento podem ser constitudos de:
Mtricas como a cobertura de cdigo, riscos ou funcionalidades.
Estimativa da densidade de defeitos ou segurana nas medies.
Custos.
Riscos residuais, como defeitos no solucionados ou falta de cobertura de teste em algumas reas.
Cronograma, baseado na data de entrega do produto.
5.2.5 Estimativa do teste (K2)

Duas abordagens para estimativa do esforo do teste so cobertas no syllabus:
Estimativa do esforo do teste baseado em mtricas de projetos anteriores ou similares, ou baseado em
valores tpicos.
Estimativas das tarefas pelo prprio executor ou por especialistas.
Uma vez que a estimativa do esforo do teste efetuada, recursos podem ser alocados e um cronograma pode
ser elaborado.
O esforo do teste pode depender de inmeros fatores que incluem:
Caractersticas do produto: a qualidade da especificao ou outra informao usada por projetos de
teste, o tamanho do produto, a complexidade do problema, os requisitos para segurana e os requisitos
para documentao.
Caractersticas do processo de desenvolvimento: A estabilidade da organizao, ferramentas usadas,
processos de teste, experincia das pessoas envolvidas e presso no prazo.
As sadas do teste: o nmero de defeitos e a quantidade de retrabalho necessria.
5.2.6 A Estratgia do Teste, Abordagem de teste (K2)

A abordagem de teste a implementao da estratgia de teste para um projeto especfico. A abordagem de
teste definida e refinada nos planos de teste e na modelagem de teste. Geralmente, ela inclui as decises
tomadas com base na meta do projeto (teste) e avaliao de risco. o ponto de partida para o planejamento do
processo de teste, para selecionar as tcnicas de modelagem de teste e tipos de teste a ser aplicado, e para a
definio dos critrios de entrada e sada.
A abordagem escolhida depende do contexto e pode considerar os riscos, perigos de segurana, recursos
disponveis e habilidades, tecnologia, natureza do sistema, objetivos do teste, e regulamentaes.
Abordagens tpicas incluem:
Analtica: nas quais os testes so direcionados nas reas do software ou sistema onde apresentem
maiores riscos.
Baseada em modelos: nas quais os testes so baseados em dados informais estatsticos sobre taxa de
erros (tais como erros operacionais e de segurana).
Abordagem metdica: como a baseada em falhas (incluindo deduo de erros e injeo de falhas),
baseadas em check-list, e baseadas em caracterstica de qualidade.
Verso 2011br
Agosto 2011
Pgina 48 de 77
Certified Tester
Compatvel com processos ou padres: como algumas especificadas por padres da indstria ou as
vrias metodologias geis.
Dinmica e heurstica: tais como os testes exploratrios onde a atividade de testar mais reativa do
que pr-planejada e onde a execuo e avaliao so tarefas concorrentes.
Baseada em conselhos: como os testes em que a cobertura dirigida por conselhos de especialistas em
tecnologia ou negcio fora do time de teste.
Regresso: como aqueles em que h o reuso do material de teste, automao extensiva dos testes
funcionais de regresso, e um conjunto de testes padro.
Diferentes abordagens para montar uma estratgia podem ser utilizadas como, por exemplo, abordagem
baseada em risco.
Verso 2011br
Agosto 2011
Pgina 49 de 77
Certified Tester
5.3 Controle e Monitorao do Progresso do Teste (K2)
20 minutos
Termos
Densidade do defeito, taxa de falha, controle do teste, monitorao do teste e relatrio de resumo do teste.
5.3.1 Monitorao do Progresso do Teste (K1)

O propsito da monitorao do progresso do teste permitir uma visibilidade sobre as atividades do teste. As
informaes a serem monitoradas podem ser coletadas manualmente ou automaticamente e serem utilizadas
para medir os critrios de sada, como cobertura. Mtricas podem ser usadas para avaliar o progresso em
relao ao oramento e cronogramas planejados.
As mtricas mais comuns incluem:
Porcentagem de trabalho na preparao do caso de teste (ou porcentagem de casos de testes
devidamente planejados).
Porcentagem de trabalho na preparao do ambiente.
Execuo dos casos de testes (nmeros de casos de teste executados ou no, testes com resultados
positivos e negativos).
Informaes dos defeitos (densidade do defeito, defeitos encontrados e resolvidos, taxas de falha e
resultado de retestes).
Cobertura de requisitos, riscos ou cdigo.
Confiana subjetiva do testador sob o produto
Datas dos pontos de controle.
Custo do teste, incluindo o custo comparado ao benefcio de encontrar o prximo erro ou de executar o
prximo teste.
5.3.2 Relatrio do teste (K2)

O relatrio do teste constitudo de informaes resumidas sobre o esforo do teste, incluindo:
O que aconteceu durante a o perodo do teste, e qual o melhor momento de parar.
Informaes e mtricas para dar suporte na tomada de deciso e recomendaes sobre futuras aes,
tais como avaliao dos defeitos persistentes, vantagem econmica da continuao dos testes e dos
riscos considerveis apontados alm do nvel de confiana no software testado.
A essncia de um relatrio de teste tratada no Standard for Software Test Documentation (IEEE 829). As
mtricas podem ser coletadas durante ou ao final do teste:
A adequao dos objetivos do teste com o nvel do teste.
A adequao da abordagem/estratgia do teste.
A eficcia dos testes em respeito a seus objetivos.
5.3.3 Controle do Teste (K2)

O controle do teste descreve qualquer orientao ou ao corretiva tomada como resultado de informaes e
mtricas coletadas e relatadas. As aes podem abranger qualquer atividade de teste e pode afetar qualquer
outro software de atividade do ciclo de vida ou tarefa.
Verso 2011br
Agosto 2011
Pgina 50 de 77
Certified Tester
Exemplos de controle de teste:
Tomar decises baseadas em informaes adquiridas na monitorao dos testes.
Priorizar novamente os testes quando riscos so identificados.
Mudar o cronograma de acordo com disponibilidade do ambiente de teste.
Definir um critrio de entrada para se iniciar o reteste de bugs resolvidos pelo desenvolvedor antes de
aceit-lo em uma build.
Verso 2011br
Agosto 2011
Pgina 51 de 77
Certified Tester
5.4 Gerenciamento de Configurao (K2)
10 minutos
Termos
Gerenciamento de configurao, controle de verso.
Conceito
O propsito do gerenciamento de configurao estabelecer e manter a integridade dos produtos
(componentes, dados e documentao) do software ou sistema durante todo o projeto ou ciclo de vida do
produto.
Para o teste, o gerenciamento de configurao pode garantir que:
Todos os itens do software so identificados, controladas as mudanas, seus relacionamentos,
facilitando manuteno e a rastreabilidade durante todo o processo de teste.
Todos os documentos e itens do software so referenciados sem ambiguidade na documentao do
teste.
Para o testador, o gerenciamento de configurao ajuda na identificao nica (e a reproduo) do item
testado, documentos de testes, aos testes e aos scripts de execuo de testes.
Durante o planejamento do teste a ferramenta e processos de gerenciamento de configurao devem ser
escolhidos, documentados e implementados.
Verso 2011br
Agosto 2011
Pgina 52 de 77
Certified Tester
5.5 Riscos e Teste (K2)
30 minutos
Termos
Risco do produto, risco do projeto, risco, teste baseado em risco.
Conceito
Risco pode ser definido como uma chance de um evento indesejvel acontecer, causando um problema em
potencial. O nvel do risco pode ser determinado pela possibilidade do evento acontecer e os danos que podem
causar caso acontea.
5.5.1 Riscos no Projeto (K2)

Riscos no projeto so os aqueles que comprometem a capacidade do projeto no atender seus objetivos.
Fatores organizacionais:
Falta de conhecimento da equipe.
Reciclagem e treinamento pessoal.
Fatores polticos como:
Problemas com testadores comunicando suas necessidades com os resultados dos testes.
Dificuldade para passar informaes (defeitos) encontradas nos testes e revises, no permitindo o
aprimoramento do desenvolvimento e, da prtica do teste.
Atitudes imprprias em relao s expectativas do teste (ex.: a no valorizao dos defeitos
encontrados durante os testes).
Fatores Tcnicos:
Problema na definio correta do requisito.
At que ponto os requisitos podem ser satisfeitos dadas restries diversas.
A qualidade da modelagem, do cdigo e do teste.
Problemas do fornecedor:
Falhas de terceiros
Problemas contratuais
Quando analisando, gerenciando e mitigando os riscos, o gerente de teste conduzido por um princpio de
gerenciamento de projeto bem estabelecido. A definio de planos de teste contida no Standard for Software
Test Documentation (IEEE 829-1998) requisita que os riscos e a contingncias devam ser declaradas.
5.5.2 Riscos do Produto (K2)

reas de potenciais de falhas, (futuros eventos ou riscos indesejveis) no software ou sistema so conhecidas
como riscos para a qualidade do produto final. Incluindo:
Software instvel (com alta probabilidade de erros).
O dano potencial que um software ou hardware pode causar a uma pessoa ou companhia.
Software com caractersticas pobres (funcionalidade, segurana, confiana, usabilidade e
performance).
Software com integridade de dados e qualidade pobres (pendncias na migrao de dados, problemas
de converso de dados, problemas de transporte de dados, violao de padres de dados).
Software que no cumpre com seus objetivos.
Verso 2011br
Agosto 2011
Pgina 53 de 77
Certified Tester
Risco usado para se decidir quando comear e onde dever se testar com mais frequncia; o teste utilizado
para reduzir o risco da ocorrncia de um efeito indesejado, ou para reduzir seu impacto.
Risco do produto um tipo especial de risco porque compromete o sucesso de um projeto. A atividade de
controle de riscos fornece informaes sobre riscos residuais, por medir a eficincia da retirada de defeitos
crticos e dos planos de contingncia.
Um teste baseado nos riscos pode fornecer oportunidades proativas para reduzir os nveis do risco do produto
quando abordado no estgio inicial do projeto. Envolve a identificao do risco e seu uso para orientar o
planejamento, especificao, preparao e execuo do teste. Os riscos identificados podem ser utilizados
para:
Determinar a tcnica de teste a ser empregada.
Determinar o nvel de detalhamento do teste.
Priorizar o teste na tentativa de buscar erros crticos o mais cedo possvel.
Determinar se alguma atividade (que no seja o teste) poderia ser efetuada para reduzir o risco (ex.:
prover treinamento).
Teste baseado no risco auxilia os stakeholders a determinar os riscos e nveis de testes, com base no
conhecimento coletivo e na viso do projeto.
Para assegurar que a chance de um produto falhar seja minimizada, o gerenciamento de riscos dever prover
disciplina para:
Avaliar (e reavaliar periodicamente) o que poder dar errado (riscos).
Determinar quais riscos so importantes para negoci-los.
Implementar aes para negociar aqueles riscos.
Alm disto, o teste pode demonstrar a identificao de novos riscos, que riscos deveriam ser reduzidos e
diminuir as incertezas sobre os riscos.
Verso 2011br
Agosto 2011
Pgina 54 de 77
Certified Tester
5.6 Gerenciamento de Incidente (K3)
40 minutos
Termos
Registro de Incidente, Gerncia de Incidente, Reporte de Incidente.
Conceito
Levando em considerao que um dos objetivos do teste encontrar defeitos, as discrepncias entre o
resultado atual e o esperado precisam ser registradas como incidentes. Um incidente precisa ser investigado e
pode se tornar um defeito. Aes apropriadas para dispor incidentes e defeitos devem ser disponveis.
Incidente e defeito deve ser rastrevel desde a descoberta, classificao at correo e confirmao da
resoluo. Para gerenciar os incidentes, a empresa deve estabelecer processos e regras para classific-los.
Incidentes podem ser descobertos durante o desenvolvimento, o teste e a utilizao do software. Eles podem
se revelar por problemas no cdigo, por funes do sistema, documentao de desenvolvimento,
documentao de teste, manual de instalao ou manual do usurio.
O Relatrio de Incidentes tem os seguintes objetivos:
Prover aos desenvolvedores e outros envolvidos um retorno sobre o problema para permitir a
identificao, isolamento e correo se necessrio.
Prover aos lderes de teste um meio para se rastrear a qualidade do sistema em teste e o progresso do
teste.
Prover ideias para aprimorar o processo de testes.
Os detalhes de um relatrio de incidente podem incluir:
Data da emisso, autor, status e organizao.
Resultados esperados e resultados atuais.
Identificao do item de teste (item de configurao) e ambiente.
Processo do ciclo de vida do sistema ou software em que o incidente foi descoberto.
Descrio do incidente para permitir a reproduo e resoluo, incluindo logs, database dumbs, ou
screenshots.
Escopo e grau de impacto para os stakeholder.
Severidade do impacto no sistema.
Urgncia / Prioridade na correo.
Estado (status) do incidente (aberto, rejeitado, duplicado, aguardando resoluo, aguardando reteste
ou fechado).
Concluso, recomendaes e aprovaes.
Comentrios gerais, tais como outras reas que podem ser afetadas por uma mudana resultante de um
incidente.
Histrico de mudanas, como a sequncia de aes tomadas pela equipe envolvida no projeto com
respeito ao isolamento do incidente, reparo e confirmao da resoluo.
Referncias, incluindo a identificao da especificao do caso de teste que revelou o problema.
A estrutura de um relatrio de incidente pode ser encontrada no Standard for Software Test Documentation
(IEEE Std. 829-1998).
Referncias:
5.1.1 Black, 2001, Hetzel, 1998
5.1.2 Black, 2001, Hetzel, 1998
5.2.5 Black, 2001, Craig, 2002, IEEE 829, Kaner 2002
5.3.3 Black, 2001, Craig, 2002, Hetzel, 1998, IEEE 829
Verso 2011br
Agosto 2011
Pgina 55 de 77
Certified Tester
5.4 Craig, 2002
5.5.2 Black, 2001 , IEEE 829
5.6 Black, 2001, IEEE 829
Verso 2011br
Agosto 2011
Pgina 56 de 77
Certified Tester
6. Ferramentas de Suporte a Teste (K2)
80 minutos
Objetivos de aprendizado para ferramentas de suporte a teste

Os objetivos identificam o que voc dever fazer para completar cada mdulo.
6.1
Tipos de ferramentas de teste (K2)
LO-6.1.1
LO-6.1.3
6.2
Uso efetivo de ferramentas: benefcios potenciais e riscos (K2)
LO-6.2.1
LO-6.2.2
6.3
Classificar diferentes tipos de ferramentas de acordo com a atividade de do processo de teste.

(K2)
Explicar o termo ferramenta de teste e o propsito de ferramentas de suporte a teste. (K2)
Resumir os benefcios e riscos potenciais da automao e das ferramentas de suporte a teste.

(K2)
Relembrar consideraes especiais para ferramentas de execuo de teste, anlise esttica e
gerenciamento de testes. (K1)
Introduzindo uma ferramenta em uma organizao (K1)
LO-6.3.1
LO-6.3.2
LO-6.3.3
Apontar os princpios para a implementao de uma ferramenta em uma organizao. (K1)

Discutir os objetivos de uma prova de conceito/piloto para avaliao da ferramenta. (K1)
Reconhecer que outros fatores alm da simples aquisio so fundamentais para o bom
aproveitamento da ferramenta de suporte. (K1)
Verso 2011br
Agosto 2011
Pgina 57 de 77
Certified Tester
6.1 Tipos de Ferramentas de Teste (K2)
45 minutos
Termos
Ferramentas de gerenciamento de configurao, ferramenta de cobertura de cdigo, ferramenta de depurao,
ferramenta de anlise dinmica, ferramenta de gesto de incidentes, ferramenta de teste de carga, ferramenta
de modelagem, ferramenta de monitorao, ferramenta de teste de performance, efeito da monitorao,
ferramentas de gerenciamento de requisitos, ferramenta de reviso, ferramentas de segurana, ferramentas de
anlise esttica, ferramenta de teste de estresse, ferramenta de comparao de teste, ferramenta de preparao
de dados, ferramenta de modelagem de teste, ambiente preparado de testes, ferramentas para execuo do
teste, ferramentas para gerenciamento do teste, framework de teste de unidade.
6.1.1 Ferramentas de suporte a teste (K2)

Ferramentas de teste podem ser usadas para uma ou mais atividades de suporte a teste. Estas incluem:
1) Ferramentas que so diretamente utilizadas no teste, como ferramentas de execuo de teste, ferramentas
de gerao de dados de teste e ferramentas de comparao de resultados.
2) Ferramentas que auxiliam na gesto do processo de teste, como aquelas utilizadas para gerenciar testes,
resultados de teste, dados, requisitos, incidentes, defeitos, etc., e para relatrios e monitorao da
execuo de teste.
3) Ferramentas que so usadas em reconhecimento, ou, em termos mais simples, explorao (exemplo:
ferramentas que monitoram atividades de arquivos para uma aplicao).
4) Quaisquer ferramentas que auxiliam no teste (uma planilha Excel tambm uma ferramenta de teste,
neste contexto.).
Ferramentas de suporte ao teste podem ter um ou mais dos seguintes objetivos, dependendo do contexto:
Aumentar a eficincia das atividades de teste, atravs da automao de tarefas repetitivas ou dar
suporte a atividades de teste manuais, como planejamento, modelagem, relatrio e monitorao.
Automatizar atividades que requerem recursos significativos quando executadas manualmente
(exemplo: teste esttico).
Automatizar atividades que no podem ser executadas manualmente (ex.: teste de performance em
larga escala de aplicaes cliente-servidor).
Aumentar a confiabilidade do teste (exemplo: pela automao de comparaes em larga escala ou
simulao de comportamento).
O termo frameworks de teste tambm frequentemente utilizado na indstria, em pelo menos trs sentidos:
Bibliotecas de teste reutilizveis e extensivas que podem ser utilizadas para construir ferramentas de
teste (chamadas de preparao de teste tambm)
Um tipo de design de automao de teste (ex.: data-driven, context-driven)
O processo de execuo de teste como um todo
Para o objetivo deste syllabus, o termo frameworks de teste utilizado em seus dois primeiros significados,
como descrito na Seo 6.1.6.
6.1.2 Classificao das Ferramentas de Teste (K2)

H vrias ferramentas que suportam diferentes aspectos do teste. Ferramentas podem ser classificadas
baseadas em vrios critrios como objetivo, comercial/livre/cdigo aberto/shareware, tecnologia utilizada e
da por diante. Ferramentas so classificadas neste syllabus de acordo com as atividades de teste que elas
suportam.
Verso 2011br
Agosto 2011
Pgina 58 de 77
Certified Tester
Algumas ferramentas suportam claramente apenas uma atividade; outras podem suportar mais que uma, mas
esto classificadas sob a atividade de que ela est mais associada. Ferramentas de um nico fornecedor,
especialmente aquelas que foram planejadas para atuarem em conjunto, podem ser agrupadas em um nico
pacote.
Alguns tipos de ferramentas de teste so intrusivos, ou seja, eles prprios podem afetar o resultado do teste.
Por exemplo, o resultado de uma aferio de tempo pode ser diferente dependendo de como a medio em
diferentes ferramentas de performance, ou ento pode-se ter uma medida diferente na cobertura do cdigo
dependendo da ferramenta que se utiliza. A consequncia de uma ferramenta intrusiva conhecida como
efeito de monitorao.
Algumas ferramentas oferecem suporte mais apropriado para desenvolvedores (durante teste de componente e
integrao dos componentes). Estas so identificadas com um (D) na classificao que segue abaixo.
6.1.3 Ferramentas para gerenciamento do teste (K1)

As ferramentas de gerncia aplicam-se a todas as atividades do teste sobre o ciclo de vida do software
Ferramenta de Gerenciamento de Teste
Estas ferramentas fornecem interfaces para a execuo de teste, rastreamento de defeitos e gesto de requisitos
juntamente com suporte para anlise quantitativa e relatrio dos objetos de teste. Elas tambm suportam o
rastreamento dos objetos de teste s especificaes de requisitos e podem ter uma capacidade de controle de
verso independente ou uma interface a um controle de verso externo.
Ferramentas de Gerenciamento de Requisitos
Estas ferramentas armazenam termos de requisitos, armazenam os atributos para os requisitos (incluindo
prioridade), fornecem identificadores nicos e do suporte ao rastreamento dos requisitos aos testes
individuais. Estas ferramentas podem tambm ajudar a identificar requisitos inconsistentes ou ausentes.
Ferramentas de Gerenciamento de Incidentes (Ferramenta de Rastreamento de Defeitos)
Estas ferramentas armazenam e gerenciam relatrios de incidentes (ex.: defeitos, falhas, problemas e
anomalias) e ajudam no gerenciamento do ciclo de vida de incidentes, opcionalmente com suporte para anlise
estatstica.
Ferramentas de Gerenciamento de Configurao
Embora no so estritamente ferramentas de teste, mas so necessrias para manter o controle da verso de
diferentes builds de softwares e testes, especialmente quando configurada mais que um ambiente de
hardware/software em termos de verses de sistemas operacionais, compiladores, browsers, etc.
6.1.4 Ferramentas de suporte para teste esttico (K1)

Ferramentas para testes esttico fornecem uma alternativa de baixo custo para encontrar mais defeitos em um
estgio inicial dentro do processo de desenvolvimento.
Ferramentas para suporte ao processo de reviso
Essas ferramentas auxiliam com o processo de reviso, check-lists, diretrizes de reviso e so utilizadas para
armazenar e comunicar comentrios de reviso e fornecer relatrios de defeitos e esforo associado. Podem
ser teis tambm no fornecimento de ajuda para revises online para times grandes ou que esto distantes
geograficamente.
Ferramentas de Anlise Esttica (D)
Ferramentas de anlise esttica ajudam os desenvolvedores, testadores e os envolvidos com a qualidade a
encontrar defeitos antes dos testes dinmicos, atravs da aplicao de padres de codificao (incluindo
Verso 2011br
Agosto 2011
Pgina 59 de 77
Certified Tester
cdigo seguro), alm de anlise de estrutura e dependncias. Podem ser teis tambm no planejamento ou
anlise de risco devido ao fornecimento de mtricas para o cdigo (ex.: complexidade).
Ferramentas de Modelagem (D)
Ferramentas de modelagem validam o modelo do software (ex.: modelo fsico de dados, para um banco de
dados relacional), enumerando inconsistncia e encontrando defeitos. Essas ferramentas podem geralmente
ajudar na gerao de alguns casos de testes baseados no modelo.
6.1.5 Ferramenta de suporte para especificao de teste(K1)

Ferramenta de Modelagem de Teste
Ferramentas de modelagem de teste geram entradas de teste ou testes a partir dos requisitos, de uma interface
grfica do usurio, dos diagramas de modelagem (estado, dados ou objetos) ou do cdigo.
Ferramentas para preparao de dados de teste (D)
Estas ferramentas manipulam a base de dados, arquivos ou transmisso de dados para ajudar na preparao
dos dados de teste a serem utilizados durante a execuo de testes, alm de garantir a segurana atravs do
anonimato dos dados.
6.1.6 Ferramenta de suporte para execuo e registro (K1)

Ferramentas de execuo do teste
Ferramentas de execuo do teste permitem que o teste seja executado automaticamente, ou semiautomaticamente, usando dados de entradas e resultados esperados atravs do uso de uma linguagem de script,
e geralmente fornecem um registro de teste para cada teste executado. Tambm podem ser usadas para
registrar testes, e geralmente suportam linguagens de script ou parametrizao de dados baseados em telas e
outras customizaes do teste.
Ambiente preparado/Ferramentas framework de teste de unidade (D)
O Ambiente preparado e frameworks facilitam o teste de componente ou parte de um sistema por simular o
ambiente em que o objeto de teste ser executado, atravs do fornecimento de simuladores, como stubs ou
drivers.
Comparadores de teste
Comparadores de teste determinam as diferenas entre os arquivos, banco de dados ou resultados dos testes.
As ferramentas de execuo normalmente incluem comparaes dinmicas, mas comparao aps a execuo
pode ser feita por uma ferramenta especificamente de comparao. Um comparador de teste pode ser usado
como orculo de teste, especialmente se for automatizado.
Ferramentas de medio de cobertura (D)
Ferramenta de medio de cobertura pode ser intrusiva ou no intrusiva, e medem a porcentagem de estruturas
de cdigo que so exercitados (comandos, decises, ramos, mdulos e chamada de funes) por um dado
conjunto de testes.
Ferramentas de Segurana
Ferramentas de segurana so utilizadas para avaliar as caractersticas de segurana do software. Isso inclui a
avaliao da habilidade do software em proteger confidencialidade, integridade, autenticao, autorizao,
disponibilidade e no repdio de dados. Ferramentas de segurana so principalmente focadas em uma
plataforma especfica de tecnologia e seu objetivo.
Verso 2011br
Agosto 2011
Pgina 60 de 77
Certified Tester
6.1.7 Ferramenta de performance e monitorao (K1)
Ferramenta de Anlise dinmica (D)
Estas ferramentas encontram defeitos que s so evidenciados quando o software est em execuo, assim
como dependncia de tempo ou vazamento de memria. So normalmente utilizados em testes de
componentes, testes de integrao dos componentes e teste de middleware.
Ferramentas de Teste de Performance/Teste de Carga/Teste de Estresse
Ferramenta de teste de performance monitoram e relatam como um sistema se comporta sob uma variedade de
condies simuladas, em termos de nmero de usurios concorrentes, seu padro ramp-up, frequncia e
porcentagem relativa de transaes. A simulao de carga conseguida atravs da criao de usurios virtuais
que executam um conjunto selecionado de transaes, espalhados atravs de vrias mquinas de testes
normalmente chamadas de geradores de carga.
Ferramentas de monitorao
Ferramentas de monitorao continuamente analisam, verificam e reportam a respeito do uso de recursos
especficos do sistema, e fornecem avisos de possveis problemas do servio.
6.1.8 Ferramenta de suporte para reas de aplicaes especficas (K1)

Avaliao de qualidade de dados
Dados esto no centro de alguns projetos, como aqueles de converso/migrao de dados e aplicaes como
data warehouse e seus atributos podem variar em termos de criticidade e volume. Em tais contextos,
ferramentas precisam ser empregadas para avaliao da qualidade dos dados para revisar e verificar a
converso de dados e regras de migrao, para garantir que os dados processos esto corretos, completos e
aderentes com padres pr-definidos especficos ao contexto.
Outras ferramentas de teste existem para teste de usabilidade.
Verso 2011br
Agosto 2011
Pgina 61 de 77
Certified Tester
6.2 Uso Efetivo das Ferramentas: Riscos e Benefcios em
potenciais (K2)
20 minutos
Termos
Teste orientado a dados, Teste orientado a palavras-chaves, linguagem de scripts.
6.2.1 Potenciais benefcios e riscos de ferramentas de suporte ao teste (K1)

A simples compra da ferramenta no significa o sucesso da mesma. Cada tipo de ferramenta pode requerer um
esforo para atingir os benefcios reais e contnuos. H oportunidades d benefcios potenciais com o uso de
ferramentas de teste, mas tambm existem riscos:
Benefcios potenciais do uso das ferramentas incluem:
Reduzir trabalhos repetitivos (executar os testes de regresso, entrar os mesmos dados do teste e
checar a padronizao do cdigo).
Maior consistncia e possibilidade de repeties (ex.: testes executados por uma ferramenta e testes
derivados de requisitos).
Avaliao dos objetivos (ex.: medidas estticas, cobertura e comportamento do sistema)
Facilidade do acesso a informaes sobre o teste (ex.: estatsticas e grficos referente ao progresso de
teste, taxas de incidente e performance).
Riscos no uso das ferramentas so:
Expectativas falsas referentes ferramenta (incluindo funcionalidades e facilidade de uso).
Subestimao do tempo, custo e esforo necessrio para a introduo inicial da ferramenta (incluindo
treinamento e expertise externo).
Subestimao do esforo e tempo necessrios para obter benefcios significantes e contnuos do uso
da ferramenta (incluindo a necessidade para mudanas no processo de teste e melhoria contnua na
forma como a ferramenta utilizada).
Subestimao do esforo para manter os artefatos de teste gerados pela ferramenta.
Confiana excessiva na ferramenta (quando o emprego de teste manual e modelagem de teste so
mais recomendados).
Negligncia no controle de verso de ativos de teste dentro da ferramenta.
Negligncia na manuteno dos relacionamentos e questes de interoperabilidade entre ferramentas
crticas, como ferramentas de gesto de requisitos, controle de verso, gerenciamento de incidente,
rastreamento de defeitos e ferramentas de mltiplos fornecedores.
Risco do fornecedor da ferramenta abandonar o negcio, aposentar a ferramenta, ou vender a
ferramenta para outro fornecedor.
Baixa capacidade do fornecedor para suporte, upgrades e correes de defeitos.
Risco de suspenso de projetos de cdigo aberto e ferramentas livres.
Imprevistos, como a falta de habilidade para dar suporte a uma nova plataforma.
6.2.2 Consideraes especiais para alguns tipos de ferramentas (K1)

Ferramentas de execuo de testes
Ferramentas de execuo de testes executam os scripts desenvolvidos para implementar testes que foram
armazenados eletronicamente. Este tipo de ferramenta muitas vezes requer um esforo significativo para obter
os benefcios.
Verso 2011br
Agosto 2011
Pgina 62 de 77
Certified Tester
Capturar testes pela gravao de aes manuais do usurio pode parecer atrativo, mas esta abordagem no tem
uma escalabilidade. Um script de captura uma representao linear com dados e aes especficas como
parte de cada script. Este tipo de script pode se tornar instvel a eventos inesperados.
Uma abordagem orientada a dados separa os dados de entrada dos testes, normalmente em diversas planilhas
contendo variaes destes dados, utilizando scripts mais genricos que possam ler estas planilhas na execuo
de um mesmo teste fazendo com que os dados utilizados sejam diferentes. Os testadores que no tem
familiaridade com a linguagem dos scripts podem entrar com os dados para estes scripts pr-definidos.
Em uma abordagem orientada a palavras-chave, as planilhas contm palavras-chaves que descrevem aes a
serem tomadas e os dados do teste. Testadores (mesmo que no tenham familiaridade com a linguagem de
scripts) podem ento definir os testes utilizando estas palavras-chaves, que poder ser montada para o
aplicativo que ser testado.
Um tcnico especialista na linguagem do script ser necessrio para todos os casos (ainda que como testador
ou como especialista em automao).
Para qualquer tcnica de script utilizada, os resultados de cada teste precisam ser armazenados para futuras
comparaes.
Ferramentas de anlises estticas
Ferramentas de anlises estticas aplicadas ao cdigo fonte podem forar a padronizao do cdigo. No
entanto se aplicada a um cdigo existente (sistemas legado) pode gerar grande quantidade de mensagens.
Mensagens de ateno no param o processo de compilao, mas devem ser tratados para que a manuteno
do cdigo seja mais fcil no futuro. Uma implementao gradual com filtros iniciais para excluir algumas
mensagens poder ser uma boa e eficiente alternativa.
Ferramentas de gerenciamento de teste
Ferramentas de gerenciamento de teste precisam fazer a interface com outras ferramentas ou planilhas para
produzir as informaes no melhor formato possvel de modo a atender as necessidades da empresa. O
relatrio precisa ser bem desenhado e monitorado para que traga o benefcio esperado.
Verso 2011br
Agosto 2011
Pgina 63 de 77
Certified Tester
6.3 Implementando uma Ferramenta na Organizao (K1)
15 minutos
Termos
No h
Conceito
Os princpios para introduzir uma ferramenta em uma organizao so:
Avaliao da maturidade da organizao, pontos fracos e pontos fortes na identificao de
oportunidades para um aperfeioamento do processo de teste com uso de uma ferramenta.
Avaliao frente a requisitos claros e os critrios objetivos.
Uma prova de conceito, utilizando a ferramenta durante a fase de avaliao para estabelecer se ela
funciona adequadamente com o software sendo testado e dentro da infraestrutura atual ou para
identificar mudanas necessrias infraestrutura para efetivamente utilizar a ferramenta.
Avaliao do fornecedor (incluindo treinamento, suporte e aspectos comerciais) ou fornecedores de
suporte ao servio em caso de ferramentas no comerciais.
Identificao dos requisitos internos para acompanhamento (mentoring e coaching) no uso da
ferramenta.
Avaliao das necessidades de treinamento, considerando as habilidades de automao de teste da
equipe.
Estimativa de uma razo custo-benefcio baseado em um business case concreto.
Introduzir a ferramenta seleciona em uma organizao se inicia com um projeto piloto, que tem os seguintes
objetivos:
Aprender mais detalhes sobre a ferramenta.
Ver como a ferramenta poder se adequar aos processos e prticas e como necessitariam mudar.
Decidir as formas e padres de uso, gerenciamento, arquivamento e manuteno da ferramenta e
artefatos de testes (ex.: decidir a conveno dos nomes de arquivos, criao de bibliotecas e decidir a
modularidade dos grupos de teste).
Estimar se os benefcios sero atingidos a um custo razovel.
Os fatores de sucesso para a implantao de uma ferramenta em uma organizao incluem:
Implementar a ferramenta ao restante da organizao incrementalmente.
Adaptar e aprimorar o processo para combinar com o uso da ferramenta.
Providenciar treinamentos para novos usurios.
Definir diretrizes de utilizao.
Implementar um modo de aprender lies com o uso da ferramenta.
Fornecer suporte ao time de teste para uma determinada ferramenta.
Monitorar o uso e os benefcios da ferramenta.
Referncias
6.2.2 Buwalda, 2001, Fewster, 1999
6.3 Fewster, 1999
Verso 2011br
Agosto 2011
Pgina 64 de 77
Certified Tester
7. Referncias
Padres
ISTQB Glossrio de termos usados no Teste de Software Verso 2.1
[CMMI] Chrissis, M.B., Konrad, M. and Shrum, S. (2004) CMMI, Guidelines for Process Integration
and Product Improvement, Addison Wesley: Reading, MA - Ver seo 2.1
[IEEE 829-1998] IEEE Std 829 (1998) IEEE Standard for Software Test Documentation) - Ver
sees 2.3, 2.4, 4.1, 5.2, 5.3, 5.5, 5.6
[IEEE 1028] IEEE Std 1028 (2008) IEEE Standard for Software Reviews and Audits- Ver seo
3.2
[IEEE 12207] IEEE 12207/ISO/IEC 12207-1996, Software life cycle processes - Ver seo 2.1
[ISO 9126] ISO/IEC 9126-1:2001, Software Engineering Software Product Quality - Ver seo 2.3
Livros
[Beizer, 1990] Beizer, B. (1990) Software Testing Techniques (2nd edition), Van Nostrand Reinhold:
Boston - Ver sees 1.2, 1.3, 2.3, 4.2, 4.3, 4.4, 4.6
[Black, 2001] Black, R. (2001) Managing the Testing Process (2nd edition), John Wiley & Sons:
NewYork - Ver sees 1.1, 1.2, 1.4, 1.5, 2.3, 2.4, 5.1, 5.2, 5.3, 5.5, 5.6
[Buwalda, 2001] Buwalda, H. et al. (2001) Integrated Test Design and Automation, Addison Wesley:
Reading, MA - Ver seo 6.2
[Copeland, 2004] Copeland, L. (2004) A Practitioners Guide to Software Test Design, Artech House:
Norwood, MA - Ver sees 2.2, 2.3, 4.2, 4.3, 4.4, 4.6
[Craig, 2002] Craig, Rick D. and Jaskiel, Stefan P. (2002) Systematic Software Testing, Artech
House: Norwood, MA - Ver sees 1.4.5, 2.1.3, 2.4, 4.1, 5.2.5, 5.3, 5.4
[Fewster, 1999] Fewster, M. and Graham, D. (1999) Software Test Automation, Addison Wesley:
Reading, MA - Ver sees 6.2, 6.3
[Gilb, 1993]: Gilb, Tom and Graham, Dorothy (1993) Software Inspection, Addison Wesley:
Reading, MA - Ver sees 3.2.2, 3.2.4
[Hetzel, 1988] Hetzel, W. (1988) Complete Guide to Software Testing, QED: Wellesley, MA - Ver
sees 1.3, 1.4, 1.5, 2.1, 2.2, 2.3, 2.4, 4.1, 5.1, 5.3
[Kaner, 2002] Kaner, C., Bach, J. and Pettticord, B. (2002) Lessons Learned in Software Testing,
John Wiley & Sons - Ver sees 1.1, 4.5, 5.2
[Myers 1979] Myers, Glenford J. (1979) The Art of Software Testing, John Wiley & Sons - Ver
sees 1.2, 1.3, 2.2, 4.3
[van Veenendaal, 2004] van Veenendaal, E. (ed.) (2004) The Testing Practitioner (Chapters 6, 8, 10),
UTN Publishers: The Netherlands - Ver sees 3.2, 3.3
Verso 2011br
Agosto 2011
Pgina 65 de 77
Certified Tester
Apndice A Syllabus Background

Histrico deste documento
Este documento foi preparado durante os anos de 2004 e 2011 por um trabalho composto por membros
apontados pelo ISTQB. Foi inicialmente revisado por uma equipe selecionada e ento por representantes da
comunidade internacional de teste de software. As regras usadas na produo deste documento so exibidas
no Apndice C.
Este documento o syllabus para a Certificao Internacional de Teste de Software em Nvel Fundamental, o
primeiro nvel de qualificao internacional aprovado pelo ISQTB (www.istqb.org).
Objetivos da Qualificao Certificado em Nvel Fundamental

Obter reconhecimento do teste como uma especializao profissional e essencial da engenharia de
software.
Prover um framework padro para desenvolvimento da carreira dos testadores.
Capacitar testadores qualificados profissionalmente a serem reconhecidos por empresrios, clientes e
colegas, e criar um perfil do testador.
Promover boas e consistentes prticas de teste com todas as disciplinas de engenharia de software
Identificar os tpicos do teste que so relevantes e o valor para o mercado.
Capacitar os fornecedores de software a contratar testadores certificados e atravs disso obter
vantagens comerciais sob seus competidores por propagar suas prprias polticas de recrutamento de
testadores.
Promover uma oportunidade para os testadores e aqueles interessados no teste, a adquirir uma
qualificao internacionalmente reconhecida no assunto.
Objetivos da Qualificao Internacional (adaptado da reunio do ISTQB em

Sollentuna, Novembro de 2001)
Estar apto a comparar a prtica do teste entre os diferentes pases.
Capacitar testadores a trocarem conhecimento entre as comisses mais facilmente.
Permitir que projetos multinacionais/internacionais tenham uma compreenso comum do
empreendimento do teste.
Aumentar o nmero de testadores qualificados ao redor do mundo.
Ter mais impacto como uma iniciativa baseada internacionalmente do que qualquer abordagem de um
pas especfico.
Desenvolver um corpo comum internacional de compreenso e conhecimento sobre teste e
terminologias atravs do syllabus e aumentar o nvel de conhecimento sobre teste para todos os
participantes.
Promover o teste como uma profisso em mais pases.
Capacitar testadores a obter uma qualificao reconhecida na sua linguagem nativa.
Permitir o compartilhamento de conhecimentos e recursos entre os pases.
Prover o reconhecimento internacional dos testadores e desta qualificao devido participao
oriunda de muitos pases.
Verso 2011br
Agosto 2011
Pgina 66 de 77
Certified Tester
Requisitos bsicos para esta qualificao
O critrio de entrada para fazer o exame do ISTQB (Certificado dos Fundamentos em Teste de Software)
que o candidato tenha um interesse em teste de software. No entanto, altamente recomendvel que o
candidato tambm:
Tenha um conhecimento mnimo seja em desenvolvimento de software ou teste de software, como
seis meses de experincia como um testador em testes de sistema ou de aceite, ou como
desenvolvedor de software.
Fazer o curso que autorizado pelos padres do ISTQB (por uma comisso nacional reconhecida).
Histrico da Certificao em Fundamentos em Teste de Software

A certificao independente de testadores de software comeou no Reino Unido com a British Computer
Societys Information Systems Examination Board (ISEB), quando uma comisso de teste de software surgiu
em 1998 (www.bcs.org.uk/iseb). Em 2002, ASQF na Alemanha comeou a dar suporte a um esquema de
qualificao ao testador (www.asqf.de). Este syllabus baseado no ISEB e ASQF syllabi; inclui um contedo
organizado, atualizado e novo, e a nfase dada aos tpicos que fornecem ajuda mais prtica aos testadores.
Um Certificado em Fundamentos em Teste de Software (ex.: ISEB, ASQF ou outra organizao reconhecida
por uma comisso nacional do ISQTB) obtido por algum, antes do Certificado Internacional ter sido criado,
ser considerado equivalente ao certificado internacional. A Certificao em Fundamentos de Teste de
Software no expira e no precisa ser renovado. A data em que foi obtido ser demonstrada no Certificado.
Com a participao de cada pas, aspectos locais so controlados pela comisso nacional reconhecida pelo
ISTQB. As responsabilidades da comisso nacional so especificadas pelo ISTQB, mas so implementadas
em cada pas. Dentre as obrigaes das comisses dos pases esto a autorizao para prover treinamentos e a
ministrar os exames.
Verso 2011br
Agosto 2011
Pgina 67 de 77
Certified Tester
Apndice B Objetivos de estudo/Nveis de Conhecimento

Os seguintes objetivos de estudos so definidos como aplicveis para este syllabus. Cada tpico neste syllabus
ser examinado de acordo com os seus objetivos de estudo.
Nvel 1: Relembrar (K1)

O candidato reconhecer, relembrar e retomar um termo ou conceito.
Palavras chave: Relembrar, recuperar, reconhecer, saber.
Exemplo:
Ser capaz de reconhecer a definio de falha como:
No entrega de servio a um usurio final ou qualquer outro interessado (stakeholder) ou
Desvios atuais do componente ou sistema de suas expectativas de entrega, servios ou resultados.
Nvel 2: Compreender (K2)

O candidato pode selecionar as razes ou explicaes para declaraes relacionadas ao tpico podendo
resumir, comparar, classificar e dar exemplos para os conceitos de teste.
Palavras chave: Sumarizar, generalizar, abstrair, classificar, comparar, mapear, contrastar, exemplificar,
interpretar, traduzir, representar, inferir, concluir, categorizar, construir modelos.
Exemplo:
Ser capaz de explicar as razes porque os testes devem ser elaborados o mais cedo possvel:
Encontrar defeitos quando eles podem ser removidos a um preo baixo.
Encontrar primeiramente os defeitos mais importantes.
Ser capaz de explicar as semelhanas e diferenas entre teste de integrao e de sistema:
Semelhanas: testar mais do que um componente, e poder testar aspectos no funcionais.
Diferenas: teste de integrao concentrado nas interfaces e interaes e teste de sistemas se
concentram nos aspectos do sistema como um todo, como o processamento do incio ao fim.
Nvel 3: Aplicar (K3)

O candidato pode selecionar a aplicao correta de um conceito ou tcnica e aplic-la em um dado contexto.
Palavras chave: Implementar, executar, usar, seguir um procedimento, aplicar um procedimento.
Exemplo:
Ser capaz de identificar os valores limites para parties vlidas e invlidas.
Ser capaz de selecionar os casos de teste de um dado diagrama de transio de estados de maneira a
cobrir todas as transies.
Verso 2011br
Agosto 2011
Pgina 68 de 77
Certified Tester
Nvel 4: Analisar (K4)
O candidato pode separar a informao relacionada a um procedimento ou tcnica em suas partes constituintes
para melhor entendimento, e pode distinguir entre fatos e inferncias. A aplicao tpica uma anlise de
documento, software ou situao de projeto e propor aes adequadas para resolver um problema ou tarefa.
Palavras chave: Analisar, organizar, encontrar coerncia, integrar, esboar, estruturar, atribuir, desconstruir,
diferenciar, discriminar, distinguir, focar, selecionar.
Exemplo:
Avaliar riscos de produto e propor atividades de mitigao preventivas e corretivas.
Descrever quais pores de um relatrio de incidente so factuais e quais so inferidas a partir de
resultados.
Referncias
(Para os nveis cognitivos dos objetivos de estudo)
Anderson, L. W. and Krathwohl, D. R. (eds) (2001) A Taxonomy for Learning, Teaching, and Assessing: A
Revision of Bloom's Taxonomy of Educational Objectives, Allyn & Bacon:
Verso 2011br
Agosto 2011
Pgina 69 de 77
Certified Tester
Apndice C Regras aplicadas ao ISTQB Fundation Syllabus

Foundation Syllabus
As regras listadas aqui foram usadas no desenvolvimento e reviso do syllabys. (Uma LEGENDA exibida
aps cada regra como abreviao da mesma).
Regras gerais
SG1
O syllabus deve ser compreensvel e absorvvel por pessoas com 0 a 6 meses (ou mais) de
experincia em teste. (6-MESES)
SG2
O syllabus mais prtico do que terico. (PRTICO)
SG3
O syllabus claro e objetivo (no tem ambiguidades) aos leitores interessados. (CLARO)
SG4
O syllabus compreensvel a pessoas de diferentes pases e, de fcil traduo em diferentes

linguagens. (TRADUZVEL)
SG5
O syllabus original usa o ingls americano. (INGLS-AMERICANO)
Contedo Atual
SC1
O syllabus inclui conceitos recentes de testes e reflete as melhores prticas da atualidade em teste
de software, quando estas forem adotadas de forma geral. O syllabus est sujeito reviso de trs
a cinco anos (ATUALIZADO).
SC2
O syllabus deve minimizar aspectos relacionados a tempo, assim como as condies atuais do
mercado para permitir possua uma vida til de trs a cinco anos. (VIDA UTIL)
Objetivos de Estudos
LO1 Objetivos de estudos distinguem os itens a ser reconhecidos/relembrados (nvel cognitivo K1),
itens que o candidato deve compreender conceitualmente (K2) e aqueles que os candidatos esto
aptos a praticar/utilizar (K3). (NVEL DE CONHECIMENTO)
LO2 A descrio do contedo consistente com os objetivos de estudo. (CONSISTNCIA)
LO3 Para ilustrar os objetivos de aprendizado, questes simuladas de exame devero ser apresentadas
para as sees principais do syllabus. (EXAME)
Estrutura geral
ST1
A estrutura do syllabus clara e permite o cruzamento de referncia e de uma parte a outra das
questes dos exames e de outros documentos relevantes. (REFERNCIAS CRUZADAS).
ST2
Sobreposio entre sees do syllabus minimizado. (SOBREPOSIO)
ST3
Cada seo do syllabus tem a mesma estrutura. (ESTRUTURA CONSISTENTE)
ST4
O syllabus contm verso, data de emisso e nmero de cada pgina. (VERSO)
ST5
O syllabus contempla um guia que aponta a quantidade de tempo a ser gasta em cada seo (para
refletir a importncia relativa de cada tpico). (TEMPO GASTO)
Referncias
SR1
Origens e referncias dos conceitos so dadas no syllabus para ajudar os instrutores a encontrar
mais informaes sobre o tpico. (REFS)
Verso 2011br
Agosto 2011
Pgina 70 de 77
Certified Tester
SR2
Quando no existir fontes claras ou identificveis, mas detalhes deveram ser fornecidos no
syllabus. Por exemplo, definies esto no Glossrio, sendo assim apenas os termos sero listados
no syllabus. (REFS SEM DETL)
Fontes e Informaes
Os termos utilizados no syllabus so definidos no Glossrio do ISTQB que usado em teste de software. Uma
verso do glossrio disponibilizada pelo ISTQB. A traduo poder ser encontrada no site do BSTQB
(www.bstqb.org.br)
Uma lista de livros sobre teste de software recomendada para estudos em paralelo com este syllabus. A
principal lista de livros parte da seo Referncias.
Verso 2011br
Agosto 2011
Pgina 71 de 77
Certified Tester
Apndice D Observao aos provedores de treinamentos.

Cada cabealho dos temas do syllabus assinalado com o tempo a ser alocado em minutos. O propsito disto
dar uma viso da relativa proporo de tempo a ser alocado em cada seo do curso, e dar um tempo mnimo
aproximado para ensinar cada seo. Instrutores podem gastar mais tempo do que indicado e os candidatos
tambm podem gastar mais tempo em leitura e pesquisa. Um programa de treinamento no precisa seguir a
mesma ordem que o syllabus.
O syllabus contm referncias para padres estabelecidos, que devem ser usados na preparao do material
para o treinamento. Cada padro utilizado deve estar com a verso mencionada na verso atual do syllabus.
Outras publicaes, templates ou padres no referenciados neste syllabus podem tambm ser utilizados e
referenciados, mas no far parte do exame.
Todos os objetivos de estudo K3 e K4 requerem um exerccio prtico a ser includo nos materiais de
treinamento.
Verso 2011br
Agosto 2011
Pgina 72 de 77
Certified Tester
Appendix E Release Notes

Release 2010
1) Mudana dos objetivos de estudo (LO) incluem alguma clarificao:
a) Mudana de termos para os seguintes LOs (o contedo e nvel do LO permanecem inalterados): LO1.2.2, LO-1.3.1, LO-1.4.1, LO-1.5.1, LO-2.1.1., LO-2.4.2, LO-4.1.3, LO-4.2.1, LO-4.2.2., LO-4.3.1,
LO-4.3.2, LO-4.3.3, LO-4.4.1, LO-4.4.2, LO-4.4.3, LO-4.6.1, LO-5.1.2, LO-5.2.2, LO-5.3.2, LO5.3.3, LO-5.5.2, LO-6.1.1, LO-6.2.2, LO-6.3.2.
b) LO-1.1.5 foi atualizado e alterado para K2. Pois uma comparao dos termos relacionados a defeito
pode ser esperada.
c) LO-1.2.3 (K2) foi adicionado. O contedo j estava coberto no syllabus 2007.
d) LO-3.1.3 (K2) agora combina o contedo do LO-3.1.3 e LO-3.1.4.
e) LO-3.1.4 foi removido do syllabus 2010, j que parcialmente redundante com o LO-3.1.3.
f) LO-3.2.1 foi atualizado para consistncia com o contedo do syllabus 2010.
g) LO-3.3.2 foi modificado, e seu nvel foi alterado de K1 para K2, para consistncia com o LO-3.1.2.
h) LO 4.4.4 foi modificado para maior clareza, e foi mudado de K3 para K4. Razo: o LO-4.4.4 j havia
sido escrito em uma forma K4.
i) LO-6.1.2 (K1) foi retirado do syllabus 2010 e substitudo pelo LO-6.1.3 (K2). No h LO-6.1.2 no
syllabus 2010.
2) Uso consistente da abordagem de teste de acordo com a definio do glossrio. O termo estratgia de teste
no mais definido como um termo a ser relembrado.
3) O Captulo 1.4 agora contm o conceito de rastreabilidade entre base de teste e casos de teste.
4) Captulo 2.x agora contm objetos de teste e bases de teste.
5) Reteste agora o principal termo no glossrio, ao invs de teste de confirmao.
6) O aspecto qualidade e teste de dados foram adicionados em vrias partes no syllabus: qualidade de dados
e riscos nos Captulos 2.2, 5.5 e 6.1.8.
7) O Critrio de Entrada, Captulo 5.2.3, foi adicionado como um novo subcaptulo. Razo: consistncia com
o critrio de sada (-> critrio de entrada adicionado ao LO-5.2.9).
8) Uso consistente dos termos estratgia de testes e abordagem de testes com sua definio no glossrio.
9) O Captulo 6.1 foi diminudo, pois a descrio das ferramentas estava longa demais para uma aula de 45
minutos.
10) O IEEE Std 829:2008 foi lanado. Esta verso do syllabus no considera ainda esta nova edio. A seo
5.2 se refere ao documento Plano de Teste Mestre. O contedo do Plano de Teste Mestre coberto pelo
conceito de que o documento Plano de Teste cobre diferentes nveis de planejamento: Planos de Teste
para os nveis de teste podem ser criados, assim como um plano de teste no nvel de projeto cobrindo
mltiplos nveis de teste. Este ltimo chamado de Plano de Teste Mestre neste syllabus e no glossrio
ISTQB.
11) O Cdigo de tica foi movido do CTAL para o CTFL.
Release 2011
Mudanas feitas no release de manuteno 2011:
1) Primeira ocorrncia: ISTQB substitudo por ISTQB.
2) Introduo neste syllabus: Descrio dos nveis cognitivos de conhecimento removidos, pois isto estava
redundante com o Apndice B.
3) Seo 1.6: Sendo que o intuito no era definir um Objetivo de Estudo para o Cdigo de tica, o nvel
cognitivo para a seo foi removido.
4) Sees 2.2.1, 2.2.2, 2.2.3 e 2.2.4, 3.2.3: Correo de formatao em listas.
5) Seo 2.2.2. A palavra falha no estava correta de acordo com a descrio: ... isolar falhas em um
componente especfico.... Portanto, foi substituda com a expresso defeito para a mesma sentena.
6) Seo 2.3: Formatao corrigida da lista de tpicos de objetivos de teste relacionados aos termos de teste
na seo Tipos de Teste (K2).
Verso 2011br
Agosto 2011
Pgina 73 de 77
Certified Tester
7) Seo 2.3.4: Descrio atualizada de debugging para ser consistente com a Verso 2.1 do Glossrio
ISTQB.
8) Seo 3.2.1: Devido ao fato das atividades de uma reviso formal terem sido incorretamente formatadas, o
processo de reviso tinha 12 atividades principais ao invs de 6, conforme previsto. Portanto, foi alterado
de novo para seis, o que torna essa seo aderente ao Syllabus 2007 e o ISTQB Advanced Level Syllabus
2008.
9) Seo 4.2: Mudana de texto para clarificar como o teste caixa-preta e caixa-branca podem ser usados em
conjunto com tcnicas baseadas na experincia.
10) Seo 4.3.5: caminho alternativo substitudo por cenrio alternativo.
11) Seo 4.4.2: Para clarear o termo teste de desvio no texto da Seo 4.4, uma sentena para clarificar o
foco do teste de desvio foi alterado.
12) Seo 6.1: Tpico 6.1.1 Entendendo o Significado e Objetivo do Suporte a Ferramentas para Teste (K2)
substitudo por 6.1.1. Suporte a Ferramentas para Teste (K2).
13) Seo 7 / Livros: A terceira edio de [Black, 2001] listada, substituindo a segunda edio.
14) Apndice D: Captulos requerendo exerccios foram substitudos pelos requisitos genricos informando
que todos Objetivos de Estudo K3 e superiores requerem exerccios. Este um requisito especificado no
Processo de Certificao ISTQB (Verso 1.26).
15) Apndice E: os objetivos de estudo alterados entre as verses 2007 e 2010 esto agora listados
corretamente.
Verso 2011br
Agosto 2011
Pgina 74 de 77
Certified Tester
Apncide F ndice Remissivo

A
condio de teste, 18
Acompanhamento, 38
controladores, 27
Alfa Teste, 27, 30
controle de verso, 64
Anlise de impacto, 34
critrio de sada, 18
Anlise dinmica, 73
Anlise do Valor Limite, 48
dados de teste, 18, 48, 72
Anlise e modelagem de teste, 19
dano, 14
Anlise Esttica, 36, 41, 72, 76
data-driven, 76
Autor, 38
deduo de erros, 52
defeito, 14, 32
base de teste, 18
depurao, 16, 27, 32
Beta Teste, 27, 30
diagrama de fluxo de processo, 31
big bang, 28
diagrama de transio de estados, 31
bottom-up, 28
Bug, 14
efeito de monitorao, 71
encerramento de teste, 20
caixa-branca, 29, 31, 32, 47, 50
engano, 14
caixa-preta, 28, 31, 47
erros, 15
caso de teste, 16, 31, 36, 45, 48, 51
escopo da integrao, 28
caso de uso, 28, 49
especificao de riscos, 28
cenrios, 49
especificao de teste, 36
Ch
estimativa do esforo do teste, 60
check-list, 38
estratgia de teste, 18, 57, 61
execuo de teste, 18, 19, 73, 76
cobertura, 32
cobertura de cdigo, 27, 60
falha, 14
cobertura de condies, 51
Ferramentas de Teste, 71
cobertura de deciso, 51
Ferramentas para gerenciamento do teste, 71
cobertura de mltiplas condies, 51
Ferramentas para testes estticos, 72
cobertura de teste, 18, 60
cobertura estrutural, 51
garantia da qualidade, 15
comparadores, 73
gerenciamento de configurao, 64, 72

Verso 2011br
Agosto 2011
Pgina 75 de 77
Certified Tester
gerenciamento de incidentes, 72
plano de teste, 18, 65
gerenciamento de requisitos, 71
poltica de teste, 18
gerenciamento de riscos, 66
Preparao individual, 37
gerenciamento de teste, 71, 76
processo de reviso, 72
gerente de teste, 38, 56, 57, 65
processo mental, 16
processos de negcios, 28
implementao, 19, 57
incidente, 18, 67
qualidade, 14
Kick-off, 37
rastreabilidade, 45
registro de teste, 18
lder de teste, 56, 57
regras de negcio, 28
linguagem de scripts, 75
relatrio consolidado de teste, 18
relatrio de incidentes, 67
medio de cobertura, 73
relatrio do teste, 62
mtricas, 62
requisito, 16, 25, 28, 36
modelagem, 25, 72
reteste, 18
modelagem de teste, 45, 72
Retrabalho, 37
modelo de desenvolvimento incremental, 25
Reunio de reviso, 37
Modelo V, 25
reviso, 16
Moderador, 38
Revisores, 38
monitorao, 74
risco, 14, 28, 59, 60, 65, 66
monitorao do teste, 62
mudanas, 34
script de teste, 36, 45
segurana, 73
nvel do risco, 15
simuladores, 27
software de prateleira, 25
objetivo do teste, 16
stakeholders, 20, 21, 29
sute de teste, 18
palavras-chave, 76
Partio de Equivalncia, 48
tabela de deciso, 28, 48
performance, 73, 75
testador, 56, 57, 58
Planejamento, 37
teste automatizado, 45
planejamento de integrao, 57
teste de aceite, 29, 59
Planejamento de teste, 59
teste de carga, 32
Verso 2011br
Agosto 2011
Pgina 76 de 77
Certified Tester
Teste de Caso de Uso, 49
Teste e Cobertura de Deciso, 50
teste de componente, 27
teste esttico, 36
teste de confiabilidade, 32
teste estrutural, 27, 31, 32
teste de confirmao, 18, 31, 32
Teste exaustivo, 17
teste de estresse, 32
teste exploratrio, 52
teste de funcionalidade, 27
teste funcional, 31, 32
teste de integrao, 27, 29, 32, 51
teste independente, 21
teste de interoperabilidade, 32
teste no funcional, 32
teste de manuteno, 34
Teste Operacional de Aceite, 29
teste de manutenibilidade, 32
Teste orientado a dados, 75
teste de performance, 32
Teste orientado a palavras-chaves, 75
teste de portabilidade, 32
testes de integrao, 28
teste de regresso, 18, 26, 32
testware, 18, 19, 20, 57
teste de segurana, 31
Tipos de reviso, 38
teste de sistema, 28, 59
top-down, 28
Teste de transio de estados, 49
teste de unidade, 73
validao, 25
teste de usabilidade, 32
verificao, 25
teste dinmico, 36, 41
Verso 2011br
Agosto 2011
Pgina 77 de 77

Syllabus CTFL 2011br

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Syllabus CTFL 2011br

Hochgeladen von

Copyright:

Verfügbare Formate

International Software Testing Qualifications Board

Comisso Internacional para Qualificao de Teste de Software

Traduo realizada pela TAG01 - Documentao do BSTQB baseada

Brazilian Software Testing Qualifications Board

Ver Apendice E Notas da Verso

Traduo para portugus do Brasil

Certified Tester Foundation Level Syllabus

Certified Tester Foundation Level Syllabus

ASQF Syllabus Foundation Level Version 2.2 Lehrplan,

ISEB Software Testing Foundation Syllabus V2.0

Fundamentos do Teste (K2) ................................................................................... 10

Teste durante o ciclo de vida do software (K2) ..................................................... 20

Modelos de Desenvolvimento de Software (K2) .............................................................. 21

Tcnicas Estticas (K2) .......................................................................................... 29

Reviso e o Processo de Teste (K2) .................................................................................. 30

Tcnica de Modelagem de Teste (K3) ................................................................... 35

Gerenciamento de Teste (K3) ................................................................................ 43

Organizao do Teste (K2) ............................................................................................... 45

Ferramentas de Suporte a Teste (K2) ..................................................................... 57

Identificando as condies de testes e projetando os casos de testes (K3) ....................... 36

Tipos de Ferramentas de Teste (K2) ................................................................................. 58

CTFL (Certified Tester Foundation Level)

Objetivos de aprendizagem / nveis de conhecimento

Como este syllabus est organizado

2. Teste durante o ciclo de vida do software (K2)

1. Fundamentos do Teste (K2)

Objetivos de estudo para os fundamentos do teste

Porque necessrio testar? (K2)

O que teste? (K2)

Explicar os sete princpios do teste. (K2)

Fundamentos do processo de teste (K1)

Recordar os objetivos comuns do teste. (K1)

Princpios gerais do teste (K2)

Recordar as cinco atividades fundamentais de teste e suas respectivas no planejamento do teste.

A psicologia do teste (K2)

Recordar que o sucesso do teste influenciado por fatores psicolgicos (K1)

1.1.1 Contexto dos sistemas de software (K1)

1.1.2 Causas dos defeitos de software (K2)

1.1.3 Funo do teste no desenvolvimento, manuteno e operao de software (K2).

1.1.4 Teste e qualidade (K2)

1.1.5 Quanto teste suficiente? (K2)

Princpio 1 Teste demonstra a presena de defeitos

Princpio 2 Teste exaustivo impossvel

Princpio 3 Teste antecipado

Princpio 4 Agrupamento de defeitos

Princpio 5 Paradoxo do Pesticida

Princpio 6 Teste depende do contexto

Princpio 7 A iluso da ausncia de erros

1.4.1 Planejamento e controle do teste (K1)

1.4.2 Anlise e modelagem do Teste (K1)

1.4.3 Implementao e execuo de teste (K1)

1.4.4 Avaliao do critrio de sada e relatrio (K1)

1.4.5 Atividades de encerramento de teste (K1)

O envolvimento em teste de software permite que pessoas conheam informaes confidenciais e

2. Teste durante o ciclo de vida do software (K2)

Objetivos de estudo para o teste durante o ciclo de vida do software

Modelos de desenvolvimento de software (K2)

Nveis de Teste (K2)

Tipos de teste: os alvos do teste (K2)

Compreender as relaes entre o desenvolvimento, atividades de teste e produtos de trabalho

Comparar quatro tipos de teste de software (funcional, no funcional, estrutural e relativo

Teste de Manuteno (K2)

2.1.1 Modelo V (K2)