LIVRO Base de Conhecimento em Teste de Software PDF

Base de Conhecimento
para
Certificao em Teste
Verso 2005
Comisso Internacional para Qualificao de Teste

de Software
Base de Conhecimento para Certificao em Teste
Comisso Internacional
para Qualificao de
Teste de Software
Copyright 2005, aos autores (Thomas Mller (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 2005
Pgina 2 de 89
Comisso Internacional para Qualificao de Teste de Software
29-Jun-2006
para Qualificao de
Teste de Software
Histrico de Revises
Verso
Data
Observao
BSTQB V1.1
01-Julho-2007
Reviso
BSTQB V1.0
29-Junho-2006 Traduo para portugus do Brasil
ISTQB 2005
01-Julho-2005
Certified Tester Foundation Level Syllabus
ASQF V2.2
Julho-2003
ASQF Syllabus Foundation Level Version 2.2

Lehrplan, Grundlagen des Softwaretestens
25-Fev-1999
ISEB Software Testing Foundation Syllabus

V2.0
25 February 1999
ISEB V2.0
Verso 2005
Pgina 3 de 89
29-Jun-2006
para Qualificao de
Teste de Software
ndice
Histrico de Revises......................................................................................... 3
ndice.................................................................................................................. 4
Agradecimentos ................................................................................................. 6
Introduo do Syllabus....................................................................................... 7
1. Fundamentos do Teste (K2)...................................................................... 10
1.1
1.1.1
1.1.2
1.1.3
1.1.4
1.1.5
1.2
1.3
1.4
1.4.1
1.4.2
1.4.3
1.4.4
1.4.5
1.5
2.
Porque necessrio testar? (K2) ................................................................. 11

Contexto dos sistemas de software (K1)................................................................. 11
Causas dos defeitos de software (K2)..................................................................... 11
Funo do teste no desenvolvimento, manuteno e operao de software (K2). 11
Teste e qualidade (K2) ............................................................................................ 11
Quanto teste suficiente? (K2) ............................................................................... 12
O que teste? (K2)....................................................................................... 13

Princpios gerais do teste (K2)...................................................................... 15
Fundamentos do Processo de Teste (K1) .................................................... 17
Planejamento e controle do teste (K1) .................................................................... 17
Anlise e modelagem do Teste (K1) ....................................................................... 18
Implementao e execuo de teste (K1) ............................................................... 18
Avaliao do critrio de sada e relatrio (K1)......................................................... 19
Atividades de encerramento de teste (K1) .............................................................. 19
A Psicologia do Teste (K2) ........................................................................... 20
Teste durante o ciclo de vida do software (K2) ......................................... 22

2.1
Modelos de Desenvolvimento de Software (K2) ........................................... 24
2.1.1 Modelo V (K2) .......................................................................................................... 24

2.1.2 Modelos iterativos de desenvolvimento (K2)........................................................... 24
2.1.3 Teste dentro de um modelo de ciclo de vida........................................................... 25
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.
Teste de Componente (K2) ..................................................................................... 26

Teste de Integrao (K2) ......................................................................................... 27
Teste de Sistema (K2) ............................................................................................. 27
Teste de Aceite (K2) ................................................................................................ 28
Tipos de Teste: o alvo do teste..................................................................... 30

Teste de Funo (Teste funcional) (K2) .................................................................. 30
Teste de caractersticas do produto de software (testes no-funcionais) (K2) ....... 31
Teste de estrutura / arquitetura do software (teste estrutural) (K2) ........................ 31
Teste relacionado a mudanas (teste de confirmao e regresso) (K2)............... 31
Teste de Manuteno ................................................................................... 33
Tcnicas Estticas (K2)............................................................................. 34

3.1
3.2
3.2.1
3.2.2
3.2.3
3.2.4
3.3
4.
Nveis de Teste (K2) ..................................................................................... 26
Reviso e o Processo de Teste (K2) ............................................................ 35

Processo de Reviso (K2) ............................................................................ 36
Fases de uma reviso formal (K1)........................................................................... 36
Papis e responsabilidades (K1) ............................................................................. 36
Tipos de reviso (K2)............................................................................................... 37
Fatores de sucesso para as revises (K2) .............................................................. 38
Anlise Esttica por Ferramentas (K2) ......................................................... 40
Tcnica de Modelagem de Teste (K3) ...................................................... 42

4.1
4.2
4.3
4.3.1
4.3.2
4.3.3
4.3.4
Identificando as condies de testes e projetando os casos de testes (K3). 44

Categorias das tcnicas de modelagem de teste (K2) ................................. 46
Tcnicas baseadas em especificao ou Caixa-Preta (K3).......................... 47
Partio de Equivalncia ......................................................................................... 47
Anlise do Valor Limite ............................................................................................ 47
Tabela de Deciso ................................................................................................... 47
Teste de transio de estados................................................................................. 48
Verso 2005
Pgina 4 de 89
29-Jun-2006
para Qualificao de
Teste de Software
4.3.5 Teste de Caso de Uso ............................................................................................. 48
4.4
Tcnicas baseadas em estrutura ou Caixa-Branca (K3) .............................. 50
4.4.1 Teste e Cobertura de Comandos ............................................................................ 50

4.4.2 Teste e Cobertura de Deciso................................................................................. 50
4.4.3 Outras tcnicas baseadas na estrutura ................................................................... 51
4.5
4.6
5.
Tcnicas baseadas na experincia (K2) ....................................................... 52

Escolhendo as tcnicas de teste (K2)........................................................... 53
Gerenciamento de Teste (K3) ................................................................... 54

5.1
Organizao do Teste (K2) ........................................................................... 56
5.1.1 A organizao e o teste independente (K2) ............................................................ 56

5.1.2 Tarefas do lder de teste e dos testadores (K1) ...................................................... 57
5.2
5.2.1
5.2.2
5.2.3
5.2.4
5.2.5
5.3
Organizao do Teste (K2) ........................................................................... 59

Planejamento Teste (K2) ......................................................................................... 59
Atividades no Planejamento de testes (K2)............................................................. 59
Critrio de Sada (K2) .............................................................................................. 60
Estimativa do teste (K2)........................................................................................... 60
A Estratgia do Teste (abordagem de teste) (K2)................................................... 60
Monitorao e Controle do Progresso do Teste (K2).................................... 62
5.3.1 A Monitorao do Progresso do Teste (K1) ............................................................ 62

5.3.2 Relatrio do teste (K2)............................................................................................. 62
5.3.3 Controle do Teste (K2) ............................................................................................ 63
5.4
5.5
Gerenciamento de Configurao (K2) .......................................................... 64

Riscos e Teste (K2) ...................................................................................... 65
5.5.1 Riscos no Projeto (K1, K2) ...................................................................................... 65

5.5.2 Riscos do Produto (K2)............................................................................................ 66
5.6
6.
Gerenciamento de Incidente (K3) ................................................................. 67
Ferramentas de Suporte a Teste (K2)....................................................... 69

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
Tipos de Ferramentas de Teste (K2) ............................................................ 70

Classificao das Ferramentas de Teste (K2) ........................................................ 70
Ferramentas para gerenciamento do teste (K1)...................................................... 70
Ferramentas para testes estticos (K1) .................................................................. 72
Ferramenta de suporte para especificao de teste(K1) ........................................ 72
Ferramenta de suporte para execuo e registro (K1)............................................ 73
Ferramenta de performance e monitorao (K1) .................................................... 74
Ferramenta de suporte para reas de aplicaes especficas (K1)........................ 74
Ferramentas de suporte utilizando outras ferramentas........................................... 75
Uso Efetivo das Ferramentas: Riscos e Benefcios em potenciais (K2) ....... 76
6.2.1 Potenciais benefcios e riscos de ferramentas de suporte ao teste (para todas as

ferramentas) (K1)................................................................................................................ 76
6.2.2 Consideraes especiais para alguns tipos de ferramentas (K1) ........................... 76
6.3
Implementando uma Ferramenta na Organizao (K1)................................ 78
7. Referncias ............................................................................................... 80
Apndice A Syllabus Background ................................................................. 82
Apndice B Objetivos de Estudos / Nveis de Conhecimento ....................... 85
Apendice C Regras aplicadas ao ISTQB Fundation Syllabus ....................... 87
Apndice D Observao aos provedores de treinamentos. .......................... 89
Verso 2005
Pgina 5 de 89
29-Jun-2006
para Qualificao de
Teste de Software
Agradecimentos
Este documento foi produzido pela Comisso Internacional de Qualificao de
Teste de Software - International Software Testing Qualifications Board, com
trabalhos para parte do nvel base: Thomas Mller (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 Mller, 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 2005
Pgina 6 de 89
29-Jun-2006
para Qualificao de
Teste de Software
Introduo do Syllabus
Objetivo deste documento
Este syllabus forma a base de conhecimento para a Qualificao Internacional
de Teste de Software (International Software Testing Qualification). O
International Software Testing Qualifications Board (que ser referenciado
como ISTQB nas citaes futuras) 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.
Base de Conhecimento para Certificao em Teste de Software

A qualificao na Base de Conhecimento em Teste de Software voltada para
qualquer pessoa envolvida em teste de software. Isto inclui pessoas em
funes como testadores, analistas de testes, engenheiros de teste,
consultores de teste, gerente de teste, usurio que realiza 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, reconhecer, retomar;
K2: compreender, explicar, dar justificativas, comparar, classificar,

sumarizar;
K3: aplicar.
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 mencionado nos objetivos de
estudo.
Verso 2005
Pgina 7 de 89
29-Jun-2006
para Qualificao de
Teste de Software
O Exame
O exame de certificao 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
independentemente (ex: um local s para realizao do 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.
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 da Base de

Conhecimento.
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.
Verso 2005
Pgina 8 de 89
29-Jun-2006
para Qualificao de
Teste de Software
Como este syllabus est organizado

H seis captulos principais. O ttulo no nvel mais alto acompanhado pelos
nveis de aprendizagem (K1 a K3) cobertos pelo captulo e pelo tempo de
estudo para cada captulo. Por exemplo:
2. Teste durante o ciclo de vida do

software (K2)
135 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
135 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 2005
Pgina 9 de 89
29-Jun-2006
para Qualificao de
Teste de Software
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)
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)
Recordar termos como engano,

correspondentes erro e bug. (K1)
1.2
defeito,
falha
seus
termos
O que teste? (K2)
Recordar os objetivos comuns do teste. (K1)
Descrever os propsitos do teste no desenvolvimento, manuteno e

operao de software como um meio de encontrar defeitos, prover
confiabilidade, informaes e prevenir defeitos. (K1)
1.3
1.4
1.5
Princpios gerais do teste (K2)

Explicar os princpios fundamentais do teste. (K2)
Fundamentos do processo de teste (K1)

Recordar as atividades fundamentais de teste desde planejamento ao
encerramento de teste e as principais tarefas de cada atividade de teste.
(K1)
A psicologia do teste (K2)

Recordar que o sucesso do teste influenciado por fatores psicolgicos
(K1)
o Objetivos claros;
o Equilbrio entre teste independente e teste por conta prpria.
o Reconhecimento da necessidade da comunicao corts e retorno
das informaes sobre os defeitos.
Diferenciar a forma de pensar dos testadores e dos desenvolvedores.
(K2)
Verso 2005
Pgina 10 de 89
29-Jun-2006
1.1 Porque necessrio testar? (K2)
para Qualificao de
Teste de Software
135 minutos
Palavras-Chave
Bug, defeito, erro, falha, dano, engano, qualidade, risco, software, teste.
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. Podem, inclusive, chegar a influenciar na integridade das pessoas
ou at mesma em mortes.
1.1.2 Causas dos defeitos de software (K2)

O ser humano est sujeito a cometer um erro (engano), que produz um defeito
(dano, 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 infra-estrutura,
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
danos em software embarcado (firmware) ou influenciar a execuo do
software pela mudana das caractersticas 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 nofuncionais
do
software
(confiabilidade,
usabilidade,
eficincia
e
manutenibilidade). Para mais informaes sobre testes no-funcionais veja o
Verso 2005
Pgina 11 de 89
29-Jun-2006
para Qualificao de
Teste de Software
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.
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,
conseqentemente, 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.)
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 2005
Pgina 12 de 89
29-Jun-2006
1.2 O que teste? (K2)
para Qualificao de
Teste de Software
30 minutos
Palavras-Chave
Cdigo, depurao, desenvolvimento (de software), requisitos, reviso, base de
testes, caso de teste, teste, objetivos 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 e checagem dos resultados, avaliao do critrio de concluso,
gerao de relatrios sobre o processo de teste e sobre sistema alvo de teste e
encerramento ou concluso (exemplo: 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 provem 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 e prover informaes.
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. Reviso de
documentos (ex: requisitos) tambm ajuda a prevenir defeitos que possam
aparecem no cdigo.
No processo de teste, diferentes pontos de vista levam em conta 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. Testes de manuteno podem ser usados para testar se no foram
inseridos erros durante o desenvolvimento de mudanas. Durante os testes
Verso 2005
Pgina 13 de 89
29-Jun-2006
para Qualificao de
Teste de Software
operacionais, o principal objetivo pode ser avaliar caractersticas como

confiabilidade e disponibilidade.
Depurao (debbuging) e teste so atividades diferentes. Testes podem
demonstrar falhas que so causadas por defeitos. Depurao 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 2005
Pgina 14 de 89
29-Jun-2006
1.3 Princpios gerais do teste (K2)
para Qualificao de
Teste de Software
35 minutos
Palavras-Chave
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

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
freqentemente 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 (por exemplo, software do computador de bordo
Verso 2005
Pgina 15 de 89
29-Jun-2006
para Qualificao de
Teste de Software
de aeronaves) 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 2005
Pgina 16 de 89
29-Jun-2006
para Qualificao de
Teste de Software
1.4 Fundamentos do Processo de Teste (K1)
35 minutos
Palavras-Chave
Teste de confirmao, critrio de sada, incidente, teste de regresso, base de
testes, condies de teste, cobertura de teste, dados de teste, execuo de
teste, registro de teste, plano de teste, estratgia de teste, relatrio consolidado
de teste, testware.
Conceito
A parte mais visvel do Teste a execuo. Mas para ser eficaz e eficiente,
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 do critrio de sada e relatrios
Atividades de encerramento de teste

Apesar de serem apresentadas seqencialmente, as atividades durante o
processo podem se sobrepor ou acontecer de forma concorrente.
1.4.1 Planejamento e controle do teste (K1)

Planejamento de teste a atividade que consiste em verificar a misso do
teste, definindo os seus objetivos e especificando as atividades de forma a
alcan-los.
Controle de teste a constante atividade que consiste em comparar o
progresso atual contra o que foi planejado, reportando o status e os desvios do
plano. 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.
O planejamento de teste composto pelas seguintes atividades principais:
Determinar escopo, riscos e identificar os objetivos do teste.
Determinar a abordagem de teste (tcnicas, itens de teste, cobertura,

identificar e promover o relacionamento entre as equipes envolvidas no
teste, testware).
Determinar os recursos necessrios (pessoas, ambientes de teste,

estaes de trabalho)
Implementar a poltica de teste e/ou estratgia de teste.

Verso 2005
Pgina 17 de 89
29-Jun-2006
Planejar a anlise dos testes e projetar as tarefas.
Planejar a implementao, execuo e avaliao.
para Qualificao de
Teste de Software
Determinar os critrios de sada.

O controle de teste composto pelas seguintes atividades principais:
Medir e analisar os resultados.
Monitorar e documentar o progresso, cobertura e critrio de sada.
Iniciar as aes corretivas.
Tomar decises.
1.4.2 Anlise e modelagem do Teste (K1)

Anlise e modelagem de teste so atividades onde os objetivos gerais do teste
so transformados em condies e modelos de teste tangveis.
Anlise e modelagem de teste so compostos pelas seguintes atividades
principais:
Revisar a base de testes (como requisitos, arquitetura, modelagem,

interfaces).
Identificar condies ou requisitos de testes e dados de testes baseados

na anlise dos itens de teste, na especificao, no comportamento e na
estrutura.
Projetar os testes
Avaliar a testabilidade dos requisitos e do sistema.
Planejar a preparao do ambiente de teste e identificar a infra-estrutura

e ferramentas necessrias.
1.4.3 Implementao e execuo de teste (K1)

A implementao e execuo de teste a atividade onde as condies de teste
so transformadas em casos de teste e testware e o ambiente preparado.
Implementao e execuo de teste so compostas pelas seguintes atividades
principais:
Desenvolver e priorizar casos de teste, criar dados de teste, escrever os

procedimentos 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.
Executar os casos de teste manualmente ou utilizando ferramentas de

acordo com a seqncia planejada.
Registrar os resultados da execuo do teste e anotar as caractersticas

e verses do software sob teste, ferramenta de teste e testware.
Comparar resultados obtidos com os resultados esperados.
Verso 2005
Pgina 18 de 89
29-Jun-2006
para Qualificao de
Teste de Software
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 atividades 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.
Esta atividade 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.
As atividades de encerramento de teste so compostas pelas seguintes
atividades principais:
Checar quais entregveis planejados foram entregues, fechar os

relatrios de incidentes, levantar e registrar as mudanas para os que
permaneceram abertos e a documentao de aceite do sistema.
Finalizar e arquivar o testware, ambiente de teste e infra-estrutura de

teste para o reuso em outros projetos.
Entregar o testware para a manuteno da organizao.
Analisar as lies aprendidas para futuras releases e projetos e aprimorar

a maturidade do teste.
Verso 2005
Pgina 19 de 89
29-Jun-2006
1.5 A Psicologia do Teste (K2)
para Qualificao de
Teste de Software
35 minutos
Palavras-Chave
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.
Um 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:
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).
Testes elaborados 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 comunicadas de uma forma construtiva,
pode-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
Verso 2005
Pgina 20 de 89
29-Jun-2006
para Qualificao de
Teste de Software
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 / guerra

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 viceversa.
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 2005
Pgina 21 de 89
29-Jun-2006
2. Teste durante o ciclo de vida do

software (K2)
para Qualificao de
Teste de Software
135 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)
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 razes para os diferentes nveis de teste e caractersticas de

bons testes em qualquer modelo de ciclo de vida (K1).
2.2
2.3
Nveis de Teste (K2)

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)
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)
2.4
Teste de Manuteno (K2)

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)
Verso 2005
Pgina 22 de 89
29-Jun-2006
para Qualificao de
Teste de Software
Descrever as funes do teste de regresso e da anlise de impacto na

manuteno. (K2)
Verso 2005
Pgina 23 de 89
29-Jun-2006
2.1 Modelos de Desenvolvimento de Software

(K2)
para Qualificao de
Teste de Software
35 minutos
Palavras-Chave
Pacote ou software de prateleira (COTS - Commercial off the shelf), modelo
de desenvolvimento incremental, nvel de teste, 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 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 Processos de
Ciclo de Vida de Software 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
Verso 2005
Pgina 24 de 89
29-Jun-2006
para Qualificao de
Teste de Software
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

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.
A anlise e modelagem do teste para um dado nvel de teste deve

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 infra-estrutura ou outros
sistemas, ou implantao do sistema) e teste de aceite (funcional e/ou nofuncional, teste de usurio e/ou operacional).
Verso 2005
Pgina 25 de 89
29-Jun-2006
2.2 Nveis de Teste (K2)
para Qualificao de
Teste de Software
60 minutos
Palavras-Chave
Teste alfa, teste beta, teste de componente (tambm conhecido como teste de
unidade, mdulo ou teste de programa), teste de aceite de contrato,
controladores (drivers), teste no campo, requisitos funcionais, integrao,
teste de integrao, requisitos no-funcionais, teste operacional (aceite), teste
de aceite de regulamento, testes de robustez, simuladores (stubs), teste de
sistema, 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.
Verso 2005
Pgina 26 de 89
29-Jun-2006
para Qualificao de
Teste de Software
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 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, seqncias 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.
Verso 2005
Pgina 27 de 89
29-Jun-2006
para Qualificao de
Teste de Software
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 freqentemente responsvel pelo teste de
sistema.
2.2.4 Teste de Aceite (K2)

Teste de aceite freqentemente so a 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.
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.
Verso 2005
Pgina 28 de 89
29-Jun-2006
para Qualificao de
Teste de Software
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 sob encomenda. O critrio de
aceite deve ser definido quando o contrato assinado. Teste de aceite de
regulamento quando verifica-se a necessidade de a adeso a algum
regulamento de acordo com outras normas (ex:segurana, governamental,
legislao).
Testes Alfa e Beta (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 na fbrica e
teste de aceite no site, para sistemas que so testados antes e aps terem
sido movidos ao site do cliente.
Verso 2005
Pgina 29 de 89
29-Jun-2006
2.3 Tipos de Teste: o alvo do teste
para Qualificao de
Teste de Software
40 minutos
Palavras-Chave
Automao, teste de caixa-preta, cobertura de cdigo, teste de confirmao,
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, sute de teste, teste de
usabilidade, teste de 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 deve ser realizada 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 de 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.
Verso 2005
Pgina 30 de 89
29-Jun-2006
para Qualificao de
Teste de Software
2.3.2 Teste de caractersticas do produto de software (testes nofuncionais) (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).
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 re-testado
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.
Verso 2005
Pgina 31 de 89
29-Jun-2006
para Qualificao de
Teste de Software
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 2005
Pgina 32 de 89
29-Jun-2006
2.4 Teste de Manuteno
para Qualificao de
Teste de Software
15 minutos
Palavras-Chave
Anlise de impacto, teste de manuteno, migrao, modificao, retirada.
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 2005
Pgina 33 de 89
29-Jun-2006
3. Tcnicas Estticas (K2)
para Qualificao de
Teste de Software
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)
Reconhecer os produto 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. (K2)
3.2
Processo de Reviso (K2)
Retomar 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).
3.3
Ferramentas de anlise estticas (K2)
Descreve o objetivo para anlises estticas e comparar com o teste

dinmico. (K2)
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 2005
Pgina 34 de 89
29-Jun-2006
3.1 Reviso e o Processo de Teste (K2)
para Qualificao de
Teste de Software
15 minutos
Palavras-Chave
Teste dinmico, reviso, anlise esttica.
Contedo
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,
identificar
encontrar
contraste
falhas.
anlises estticas e testes dinmicos tm os mesmos objetivos

defeitos. Eles so complementares: as diferentes tcnicas podem
diferentes tipos de defeitos eficazmente e eficientemente. Em
com o teste dinmico, revises encontram defeitos ao invs de
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 2005
Pgina 35 de 89
29-Jun-2006
3.2 Processo de Reviso (K2)
para Qualificao de
Teste de Software
25 minutos
Palavras-Chave
Critrio de entrada, critrio de sada, reviso formal, reviso informal, inspeo,
kick-off, mtricas, moderador / lder de inspeo, reviso em pares, revisor,
reunio de reviso, reviso de processo, 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 tem as seguintes fases principais:
Planejamento: selecionar a equipe, alocar as funes, definir os critrio

de entrada e de sada para os diversos tipos de reviso formal (ex:
inspeo), e selecionar quais as partes dos documentos sero vistos.
Kick-off: distribuir os documentos, explicar os objetivos, processos e

documentos para os participantes; e checar os critrios de entrada (para
os diversos tipos de reviso).
Preparao individual: trabalho feito por cada participante antes da

reunio de reviso, tomando nota dos defeitos em potenciais, questes e
comentrios.
Reunio de reviso: discusso ou registro, com resultados

documentados ou anotaes (para os tipos de revises mais formais). Os
participantes da reunio podem simplesmente anotar os defeitos, fazer
recomendaes para o tratamento de defeitos ou tomar decises sobre
os defeitos.
Re-trabalho: Resolver defeitos encontrados, tipicamente feitos pelo autor.
Acompanhamento: Checar se os defeitos foram encaminhados, obtendo

mtricas e checando o critrio de sada (para tipos de revises formais).
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.
Verso 2005
Pgina 36 de 89
29-Jun-2006
para Qualificao de
Teste de Software
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 sob reviso. Revisores
podem ser escolhidos para representar diferentes funes e perspectivas
no processo de reviso, e parte integrante de qualquer reunio de
reviso.
Secretrio (ou 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.
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 (walkthrough) com clientes. As principais caractersticas,
opes e propsitos dos tipos de reviso comumente so:
Reviso informal
Principais Caractersticas:
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 (walkthrough)
Principais caractersticas:
Reunio conduzida pelo autor.
Cenrios, grupos de discusso, exerccios prticos.
Sesses sem restrio de tempo.
Opcionalmente h uma reunio preparatria dos revisores, relatrios de

reviso, lista de defeitos encontrados e um redator (diferente do autor).
Verso 2005
Pgina 37 de 89
29-Jun-2006
para Qualificao de
Teste de Software
Na prtica pode variar de informal para muito formal.
Principal propsito:
defeitos.
Revises tcnicas:
Principais caractersticas:
aprendizagem,
obter
entendimento,
encontrar
Documentado, processo de deteco de defeito definido que inclui

tcnicos ou colegas especialistas.
Pode ser feito por um colega sem a participao da gerncia.
Idealmente so conduzidas por um moderador treinado (que no seja o

autor).
Reunio preparatria.
Opcionalmente usa check-lists, relatrio de reviso, lista de defeitos e

participao da gerncia.
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
Principais caractersticas;
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 com critrio

de entrada e sada.
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.
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.
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).
Verso 2005
Pgina 38 de 89
29-Jun-2006
para Qualificao de
Teste de Software
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 2005
Pgina 39 de 89
29-Jun-2006
3.3 Anlise Esttica por Ferramentas (K2)
para Qualificao de
Teste de Software
20 minutos
Palavras-Chave
Compiladores, 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 precoce sobre aspectos suspeitos no cdigo ou programa

atravs de mtricas, por exemplo, na obteno de uma medida da alta
complexidade.
Identificao de defeitos no facilmente encontrados por testes

dinmicos.
Detecta 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;
Cdigo morto;
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
Verso 2005
Pgina 40 de 89
29-Jun-2006
para Qualificao de
Teste de Software
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 2005
Pgina 41 de 89
29-Jun-2006
4. Tcnica de Modelagem de Teste (K3)
para Qualificao de
Teste de Software
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)
Diferenas entre especificao de Planos de Teste, Casos de Testes e

procedimentos de Teste.(K1)
Comparar os termos: Condies do Teste, Caso de Teste e

Procedimento de Teste.(K2)
Criar Casos de Teste: (K3)

o Demonstrar clara rastreabilidade aos requisitos.
o Contedo de um Resultado Esperado
Traduzir Casos de Testes em uma especificao de procedimento de
teste bem estruturada em um nvel de detalhe relevante para os
testadores. (K3)
4.2
Escrever um plano de execuo para um conjunto de casos de teste

considerando a priorizao, as dependncias lgicas e tcnicas.(K3)
Categorias de tcnicas de modelagem de teste (K2)
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)
4.3
Tcnicas baseada em especificao ou Caixa Preta (K3)

Montar os casos de teste de um dado software utilizando as seguintes
tcnicas (K3)
o Partio de Equivalncia
o Anlises dos valores limites
o Tabela de Deciso
o Diagrama de Transio
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)
Verso 2005
Pgina 42 de 89
29-Jun-2006
para Qualificao de
Teste de Software
Compreender o conceito de Teste de Caso de Uso e seus benefcios.

(K2)
4.4 Tcnicas baseadas em estrutura interna do software ou

Caixa Branca (K3)
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: (K3)
o Teste de Comandos
o Teste de Deciso
Avaliar a completitude da cobertura de comando e deciso. (K3)
4.5
Tcnicas baseadas em experincia (K2)
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)
4.6
Escolhendo tcnicas de teste (K2)

Apresentar os fatores que influenciam na escolha da tcnica apropriada
para um problema particular como: tipo de sistema, riscos, requisitos do
usurio, modelos de caso de uso, modelos de requisitos ou
conhecimento dos testadores. (K2)
Verso 2005
Pgina 43 de 89
29-Jun-2006
4.1 Identificando as condies de testes e

projetando os casos de testes (K3)
para Qualificao de
Teste de Software
15 minutos
Palavras Chave
Casos de teste, especificao de caso de teste, condio de teste,
especificao de procedimento de teste, script de teste e rastreabilidade.
Conceito
O processo da identificao das condies de teste e modelagem de testes
consiste de certo nmero de passos:
Projetar os testes a partir da identificao das condies.
Especificar os casos de teste.
Especificar os procedimentos de testes.

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 modelagem 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 atividade de especificao, os casos de teste e os dados de teste
so elaborados e descritos em detalhe utilizando as tcnicas de modelagem de
teste. Um Caso de Teste consiste de um conjunto de valores de entrada, prcondies de execuo, resultados esperados e ps-condies de execuo,
desenvolvidos para cobrir certas condies de teste. O Padro para
Documentao de Teste de Software (IEEE 829) descreve o contedo da
especificao da modelagem 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 conseqncia 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.
Verso 2005
Pgina 44 de 89
29-Jun-2006
para Qualificao de
Teste de Software
A especificao do procedimento de teste o conjunto de casos de testes

colocados em uma ordem de execuo. O procedimento de teste (ou script de
teste manual) especifica a seqncia de aes para a um execuo de teste.
Se os testes so executados por uma ferramenta, a seqncia de aes
especificada por um script automatizado (que um procedimento automatizado
de teste).
Os vrios procedimentos de teste e scripts de testes automatizados formam um
seqncia de execuo de teste que define a ordem em que os procedimentos,
e/ou os scripts automatizados sero executados e quem os executar. A
seqncia de execuo de teste considera alguns fatores como testes de
regresso, priorizao, dependncias tcnicas e lgicas.
Verso 2005
Pgina 45 de 89
29-Jun-2006
4.2 Categorias das tcnicas de modelagem de

teste (K2)
para Qualificao de
Teste de Software
15 minutos
Palavras Chave
Tcnicas de caixa preta, tcnicas baseadas em experincia, tcnica baseadas
em especificao, tcnica baseadas em estrutura e tcnicas de caixa branca.
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 diferenciao clssica.
Tcnicas de 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, seja funcional ou no-funcional,
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. O Syllabus considera tcnicas baseadas
em especificao ou baseadas em experincia como caixa-preta e tcnicas
baseadas em estrutura como 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 modelagem.
A extenso da cobertura do cdigo 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.
o Conhecimento de testadores, desenvolvedores, usurios, outros
interessados (stakeholders) responsveis pelo software, seu uso e
ambiente.
o Conhecimento sobre defeitos provveis e sua distribuio.
Verso 2005
Pgina 46 de 89
29-Jun-2006
4.3 Tcnicas baseadas em especificao ou

Caixa-Preta (K3)
para Qualificao de
Teste de Software
120 minutos
Palavras-Chave
Anlise de valores limites, tabela de deciso, partio de equivalncia, teste de
transio de estados, teste de caso de uso.
4.3.1 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 tcnica de 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

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

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
Verso 2005
Pgina 47 de 89
29-Jun-2006
para Qualificao de
Teste de Software
de entrada e aes so declaradas de uma forma que possam ser entendidas,

como verdadeira ou falsa (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.
4.3.4 Teste de transio de estados

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 sob 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 seqncia tpica de status,
para cobrir todos os estados, para exercitar todas as transies, para exercitar
uma seqncia especfica de transies ou para 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

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.
Verso 2005
Pgina 48 de 89
29-Jun-2006
para Qualificao de
Teste de Software
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 2005
Pgina 49 de 89
29-Jun-2006
para Qualificao de
Teste de Software
4.4 Tcnicas baseadas em estrutura ou CaixaBranca (K3)
60 minutos
Palavras-Chave
Cobertura de cdigo, cobertura de deciso, cobertura de comando, teste
estrutural, teste baseado em estrutura, teste de caixa-branca.
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 Comandos

No teste de componente, cobertura de comando avaliado pela porcentagem
de comandos executveis que foram exercitados por um conjunto de casos de
testes. No teste de comandos deriva-se os casos de teste para executar
comandos especficos, normalmente para se aumentar a cobertura.
4.4.2 Teste e Cobertura de Deciso

Cobertura de deciso, tambm chamado de teste de ramificao, avaliado
pela porcentagem dos resultados da deciso (por exemplo, as opes
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. Cobertura de deciso mais
eficiente que cobertura de comandos: 100% da cobertura de deciso garante
100% da cobertura de comandos, mas no vice-versa.
Verso 2005
Pgina 50 de 89
29-Jun-2006
para Qualificao de
Teste de Software
4.4.3 Outras tcnicas baseadas na estrutura

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 2005
Pgina 51 de 89
29-Jun-2006
4.5 Tcnicas baseadas na experincia (K2)
para Qualificao de
Teste de Software
30 minutos
Palavras-Chave
Deduo de erros, teste exploratrio
Conceito
Possivelmente a tcnica mais amplamente aplicada a de supor (adivinhar)
onde esto os erros. Os testes derivam da intuio e conhecimento dos
testadores com 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. 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.
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, baseia-se nos objetivos de teste, e 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 2005
Pgina 52 de 89
29-Jun-2006
4.6 Escolhendo as tcnicas de teste (K2)
para Qualificao de
Teste de Software
15 minutos
Palavras-Chave
No h nenhum termo especfico.
Conceito
A escolha de qual tcnica utilizar vai 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.
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 2005
Pgina 53 de 89
29-Jun-2006
5. Gerenciamento de Teste (K3)
para Qualificao de
Teste de Software
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)
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)
5.2
Planejamento e estimativa do Teste (K2)
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 de teste e os procedimentos do teste de acordo com
Padro para Documentao de Teste de Software (IEEE 829). (K2)
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)
Diferenciar os objetivos do plano de teste de um projeto, para um nvel de

testes especfico (ex: testes de sistema), metas especficas (ex: teste de
usabilidade) e para execuo do teste.(K2)
Listar as tarefas de preparao e execuo de teste que precisam ser

planejadas.(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)
5.3
Controle e Monitorao do progresso do Teste (K2)
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 encontradas, corrigidos e testes
que passaram e falharam). (K1)
Verso 2005
Pgina 54 de 89
29-Jun-2006
5.4
5.5
para Qualificao de
Teste de Software
Sumarizar o objetivo e o contedo do relatrio de teste sumarizado de

acordo com o Padro de Documentao de Teste de Software (IEEE
829).(K2)
Gerenciamento de Configurao (K2)

Rever como a gerncia de configurao pode servir de suporte ao teste.
(K2)
Riscos e Teste (K2)
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)
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)
5.6
Gerenciamento de Incidente (K3)
Reconhecer o contedo do relatrio de incidente do Padro de

Documentao de Teste de Software (IEEE 829). (K1)
Preparar um relatrio de incidente cobrindo a observao de uma falha

durante os testes. (K3)
Verso 2005
Pgina 55 de 89
29-Jun-2006
5.1 Organizao do Teste (K2)
para Qualificao de
Teste de Software
30 minutos
Palavras - Chave
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:
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 infra-estrutura ou operaes em TI.
Verso 2005
Pgina 56 de 89
29-Jun-2006
para Qualificao de
Teste de Software
5.1.2 Tarefas do lder de teste e dos testadores (K1)

No 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, gerente de
desenvolvimento, gerente 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. Normalmente, o lder planeja, monitora e controla 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.
Agendar o teste
Montar um relatrio com base nas informaes obtidas durante o teste.

As tarefas tpicas de um testador podem ser:
Revisar e contribuir no planejamento dos testes.
Analisar, revisar e avaliar os requisitos de usurios, especificaes e

modelos para testabilidade.
Criar especificao de teste.
Verso 2005
Pgina 57 de 89
29-Jun-2006
para Qualificao de
Teste de Software
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 2005
Pgina 58 de 89
29-Jun-2006
para Qualificao de
Teste de Software
5.2 Organizao do Teste (K2)
50 minutos
Palavras-Chave
Critrio de entrada, critrio de sada, teste exploratrio, abordagem de teste,
nvel de teste, plano de teste, procedimento de teste e estratgia de teste.
5.2.1 Planejamento 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
Padro de Documentao de Teste de Software (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 do testes, mais informaes
estaro disponveis e mais detalhes podem ser includos no plano.
Planejamento do teste uma atividade contnua e feita 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:
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).
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.
Verso 2005
Pgina 59 de 89
29-Jun-2006
para Qualificao de
Teste de Software
5.2.3 Critrio de Sada (K2)

O objetivo do critrio de sada definir quando parar de testar. Por exemplo: ao
final de um nvel de teste ou quando um conjunto de testes tem um alvo
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, como os baseados na data de entrega do produto.
5.2.4 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:
Caracterstica 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.
Caracterstica 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 re-trabalho

necessria.
5.2.5 A Estratgia do Teste (abordagem de teste) (K2)

Uma maneira de classificar a abordagem do teste ou estratgia baseando-se
no ponto em que comea aparecer o volume de trabalho da modelagem de
teste.
Estratgia preventiva, na qual os testes so construdos o mais cedo

possvel.
Estratgia reativa, nas quais os teste so construdos aps o software e

/ou sistemas estarem prontos.
Estratgias ou abordagens tpicas incluem:
Verso 2005
Pgina 60 de 89
29-Jun-2006
para Qualificao de
Teste de Software
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.
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.
A escolha da estratgia do teste dever considerar o contexto, incluindo:
Risco de falha do projeto, perigo do produto em caso de falhas do

software a afetar as pessoas, ambiente e a empresa.
Experincia das pessoas nas tcnicas propostas, ferramentas e mtodos.
Os objetivos do teste, esforo e a misso da equipe de teste.
Aspectos regulamentares, tais como alteraes internas e externas no

processo de desenvolvimento.
A natureza do produto e do negcio.
Verso 2005
Pgina 61 de 89
29-Jun-2006
para Qualificao de
Teste de Software
5.3 Monitorao e Controle do Progresso do

Teste (K2)
20 minutos
Palavras-Chave
Densidade do defeito, taxa de falha, controle do teste, cobertura do teste,
monitorao do teste e relatrio do teste.
5.3.1 A 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 podem ser 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 testes (nmeros de teste executados, testes com

resultados ok e no ok).
Informaes dos defeitos (densidade do defeito, defeitos encontrados e

resolvidos, taxas de falha e resultado da re-execuo).
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 Padro de Documentao de
Teste de Software (IEEE 829).
As mtricas podem ser coletadas durante ou ao final do teste:
Verso 2005
Pgina 62 de 89
29-Jun-2006
para Qualificao de
Teste de Software
A adequao dos objetivos do teste com o nvel do teste.
A adequao da abordagem / estratgia do teste.
A eficincia dos testes referente a seus objetivos.
5.3.3 Controle do Teste (K2)

O controle do teste descreve uma orientao ou ao corretiva tomada como
um resultado de informaes e mtricas obtidas e relatadas. Aes podem
cobrir qualquer atividade do teste e qualquer atividade em um ciclo de vida de
um software.
Exemplos de controle de teste:
Re-priorizar os teste quando riscos so identificados.
Mudar o cronograma de acordo com disponibilidade do ambiente de

teste.
Definir um critrio de entrada para se iniciar o re-teste de bugs resolvidos

pelo desenvolvedor antes de aceit-lo em uma build.
Verso 2005
Pgina 63 de 89
29-Jun-2006
5.4 Gerenciamento de Configurao (K2)
para Qualificao de
Teste de Software
10 minutos
Palavras-Chave
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

ambigidade 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 2005
Pgina 64 de 89
29-Jun-2006
5.5 Riscos e Teste (K2)
para Qualificao de
Teste de Software
30 minutos
Palavras-Chave
Risco do produto, risco do projeto, riscos, 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 (K1, K2)

Riscos no projeto so os aqueles que comprometem a capacidade do projeto
no atender seus objetivos.
Problemas do fornecedor
Falhas de terceiros
Problemas contratuais
Fatores organizacionais:
Falta de conhecimento da equipe.
Reciclagem e treinamento pessoal.
Fatores polticos como:

o Problemas com testadores comunicando suas necessidades com
os resultados dos testes.
o 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:
o Problema na definio correta do requisito.
o At que ponto os requisitos podem ser satisfeitos dadas restries
diversas.
o A qualidade da modelagem, do cdigo e do testes.
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 Padro de Documentao de Teste de
Software (IEEE 829) requisita que os riscos e a contingncias devam ser
declaradas.
Verso 2005
Pgina 65 de 89
29-Jun-2006
para Qualificao de
Teste de Software
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 de produto, pois so
considerados riscos para a qualidade do produto final. Por exemplo:
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

confiana, usabilidade e performance).
(funcionalidade,
segurana,
Software que no cumpre com seus objetivos.

Risco usado para se decidir quando comear e onde dever se testar com
mais freqncia; 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 pr-ativas 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 interessados (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:
Estimar (e re-estimar periodicamente) o que poder dar errado (riscos).
Determinar quais os 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 2005
Pgina 66 de 89
29-Jun-2006
5.6 Gerenciamento de Incidente (K3)
para Qualificao de
Teste de Software
40 minutos
Palavras-Chaves
Registro de incidentes
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. Incidente 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 sob teste e o progresso do teste.
Prover idias para aprimorar o processo de testes.

Normalmente um testador ou revisor registram as seguintes informaes, no
caso de um incidente:
Data da emisso, autor, status e organizao.
Escopo, severidade e prioridade do incidente.
Referncias, incluindo a identificao da especificao do caso de teste

que revelou o problema.
Os detalhes de um relatrio de incidente podem incluir:
Resultados esperados e resultados atuais.
Data em que o incidente foi descoberto.
Identificao ou item de configurao do software ou sistema.
Processo do ciclo de vida do sistema ou software em que o incidente foi

descoberto.
Descrio da anomalia para permitir a resoluo.
Grau de impacto para os interessados (stakeholder)
Severidade do impacto no sistema.
Urgncia / Prioridade na correo.
Verso 2005
Pgina 67 de 89
29-Jun-2006
para Qualificao de
Teste de Software
Estado (status) do incidente (aberto, aceito, duplicado, aguardando

resoluo, aguardando re-teste ou fechado).
Concluso e recomendaes.
Comentrios gerais, tais como outras reas que podem ser afetadas por
uma mudana resultante de um incidente.
Mudana no histrico, como a seqncia de aes tomadas pela equipe

envolvida no projeto com respeito ao isolamento do incidente, reparo e
confirmao da resoluo.
A estrutura de um relatrio de incidente coberta pelo Padro de
Documentao de Teste de Software) IEEE 829 e conhecido de relatrio de
irregularidades (anomaly report).
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
5.4 Craig, 2002
5.5.2 Black, 2001 , IEEE 829
5.6 Black, 2001, IEEE 829
Verso 2005
Pgina 68 de 89
29-Jun-2006
6. Ferramentas de Suporte a Teste (K2)
para Qualificao de
Teste de Software
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)
Classificar diferentes tipos de ferramentas de acordo com a atividade de

do processo de teste. (K2)
Reconhecer ferramentas que apiam os desenvolvedores em seus

testes. (K1)
6.2 Uso efetivo de ferramentas: benefcios potenciais e riscos

(K2)
Resumir os benefcios e riscos potenciais da automao e das

ferramentas de suporte a teste. (K2)
Identificar as ferramentas de automao de testes e as tcnicas de

montagem de scripts incluindo as direcionadas a dados (data driven) e a
direcionada a palavras-chave (keywords driven). (K1)
6.3
Introduzindo uma ferramenta em uma organizao (K1)
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 2005
Pgina 69 de 89
29-Jun-2006
para Qualificao de
Teste de Software
6.1 Tipos de Ferramentas de Teste (K2)
45 minutos
Palavras-Chave
Ferramentas de gerenciamento de configurao, ferramenta de cobertura de
cdigo, ferramenta de depurao, controlador (driver), 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, ferramenta de gerenciamento de requisitos, efeito da monitorao
(probe effect), ferramentas de gerenciamento de requisitos, ferramenta de
suporte ao processo de reviso, ferramentas de segurana, ferramentas de
anlise esttica, ferramenta de teste de estresse, simulador (stub), ferramenta
de comparao de teste, ferramenta de preparao de dados, ferramenta de
modelagem de teste, ambiente preparado de testes (test harness), ferramentas
para execuo do teste, ferramentas para gerenciamento do teste, arcabouo
(framework) de teste de unidade.
6.1.1 Classificao das Ferramentas de Teste (K2)

H vrias ferramentas que suportam diferentes aspectos do teste. As
ferramentas so classificadas no Syllabus de acordo com a atividade do teste
que ela suporta.
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. Alguns fornecedores oferecem suporte somente para
um tipo de atividade, outros j oferecem uma sute, ou seja, um conjunto de
vrias ferramentas que provem suporte para muitas ou at mesmo todas as
atividades do teste.
Ferramentas de teste podem melhorar a eficincia do teste automatizando
tarefas repetitivas. Pode tambm melhorar a segurana do teste, por exemplo
automatizando grandes comparaes de dados ou simulando comportamento
do sistema ou software.
Alguns tipos de ferramentas de teste so intrusivas, ou seja, elas prprias
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 conseqncia
de uma ferramenta intrusiva conhecida como efeito de monitorao (probe
effect).
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.2 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
Verso 2005
Pgina 70 de 89
29-Jun-2006
para Qualificao de
Teste de Software
Ferramenta de Gerenciamento de Teste

As caractersticas das ferramentas de gerenciamento de teste so:
Dar suporte ao gerenciamento de testes e a suas atividades.
Fazer a interface entre as ferramentas de execuo, ferramentas de

gerenciamento de defeitos e ferramentas de gerenciamento de requisitos.
Controle de verso independente ou uma interface com o gerenciador de

configurao.
Dar suporte a rastreabilidade do teste, resultados, e incidentes aos

documentos de origem, como especificao de requisitos.
Registrar os resultados e gerar o relatrio de progresso do teste.
Anlise quantitativa (mtricas), relacionadas aos testes (ex: testes

executados e testes que passaram) e aos objetos de teste (ex: incidentes
levantados), visando fornecer informaes sobre o objeto de teste e para
controlar e melhorar o processo.
Ferramentas de Gerenciamento de Requisitos
Ferramentas de gerenciamento de requisitos armazenam, checam a
consistncia e ausncia de requisitos, permitem a priorizao de requisitos, e
permite que os testes sejam individualmente rastreveis com relao aos
requisitos, funes e/ou funcionalidades. A cobertura dos requisitos,
funcionalidade e funes por um conjunto de testes pode tambm ser
reportada.
Ferramentas de Gerenciamento de Incidentes
Esta ferramenta funciona como o repositrio e gesto dos incidentes (ex:
defeitos, falhas, problemas e anomalias) e suporte para gerenciar tais
incidentes incluindo:
Facilidade na priorizao dos incidentes
Facilidade na atribuio de tarefas (ex: corrigir o erro ou executar um

teste de confirmao).
Atribuio de status (rejeitado, pronto para teste, movido para prxima

release)
Estas ferramentas permitem que o progresso do incidente seja monitorado
durante o projeto. Muitas vezes provem o suporte para anlises estatsticas e
relatrios. So conhecidas tambm como ferramentas de rastreamento de
defeitos.
Ferramentas de Gerenciamento de Configurao
Ferramentas de gerenciamento de configurao no so estritamente
ferramentas de teste, mas so necessrias para manter o controle da verso
de diferentes builds de softwares e testes.
As Ferramenta de Gerenciamento de Configurao:
Armazenam todas as informaes sobre as verses dos softwares e

testware.
Permitem a rastreabilidade entre testware, software e outros produtos

relacionados.
Verso 2005
Pgina 71 de 89
29-Jun-2006
para Qualificao de
Teste de Software
So particularmente teis quando existem mltiplas configuraes de

ambiente (hardware / software) (ex: diferentes sistemas operacionais,
bibliotecas e compiladores, diferentes browsers ou diferentes
computadores.)
6.1.3 Ferramentas para testes estticos (K1)

Ferramentas para suporte ao processo de reviso
As ferramentas de suporte ao processo de reviso podem armazenar as
informaes sobre a reviso dos processos, comentrios, relatar os defeitos e
esforo, gerenciar as referncias para revisar as regras ou check-lists, e manter
o controle da rastreabilidade entre os documentos e o cdigo fonte. Pode
tambm ajudar na reviso online, muito comum quando as equipes 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.
Seus principais objetivos so:
Esforo na padronizao do cdigo.
Anlise da estrutura e dependncia.
Ajuda na compreenso do cdigo.

Estas ferramentas podem calcular as mtricas de um cdigo (por exemplo a
complexidade), o que pode contribuir com informaes valiosas para
planejamento ou anlise dos riscos.
Ferramentas de Modelagem (D)
Ferramentas de modelagem validam o modelo do software. Por exemplo na
modelagem de banco de dados pode ser verificado que h inconsistncias no
modelo de dados; outra ferramenta de modelagem pode encontrar defeitos em
modelos de declarao ou objetos. Estas ferramentas podem ajudar a gerar
casos de testes com base na modelagem.
O maior benefcio das ferramentas de anlise estticas e modelagens o fato
de encontrar defeitos no incio do processo de desenvolvimento. Como
resultado, o processo de desenvolvimento pode ser acelerado e melhorado em
virtude da diminuio de re-trabalho.
6.1.4 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. Este tipo de ferramenta
pode gerar resultados esperados tambm. Os testes gerados de um modelo de
estado ou objeto so teis para verificar a implementao do modelo no
software, mas so raramente suficientes para verificar todos os aspectos do
software ou sistema.
Outras ferramentas desta categoria podem ajudar no suporte da criao do
teste disponibilizando templates estruturados, algumas vezes chamados de test
Verso 2005
Pgina 72 de 89
29-Jun-2006
para Qualificao de
Teste de Software
frames, que geram testes ou simuladores de teste e, desta forma agilizam a

modelagem de teste.
Ferramentas para preparao de dados de teste (D)
Ferramentas que preparam os dados para testes manipulam a base de dados,
arquivos ou transmisso de dados, extraindo-os para serem utilizados em uma
determinada execuo do teste. O benefcio destas ferramentas assegurar
que a existncia de dados transferidos a um ambiente de teste feita de forma
a garantir a integridade destes dados.
6.1.5 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 semi-automaticamente, usando dados de entradas e
resultados esperados atravs de um script.
A linguagem de script torna possvel a manipulao o teste com o esforo
limitado, por exemplo, para repetir o teste com diferentes dados ou testar
diferente partes do sistema com passos similares. Geralmente estas
ferramentas incluem comparao dinmica e gera o log do teste para cada
execuo.
Ferramentas de execuo de testes tambm podem ser utilizadas para gravar
testes. Neste caso, elas so chamadas de ferramentas de captura de entradas
de testes. Capturar entradas durante teste exploratrio ou testes sem script
pode ser til para reproduzir ou documentar um teste, por exemplo, no caso de
ocorrncia de uma falha.
Ambiente preparado para testes (test harness)/ Ferramentas de teste de
unidade (D)
Estas ferramentas podem facilitar o teste de componente ou parte de um
sistema por simular o ambiente em que o objeto de teste ser executado. Isto
deve ser feito porque outros componentes do ambiente, ainda no esto
disponveis, sendo trocados por simuladores (stubs) e/ou controladores
(drivers), ou simplesmente fornecem um ambiente estvel e controlvel em que
qualquer falha possa ser localizada no objeto sob teste.
Um framework pode ser criado onde parte do cdigo, objeto, mtodo ou
funo, unidade ou componente pode ser executado, carregando o objeto a ser
testado e / ou dando o retorno daquele objeto. Isto pode ser feito fornecendo
meios artificiais para as entradas de teste, e/ou fornecendo simuladores para
tratar as sadas, no lugar do objeto real.
Ferramentas de harness podem tambm ser usada para prover a uma forma
de execuo, onde linguagem, sistema operacional e hardware devem ser
testados em conjuntos.
Elas podem ser chamadas de ferramentas de testes de unidade (framework)
quando o foco est no nvel de teste de componente. Este tipo de ferramenta
ajuda na execuo de testes de componentes em paralelo com a codificao
(construo do cdigo).
Comparadores
Verso 2005
Pgina 73 de 89
29-Jun-2006
para Qualificao de
Teste de Software
Os comparadores determinam as diferenas entre os arquivos, banco de dados

ou resultado de 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,
dependendo da tcnica de medio utilizada, do que for medido e a linguagem.
Ferramenta de cobertura de cdigo mede a porcentagem de estruturas de
cdigo que so exercitados (comandos, decises, ramos, mdulos e chamada
de funes). Estas ferramentas demonstram o quanto foi coberta a estrutura
por um dado conjunto de testes.
Ferramentas de Segurana
Ferramentas de segurana verificam a vulnerabilidade do computador
infeco de vrus e a recusa de ataques. Um firewall, por exemplo, no uma
ferramenta de teste, mas pode ser usada para fazer teste de segurana. Outras
ferramentas de segurana estressam os sistemas procurando pontos de
vulnerabilidades.
6.1.6 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 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, carga e estresse
Ferramenta de teste de performance monitora e relata como um sistema se
comporta sob uma variedade de condies simuladas. Elas simulam a carga de
um banco de dados, aplicao ou sistema, assim como numa rede ou servidor.
As ferramentas so freqentemente nomeadas de acordo com o que ser
medido. Por exemplo, para carga ou estresse, as ferramentas so conhecidas
como ferramentas de carga e estresse. So muitas vezes baseadas na
automatizao da execuo dos testes controlada por parmetros.
Ferramentas de monitorao
Ferramentas de monitorao no so estritamente ferramentas de teste, mas
provem informaes que podem ser utilizadas para o propsito dos testes,
quando no h outros meios para se obter estas informaes.
Ferramenta de monitorao analisa continuamente, verifica e reporta a
utilizao de recursos especficos do sistema, e alerta para possveis
problemas nos servios. Ela armazena as informaes sobre a verso e build
do software e testware e permite a rastreabilidade.
6.1.7 Ferramenta de suporte para reas de aplicaes especficas

(K1)
Podem haver especializaes dos exemplos de ferramentas apresentadas
acima, para o uso em um tipo particular de aplicao. Por exemplo, h
Verso 2005
Pgina 74 de 89
29-Jun-2006
para Qualificao de
Teste de Software
ferramentas de teste de performance especificamente para aplicaes Web,

ferramentas de anlise esttica para plataformas especficas de
desenvolvimento e ferramentas de anlises dinmicas para testar aspectos
especficos de teste de segurana.
Ferramentas comerciais normalmente so direcionadas para reas de
aplicao especficas (ex: software embarcado).
6.1.8 Ferramentas de suporte utilizando outras ferramentas

As ferramentas de testes apresentadas aqui no so os nicos tipos e
ferramentas usadas pelos testadores. Eles podem usar planilhas, documentos
do Word, SQL e ferramentas de depurao (D), por exemplo.
Verso 2005
Pgina 75 de 89
29-Jun-2006
6.2 Uso Efetivo das Ferramentas: Riscos e
para Qualificao de
Teste de Software
20 minutos
Benefcios em potenciais (K2)

Palavras-Chave
Teste direcionado a dados, Teste direcionado a palavras-chaves, linguagem de
scripts.
6.2.1 Potenciais benefcios e riscos de ferramentas de suporte ao

teste (para todas as ferramentas) (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 de benefcios potenciais com o uso de
ferramentas de teste, mas tambm riscos:
Riscos potenciais 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

comportamento do sistema)
(ex:
medidas
estticas,
cobertura
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 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).
6.2.2 Consideraes especiais para alguns tipos de ferramentas

(K1)
Ferramenta 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 2005
Pgina 76 de 89
29-Jun-2006
para Qualificao de
Teste de Software
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 direcionada a dados (data-driven), separa os dados de
entrada dos testes, normalmente em planilhas, utilizando scripts mais
genricos que possam ler os dados do teste e fazer o mesmo teste com dados
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 direcionada a palavras-chave (keyword-driven), 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 palavraschaves, 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.
Ferramenta para teste de performance
Ferramentas de teste de performance precisam de especialistas para ajudar a
projetar os testes e interpretar os resultados.
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 2005
Pgina 77 de 89
29-Jun-2006
6.3 Implementando uma Ferramenta na
para Qualificao de
Teste de Software
15 minutos
Organizao (K1)
Palavras-Chave
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.
A prova de conceito para avaliar a funcionalidade e determinar se a

ferramenta atende os objetivos.
Avaliao do fornecedor (incluindo treinamento, suporte e aspectos

comerciais).
Identificao dos requisitos internos para acompanhamento (mentoring e

coaching) no uso da ferramenta.
A prova de conceito poder ser feita atravs um pequeno projeto piloto, de
modo a minimizar os impactos caso no obtenha sucesso.
Um projeto piloto 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 permanncia de uma ferramenta em uma
organizao incluem:
Fazer o revezamento na utilizao da ferramenta para os recursos da

empresa (rea de TI) de forma incremental.
Adaptar e aprimorar o processo para combinar com o uso da ferramenta.
Providenciar treinamentos para novos usurios.
Definir um guia de usurios (de acordo com o processo estabelecido).
Implementar um modo de aprender lies com o uso da ferramenta.
Monitorar o uso e os benefcios da ferramenta.

Verso 2005
Pgina 78 de 89
29-Jun-2006
para Qualificao de
Teste de Software
Referncias
6.2.2 Buwalda, 2001, Fewster, 1999
6.3 Fewster, 1999
Verso 2005
Pgina 79 de 89
29-Jun-2006
para Qualificao de
Teste de Software
7. Referncias
Padres
ISTQB Glossrio de termos usados no Teste de Software Verso 1.0
[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] IEEE Std 829 (1998/2005) IEEE Standard for Software Test
Documentation (currently
under revision)
Ver sees 2.3, 2.4, 4.1, 5.2, 5.3, 5.5, 5.6
[IEEE 1028] IEEE Std 1028 (1997) IEEE Standard for Software Reviews
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: New
York
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:
Verso 2005
Pgina 80 de 89
29-Jun-2006
para Qualificao de
Teste de Software
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 2005
Pgina 81 de 89
29-Jun-2006
para Qualificao de
Teste de Software
Apndice A Syllabus Background

Histrico deste documento
Este documento foi preparado durante os anos de 2004 e 2005 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 Fundao da Certificao Internacional de
Teste de Software, o primeiro nvel de qualificao internacional aprovado pelo
ISQTB (www.istqb.org). No momento em que foi escrito (2005), os membros do
ISTQB incluam: ustria, Dinamarca, Finlndia, Frana, Alemanha, ndia, Israel,
Japo, Corea, Noruega, Polnia, Portugal, Espanha, Sucia, Sua, Holanda,
Reino Unido e Estados Unidos.
Objetivos da Fundao do Certificado de Qualificao
Obter reconhecimento o teste como uma especializao profissional e

essencial da engenharia de software.
Prover um padro framework para desenvolvimento da carreira dos

testadores.
Capacitar profissionalmente testadores qualificados a serem

reconhecidos por empresrios, clientes e colegas, e criar um perfil do
testador.
Promover uma boa e consistente prtica 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 de ganhos e vantagens comerciais sob seus
competidores por propagar suas prpria poltica 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 trocarem conhecimento entre as comisses mais

facilmente.
Permitir que projetos multinacionais / internacionais tenham uma

compreenso comum do empreendimento do teste.
Verso 2005
Pgina 82 de 89
29-Jun-2006
para Qualificao de
Teste de Software
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 qualificao reconhecida na sua linguagem

nativa.
Permitir o compartilhamento de conhecimentos e recursos entre os

pases.
Prover o reconhecimento internacional de testadores e desta qualificao

junto a participao de muitos pases.
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 mnimo conhecimento em qualquer desenvolvimento de

software ou teste de software, seis meses de experincias em um
sistema ou teste de aceite ou desenvolvedor de software.
Fazer o curso que autorizado pelos padres do ISTQB (por uma

comisso nacional reconhecida)
Histrico da Certificao do Fundamento 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 de 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 fosse criado, ser considerado
equivalente ao certificado internacional. O Certificado de Fundamentos no
expira e no precisa ser renovado. A data em que foi obtido ser demonstrado
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.
Verso 2005
Pgina 83 de 89
29-Jun-2006
para Qualificao de
Teste de Software
Dentre as obrigaes das comisses dos pases esto a autorizao para

prover treinamentos e a ministrar os exames.
Verso 2005
Pgina 84 de 89
29-Jun-2006
para Qualificao de
Teste de Software
Apndice B Objetivos de Estudos / 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 estudos.
Nvel 1: Relembrar (K1)

O candidato reconhecer, relembrar e retomar um termo ou conceito.
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 e pode resumir, comparar, classificar e dar exemplos
para os conceitos de teste.
Exemplos
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.
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 2005
Pgina 85 de 89
29-Jun-2006
para Qualificao de
Teste de Software
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 2005
Pgina 86 de 89
29-Jun-2006
para Qualificao de
Teste de Software
Apendice C Regras aplicadas ao ISTQB Fundation

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 de 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 ambigidades) 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)
L02. 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)
Verso 2005
Pgina 87 de 89
29-Jun-2006
para Qualificao de
Teste de Software
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)
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.
Uma lista de livros sobre teste de software recomendada para estudos em
paralelo com este syllabus. A principal lista de livros parte da seo de
Referencias
Verso 2005
Pgina 88 de 89
29-Jun-2006
para Qualificao de
Teste de Software
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 pode
tambm ser utilizados e referenciado, mas no far parte do exame.
As reas especficas do syllabus requerem exerccios prticos, tais como:
4.3
Tcnica baseada em especificao (Caixa Preta)
Trabalhos prticos (exerccios curtos) devem ser includos cobrindo as quatro

tcnicas: parties de equivalncias, anlise dos valores limites, teste da tabela
de deciso e teste de transio de estado. As leituras e exerccios relacionados
a estas tcnicas sero baseados nas referncias fornecidas para cada tcnica.
4.4
Tcnica baseada em estrutura ou (Caixa Branca)
Trabalhos prticos (exerccios curtos) devem includos para avaliar se os testes

atingiram ou no, a cobertura de 100% das declaraes e 100% das decises,
tanto quanto a construo dos casos de testes para um dado controle de fluxo.
5.6
Gerenciamento de incidente
Trabalhos prticos (exerccios curtos) devem includos para cobrir e escrever

/ou avaliar um relatrio de incidentes.
Verso 2005
Pgina 89 de 89
29-Jun-2006

LIVRO Base de Conhecimento em Teste de Software PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

LIVRO Base de Conhecimento em Teste de Software PDF

Încărcat de

Drepturi de autor:

Formate disponibile

Base de Conhecimento

Comisso Internacional para Qualificao de Teste

Base de Conhecimento para Certificao em Teste

Comisso Internacional para Qualificao de Teste de Software

Base de Conhecimento para Certificao em Teste

29-Junho-2006 Traduo para portugus do Brasil

Certified Tester Foundation Level Syllabus

ASQF Syllabus Foundation Level Version 2.2

ISEB Software Testing Foundation Syllabus

Comisso Internacional para Qualificao de Teste de Software

Base de Conhecimento para Certificao em Teste

Porque necessrio testar? (K2) ................................................................. 11

O que teste? (K2)....................................................................................... 13

A Psicologia do Teste (K2) ........................................................................... 20

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

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

2.1.1 Modelo V (K2) .......................................................................................................... 24

Teste de Componente (K2) ..................................................................................... 26

Tipos de Teste: o alvo do teste..................................................................... 30

Teste de Manuteno ................................................................................... 33

Tcnicas Estticas (K2)............................................................................. 34

Nveis de Teste (K2) ..................................................................................... 26

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

Anlise Esttica por Ferramentas (K2) ......................................................... 40

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

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

Comisso Internacional para Qualificao de Teste de Software

Base de Conhecimento para Certificao em Teste

4.3.5 Teste de Caso de Uso ............................................................................................. 48

Tcnicas baseadas em estrutura ou Caixa-Branca (K3) .............................. 50

4.4.1 Teste e Cobertura de Comandos ............................................................................ 50

Tcnicas baseadas na experincia (K2) ....................................................... 52

Gerenciamento de Teste (K3) ................................................................... 54

Organizao do Teste (K2) ........................................................................... 56

5.1.1 A organizao e o teste independente (K2) ............................................................ 56

Organizao do Teste (K2) ........................................................................... 59

Monitorao e Controle do Progresso do Teste (K2).................................... 62

5.3.1 A Monitorao do Progresso do Teste (K1) ............................................................ 62

Gerenciamento de Configurao (K2) .......................................................... 64

5.5.1 Riscos no Projeto (K1, K2) ...................................................................................... 65

Gerenciamento de Incidente (K3) ................................................................. 67

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

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

Uso Efetivo das Ferramentas: Riscos e Benefcios em potenciais (K2) ....... 76

6.2.1 Potenciais benefcios e riscos de ferramentas de suporte ao teste (para todas as

Implementando uma Ferramenta na Organizao (K1)................................ 78

Comisso Internacional para Qualificao de Teste de Software

Base de Conhecimento para Certificao em Teste

Comisso Internacional para Qualificao de Teste de Software

Base de Conhecimento para Certificao em Teste

Base de Conhecimento para Certificao em Teste de Software

Objetivos de aprendizagem / nveis de conhecimento

K1: relembrar, reconhecer, retomar;

K2: compreender, explicar, dar justificativas, comparar, classificar,

Comisso Internacional para Qualificao de Teste de Software

Base de Conhecimento para Certificao em Teste

Objetivos de instruo geral descrevendo as intenes da Base de

Uma lista de informaes para o treinamento, incluindo uma descrio e

Objetivos de estudos para cada rea de conhecimento, descrevendo os

Uma lista de termos que os estudantes precisam estar aptos a relembrar

Uma explicao dos conceitos principais a serem ensinados, incluindo as

Comisso Internacional para Qualificao de Teste de Software

Base de Conhecimento para Certificao em Teste