PSTQB SyllabusFoundation v2011 PDF

Programa de Certificao
de Testador (Tester) de Nvel

Foundation
Verso 2011
International Software Testing Qualifications Board
Anuncio sobre Direitos de Autor

Este documento pode ser copiado na integra ou de forma parcial, se a fonte for identificada.
Copyright O International Software Testing Qualifications Board (daqui em diante chamado de
ISTQB) ISTQB uma marca registada do International Software Testing Qualifications Board,
de Testador (Tester) de Nvel Foundation
Copyright 2010 os autores da atualizao de 2010 (Thomas Mller (presidente), Armin Beer,
Martin Klonk, Rahul Verma)
Copyright 2007 os autores da atualizao de 2007 (Thomas Mller (presidente), Dorothy Graham,
Debra Friedenberg e Erik van Veendendaal)
Copyright 2005, os autores (Thomas Mller (presidente), Rex Black, Sigrid Eldh, Dorothy Graham,
Klaus Olsen, Maaret Pyhjrvi, Geoff Thompson e Erik van Veendendaal).
Todos os direitos reservados.
Os autores faro a transferncia dos direitos para o International Software Testing Qualifications
Board (ISTQB). Os autores (como atuais donos dos direitos) e o ISTQB (como futuro possuidor de
tais direitos) acordaram sobre as seguintes condies de uso:
1) Qualquer individuo ou empresa de formao pode usar este Programa como base para um
curso de formao sempre que os autores e o ISTQB sejam apresentados como a fonte
utilizada e como proprietrios dos direitos sobre este Programa, qualquer anuncio sobre tal
curso de formao dever mencionar o Programa apenas aps a sua submisso a uma
acreditao oficial de materiais de formao perante um Conselho Nacional reconhecido pelo
ISTQB.
2) Qualquer individuo, ou grupo de indivduos pode usar este Programa como base para artigos,
livros ou quaisquer outros escritos derivados desde que os autores assim como o ISTQB sejam
dados a conhecer como a sua fonte, assim como os donos dos direitos deste Programa.
3) Qualquer Conselho Nacional oficialmente reconhecido pelo ISTQB pode traduzir este Programa
e licencia-lo (ou a sua traduo) a outras entidades.
Verso 2011
Pgina 2 de 85
01-Abr-2011
Histrico de Revises
Verso
Data
Comentrios
ISTQB 2011
Efetivo a 01-Abril-2011
ISTQB 2010
Efetivo a
30-Maro-2010
ISTQB 2007
01-Maio-2007
ISTQB 2005
01-Julho-2005
ASQF V2.2
Julho-2003
ISEB V2.0
25-Fevereiro-1999
Programa de Certificao de Testador (Tester) de

Nvel Foundation, lanamento de verso de
manuteno ver Apndice E Notas de
Lanamento
Lanamento Programa 2010
Lanamento Programa 2007
Nvel Foundation
Programa ASQF Nvel Foundation Verso 2.2
Lehrplan Grundlagen des Software-testens
ISEB Software Testing Foundation Syllabus V2.0
25 Fevereiro 1999
Verso 2011
Pgina 3 de 85
01-Abr-2011
ndice
Objetivo deste documento.................................................................................................................. 8

O Testador (Tester) Certificado de Nvel Foundation em Testes de Software .................................. 8
Objetivos de Aprendizagem/Nvel Cognitivo de Conhecimento......................................................... 8
O Exame............................................................................................................................................. 8
Acreditao......................................................................................................................................... 8
Nvel de Detalhe ................................................................................................................................. 9
Como est o Programa Organizado................................................................................................... 9
1. Fundamentos de Testes (K2)......................................................................................................... 10
1.1. Porque Precisamos de Testes (K2).........................................................................................11
1.1.1 Contexto de Sistemas de Software (K1) .........................................................................11
1.1.2. Causas de Defeitos de Software (K2) .............................................................................11
1.1.3. Funo dos Testes no Desenvolvimento, Manuteno e Operaes de Software (K2).11
1.1.4. Testes e Qualidade (K2) ..................................................................................................11
1.1.5. Qual a Quantidade Suficiente de Testes? (K2) .............................................................. 12
1.2. O que so os Testes? (K2)..................................................................................................... 13
1.3. Os Sete Princpios dos Testes (K2) ....................................................................................... 14
1.4. Processo de Teste Fundamental (K1) .................................................................................... 15
1.4.1. Planeamento e Controlo de Testes (K1) ........................................................................ 15
1.4.2. Anlise e Conceo de Testes (K1) ............................................................................... 15
1.4.3. Implementao e Execuo de Testes (K1) ................................................................... 16
1.4.4. Avaliao de Critrio de Sada e Relatrios (K1)........................................................... 16
1.4.5. Atividades de Fecho da Fase de Testes (K1)................................................................. 17
1.5. A Psicologia dos Testes (K2).................................................................................................. 18
1.6 Cdigo de tica ...................................................................................................................... 20
2. Testes atravs do Ciclo de Vida de Software (K2) ........................................................................ 21
2.1. Modelos de Desenvolvimento de Software (K2) .................................................................... 22
2.1.1. Modelo em V (Modelo Sequencial de Desenvolvimento) (K2)....................................... 22
2.1.2. Modelos de Desenvolvimento Iterativo-incremental (K2)............................................... 22
2.1.3. Testes dentro de um Modelo de Ciclo de Vida (K2) ....................................................... 22
2.2. Nveis de Teste (K2) ............................................................................................................... 24
2.2.1. Testes de Componentes (K2) ......................................................................................... 24
2.2.2. Testes de Integrao (K2) .............................................................................................. 25
2.2.3. Testes de Sistema (K2) .................................................................................................. 26
2.2.4 Testes de Aceitao (K2)................................................................................................ 26
Tipos de Teste (K2) ................................................................................................................ 29
2.3.1. Testes de Funo (Testes Funcionais) (K2) ................................................................... 29
2.3.2. Testes a Caractersticas de Software No funcionais (Testes No Funcionais) (K2) .... 29
2.3.3. Testes Estrutura/Arquitetura do Software (Testes Estruturais) (K2)............................ 30
2.3.4. Testes Relacionados com Alteraes: Reteste e Testes de Regresso (K2) ................ 30
2.4. Testes de Manuteno (K2) ................................................................................................... 31
3. Tcnicas Estticas (K2) ................................................................................................................. 33
3.1. Tcnicas Estticas e o Processo de Teste (K2)..................................................................... 34
3.2. Processo de Reviso (K2) ..................................................................................................... 35
3.2.1. Atividades de uma Reviso Formal (K1) ..................................................................... 35
2.3
3.2.2 Funes e Responsabilidades (K1) ............................................................................... 36

3.2.3. Tipos de Reviso (K2) .................................................................................................... 36
3.2.4. Fatores de Sucesso para as Revises (K2) ................................................................... 37
3.3. Anlise Esttica via Ferramentas (K2)................................................................................... 39
4. Tcnicas de Conceo de Testes (K4) .......................................................................................... 40
Verso 2011
Pgina 4 de 85
01-Abr-2011
4.1.
4.2.
4.3.
O Processo de Desenvolvimento de Testes (K3) .................................................................. 42

Categorias das Tcnicas de Conceo de Testes (K2) ......................................................... 43
Tcnicas Baseadas nas Especificaes ou Caixa-Preta (K3) ............................................... 44
4.3.1
4.3.2.
4.3.3.
4.3.4.
Particionar por Equivalncias (K3) ................................................................................. 44

Anlise de Valor Fronteira (K3) ...................................................................................... 44
Testes baseados em Tabelas de Deciso (K3) .............................................................. 44
Testes de Transio de Estados (K3)............................................................................. 45
4.3.5 Testes de Casos de Uso (K2)......................................................................................... 45

4.4. Tcnicas Baseadas na Estrutura ou Caixa-Branca (K4)..................................................... 46
4.4.1. Testes de Instruo e sua Cobertura (K4)...................................................................... 46
4.4.2. Testes de Deciso e sua Cobertura (K4) ....................................................................... 46
4.4.3. Outras Tcnicas baseadas na Estrutura (K1) ................................................................ 46
4.5. Tcnicas baseadas na Experincia (K2) ............................................................................... 48
4.6 Escolher as Tcnicas de Teste (K2)....................................................................................... 49
5. Gesto de Testes (K3) ................................................................................................................... 50
5.1. Organizao de Testes (K2)................................................................................................... 52
5.1.1. Organizao e Independncia de Testes (K2) ............................................................... 52
5.1.2. Tarefas do Lder de Teste e Testador (tester) (K1) ......................................................... 52
5.2. Estimativa e Planeamento de Testes (K3) ............................................................................. 54
5.2.1. Planeamento de Testes (K2) .......................................................................................... 54
5.2.2. Atividades de Planeamento de Testes (K3) ................................................................... 54
5.2.3
5.2.4.
Critrios de Entrada (K2)................................................................................................ 54

Critrios de Sada (K2) ................................................................................................... 55
5.2.5 Estimativa de Teste (K2)................................................................................................. 55

5.2.6. Estratgia de Teste, Abordagem de Teste (K2) .............................................................. 55
5.3. Monitorizao e Controlo de Progresso de Testes (K2) ........................................................ 57
5.3.1. Monitorizao do Progresso de Testes (K1) .................................................................. 57
5.3.2. Relatrio de Testes (K2) ................................................................................................. 57
5.3.3 Controlo de Testes (K2).................................................................................................. 57
5.4. Gesto de Configuraes (K2)............................................................................................... 59
5.5. Riscos e Testes (K2) .............................................................................................................. 60
5.5.1
Riscos de Projeto (K2).................................................................................................... 60
5.5.2 Riscos de Produto (K2) .................................................................................................. 60

5.6. Gesto de Incidentes (K3) ..................................................................................................... 62
6. Ferramentas de Suporte aos Testes (K2) ...................................................................................... 64
6.1
Tipos de Ferramentas de Teste (K2)...................................................................................... 65

6.1.1
Ferramentas de Suporte aos Testes (K2) ...................................................................... 65
6.1.2
Classificao de Ferramentas de Teste (K2) ................................................................. 66
6.1.3 Ferramentas de Suporte aos Testes e sua Gesto (K1) ............................................. 66

6.1.4. Ferramentas de Suporte aos Testes Estticos (K1).......................................................... 66
6.1.5
6.1.6.
Ferramentas de Suporte Especificao de Teste (K1)................................................ 67

Ferramentas de Suporte Execuo de Testes e Registo (Logging) (K1).................... 67
6.1.7
Ferramentas de Suporte ao Desempenho e Monitorizao (K1)................................... 68
6.1.8 Ferramentas de Suporte a Necessidades Especficas de Teste (K1)............................ 68

6.2. Uso efetivo de Ferramentas: Potenciais Vantagens e Riscos (K2) ....................................... 69
6.2.1
Verso 2011
Potenciais Vantagens e Riscos do uso de Ferramentas de Suporte aos Testes (para

todas as ferramentas) (K2)............................................................................................. 69
Pgina 5 de 85
01-Abr-2011
6.2.2 Consideraes Especiais para alguns Tipos de Ferramentas (K1) ............................... 69

6.3 Introduzir uma Ferramenta na Organizao (K1) .................................................................. 71
7. Referncias .................................................................................................................................... 72
Normas ............................................................................................................................................. 72
Livros ................................................................................................................................................ 72
8. Apndice A Origem do Syllabus ................................................................................................. 74
Histrico deste Documento .............................................................................................................. 74
Objetivos da Qualificao de Certificao de nvel Foundation....................................................... 74
Objetivos da Qualificao Internacional (adaptado da reunio do ISTQB em Sollentuna, novembro
2001)................................................................................................................................................. 74
Requisitos de Acesso a esta Qualificao ....................................................................................... 75
Perfil e Histria do Certificado de nvel Foundation em Testes de Software................................... 75
9. Apndice B Objetivos de Aprendizagem/Nvel Cognitivo de Conhecimento.............................. 76
Nvel 1: Lembrar (K1) ....................................................................................................................... 76
Nvel 2: Compreender (K2)............................................................................................................... 76
Nvel 3: Aplicar (K3).......................................................................................................................... 76
Nvel 4: Analisar (K4)........................................................................................................................ 77
10. Apndice C Regras aplicadas ao ISTQB.................................................................................... 78
Programa de nvel Foundation ......................................................................................................... 78
10.1.1 Regras Gerais ....................................................................................................................... 78
10.1.2 Contedos Atuais .................................................................................................................. 78
10.1.3 Objetivos de Aprendizagem .................................................................................................. 78
10.1.4 Estrutura Global..................................................................................................................... 78
11. Apndice D - Aviso s Entidades Formadoras .............................................................................. 80
12. Apndice E Notas de Lanamento do Programa ....................................................................... 81
13. ndice remissivo ............................................................................................................................. 83
Verso 2011
Pgina 6 de 85
01-Abr-2011
Agradecimentos
Equipa de Trabalho do International Software Testing Qualifications Board de nvel Foundation
(Edio 2011): Thomas Mller (presidente), Debra Friedenberg. A equipa nuclear agradece equipa
de reviso (Dan Almog, Armin Beer, Rex Black, Julie Gardiner, Judy McKay, Tuula Pkknen, Eric
Riou du Cosquier, Hans Schaefer, Stephanie Ulrich, Erik van Veendendaal), assim como a todos os
Conselhos Nacionais pelas sugestes para a verso atual deste programa.
(Edio 2010): Thomas Mller (presidente), Rahul Verma, Martin Klonk e Armin Beer. A equipa
nuclear agradece equipa de reviso (Rex Black, Mette-Bruhn Pederson, Debra Friedenberg, Klaus
Olsen, Tuula Pkknen, Meile Posthuma, Hans Schaefer, Stephanie Ulrich, Pete Williams, Erik van
Veendendaal), assim como a todos os Conselhos Nacionais pelas sugestes para a verso atual
deste programa.
(Edio 2007): Thomas Mller (presidente), Dorothy Graham, Debra Friedenberg, e Erik van
Veendendaal e equipa de reviso (Hans Schaefer, Stephanie Ulrich, Meile Posthuma, Anders
Pettersson, e Wonil Kwon) e a todos os Conselhos Nacionais pelas suas sugestes.
(Edio 2005): Thomas Mller (presidente), Rex Black, Sigrid Eldh, Dorothy Graham, Klaus Olsen,
Maaret Pyhjrvi, Geoff Thompson, Erik van Veendendaal e equipa de reviso assim como a todos
os Conselhos Nacionais pelas suas sugestes.
Verso 2011
Pgina 7 de 85
01-Abr-2011
Introduo ao Programa
Objetivo deste documento
Este documento consiste no programa base para a Qualificao Internacional em Testes de
Software no nvel Foundation. O ISTQB (International Software Testing Qualifications Board)
disponibiliza o mesmo aos Conselhos Nacionais para que estes acreditem entidades formadoras
assim como para que possam criar a partir deste as questes para os exames na lngua local. As
entidades formadoras devero determinar os mtodos de ensino mais adequados bem como
produzir todo o material didtico a fim de obter acreditao. Este programa pretende ajudar os
candidatos na preparao para o exame de certificao. Mais informao sobre o histrico e perfil
deste programa poder ser encontrada no Apndice A.
O Testador (Tester) Certificado de Nvel Foundation em Testes de

Software
A qualificao de nvel Foundation destina-se a qualquer indivduo envolvido em testes de software,
independentemente da funo desempenhada, tais como: testadores (testers), analistas de testes,
engenheiros de testes, consultores de testes, gestores de testes, testadores (testers) de aceitao
de utilizador e programadores. A qualificao de nvel Foundation tambm sugerida para quem
quer obter conhecimentos bsicos em testes de software, tais como gestores de projeto, gestores de
qualidade, gestores de desenvolvimento de software, analistas de negcio, diretores de TI e
consultores de gesto. Os detentores da certificao de nvel Foundation podero evoluir para uma
qualificao de nvel superior em testes de software.
Objetivos de Aprendizagem/Nvel Cognitivo de Conhecimento

Os objetivos de aprendizagem esto referenciados para cada seco deste programa e
classificados da seguinte forma:
o K1: lembrar, reconhecer, recordar.
o K2: compreender, explicar, justificar, comparar, classificar, categorizar, dar exemplos,
resumir.
o K3: aplicar, usar.
o K4: analisar.
Mais detalhes e exemplos de objetivos de aprendizagem so apresentados no Apndice B.
Todos os termos que figurem em Termos, logo aps o ttulo de cada captulo, devem ser
lembrados (K1), mesmo que no sejam mencionados explicitamente nos objetivos de
aprendizagem.
O Exame
O exame da certificao de nvel Foundation tem por base este programa. As respostas s questes
de exame podem requerer o uso de material includo nas vrias seces deste programa. Todas as
seces do programa so passiveis de avaliao no exame.
O formato do exame de escolha mltipla.
Os exames podem ser considerados como parte de um curso de formao acreditado ou efetuados
de forma independente (p.ex. num centro de exames ou exame pblico). Para efetuar o exame no
obrigatrio que o candidato tenha frequentado um curso de formao acreditado.
Acreditao
Um Conselho Nacional do ISTQB pode acreditar entidades formadoras, cujo material de curso siga
este programa. As entidades formadoras devem obter orientaes de acreditao do conselho ou
Verso 2011
Pgina 8 de 85
01-Abr-2011
rgo do mesmo que realiza a acreditao. Um curso acreditado reconhecido como estando de
acordo com este programa, e permitido que exista um exame do ISTQB como parte desse mesmo
curso.
Mais informao para entidades formadoras apresentada no Apndice D.
Nvel de Detalhe
O nvel de detalhe deste programa normaliza o ensino e exame ao nvel internacional. Para tal, o
programa consiste em:
o
o
o
o
o
Objetivos gerais de instruo descrevendo a inteno do nvel Foundation

Lista de informao para ensino, incluindo uma descrio e referncias a fontes adicionais
se necessrio.
Objetivos de aprendizagem para cada rea de conhecimento, descrevendo os resultados
relativos aprendizagem cognitiva e de mentalidade a alcanar.
Lista de termos que o formando deve ser capaz de recordar e compreender.
Descrio dos principais conceitos de ensino, incluindo fontes como a literatura ou as
normas relevantes.
O contedo programtico no uma descrio exaustiva da rea de conhecimento de testes de

software, reflete antes o nvel de detalhe que deve ser abrangido em cursos de formao de nvel
Foundation.
Como est o Programa Organizado

Existem seis captulos principais O ttulo principal de cada um mostra o nvel mais elevado de
objetivos de aprendizagem cobertos pelo mesmo e especifica a sua durao. Por exemplo:
2. Testes atravs do Ciclo de Vida de Software (K2)
115 minutos
Este ttulo mostra que o captulo 2 tem objetivos de aprendizagem K1 (assumido quando um nvel
mais elevado mostrado) e K2 (mas no K3), e destinado a 115 minutos de ensino das matrias
desse captulo. Dentro de cada captulo existem vrias seces. Cada seco ter tambm os seus
objetivos de aprendizagem e a respetiva durao necessria. Subseces sem durao tm o seu
tempo includo na durao da seco.
Verso 2011
Pgina 9 de 85
01-Abr-2011
1. Fundamentos de Testes (K2)
155 minutos
Objetivos de Aprendizagem para Fundamentos de Testes

Estes objetivos identificam o que o formando dever ser capaz de fazer aps a concluso de cada
mdulo.
1.1.. Porque precisamos de Testes? (K2)

LO-1.1.1.
LO-1.1.2.
LO-1.1.3.
LO-1.1.4.
LO-1.1.5.
Descrever e exemplificar a forma como um defeito de software pode causar danos a

pessoas, ao ambiente ou s empresas (K2).
Distinguir entre a causa raiz de um defeito e os seus efeitos (K2).
Justificar, exemplificando, por que so necessrios os testes (K2).
Descrever por que faz o teste parte da garantia de qualidade e apresentar exemplos de
como os testes contribuem para um acrscimo de qualidade (K2).
Explicar e comparar os termos erro, defeito, falha e os termos correspondentes
engano e defeito, apresentando exemplos (K2).
1.2. O que so Testes? (K2)

LO-1.2.1.
LO-1.2.2.
LO-1.2.3.
Recordar os objetivos comuns dos testes (K1).

Fornecer exemplos para os objetivos dos testes nas diferentes fases do ciclo de vida
do software (K2).
Diferenciar testes de debugging (K2).
1.3. Os Sete Princpios dos Testes (K2)
LO-1.3.1. Explicar os sete princpios dos testes (K2).
1.4. Processo de Teste Fundamental (K1)

LO-1.4.1.
Recordar as cinco atividades fundamentais de teste e respetivas tarefas do

planeamento ao encerramento (K1).
1.5. A Psicologia dos Testes (K2)

LO-1.5.1.
LO-1.5.2.
Verso 2011
Recordar os fatores psicolgicos que influenciam o sucesso dos testes (K1).

Diferenciar a mentalidade de um testador (tester) com a de um programador (K2).
Pgina 10 de 85
01-Abr-2011
1.1. Porque Precisamos de Testes (K2)
155 minutos
Termos
Bug, defeito, erro, falha, engano qualidade, risco
1.1.1..
Contexto de Sistemas de Software (K1)
Os sistemas de software so uma parte integrante da vida atual, das aplicaes de negcio (p. ex.
servios bancrios) aos produtos de consumo (p. ex. automveis). A maioria das pessoas j teve
uma experincia com software que no funcionou de acordo com o esperado. Software que no
funciona corretamente pode provocar muitos problemas, incluindo perdas de tempo, dinheiro ou
reputao profissional, podendo mesmo causar efeitos mais graves como ferimentos ou morte.
1.1.2.
Causas de Defeitos de Software (K2)
Um ser humano pode cometer um erro (engano), que produz um defeito (falha, bug) no cdigo do
programa ou num documento. Se um defeito no cdigo executado, o sistema poder deixar de
fazer o que deveria fazer (ou fazer algo que no deveria), causando uma falha. Os defeitos de
software, sistemas ou documentos podem resultar em falhas, mas nem todos os defeitos o fazem.
Defeitos ocorrem porque os seres humanos so falveis e porque esto sujeitos presso de tempo,
cdigo complexo, complexidade de infraestruturas, evoluo tecnolgica e/ou muitas interaes de
sistemas diferentes.
As falhas tambm podem ser causadas por questes ambientais. Por exemplo, a radiao, o
magnetismo, os campos eletrnicos e a poluio podem causar defeitos no firmware ou influenciar a
execuo do software pela mudana de condies do hardware.
1.1.3. Funo dos Testes no Desenvolvimento, Manuteno e Operaes de

Software (K2)
Testes rigorosos aos sistemas e documentao podem ajudar a reduzir o risco de ocorrncia de
problemas durante a operao e contribuir para a qualidade do sistema de software, se os defeitos
encontrados forem corrigidos antes do lanamento do sistema para uso operacional.
Os testes de software podem tambm ser necessrios para responder a requisitos contratuais,
legais, ou normas especficas de indstria.
1.1.4.
Testes e Qualidade (K2)
Com a ajuda dos testes, possvel medir a qualidade do software em termos de defeitos
encontrados, tanto relativamente a requisitos e caractersticas funcionais como aos no funcionais
(p. ex. fiabilidade, usabilidade, eficincia, manutenibilidade e portabilidade). Para obter mais
informaes sobre testes no funcionais ver o captulo 2. Para obter mais informaes sobre as
caractersticas do software ver Software Engineering Software Product Quality (ISO 9126).
Os testes podem dar a confiana relativamente qualidade do software se ao execut-los se
detetarem poucos ou nenhuns defeitos. Um teste bem elaborado, ao passar com sucesso, reduz o
nvel de risco geral no sistema. Quando os testes detetam defeitos, a qualidade do sistema de
software aumenta com a correo desses mesmos defeitos.
Devem tirar-se lies de projetos anteriormente executados. Ao compreender as origens dos
defeitos encontrados em projetos anteriores, os processos podem ser melhorados, eliminando
Verso 2011
Pgina 11 de 85
01-Abr-2011
potencialmente a recorrncia de defeitos e, em consequncia, melhorando a qualidade de futuros

sistemas. Este um aspeto fundamental da garantia de qualidade.
Os testes devem ser integrados como uma das atividades de garantia de qualidade (i.e., lado a lado
com as normas de desenvolvimento, formao e anlise de defeitos).
1.1.5.
Qual a Quantidade Suficiente de Testes? (K2)
Decidir a quantidade exata de testes a executar deve ter em conta o nvel de risco, incluindo os
riscos de segurana, riscos tcnicos, assim como os riscos empresariais, e restries do projeto, tais
como tempo e oramento. O risco ser discutido mais aprofundadamente no captulo 5.
Os testes devem fornecer informao suficiente sobre o software ou sistema em testes, para a
tomada de deciso das partes interessadas sobre a passagem prxima fase de desenvolvimento
ou mesmo acerca da entrega ao cliente.
Verso 2011
Pgina 12 de 85
01-Abr-2011
1.2. O que so os Testes? (K2)
30 minutos
Termos
Debugging, requisito, reviso, caso de teste, testes, objetivo de teste
Conhecimento
A perceo mais comum sobre os testes que estes consistem apenas na execuo do software.
Contudo, isto apenas uma parte das atividades, no correspondendo assim a todas as atividades
de teste.
As atividades de teste existem antes e aps a execuo do teste propriamente dita. Estas atividades
incluem planear e controlar, escolher as condies de teste, conceber e executar os casos de teste,
verificar os resultados, avaliar os critrios de sada, manter informadas as partes envolvidas sobre
todo o decorrer do processo de testes e do sistema sob teste, e finalizar ou completar as atividades
de encerramento, logo que alguma das fases de teste tenha sido concluda. Os testes tambm
incluem a reviso de documentos (incluindo o cdigo fonte) e a realizao de anlise esttica.
Os testes dinmicos e estticos podem ambos ser usados como forma de alcanar objetivos
similares, e fornecer informaes que podem ser usadas para melhorar tanto o sistema que est em
testes como os processos de desenvolvimento e de testes.
Os testes podem ter os seguintes objetivos:
o Encontrar defeitos.
o Ganhar confiana sobre o nvel de qualidade.
o Fornecer informao para tomadas de deciso.
o Prevenir defeitos.
O processo de pensar e as atividades envolvidas na conceo de testes logo no incio do ciclo de
vida (verificando as bases para testes via conceo de teste) pode ajudar a prevenir a insero de
defeitos no cdigo. Reviso de documentos (p. ex. requisitos), e a identificao e resoluo de
questes nesse momento do ciclo tambm ajudam a prevenir defeitos no cdigo.
Ao testar, diferentes pontos de vista podem tomar em conta diferentes objetivos. Por exemplo, em
testes de desenvolvimento (ou seja, testes de componentes, integrao e sistema), o principal
objetivo pode ser provocar o mximo de falhas possvel para que os defeitos do software possam
ser detetados e corrigidos. Nos testes de aceitao, o principal objetivo pode ser confirmar que o
sistema funciona tal como esperado, para adquirir a confiana de que se cumpriram os requisitos
Em alguns casos, o principal objetivo dos testes pode ser avaliar a qualidade do software (sem a
inteno de corrigir defeitos), para fornecer informao s partes interessadas sobre o risco de
entregar o sistema num dado momento. Os testes de manuteno normalmente incluem testes que
demonstrem que durante o desenvolvimento de alteraes no se introduziram novos defeitos.
Durante os testes operacionais, o principal objetivo pode ser avaliar algumas das caractersticas do
sistema, tais como, fiabilidade e disponibilidade.
Efetuar debugging e testar so atividades bastante diferentes. Testes dinmicos mostram falhas
causadas por defeitos. Debugging a atividade de desenvolvimento que deteta, analisa e remove a
causa da falha. Subsequentemente, ao efetuar o reteste o testador (tester) assegura que a correo
de facto resolveu a falha. A responsabilidade sobre cada uma destas atividades geralmente a
seguinte: o testador (tester) testa, e o programador faz debug.
O processo de testes e suas atividades explicado na seco 1.4.
Verso 2011
Pgina 13 de 85
01-Abr-2011
1.3. Os Sete Princpios dos Testes (K2)
35 minutos
Termos
Testes exaustivos
Princpios
Ao longo dos ltimos 40 anos, foi definido o seguinte conjunto de princpios de teste que oferecem
linhas de orientao gerais, comum a todos os tipos de testes.
Princpio 1 Os testes mostram a presena de defeitos
Os testes podem mostrar a presena de defeitos, mas no provam a inexistncia dos mesmos. Os
testes reduzem a probabilidade de que defeitos no detetados permaneam no software, mas na
hiptese de no detetarem defeitos, tal no se pode considerar como prova de conformidade.
Princpio 2 Testes exaustivos so impossveis
Testar tudo (considerando todas as combinaes de entradas e pr-condies) no vivel, exceto
para os casos triviais. Em vez de testes exaustivos, a anlise de risco e as prioridades devem ser
utilizadas para focar os esforos de teste.
Princpio 3 Testar cedo
Para detetar os defeitos mais cedo, as atividades de teste devem ser iniciadas o mais cedo possvel
no ciclo de vida de desenvolvimento do software ou sistema, e devem estar focadas nos objetivos
definidos.
Princpio 4 Agrupamento de defeitos
O esforo de testes deve estar focado proporcionalmente densidade de defeitos por mdulo
esperada e mais tarde observada. Um nmero reduzido de mdulos normalmente apresenta a
maioria dos defeitos detetados durante os testes de pr-lanamento, ou responsvel pela maioria
das falhas operacionais.
Princpio 5 Paradoxo do pesticida
Tendencialmente, a repetio exaustiva dos mesmos casos de teste leva no deteo de novos
defeitos. Para superar este paradoxo do pesticida, os casos de teste devem ser regularmente
analisados e revistos e testes diferentes ou novos devem ser desenvolvidos para executar diferentes
partes do software ou sistema por forma a detetar mais defeitos potenciais.
Princpio 6 Os testes so dependentes do seu contexto
Os testes so efetuados de forma diferente em diferentes contextos. Por exemplo, o software crtico
em segurana (safety-critical software) testado de forma diferente de um site de comrcio
eletrnico.
Princpio 7 Falcia da ausncia de erros
Detetar e corrigir defeitos por si s no ajuda se o sistema construdo for impossvel de utilizar e no
satisfizer as necessidades e expectativas dos seus utilizadores.
Verso 2011
Pgina 14 de 85
01-Abr-2011
1.4. Processo de Teste Fundamental (K1)
35 minutos
Termos
Testes de confirmao, reteste, critrios de sada, incidente, testes de regresso, base para testes,
condio de teste, cobertura de teste, dados de teste, execuo de testes, registo de testes, plano
de testes, procedimento de testes, poltica de testes, conjunto de testes, relatrio de testes, testware
Conhecimento
A parte mais visvel dos testes sem dvida a execuo. Mas, para que esta seja eficaz e eficiente,
os planos de testes devem incluir tambm o tempo a ser gasto no planeamento dos testes,
conceo de casos de teste, preparao da execuo e avaliao de resultados.
O processo de testes fundamental consiste nas seguintes atividades principais:
o
Planeamento e controlo
Anlise e conceo
Implementao e execuo
Avaliao de critrios de sada e relatrios
Atividades de fecho da fase de testes
Embora sigam uma lgica sequencial, as atividades do processo podem ser sobrepostas ou
decorrer de forma simultnea. Normalmente necessria a customizao destas atividades
principais dentro do contexto do sistema e do projeto s quais se destinam.
1.4.1.
Planeamento e Controlo de Testes (K1)
O planeamento de testes a atividade que define os objetivos dos testes e especifica as atividades
de teste, a fim de cumprir os objetivos e misso estabelecidos.
O controlo de testes uma atividade permanente que compara o progresso atual com o planeado, e
reporta o seu estado, incluindo desvios do plano. Envolve tomar iniciativa, na medida necessria,
para cumprir a misso e objetivos do projeto. De modo a controlar os testes, as atividades de teste
devem ser monitorizadas durante todo o projeto. O planeamento de testes leva em conta o feedback
das atividades de monitorizao e controlo.
As atividades de planeamento e tarefas de controlo so definidas no captulo 5 deste programa.
1.4.2.
Anlise e Conceo de Testes (K1)
A anlise e conceo de testes a atividade durante a qual os objetivos gerais dos testes so
transformados em condies de teste tangveis e em casos de teste.
A atividade de anlise e conceo de testes pressupe as seguintes tarefas principais:
Reviso da base para testes (tais como requisitos, o nvel de integridade do software
(nvel de risco), os relatrios de anlise de risco, arquitetura, conceo, especificaes de
interface).
O grau em que o software cumpre ou deve cumprir um conjunto de software stakeholder selecionado e/ou
caractersticas do sistema baseado em software (por exemplo, a complexidade do software, avaliao de risco,
Verso 2011
Pgina 15 de 85
01-Abr-2011
o
o
o
o
o
o
1.4.3.
Avaliao da testabilidade da base para testes e dos objetos de teste.

Identificao e priorizao das condies de teste com base na anlise dos itens de teste,
na especificao, no comportamento e na estrutura do software.
Conceo e priorizao de casos de teste de alto nvel.
Identificao dos dados de teste necessrios para suportar as condies e casos de teste.
Conceo da configurao do ambiente de teste e identificao das necessidades de
infraestrutura e ferramentas.
Criao de rastreabilidade bidirecional entre a base para testes e os casos de teste.
Implementao e Execuo de Testes (K1)
A implementao e execuo de testes a atividade de especificao de procedimentos e scripts de

teste atravs da combinao de casos de teste seguindo uma determinada ordenao e incluindo
qualquer outra informao necessria execuo de teste, considera-se que a configurao do
ambiente foi efetuada e executam-se os testes.
A implementao e execuo de testes pressupem as seguintes tarefas principais:
o Finalizar, implementar e priorizar os casos de teste (incluindo a identificao de dados de
teste).
o Desenvolver e priorizar procedimentos de teste, criar dados de teste e, opcionalmente,
preparar equipamentos de teste e desenvolver guies de teste automatizados.
o Criar os conjuntos de teste a partir dos procedimentos de teste para alcanar uma
execuo de teste eficiente.
o Verificar que a configurao do ambiente de teste est correta.
o Verificar e atualizar bidireccionalmente a rastreabilidade entre a base para testes e os
casos de teste.
o Executar os procedimentos de teste, quer de forma manual ou atravs de ferramentas de
execuo de testes, de acordo com a sequncia planeada.
o Registar os resultados da execuo de teste e gravar as identidades e verses do software
sob teste, ferramentas de teste e testware.
o Comparar os resultados atuais com os resultados esperados.
o Reportar as discrepncias como incidentes e analisar os mesmos a fim de estabelecer a
sua causa (p. ex. um defeito no cdigo, nos dados de teste especficos, no documento de
teste, ou um engano na forma como o teste foi executado).
o Repetir as atividades de teste, como resultado de aes tomadas em cada discrepncia,
por exemplo, re-execuo de um teste que antes falhou, a fim de confirmar a sua correo
(teste de confirmao), a execuo de um teste j corrigido e/ou execuo de testes a fim
de garantir que no foram introduzidos defeitos em reas de software inalteradas ou que a
correo daquele defeito no
1.4.4.
provoca outros defeitos (teste de regresso)
Avaliao de Critrio de Sada e Relatrios (K1)
A avaliao do critrio de sada a atividade onde a execuo do teste avaliada face aos objetivos
definidos. Esta deve ser efetuada para cada nvel de teste (ver seco 2.2.).
A avaliao do critrio de sada tem as seguintes tarefas principais:
o Verificar os registos de teste face ao critrio de sada especificado no planeamento de
testes.
o Avaliar se existe a necessidade de executar mais testes ou se o critrio de sada
especificado deve ser alterado.
o Escrever o relatrio de teste para as partes interessadas.
nvel de segurana, desempenho desejado, fiabilidade ou custo) que so definidos para refletir a importncia
do software para os seus stakeholders.
Verso 2011
Pgina 16 de 85
01-Abr-2011
1.4.5.
Atividades de Fecho da Fase de Testes (K1)
As atividades de fecho da fase de testes pressupem a recolha de dados das atividades de teste j
encerradas a fim de consolidar experincias, testware, factos e nmeros. As atividades de fecho da
fase de testes ocorrem em marcos do projeto, tais como o lanamento do sistema de software, a
concluso (ou cancelamento) de um projeto de testes, um marco alcanado ou uma verso de
manuteno concluda.
Atividades de fecho da fase de testes incluem as seguintes tarefas principais:
o Verificar se os entregveis planeados foram realmente entregues.
o Fechar relatrios de incidentes ou registar alguma alterao significativa para os que
permanecem abertos.
o Documentar a aceitao do sistema.
o Finalizar e arquivar o testware, assim como o ambiente de teste e a infraestrutura de teste
para reutilizao futura.
o Disponibilizar o testware entidade responsvel pela manuteno.
o Analisar as lies apreendidas a fim de determinar alteraes necessrias em lanamentos
ou projetos futuros.
o Utilizar a informao recolhida para melhorar a maturidade dos testes.
Verso 2011
Pgina 17 de 85
01-Abr-2011
1.5. A Psicologia dos Testes (K2)
25 minutos
Termos
Antecipar erros, independncia
Conhecimento
A mentalidade presente enquanto testamos ou efetuamos uma reviso diferente da que devemos
assumir durante o desenvolvimento de software. Com a mentalidade certa, os programadores so
capazes de testar o seu prprio cdigo, mas a separao desta responsabilidade para um testador
(tester) normalmente efetuada para ajudar a focar o esforo e proporcionar vantagens adicionais,
tais como uma viso independente de recursos de teste profissionais e treinados para tal. Os testes
independentes podem ser realizados em qualquer nvel de teste.
Um certo grau de independncia (evitando assim a influncia do autor) faz, muitas vezes, com que o
testador (tester) seja mais eficaz na deteo de defeitos e falhas. A independncia no , no entanto,
um substituto para o conhecimento e, assim, os programadores podem encontrar defeitos no seu
prprio cdigo eficientemente. Existem vrios nveis de independncia que podem ser definidos da
forma aqui apresentada, do nvel mais reduzido ao mais elevado:
o Testes concebidos pela(s) pessoa(s) que desenvolveu(ram) o software a testar (nvel mais
baixo de independncia).
o Testes concebidos por outra(s) pessoa(s) (p. ex. pela equipa de desenvolvimento).
o Testes concebidos por outra(s) pessoa(s) de um grupo diferente da organizao (p. ex.
uma equipa de testes independente) ou por especialistas de testes (p. ex. especialistas de
testes em usabilidade e desempenho).
o Testes concebidos por outra(s) pessoa(s) de uma organizao ou empresa diferentes (i.e.,
outsourcing ou certificao por alguma entidade externa).
As pessoas e os projetos so movidos por objetivos. As pessoas tendem a alinhar os seus planos
com os objetivos definidos pela administrao e outras partes interessadas, por exemplo, para
encontrar defeitos ou para confirmar que o software cumpre os seus objetivos. Portanto,
importante indicar claramente os objetivos dos testes.
O processo de identificar falhas durante os testes pode ser percecionado como uma crtica ao
produto ou ao autor. Como resultado, os testes so, muitas vezes, vistos como uma atividade
destrutiva, mesmo que estes sejam efetivamente muito construtivos na gesto de riscos do produto.
A busca de falhas num sistema requer curiosidade, pessimismo profissional, um olhar crtico,
ateno aos detalhes, boa comunicao com os colegas do desenvolvimento, e experincia para
servir de base ao uso da tcnica de adivinhao de erros.
Se os erros, defeitos ou falhas forem comunicados de forma construtiva, o mau ambiente entre
testadores (testers) e analistas, designers e programadores pode ser evitado. Isto aplica-se a
defeitos encontrados durante as revises assim como no decorrer dos testes.
Os testadores (testers) e seus lderes devem ter boas capacidades de relacionamento interpessoal
para transmitir informaes factuais acerca dos defeitos, seu progresso e riscos de uma forma
construtiva. Para o autor do software ou documento, a informao do defeito pode ajud-lo a
melhorar a sua aptido. Defeitos encontrados e corrigidos durante os testes economizam tempo e
dinheiro, alm de reduzirem riscos.
Problemas de comunicao podem ocorrer, em particular se os testadores (testers) forem vistos
apenas como mensageiros de notcias indesejadas sobre defeitos. No entanto, existem variadas
Verso 2011
Pgina 18 de 85
01-Abr-2011
formas de melhorar a comunicao e relacionamento entre testadores (testers) e as restantes

partes envolvidas:
o Inicie com uma postura colaborativa em vez de confronto recordando a todos o objetivo
comum em obter uma melhor qualidade dos sistemas.
o Comunique o resultado dos testes ao produto de uma forma neutra, factual e sem criticar
quem o criou, por exemplo, escreva relatrios de incidentes de forma objetiva e factual
assim como as concluses de revises.
o Tente compreender a posio do outro e porque reage de certa forma.
o Confirme que a outra pessoa percebeu o que disse e vice-versa.
Verso 2011
Pgina 19 de 85
01-Abr-2011
1.6 Cdigo de tica
10 minutos
A participao em testes de software permite aos indivduos envolvidos ter acesso a informao
privilegiada e confidencial. Justifica-se portanto a existncia de um cdigo de tica, entre outras
razes, para assegurar que a informao no utilizada de forma inapropriada. O ISTQB
reconhece o cdigo de tica da ACM e do IEEE para engenheiros, que afirma o seguinte:
PBLICO Os testadores (testers) de software certificados devem atuar de forma coerente com o
interesse pblico.
CLIENTES E EMPREGADORES Os testadores (testers) de software certificados devem atuar de
acordo com o interesse dos seus clientes e empregadores, e de forma coerente com o interesse
pblico.
PRODUTO Os testadores (testers) de software certificados devem assegurar que os resultados
fornecidos (sobre os sistemas e produtos que testam) atendem aos mais elevados padres
profissionais.
JUZO - Os testadores (testers) de software certificados devem manter a integridade e
independncia no seu julgamento profissional.
GESTO Os gestores e lderes de testes de software certificados devem subscrever e promover
uma abordagem tica na gesto de testes de software.
PROFISSO Os testadores (testers) de software certificados devem alavancar a integridade e
reputao da profisso de forma coerente com o interesse pblico.
COLEGAS Os testadores (testers) de software certificados devem ser justos e solidrios com os
colegas, e promover a cooperao com os programadores.
PRPRIO Os testadores (testers) de software certificados devem promover uma abordagem tica
na prtica da sua profisso e manter o foco numa aprendizagem contnua relativa prtica da sua
atividade.
Referncias
1.1.5. Black, 2001, Kaner, 2002

1.2. Beizer, 1990, Black, 2001, Myers, 1979
1.3. Beizer, 1990, Hetzel, 1988, Myers, 1979
1.4. Hetzel, 1988
1.4.5. Black, 2001, Craig, 2002
1.5. Black, 2001, Hetzel, 1988
Verso 2011
Pgina 20 de 85
01-Abr-2011
2. Testes atravs do Ciclo de Vida de

Software (K2)
115 minutos
Objetivos de Aprendizagem para Testes atravs do Ciclo de Vida de

Software
mdulo.
2.1. Modelos de Desenvolvimento de Software (K2)

LO-2.1.1.
LO-2.1.2.
LO-2.1.3.
Explicar a relao entre desenvolvimento, atividades de teste e produtos de trabalho

no ciclo de vida do desenvolvimento, dando exemplos de projetos e tipos de produto
(K2).
Reconhecer o facto de que os modelos de desenvolvimento de software devem ser
adaptados ao contexto do projeto e das caractersticas do produto (K1).
Recordar as caractersticas de um bom teste que so aplicveis a qualquer modelo de
ciclo de vida (K1).
2.2. Nveis de Teste (K2)

LO-2.2.1.
Comparar os diferentes nveis de teste: objetivos principais, objetos de teste tpicos,

alvos de teste tpicos (p. ex. funcionais ou estruturais) e produtos de trabalho
relacionados, pessoas que testam, tipos de defeitos e falhas a detetar (K2).
2.3. Tipos de Teste (K2)

LO-2.3.1.
LO-2.3.2.
LO-2.3.3.
LO-2.3.4.
LO-2.3.5.
Comparar, por exemplo, quatro tipos de teste (funcionais, no funcionais, estruturais e

relacionados com alteraes) (K2).
Reconhecer que os testes funcionais e estruturais ocorrem em qualquer nvel de teste
(K1).
Identificar e descrever tipos de teste no funcionais baseados em requisitos no
funcionais (K2).
Identificar e descrever tipos de teste baseados na anlise da estrutura de um sistema
ou arquitetura do software (K2).
Descrever a finalidade dos testes de confirmao e testes de regresso (K2).
2.4. Testes de Manuteno (K2)

LO-2.4.1.
LO-2.4.2.
LO-2.4.3.
Verso 2011
Comparar testes de manuteno (testar um sistema j em utilizao) com testes a uma

nova aplicao no que respeita a tipos de teste e critrios de testes assim como
quantidade de testes (K2).
Reconhecer indicadores de manuteno de testes (modificao, migrao e
desabilitao) (K1).
Descrever a funo de testes de regresso e da anlise de impacto na manuteno
(K2).
Pgina 21 de 85
01-Abr-2011
2.1. Modelos de Desenvolvimento de Software

(K2)
20 minutos
Termos
Comercial de prateleira (COTS), modelos de desenvolvimento iterativo-incrementais, validao,

verificao, modelo em V
Conhecimento
Os testes no existem isoladamente; as atividades de teste esto relacionadas com as atividades de

desenvolvimento de software. Os diferentes modelos de ciclo de vida de desenvolvimento
necessitam de abordagens diferenciadas para os seus testes.
2.1.1.
Modelo em V (Modelo Sequencial de Desenvolvimento) (K2)
Apesar de existirem algumas variantes do modelo em V, o tipo mais comum do modelo em V usa
quatro nveis de teste, correspondendo aos quatro nveis de desenvolvimento.
Os quatro nveis utilizados neste programa so:
o Testes de componentes (unidade)
o
Testes de integrao
Testes de sistema
Testes de aceitao
Na prtica, um modelo em V pode ter mais, menos ou diferentes nveis de desenvolvimento e testes,
dependendo do projeto e do produto de software. Por exemplo, podem existir testes de integrao
de componentes depois dos testes de componentes, e testes de integrao de sistema depois dos
testes de sistema.
Os produtos de trabalho de software (tais como cenrios de negcio ou casos de uso,
especificaes de requisitos, documentos de conceo e cdigo) produzidos durante o
desenvolvimento so, muitas vezes, a base para um ou mais do que um nvel de teste. Referncias
para produtos de trabalho genricos incluem modelo de maturidade como o Capability Maturity
Model Integration (CMMI) ou Software life cycle processes (IEEE/IEC 12207). Verificao e
validao (e conceo de teste inicial) podem ser efetuadas durante o desenvolvimento de produtos
de trabalho de software.
2.1.2.
Modelos de Desenvolvimento Iterativo-incremental (K2)
O desenvolvimento iterativo-incremental o processo de definir requisitos, conceber, construir e

testar um sistema, efetuado como uma srie de curtos ciclos de desenvolvimento. Exemplos deste
tipo de modelo so: prottipos, Rapid Application Development (RAD), Rational Unified Process
(RUP) e modelos de desenvolvimento geis. Os sistemas resultantes da iterao podem ser
testados em diversos nveis de teste durante cada iterao. Algum acrscimo aos desenvolvimentos
anteriores constitui, s por si, um crescimento parcial do sistema que tambm deve ser testado. Os
testes de regresso so cada vez mais importantes em todas as iteraes a partir da primeira. A
verificao e validao podem ser efetuadas em cada acrscimo do desenvolvimento.
2.1.3.
Testes dentro de um Modelo de Ciclo de Vida (K2)
Em qualquer modelo de ciclo de vida, existem vrias caractersticas de um bom teste a reter:
o Para cada atividade de desenvolvimento existe uma atividade de teste correspondente.
Verso 2011
Pgina 22 de 85
01-Abr-2011
o
o
o
Para cada nvel de teste existem objetivos especficos de teste.

A anlise e conceo de testes, para um determinado nvel de teste, devem comear no
decorrer da atividade de desenvolvimento correspondente.
Os testadores (testers) devem ser envolvidos na reviso de documentos logo que existam
esboos disponveis no ciclo de vida de desenvolvimento.
Os nveis de teste podem ser combinados ou reorganizados em funo da natureza do projeto ou

arquitetura do sistema. Por exemplo, na integrao de produtos de software comercial de prateleira
(COTS) num sistema, o comprador poder realizar testes de integrao ao nvel do sistema (p. ex. a
integrao na infraestrutura e noutros sistemas, ou entrega de sistema) e testes de aceitao
(funcionais e/ou no funcionais, e de utilizador e/ou testes operacionais).
Verso 2011
Pgina 23 de 85
01-Abr-2011
2.2. Nveis de Teste (K2)
40 minutos
Termos
Testes alfa, testes beta, testes de componentes, controlador (driver), testes de campo, requisitos
funcionais, integrao, testes de integrao, requisito no funcional, testes de robustez, simulador
(stub), testes de sistema, ambiente de teste, nvel de teste, desenvolvimento orientado a testes,
testes de aceitao do utilizador
Conhecimento
Para cada um dos nveis de teste, o seguinte pode ser identificado: objetivos genricos, produto(s)
de trabalho como referncia para derivao de casos de teste (i.e., a base para testes), objetos de
teste (i.e., o que est a ser testado), defeitos mais comuns e falhas a detetar, requisitos de
equipamento de teste e ferramentas de suporte, e abordagens especficas e responsabilidades.
Testes aos dados de configurao de um sistema devem ser considerados durante o planeamento
de testes, caso esses dados faam parte de um sistema.
2.2.1.
Testes de Componentes (K2)
Base para testes:

o
Requisitos de componentes
Conceo detalhada
Cdigo
Objetos de teste tpicos:

o
Componentes.
o
Programas.
o
Converso de dados de programas/migraes.
o
Mdulos de bases de dados.
Testes de componentes (tambm conhecidos como testes de unidade, mdulos ou programas)
procuram por defeitos e verificam o funcionamento de mdulos de software, programas, objetos,
classes, etc. que possam ser testados separadamente. Podem ser feitos de forma isolada do resto
do sistema, dependendo do contexto do ciclo de vida de desenvolvimento e do sistema.
Simuladores (Stubs) e controladores (drivers) podem ser utilizados.
Testes de componentes podem incluir testes a funcionalidades e caractersticas no-funcionais
especficas, tais como o comportamento de recursos (p. ex. em busca de memria perdida) ou
testes de robustez, bem como testes estruturais (p. ex. a cobertura de decises). Os casos de teste
so derivados de produtos de trabalho, tais como, da especificao do componente, da conceo de
software ou do modelo de dados.
Normalmente, os testes de componentes ocorrem com acesso ao cdigo a testar e com o apoio do
ambiente de desenvolvimento como estrutura de testes unitrios ou ferramentas de debug. Na
prtica, os testes de componentes envolvem o programador que desenvolveu o cdigo. Os defeitos
so normalmente corrigidos logo que detetados, sem a necessidade de efetuar uma gesto formal
desses mesmos defeitos.
Uma aproximao possvel a testes de componentes a preparao e automatizao de casos de
teste antes de codificar. A esta abordagem chamamos antecipar os testes (test-first) ou
Verso 2011
Pgina 24 de 85
01-Abr-2011
desenvolvimento orientado a testes (test-driven development). Esta abordagem altamente iterativa

e baseada em ciclos de desenvolvimento de casos de teste, seguidos de construo e integrao
de pequenas peas de cdigo, sendo depois executados os testes de componentes, corrigindo
eventuais problemas executando vrias iteraes at que todos os testes passem.
2.2.2.
Testes de Integrao (K2)
Base para testes:

o
Conceo do software e do sistema.
o
Arquitetura
Fluxos de trabalho (workflows)
Casos de uso

o
Implementao de bases de dados de subsistemas.
o
Infraestrutura.
o
Interfaces.
o
Configurao de sistemas e dados de configurao.
Os testes de integrao testam as interfaces entre componentes, interaes entre as diferentes
partes de um sistema, tais como, o sistema operativo, sistema de arquivos e hardware, e as
interfaces entre os sistemas.
Pode existir mais do que um nvel de testes de integrao e este pode ser utilizado em objetos de
teste de dimenso varivel, tais como:
1. Os testes de integrao de componentes testam as interaes entre componentes de software
e so efetuados aps os testes de componentes.
2. Os testes de integrao de sistemas testam a interao entre diferentes sistemas ou entre
hardware e software e podem ser efetuados depois dos testes de sistema. Neste caso, a
organizao de desenvolvimento pode controlar apenas um lado da interface. Isto pode ser
considerado um risco. Os processos de negcio implementados em fluxos de trabalho podem
envolver vrios sistemas. Neste caso, os problemas podem ser cruzados ao longo de toda a
plataforma e ser significativos.
Quanto maior for o mbito da integrao, mais difcil se torna o isolamento de falhas num
componente especfico ou sistema, o que pode conduzir a um aumento do risco e tempo adicional
para resoluo de problemas.
Estratgias de integrao sistemtica podem ser baseadas na arquitetura do sistema (tais como
descendente (top-down) e ascendente (bottom-up)), tarefas funcionais, sequncia de
processamento de transaes, ou algum outro aspeto dos componentes ou do sistema. De modo a
facilitar o isolamento de defeitos e antecipar a sua deteo, a integrao deve normalmente ser
incremental em vez de big bang.
Testes de caractersticas especficas no funcionais (p. ex. desempenho) podem incluir testes de
integrao assim como testes funcionais.
Em cada etapa de integrao, os testadores (testers) concentram-se somente na integrao
propriamente dita. Por exemplo, se esto a integrar o mdulo A com o mdulo B, ento esto
interessados em testar a comunicao entre os mdulos, e no a funcionalidade de cada mdulo
individualmente como efetuado durante os testes de componentes. Ambas as abordagens
funcionais e estruturais podem ser utilizadas.
Verso 2011
Pgina 25 de 85
01-Abr-2011
Idealmente, os testadores (testers) devem compreender a arquitetura e refletir a sua influncia no

planeamento da integrao. Se os testes de integrao forem planeados antes dos componentes ou
do sistema a serem desenvolvidos, ento estes podem ser desenvolvidos pela sequncia que torne
mais eficiente a execuo dos testes.
2.2.3.
Testes de Sistema (K2)
Base para testes:

o
Especificao de requisitos de sistema e software
Casos de uso
Especificao funcional
Relatrios de anlise de risco

o
Manuais de sistema, utilizador e operao.
o
Configurao de sistemas e dados de configurao.
Os testes de sistema testam o comportamento de todo o sistema/produto. O mbito dos testes deve
ser claramente abordado no Plano Mestre de Testes (Master Test Plan) e/ou no Plano de Nvel de
Testes (Level Test Plan) para aquele nvel de teste.
Nos testes de sistema, o ambiente de teste deve corresponder ao objetivo final ou ao ambiente de
produo o mais possvel, de modo a minimizar o risco de falhas especficas do ambiente que no
foram detetadas em testes anteriores.
Os testes de sistema podem incluir testes baseados em risco e/ou sobre as especificaes de
requisitos, processos de negcio, casos de uso ou outras descries de texto de alto nvel, modelos
de comportamento do sistema, interaes com o sistema operativo e recursos de sistema.
Os testes de sistema devem investigar os requisitos funcionais e no funcionais do sistema, e
caractersticas de qualidade de dados. Muitas vezes, os testadores (testers) lidam com requisitos
incompletos ou no documentados. Testes de sistema de requisitos funcionais comeam por utilizar
a tcnica baseada nas especificaes (caixa-preta) mais apropriada para verificar o sistema. Por
exemplo, uma tabela de deciso pode ser criada para refletir as combinaes de condies
descritas nas regras de negcio. Tcnicas baseadas na estrutura (caixa-branca) podem ser
utilizadas para avaliar o rigor dos testes face a um elemento estrutural, tal como, uma estrutura de
menu ou navegao de uma pgina da web (ver captulo 4).
Uma equipa de testes independente muitas vezes executa os testes de sistema.
2.2.4..
Testes de Aceitao (K2)
Base para testes:

o
Requisitos do utilizador
Requisitos de sistema
Casos de uso
Processos de negcio
Relatrios de anlise de risco

Verso 2011
Pgina 26 de 85
01-Abr-2011
o
o
o
o
o
o
Processos de negcio do sistema integrado total.

Processos operacionais e de manuteno.
Procedimentos de utilizador.
Formulrios.
Relatrios.
Dados de configurao.
Os testes de aceitao so muitas vezes da responsabilidade dos clientes ou utilizadores do

sistema, mas outras partes interessadas podem estar igualmente envolvidas.
O objetivo dos testes de aceitao estabelecer a confiana no sistema, em partes do sistema ou
relativamente a caractersticas no funcionais do sistema. Encontrar defeitos no o principal foco
dos testes de aceitao Os testes de aceitao podem avaliar a disponibilidade do sistema para
entrega e utilizao, embora no seja necessariamente o ltimo nvel de testes. Por exemplo, os
testes de integrao de sistema em larga escala podem ser realizados aps a execuo dos testes
de aceitao.
Os testes de aceitao podem ser executados em variados momentos do ciclo de vida, por exemplo:
o Um produto de software COTS pode ser testado ao nvel de aceitao quando instalado ou
integrado.
o Testes de aceitao usabilidade de um componente podem ser executados durante os
testes de componentes.
o Testes de aceitao a uma nova funcionalidade ou melhoria podem ser executados antes
dos testes de sistema.
Templates tpicos de testes de aceitao podem incluir o seguinte:
Testes de aceitao de utilizador
Normalmente verifica a aptido para o uso de um sistema por parte de utilizadores de negcio.
Testes operacionais (aceitao)
A aceitao do sistema pelos administradores de sistema, incluindo:
o
Testar cpias de segurana e sua reposio (backup/restore)
Recuperao de desastres (Disaster recovery)
Gesto de utilizador
Tarefas de manuteno
Carregamento de dados e tarefas de migrao
Controlo peridico das vulnerabilidades de segurana
Testes de aceitao de contrato e regulamento

Testes de aceitao de contrato so executados face aos critrios de aceitao contratuais para a
produo de software customizado e sob encomenda. Os critrios de aceitao devem ser definidos
quando as partes determinam o contrato. Os testes de aceitao de regulamento so executados
face a todos os regulamentos que devam ser cumpridos, tais como regulamentaes
governamentais, legais ou de segurana.
Testes alfa e beta (ou teste em campo)
Os fornecedores de solues de mercado, ou software COTS, muitas vezes querem obter o
feedback dos clientes existentes ou potenciais do seu mercado antes de disponibilizar o software
para venda. Os testes alfa so executados nas organizaes que desenvolvem, mas no pela
Verso 2011
Pgina 27 de 85
01-Abr-2011
equipa de desenvolvimento. Os testes beta ou testes em campo so realizados por clientes ou

potenciais clientes nas suas prprias instalaes.
As organizaes podem tambm usar outros termos, tais como, testes de aceitao de fbrica e
teste de aceitao local para sistemas que so testados antes e depois de serem disponibilizados na
localizao do cliente.
Verso 2011
Pgina 28 de 85
01-Abr-2011
2.3 Tipos de Teste (K2)
40 minutos
Termos
Testes caixa-preta, cobertura de cdigo, testes funcionais, testes de interoperabilidade, testes de

carga, testes de manutenibilidade, testes de desempenho, testes de portabilidade, testes de
fiabilidade, testes de segurana, testes de stress, testes estruturais, testes de usabilidade, testes
caixa-branca
Conhecimento
Um conjunto de atividades de teste pode ser destinado verificao do sistema (ou parte de um
sistema) com base num objetivo ou alvo especfico de teste.
Um tipo de teste focado num objetivo de teste especfico, que pode ser qualquer um dos
seguintes:
o
o
o
o
Uma funo a ser executada pelo software

Uma caracterstica de qualidade no funcional, tais como fiabilidade ou usabilidade.
A estrutura ou arquitetura do software ou sistema
Relacionadas com alteraes, ou seja confirmar que os defeitos foram corrigidos (testes
de confirmao) e procura de alteraes no intencionais (testes de regresso).
Um modelo do software pode ser desenvolvido e/ou utilizado nos testes estruturais (p. ex. um
modelo de fluxos de controlo ou modelo de estrutura de menus), nos testes no funcionais (p. ex.
modelo de desempenho, modelo de usabilidade e modelao de ameaas segurana), e testes
funcionais (p. ex. modelo de fluxos de processo, um modelo de transio de estados ou uma
especificao em linguagem simples).
2.3.1.
Testes de Funo (Testes Funcionais) (K2)
As funes que um sistema, subsistema ou componente devem realizar podem ser descritas em
produtos de trabalho, tais como, a especificao de requisitos, casos de uso, uma especificao
funcional ou podem nem estar documentados. As funes so o que o sistema faz.
Os testes funcionais so baseados em funes e caractersticas (descritos em documentos ou
compreendidos pelos testadores (testers)) e a sua interoperabilidade com sistemas especficos, e
podem ser executados em todos os nveis de teste (p. ex. testes para componentes podem ser
baseados em especificaes de componentes).
As tcnicas baseadas nas especificaes podem ser utilizadas para derivar as condies e casos de
teste da funcionalidade do software ou sistema (ver captulo 4). Os testes funcionais consideram o
comportamento externo do software (testes caixa-preta).
Os testes de segurana, um tipo de testes funcionais, investigam as funes (p. ex. firewall)
relacionados com a deteo de ameaas, como vrus, de estranhos mal-intencionados. Os testes de
interoperabilidade, outro tipo de testes funcionais, avaliam a capacidade do produto de software de
interagir com um ou mais componentes ou sistemas especficos.
2.3.2. Testes a Caractersticas de Software No funcionais (Testes No

Funcionais) (K2)
Testes no funcionais incluem, mas no esto limitados a, testes de desempenho, testes de carga,
testes de stress, testes de usabilidade, testes de manutenibilidade, testes de fiabilidade e testes de
portabilidade. So os testes ao como o sistema funciona.
Verso 2011
Pgina 29 de 85
01-Abr-2011
Testes no funcionais podem ser realizados em todos os nveis de teste. O termo testes no
funcionais descreve os testes necessrios para medir as caractersticas dos sistemas e software que
podem ser quantificadas numa escala varivel, tal como tempos de resposta para o teste de
desempenho. Estes testes podem ser referenciados num modelo de qualidade, tal como o definido
em Software Engineering Software Product Quality (ISO 9126)). Os testes no funcionais
consideram o comportamento externo do software e, na maioria dos casos, usam a tcnica de
conceo de testes caixa-preta para o conseguir.
2.3.3.
Testes Estrutura/Arquitetura do Software (Testes Estruturais) (K2)
Os testes estruturais (caixa-branca) podem ser realizados em todos os nveis de teste. As tcnicas
estruturais so mais bem-sucedidas se aplicadas depois das tcnicas baseadas nas especificaes,
de forma a auxiliar a medio do rigor dos testes atravs da avaliao da cobertura de um tipo de
estrutura.
Considera-se a cobertura como a medida em que uma estrutura executada por um conjunto de
testes, expressa em percentagem dos itens a serem cobertos. Se a cobertura no atingir os 100%,
ento mais testes devem ser concebidos para testar os itens que no foram abrangidos e assim
aumentar a cobertura. Tcnicas de cobertura so discutidas no captulo 4.
Em todos os nveis de teste, mas especialmente nos testes de componentes e testes de integrao
de componentes, podem utilizar-se ferramentas para medir a cobertura de cdigo de elementos, tais
como, instrues ou decises. Testes estruturais podem ser baseados na arquitetura do sistema,
tais como, uma hierarquia de chamadas.
Testes estruturais podem tambm ser aplicados no sistema, integrao de sistemas ou ao nvel dos
testes de aceitao (p. ex. aos modelos de negcio ou estruturas de menu).
2.3.4.
(K2)
Testes Relacionados com Alteraes: Reteste e Testes de Regresso
Depois de um defeito ser detetado e corrigido, o software deve ser retestado para confirmar que o
defeito original foi removido com sucesso. A isto chamamos confirmao. Debugging (correo de
defeitos) uma atividade de desenvolvimento, e no uma atividade de testes.
Os testes de regresso so a repetio de testes a um programa j testado, aps uma modificao,
para descobrir eventuais defeitos introduzidos ou descobertos como resultado da(s) mudana(s).
Estes defeitos podem encontrar-se tanto no software que est a ser testado, como num outro
componente de software relacionado ou no. So realizados quando o software ou o seu ambiente
alterado. A extenso dos testes de regresso tem por base o risco de no encontrar defeitos no
software que estava a funcionar anteriormente.
Os testes devem ser repetveis para que possam ser usados como testes de confirmao e como
suporte aos testes de regresso.
Os testes de regresso podem ser realizados em todos os nveis de teste, e incluem testes
funcionais, no funcionais e estruturais. Os conjuntos de testes de regresso so executadas muitas
vezes e geralmente evoluem lentamente, assim sendo os testes de regresso so fortes candidatos
automatizao.
Verso 2011
Pgina 30 de 85
01-Abr-2011
2.4. Testes de Manuteno (K2)
15 minutos
Termos
Anlise de impacto, testes de manuteno
Conhecimento
Uma vez implantado, um sistema de software fica, muitas vezes, ao servio durante anos ou
dcadas. Durante este tempo o sistema, os seus dados de configurao ou o seu ambiente podem
ser corrigidos, alterados ou prorrogados. O planeamento antecipado dos lanamentos de novas
verses fundamental para a realizao bem-sucedida dos testes de manuteno. Uma distino
tem de ser feita entre lanamento planeado de verses e resolues de problemas (hot fixes). Os
testes de manuteno so executados num sistema operacional existente, e so desencadeados
por modificaes, migrao, ou a desabilitao do software ou sistema.
As modificaes incluem mudanas planeadas de melhoria (p. ex. baseadas em novas verses),
mudanas corretivas e de emergncia, e as mudanas de ambiente, tais como, atualizaes
previstas ao sistema operativo ou base de dados, atualizao prevista de software comercial de
prateleira (COTS) ou patches para corrigir as recm-expostas ou descobertas vulnerabilidades do
sistema operativo.
Os testes de manuteno para a migrao (p. ex. entre plataformas) devem incluir testes
operacionais ao novo ambiente, bem como, ao software alterado. Testes de migrao (testes de
converso) tambm so necessrios quando os dados de outra aplicao so migrados para o
sistema que est em manuteno.
Os testes de manuteno para a desabilitao de um sistema podem incluir os testes de migrao
de dados ou de arquivo, caso sejam necessrios longos perodos de reteno de dados.
Alm de testar o que foi alterado, os testes de manuteno incluem uma extenso de testes de
regresso s partes do sistema que no foram alteradas. O mbito dos testes de manuteno est
relacionado com o risco das alteraes, com a dimenso do sistema existente bem como a
dimenso da alterao. Dependendo das alteraes, os testes de manuteno podem ser efetuados
em qualquer ou em todos os nveis de teste e para todo e qualquer tipo de teste. Determinar como o
sistema existente pode ser afetado pelas alteraes a chamada anlise de impacto, que se utiliza
para ajudar deciso da abrangncia dos testes de regresso a efetuar. A anlise de impacto pode
ser usada para determinar o conjunto de testes de regresso a executar.
Os testes de manuteno podem ser difceis, se as especificaes estiverem desatualizadas, forem
inexistentes, ou os testadores (testers) com o conhecimento necessrio no estiverem disponveis.
Referncias
2.1.3 CMMI, Craig, 2002, Hetzel, 1988, IEEE 12207
2 2. Hetzel, 1988
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, 1988
2.3.4 Hetzel, 1988, IEEE STD 829-1998
Verso 2011
Pgina 31 de 85
01-Abr-2011
2.4 Black, 2001, Craig, 2002, Hetzel, 1988, IEEE STD 829-1998
Verso 2011
Pgina 32 de 85
01-Abr-2011
3. Tcnicas Estticas (K2)
60 minutos
Objetivos de Aprendizagem para Tcnicas Estticas

mdulo.
3.1. Tcnicas Estticas e o Processo de Teste (K2)

LO-3.1.1.
LO-3.1.2.
LO-3.1.3.
Reconhecer os produtos de trabalho de software que possam ser sujeitos a exame

pelas diversas tcnicas estticas (K1).
Descrever a importncia e valor de considerar as tcnicas estticas na avaliao de
produtos de trabalho de software (K2).
Explicar a diferena entre tcnicas estticas e dinmicas, tendo em conta os objetivos,
tipos de defeitos a identificar e a funo destas tcnicas no mbito do ciclo de vida do
software (K2).
3.2. Processo de Reviso (K2)

LO-3.2.1.
LO-3.2.2.
LO-3.2.3.
Recordar as atividades, funes e responsabilidades de uma reviso formal tpica

(K1).
Explicar as diferenas entre os diferentes tipos de revises: reviso informal, reviso
tcnica, travessia e inspeo (K2).
Explicar os fatores de sucesso no desempenho das revises (K2).
3.3. Anlise Esttica via Ferramentas (K2)

LO-3.3.1.
LO-3.3.2.
LO-3.3.3.
Verso 2011
Recordar os defeitos e erros tpicos detetados pela anlise esttica e compar-los com
as revises e testes dinmicos (K1).
Descrever, por exemplos, os benefcios tpicos da anlise esttica (K2).
Listar os defeitos tpicos de cdigo e conceo que podem ser detetados pelas
ferramentas de anlise esttica (K1).
Pgina 33 de 85
01-Abr-2011
3.1. Tcnicas Estticas e o Processo de Teste

(K2)
15 minutos
Termos
Testes dinmicos, testes estticos
Conhecimento
Contrariamente ao que acontece com os testes dinmicos, que requerem a execuo do software,
as tcnicas de teste esttico assentam na anlise manual (revises) e automatizada (anlise
esttica) do cdigo ou de qualquer outra documentao de projeto sem a execuo do cdigo
propriamente dito.
As revises so uma forma de testar produtos de trabalho de software (incluindo cdigo) e podem
ser efetuadas muito antes da execuo dinmica de testes. Os defeitos detetados durante as
revises em momentos iniciais do ciclo de vida (p. ex. defeitos detetados nos requisitos) so muitas
vezes muito mais baratos de remover do que aqueles detetados ao executar testes no cdigo
executado.
A reviso pode ser feita na ntegra como uma atividade manual, mas existem tambm ferramentas
de suporte. A principal atividade manual examinar um produto de trabalho e fazer comentrios
sobre este. Qualquer produto de trabalho de software pode ser revisto, incluindo especificao de
requisitos, especificaes de conceo, cdigo, planos de teste, especificaes de teste, casos de
teste, guies de teste, manuais de utilizao ou pginas da web.
Os benefcios das revises incluem a deteo precoce e correo de defeitos, melhoria da
produtividade do desenvolvimento, reduo de prazos de desenvolvimento, reduo de custos e
tempo de testes, reduo do custo de vida do projeto, reduo de defeitos e comunicao
melhorada. As revises podem detetar omisses, por exemplo, em requisitos que so improvveis
de serem encontrados nos testes dinmicos.
As revises, a anlise esttica e os testes dinmicos tm o mesmo objetivo: identificar defeitos. So
complementares, sendo que as diferentes tcnicas podem encontrar diferentes tipos de defeitos de
forma eficaz e eficiente. Comparadas aos testes dinmicos, as tcnicas estticas encontram as
causas de falhas (defeitos) mais do que as falhas em si.
Os defeitos tpicos que so mais fceis de encontrar em revises do que em testes dinmicos so:
desvios s normas, defeitos de requisitos, defeitos de conceo, manutenibilidade ineficiente e
especificaes de interface incorretas.
Verso 2011
Pgina 34 de 85
01-Abr-2011
3.2. Processo de Reviso (K2)
25 minutos
Termos
Critrio de entrada, reviso formal, reviso informal, inspeo, mtrica, moderador, reviso de pares,
revisor, redator, reviso tcnica, travessia
Conhecimento
Os diferentes tipos de revises variam desde a informal, caracterizada pela falta de instrues
escritas para os revisores, at sistemtica, caracterizada pela incluso da participao da equipa,
documentao dos resultados da reviso e procedimentos para a realizao da reviso. A
formalidade de um processo de reviso est relacionada com fatores como a maturidade do
processo de desenvolvimento, requisitos legais ou regulamentares ou a necessidade de um
caminho de auditoria.
A maneira como a reviso realizada depende dos objetivos acordados da reviso (p. ex. encontrar
defeitos, adquirir conhecimento, educar testadores (testers) e membros novos da equipa, ou
discusso e deciso por consenso).
3.2.1.
Atividades de uma Reviso Formal
(K1)
Uma reviso formal tpica tem as seguintes atividades principais:

1.
Planeamento:
o
Definio de critrios de reviso.
o
Seleo de pessoal.
o
Alocao de funes.
o
Definio de critrios de entrada e sada para os tipos de reviso mais formal (ex.
inspees).
o
Seleo das partes do documento a rever.
2.
Kick-off:
o
Distribuio de documentos.
o
Explicao de objetivos, processo e documentos aos participantes.
3.
Preparao individual:
o
Preparao para a reunio de reviso atravs da reviso de documentos.
o
Anotao de defeitos potenciais, dvidas e comentrios.
4.
Exame/avaliao/registo de resultados (da reunio de reviso):

o
Discusso ou registo, com resultados documentados ou minutas (para os tipos de reviso
mais formal).
o
Anotao de defeitos, recomendaes respeitantes ao tratamento de defeitos, tomada de
decises acerca dos defeitos.
o
Exame/avaliao e registo durante qualquer reunio presencial ou acompanhamento de
qualquer grupo de comunicaes eletrnicas.
5.
Refazer o trabalho
o
Correo de defeitos detetados (tipicamente feito pelo autor):
o
Registo do estado atualizado de defeitos (em revises formais).
Follow-up:
Verso 2011
Pgina 35 de 85
01-Abr-2011
o
o
o
3.2.2..
Verificao do tratamento de defeitos.

Recolha de mtricas.
Verificao de critrios de sada (para tipos de reviso mais formal).
Funes e Responsabilidades (K1)
Uma reviso formal tpica inclui as funes abaixo:

o
Gestor: decide sobre a realizao das revises, aloca tempo nos calendrios de projetos e
determina se os objetivos da reviso foram atingidos.
o
Moderador: pessoa que conduz a reviso do documento ou conjunto de documentos,
incluindo o planeamento da reviso, execuo da reunio, e acompanhamento ps reunio.
Se necessrio, o moderador pode mediar os diferentes pontos de vista e o responsvel
pelo sucesso da reviso.
o
Autor: quem escreveu o(s) documento(s) ou algum com responsabilidade hierrquica
sobre o(s) documento(s) a rever.
o
Revisores: indivduos com perfil tcnico ou de negcio especfico (igualmente
denominados de checkers ou inspetores) que, aps a devida preparao, identificam e
descrevem os resultados (p. ex. defeitos) do produto em reviso. Os revisores devem ser
escolhidos para representar diferentes funes e perspetivas no processo de reviso, e
devero participar em quaisquer reunies de reviso.
o
Redator (ou anotador): documenta todas as questes, problemas e pontos em aberto
identificados no decorrer da reunio.
Olhando para produtos de software ou produtos de trabalho relacionados a partir de diferentes
perspetivas e usando listas de verificao podem fazer-se revises de forma mais eficaz e eficiente.
Por exemplo, uma lista de verificao com base em vrias perspetivas, como a do utilizador, da
manuteno, do testador (tester) ou das operaes, ou uma lista de verificao de problemas tpicos
de requisitos pode ajudar a descobrir problemas no detetados anteriormente.
3.2.3.
Tipos de Reviso (K2)
Um nico produto de software ou produto de trabalho relacionado pode ser sujeito a mais do que
uma reviso. Se mais do que um tipo de reviso for usado, a sua ordem pode variar. Por exemplo,
uma reviso informal pode ser realizada antes de uma reviso tcnica, uma inspeo pode ser
efetuada sobre uma especificao de requisitos antes de travessia com o cliente. As principais
caractersticas, opes e efeitos dos tipos de reviso comuns so:
Reviso Informal
o No existe um processo formal.
o Pode tomar o seguinte formato: programao em pares ou um lder tcnico que rev a
conceo e o cdigo.
o Os resultados devem ser documentados.
o A sua utilidade pode variar dependendo dos revisores envolvidos.
o Principal finalidade: a forma mais econmica de obter algum benefcio.
Travessia
o A reunio liderada pelo autor.
o Pode tomar a forma de cenrios, dry runs, participao em grupos de pares.
o Sesses abertas:
Reunio de preparao opcional dos revisores.
Preparao opcional de um relatrio de reviso incluindo a lista de resultados.
o Redator opcional (que no seja o autor).
o Pode variar entre o muito informal e o muito formal.
o Principal finalidade: aprender, ganhar conhecimento, encontrar defeitos.
Verso 2011
Pgina 36 de 85
01-Abr-2011
Reviso Tcnica
o Uma atividade devidamente documentada, assim como todo o processo de deteo de
defeitos, definido incluindo pares e especialistas tcnicos com a opo da participao
de gesto.
o Pode ser executado como uma reviso de pares sem a participao da gesto.
o Idealmente liderada por um moderador treinado (que no o autor).
o Deve ocorrer uma reunio de preparao pelos revisores.
o O uso de listas de verificao opcional.
o Preparao de um relatrio de reviso que deve incluir a lista de resultados, o veredicto
sobre se o produto de software cumpre ou no os requisitos e, caso seja apropriado, as
recomendaes relativas aos resultados obtidos.
o Pode variar entre o muito informal e o muito formal.
o Principal finalidade: discutir questes detetadas, tomar decises, avaliar alternativas,
detetar defeitos, resolver problemas tcnicos e verificar a conformidade com as
especificaes, planos, regulamentaes e normas.
Inspeo
o Liderada por um moderador treinado (que no o autor).
o Geralmente realizado como um exame em pares.
o Funes definidas.
o Inclui recolha de mtricas.
o O processo formal baseado em regras e listas de verificao.
o Critrios de entrada e sada especficos para a aceitao do produto de software.
o Reunio de preparao.
o Relatrio de inspeo, incluindo a lista de resultados.
o Processo de follow-up formal (com componentes opcionais de melhoria de processo).
o Leitor opcional.
o Principal finalidade: detetar defeitos.
Travessia, revises tcnicas e inspees podem ser efetuados dentro de um grupo de pares, ou seja
colegas do mesmo nvel organizacional. Este tipo de reviso chamado reviso por pares.
3.2.4.
Fatores de Sucesso para as Revises (K2)
Fatores de sucesso para as revises incluem:

o Cada reviso tem objetivos claros e predefinidos.
o So envolvidas as melhores pessoas para efetuar a reviso.
o Os testadores (testers) so revisores valorizados que contribuem para a reviso e tambm
aprendem sobre o produto que lhes permite preparar os testes antecipadamente.
o Os defeitos detetados so bem-vindos e objetivamente manifestados.
o Abordam-se questes e aspetos psicolgicos de pessoas (p. ex. tornando-os numa
experincia positiva para o autor).
o A reviso conduzida num clima de confiana, e o resultado no ser utilizado para a
avaliao dos participantes.
o As tcnicas de reviso aplicadas so as que se julguem adequadas de forma a alcanar
os objetivos assim como as mais adequadas para o tipo e nvel dos produtos de trabalho
de software, e revisores envolvidos.
o Listas de verificao ou funes so utilizadas caso se julguem apropriadas para
aumentar a eficcia na deteo de defeitos.
o Deve ser efetuada formao em tcnicas de reviso, em particular nas tcnicas mais
formais como as de inspeo.
o A gesto deve apoiar um bom processo de reviso (p. ex. ao incorporar o tempo adequado
para as atividades de reviso nos calendrios de projetos).
Verso 2011
Pgina 37 de 85
01-Abr-2011
Existe uma nfase na aprendizagem e melhoria de processos.
Verso 2011
Pgina 38 de 85
01-Abr-2011
3.3. Anlise Esttica via Ferramentas (K2)
20 minutos
Termos
Compilador, complexidade, fluxo de controlo, fluxo de dados, anlise esttica
Conhecimento
O objetivo da anlise esttica encontrar defeitos no cdigo fonte do software assim como em
modelos de software. Este tipo de anlise efetuado sem realmente executar o software em testes
pela ferramenta, em oposio aos testes dinmicos que executam efetivamente o cdigo. A anlise
esttica pode localizar defeitos mais difceis de encontrar em testes dinmicos. Tal como nas
revises, a anlise esttica deteta defeitos em vez de falhas. As ferramentas de anlise esttica
analisam o cdigo do software (p. ex. fluxos de controlo e fluxos de dados), assim como os
resultados produzidos, tais como HTML e XML.
O valor da anlise esttica o seguinte:
o Deteo de defeitos antes ainda da execuo de testes.
o Alerta antecipado sobre aspetos suspeitos no cdigo ou na conceo pelo clculo de
mtricas, tais como medidas de complexidade elevada .
o Identificao de defeitos menos fceis de detetar via testes dinmicos.
o Deteo de dependncias e inconsistncias nos modelos de software tais como ligaes.
o Melhoria da manutenibilidade de cdigo e conceo.
o Preveno de defeitos, se forem apreendidas lies no desenvolvimento.
Os defeitos tpicos descobertos por ferramentas de anlise esttica so:
o Referncias a variveis com valores indefinidos.
o Interfaces inconsistentes entre os mdulos e componentes.
o Variveis no utilizadas ou no corretamente declaradas.
o Cdigo inatingvel (morto).
o Lgica errada ou inexistente (potenciais ciclos (loops) infinitos).
o Construes excessivamente complexas.
o Violaes de normas de programao.
o Vulnerabilidades de segurana.
o Violaes de sintaxe no cdigo e modelos de software.
As ferramentas de anlise esttica so geralmente utilizadas pelos programadores (verificando o
seu trabalho de acordo com as regras predefinidas ou normas de programao) antes e durante os
testes de componentes e de integrao ou ao efetuar o check-in de cdigo nas ferramentas de
gesto de configuraes, e pelos designers durante a fase de modelao do software. Estas
ferramentas podem ainda produzir um grande nmero de mensagens de alerta, que precisam de ser
bem geridas de forma a permitir uma utilizao mais eficaz da ferramenta.
Os compiladores podem dar algum suporte na 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 2011
Pgina 39 de 85
01-Abr-2011
4. Tcnicas de Conceo de Testes (K4)
285 minutos
Objetivo de Aprendizagem para Tcnicas de Conceo de Testes

mdulo.
4.1. O Processo de Desenvolvimento de Testes (K3)

LO-4.1.1.
LO-4.1.2.
LO-4.1.3.
LO-4.1.4.
Diferenciar entre uma especificao da conceo de testes, uma especificao de

caso de teste e uma especificao do procedimento de teste (K2).
Comparar os seguintes termos: condio de teste, caso de teste e procedimento de
teste (K2).
Avaliar a qualidade dos casos de teste face a um nvel claro de rastreabilidade com os
requisitos e resultados esperados (K2).
Traduzir casos de teste em especificaes de procedimentos de teste bem
estruturadas e com um nvel de detalhe relevante para o conhecimento dos testadores
(testers) (K3).
4.2. Categorias das Tcnicas de Conceo de Testes (K2)

LO-4.2.1.
LO-4.2.2.
Recordar as razes pelas quais as tcnicas de conceo de testes, baseadas nas

especificaes (caixa-preta) e baseadas na estrutura (caixa-branca), so teis e listar
as tcnicas comuns a ambas (K1).
Explicar as caractersticas, semelhanas e diferenas entre testes baseados nas
especificaes, testes baseados na estrutura e testes baseados na experincia (K2).
4.3. Tcnicas Baseadas nas Especificaes ou Caixa-Preta (K3)

LO-4.3.1.
LO-4.3.2.
LO-4.3.3.
Escrever casos de teste com base em modelos de software fornecidos utilizando a

partio por equivalncias, a anlise de valor fronteira, tabelas de deciso e
diagramas/tabelas de transio de estados (K3).
Explicar o objetivo principal de cada uma das quatro tcnicas de teste, qual o nvel e
tipo de teste que pode utilizar cada tcnica, e de que forma podemos medir a cobertura
(K2).
Explicar o conceito de testes de casos de uso e os seus benefcios (K2).
4.4 Tcnicas Baseadas na Estrutura ou Caixa-Branca (K4)

LO-4.4.1.
LO-4.4.2.
LO-4.4.3.
LO-4.4.4.
Descrever o conceito e valor da cobertura de cdigo (K2).

Explicar os conceitos de cobertura de instrues ou decises, fundamentando a sua
utilizao a outros nveis de teste que no os testes de componentes (p. ex. ao nvel de
teste de sistema em procedimentos de negcio) (K2).
Escrever casos de teste a partir de fluxos de controlo utilizando as tcnicas de
conceo de testes por instruo ou deciso (K3).
Avaliar a cobertura de instrues e decises face ao cumprimento integral de critrios
de sada definidos (K4).
4.5. Tcnicas baseadas na Experincia (K2)

LO-4.5.1.
LO-4.5.2.
Recordar as razes de conceber casos de teste com base na intuio, experincia e

conhecimento sobre defeitos comuns (K1).
Comparar as tcnicas baseadas na experincia com as tcnicas baseadas nas
especificaes (K2).
4.6. Escolher as Tcnicas de Teste (K2)

Verso 2011
Pgina 40 de 85
01-Abr-2011
LO-4.6.1.
Verso 2011
Classificar as tcnicas de conceo de testes de acordo com o seu enquadramento

com o contexto, a base para testes, respetivos modelos e caractersticas do software
(K2).
Pgina 41 de 85
01-Abr-2011
4.1. O Processo de Desenvolvimento de Testes

(K3)
15 minutos
Termos
Especificao de casos de teste, conceo de teste, calendrio de execues de testes,

especificao de procedimentos de teste, guies de teste, rastreabilidade
Conhecimento
O processo de desenvolvimento de testes descrito nesta seco pode ser concretizado de diferentes
formas, desde um modo muito informal que carece de pouca ou nenhuma documentao, at ao
muito formal (descrito de seguida). O nvel de formalidade depende do contexto dos testes, incluindo
a maturidade de teste, processos de desenvolvimento, restries de tempo, requisitos de segurana
ou regulamentares, e as pessoas envolvidas.
Durante a anlise de testes, a documentao da base para testes analisada, com o fim de
determinar o que testar, ou seja, para identificar as condies de teste. As condies de teste so
definidas como itens ou eventos que possam ser verificados por um ou mais casos de teste (p. ex.
uma funo, uma transao, caractersticas ou elementos estruturais de qualidade).
Estabelecer a rastreabilidade desde as condies de teste at s especificaes e requisitos tanto
permite uma anlise de impacto eficaz quando os requisitos mudam, como determinar a cobertura
dos requisitos para um conjunto de testes. Durante a anlise de testes, a abordagem de teste
detalhada implementada para selecionar as tcnicas de conceo de testes para usar com base,
entre outras consideraes, nos riscos identificados (ver captulo 5 para mais informaes sobre
anlise de risco).
Durante a conceo de teste, os casos de teste e dados de teste so criados e especificados. Um
caso de teste consiste num conjunto de valores de entrada, pr-condies de execuo, resultados
esperados e condies ps-execuo, definidos para cobrir determinado(s) objetivo(s) de teste ou
condio(es) de teste. A Standard for Software Test Documentation (IEEE STD 829-1998)
descreve o contedo das especificaes da conceo de testes (que contm as condies de teste)
e especificaes de caso de teste.
Os resultados esperados devem ser produzidos como parte da especificao de um caso de teste e
incluem as sadas, as alteraes aos dados e estados, e quaisquer outras consequncias do teste.
Se os resultados esperados no foram definidos, ento, um resultado plausvel, mas errado pode
ser interpretado como o correto. Os resultados esperados devem ser definidos idealmente antes da
execuo do teste.
Durante a implementao dos testes, os casos de teste so desenvolvidos, implementados,
priorizados e organizados na especificao do procedimento de teste (IEEE STD 829-1998). O
procedimento de teste especifica a sequncia de aes para a execuo de um teste. Se os testes
so executados utilizando uma ferramenta de execuo de testes, a sequncia de aes
especificada no guio de testes (que um procedimento automtico de teste).
Os vrios procedimentos de teste, assim como os vrios guies de testes automatizados so
posteriormente agrupados num calendrio de execuo de testes que define a ordem pela qual os
diferentes procedimentos de teste, e os guies de testes automatizados, possivelmente, sero
executados. O calendrio de execuo de testes levar em conta fatores como: testes de regresso,
priorizao e dependncias tcnicas e lgicas.
Verso 2011
Pgina 42 de 85
01-Abr-2011
4.2. Categorias das Tcnicas de Conceo

de Testes (K2)
15 minutos
Termos
Tcnica de conceo de testes caixa-preta, tcnica de conceo de testes baseada na experincia,

tcnica de conceo de testes, tcnica de conceo de testes caixa-branca
Conhecimento
O propsito da tcnica de conceo de testes identificar as condies, casos e dados de teste.

uma distino clssica para designar as tcnicas de teste caixa-preta ou caixa-branca. As tcnicas
de conceo de testes caixa-preta (tambm chamado de tcnica baseada nas especificaes)
uma maneira de derivar e selecionar as condies de teste, casos de teste, ou dados de teste com
base na anlise da documentao de base para testes. Isto inclui os testes funcionais e no
funcionais. Testes caixa-preta, por definio, no utilizam qualquer informao sobre a estrutura
interna do componente ou sistema a ser testado. As tcnicas de conceo de testes caixa-branca
(tambm chamadas de tcnicas estruturais ou baseadas na estrutura) so baseadas na anlise da
estrutura do componente ou sistema. Os testes caixa-preta e caixa-branca podem tambm ser
combinados em tcnicas baseadas na experincia de modo a tirar partido da experincia dos
programadores, testadores (testers) e utilizadores para determinar o que deve ou no ser testado.
Algumas tcnicas encaixam claramente numa nica categoria, enquanto outras tm elementos de
mais do que uma categoria.
Este programa refere-se s tcnicas de conceo de testes baseadas nas especificaes como as
tcnicas caixa-preta e s tcnicas de conceo de testes baseadas na estrutura como as tcnicas
caixa-branca. Adicionalmente, as tcnicas de conceo de testes baseadas na experincia esto
tambm cobertas.
As caratersticas comuns das tcnicas de conceo de testes baseadas nas especificaes
incluem:
o Modelos, quer formais ou informais, que so utilizados para a especificao do problema a
ser resolvido, o software ou os seus componentes.
o Casos de teste podem ser sistematicamente derivados destes modelos.
As caractersticas comuns das tcnicas de conceo de testes baseadas na estrutura incluem:
o A informao sobre como o software construdo utilizada para derivar os casos de teste
(p. ex. o cdigo e informaes detalhadas de conceo).
o A extenso da cobertura de software pode ser medida para os casos de teste existentes, e
casos de teste adicionais podem ser obtidos de forma sistemtica para aumentar a
cobertura.
As caractersticas comuns das tcnicas de conceo de testes baseadas na experincia incluem:
o O conhecimento e experincia de pessoas so utilizados para derivar casos de teste.
o O conhecimento dos testadores (testers), programadores, utilizadores e outras partes
interessadas sobre o software, a sua utilizao e ambiente so uma fonte de informao.
o Conhecimento sobre defeitos provveis e a sua distribuio so outra fonte de
informao.
Verso 2011
Pgina 43 de 85
01-Abr-2011
4.3. Tcnicas Baseadas nas Especificaes ou

Caixa-Preta (K3)
150 minutos
Termos
Anlise de valor fronteira, testes baseados em tabelas de deciso, particionar por equivalncias,
testes de transio de estados, testes de casos de uso.
4.3.1..
Particionar por Equivalncias (K3)
Na partio de equivalncia, os valores de entrada para o software ou sistema so divididos em

grupos em que se espera que apresentem comportamentos semelhantes, para que sejam
suscetveis de serem tratados da mesma maneira. Parties de equivalncia (ou classes) podem ser
encontrados tanto para dados vlidos, ou seja, valores que devem ser aceites, quer para dados
invlidos, ou seja, valores que devem ser rejeitados. As parties tambm podem ser identificadas
para os valores de sada, valores internos, valores relacionados com o tempo (p. ex. antes ou depois
de um evento) e para os parmetros de interface (p. ex. componentes integrados que esto em
testes durante os testes de integrao). Os testes devem ser desenhados para cobrir todas as
parties vlidas e invlidas. Partio de equivalncia aplicvel a todos os nveis de teste.
A partio de equivalncia pode ser utilizada para atingir metas de cobertura de entrada e sada.
Pode ser aplicada a entradas efetuadas por humanos, entradas atravs de interfaces de um sistema
ou parmetros de interface em testes de integrao.
4.3.2.
Anlise de Valor Fronteira (K3)
O comportamento no limite de uma partio de equivalncia mais provvel que esteja incorreto do
que o comportamento dentro da partio, assim as fronteiras so uma rea onde os testes so
suscetveis de produzir defeitos. Os valores mnimos e mximos de uma partio so os seus
valores fronteira. Um valor fronteira para uma partio vlida um valor fronteira vlido, a fronteira
de uma partio invlida um valor fronteira invlido. Os testes podem ser desenhados para cobrir
ambos os valores fronteira vlidos e invlidos. Ao conceber casos de teste, um teste escolhido
para cada valor fronteira.
A anlise de valor fronteira pode ser aplicada a todos os nveis de teste. relativamente fcil de
aplicar e a sua capacidade de deteo de defeitos alta. As especificaes detalhadas so teis na
determinao das fronteiras que nos interessam.
Esta tcnica muitas vezes considerada como uma extenso da partio de equivalncias ou outra
tcnica de conceo de testes caixa-preta. Pode ser utilizado em classes de equivalncia para as
entradas do utilizador no ecr, bem como, por exemplo, em intervalos de tempo (p. ex. requisitos de
tempo (time out) e de velocidade transacional) ou intervalos de tabela (p. ex. o tamanho da tabela
256 * 256).
4.3.3.
Testes baseados em Tabelas de Deciso (K3)
As tabelas de deciso so uma boa forma de capturar os requisitos do sistema que apresentam
condies lgicas e de documentar a conceo interna do sistema. Podem ser utilizadas para
registar regras de negcio complexas que um sistema dever implementar. Ao criar as tabelas de
deciso, a especificao analisada, e as condies e aes do sistema so identificadas. As
condies de entrada e aes so frequentemente declaradas de tal forma que deve utilizar-se o
verdadeiro ou falso (booleano). A tabela de deciso contm as condies de interveno, muitas
vezes combinaes de falso e verdadeiro para todas as condies de entrada, e as aes
resultantes para cada combinao de condies. Cada coluna da tabela corresponde a uma regra
Verso 2011
Pgina 44 de 85
01-Abr-2011
de negcio que define uma combinao nica de condies e que resulta na execuo das aes
associadas a essa regra. A norma utilizada relativamente cobertura dos testes baseados em
tabelas de deciso ter, pelo menos, um teste por coluna na tabela, o que normalmente envolve
cobrir todas as combinaes de condies de interveno.
A potencialidade de testes baseados em tabelas de deciso a capacidade de criar combinaes de
condies que de outra forma no poderiam ter sido executadas durante o teste. Podem ser
aplicados a todas as situaes em que a ao do software depende de muitas decises lgicas.
4.3.4.
Testes de Transio de Estados (K3)
Um sistema pode apresentar uma resposta diferente, dependendo das condies atuais ou de
antecedentes (do seu estado). Neste caso, este aspeto do sistema pode ser representado por um
diagrama de transio de estados. Este tipo de teste permite que o testador (tester) visualize o
software em termos dos seus estados, transies entre estados, entradas ou eventos que provocam
mudanas de estado (transies) e as aes que possam advir dessas transies. Os estados do
sistema ou objeto sob teste so independentes, identificveis e em nmero finito.
A tabela de estados mostra a relao entre os estados e as entradas, e pode destacar possveis
transies que so invlidas.
Os testes podem ser concebidos para cobrir uma sequncia de estados tpica, para cobrir todos os
estados, para executar cada transio, para executar sequncias especficas de transies ou testar
transies invlidas.
Os testes de transio de estados so muito utilizados na indstria de software integrado e
automatizao tcnica no geral. No entanto, esta tcnica tambm adequada para modelar objetos
de negcio com estados especficos ou testes a fluxos de ecr de dilogo (p. ex. para aplicaes de
Internet ou cenrios de negcio).
4.3.5..
Testes de Casos de Uso (K2)
Os testes podem derivar de casos de uso. Um caso de uso descreve as interaes entre os atores
(utilizadores ou sistemas), que produzem um resultado de valor para o utilizador do sistema ou para
o cliente. Os casos de uso podem ser descritos ao nvel abstrato (caso de uso de negcios,
tecnologia livre, nvel de processos de negcio) ou ao nvel do sistema (caso de uso do sistema ao
nvel da funcionalidade do sistema). Cada caso de uso tem pr-condies que precisam ser
satisfeitas para um caso de uso obter xito. Cada caso de uso termina com ps-condies, que so
os resultados observveis e o estado final do sistema aps o caso de uso ter sido concludo. Um
caso de uso tem geralmente um cenrio principal (mainstream) (ou seja, o mais provvel) e cenrios
alternativos.
Os casos de uso descrevem os fluxos de processo atravs de um sistema baseado na sua
utilizao atual real, por isso os casos de teste derivados de casos de uso so mais teis na deteo
de defeitos no processo de fluxos durante a utilizao real do sistema. Os casos de uso so muito
teis para conceber testes de aceitao com a participao do cliente/utilizador. Tambm ajudam a
detetar defeitos de integrao causados pela interao e interferncia dos diferentes componentes,
cujos testes de componentes individuais no iriam detetar. Conceber casos de teste a partir de
casos de uso pode ser combinado com outras tcnicas de teste baseadas nas especificaes.
Verso 2011
Pgina 45 de 85
01-Abr-2011
4.4. Tcnicas Baseadas na Estrutura ou

Caixa-Branca (K4)
60 minutos
Termos
Cobertura de cdigo, cobertura de decises, cobertura de instrues, testes baseados na estrutura
Conhecimento
Testes baseados na estrutura ou caixa-branca baseiam-se numa estrutura identificada do software

ou sistema, como podemos ver nos exemplos seguintes:
o Ao nvel do componente: a estrutura de um componente de software, ou seja, as suas
instrues, decises, ramos ou caminhos distintos.
o Ao nvel da integrao: a estrutura pode ser uma rvore de chamada (um diagrama no qual
mdulos invocam outros mdulos).
o Ao nvel do sistema: a estrutura pode ser um menu estruturado, um processo de negcio
ou a estrutura de uma pgina web.
Nesta seco, sero discutidas trs tcnicas de conceo de teste estrutural relacionadas com o
cdigo aplicadas nos testes sua cobertura, baseado em instrues, ramos e decises. Para os
testes de deciso, pode usar-se um diagrama de fluxo de controlo de modo a visualizar as
alternativas para cada deciso.
4.4.1.
Testes de Instruo e sua Cobertura (K4)
Em testes de componentes, a cobertura de instrues a avaliao da percentagem de instrues

executveis que tenham sido executadas por um conjunto de casos de teste. A tcnica de testes de
instruo deriva casos de teste para executar instrues especficas de forma a aumentar a
cobertura de instrues.
A cobertura de instrues determinada pelo nmero de instrues executveis cobertas por casos
de teste (desenhados ou executados), divididas pelo nmero de todas as instrues executveis do
cdigo em teste.
4.4.2.
Testes de Deciso e sua Cobertura (K4)
A cobertura de decises, relativamente aos testes de ramos, a avaliao da percentagem de

resultados de decises (p. ex. as opes Verdadeiro e Falso de uma instruo SE), que tenham sido
j executadas por um conjunto de casos de teste. A tcnica de testes de deciso deriva casos de
teste de modo a executar os resultados de decises especficas. Os ramos so originrios dos
pontos de deciso no cdigo e mostram a transferncia do controlo para diferentes localizaes do
cdigo.
A cobertura de decises determinada pelo nmero de todos os resultados de decises cobertas
por casos de teste (concebidos ou executados), dividido pelo nmero de todos os resultados de
decises possveis no cdigo em teste.
Os testes de deciso so uma forma de testes de fluxo de controlo atendendo a que seguem um
fluxo de controlo especfico atravs dos pontos de deciso. A cobertura de decises mais eficaz do
que a cobertura de instrues: 100% de cobertura de decises assegura 100% de cobertura de
instrues, mas no vice-versa.
4.4.3.
Outras Tcnicas baseadas na Estrutura (K1)
Existem nveis mais elevados de cobertura estrutural alm da cobertura de decises, por exemplo, a
cobertura de condies e a cobertura de mltiplas condies.
Verso 2011
Pgina 46 de 85
01-Abr-2011
O conceito de cobertura tambm pode ser aplicado a outros nveis de teste, por exemplo, ao nvel da
integrao, a percentagem de mdulos, componentes ou classes que tm sido executadas por um
conjunto de casos de teste pode ser expressa como cobertura de componente, mdulo ou classe.
O recurso a ferramentas muito til para os testes de cdigo estruturais.
Verso 2011
Pgina 47 de 85
01-Abr-2011
4.5. Tcnicas baseadas na Experincia (K2)
30 minutos
Termos
Testes exploratrios, ataque (a falha)
Conhecimento
Os testes baseados na experincia so testes derivados da habilidade e intuio do testador

(tester), assim como da sua experincia com aplicaes ou tecnologias similares. Quando utilizado
para reforar as tcnicas sistemticas, estas tcnicas podem ser teis na identificao de testes
especiais menos fceis de capturar pelas tcnicas formais, especialmente quando aplicadas aps
abordagens mais formais. Contudo, esta tcnica poder produzir variados graus de eficcia,
dependendo da experincia do testador (tester).
A tcnica baseada na experincia mais utilizada a de antecipar erros. Geralmente, os testadores
(testers) antecipam os defeitos com base na sua experincia. Uma abordagem estruturada para a
tcnica de antecipar erros enumerar uma lista de possveis defeitos e conceber os testes para
atacar esses defeitos. Esta abordagem sistemtica normalmente denominada por ataque. Estas
listas de defeitos e falhas podem ser construdas com base na experincia, defeitos disponveis e
dados de falhas, e do conhecimento comum sobre as razes de falhas do software.
Os testes exploratrios pressupem a conceo de testes simultaneamente com a execuo dos
mesmos, o registo de testes e a aprendizagem, com base numa carta de testes contendo os
objetivos de teste, e realizados dentro de perodos de tempo. uma abordagem mais til quando
existem poucas especificaes ou as existentes so inadequadas e existem presses de tempo
severas ou com o objetivo de aumentar ou complementar um teste mais formal. Pode servir como
uma verificao do processo de testes que ajuda a garantir que os defeitos mais graves so
encontrados.
Verso 2011
Pgina 48 de 85
01-Abr-2011
4.6 Escolher as Tcnicas de Teste (K2)
15 minutos
Termos
No existem termos especficos.
Conhecimento
A escolha de quais tcnicas de teste a utilizar depende de diversos fatores, incluindo o tipo de
sistema, normas de regulamentao, requisitos de cliente ou contratuais, nvel de risco, tipo de risco,
objetivos de teste, documentao disponvel, conhecimento dos testadores (testers), tempo e
oramento, ciclo de vida de desenvolvimento, modelos de caso de uso e experincias anteriores
sobre tipos de defeitos detetados anteriormente.
Algumas tcnicas so mais aplicveis a certas situaes e nveis de teste, enquanto outras so
aplicveis a todos os nveis de teste.
Aquando da criao de casos de teste, os testadores (testers) geralmente utilizam a combinao de
tcnicas de teste incluindo processos, regras e tcnicas orientadas a dados de modo a assegurar a
cobertura mais adequada do objeto em testes.
Referncias
4.1. Craig, 2002, Hetzel, 1988, IEEE STD 829-1998

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 2011
Pgina 49 de 85
01-Abr-2011
5. Gesto de Testes (K3)
170 minutos
Objetivos de Aprendizagem para Gesto de Testes

mdulo.
5.1. A Organizao de Testes (K2)

LO-5.1.1.
LO-5.1.2.
LO-5.1.3.
LO-5.1.4.
Identificar a importncia de testes independentes (K1).

Explicar as vantagens e inconvenientes de testes independentes dentro da
organizao (K2).
Identificar os diferentes elementos da equipa a considerar na criao de uma equipa
de testes (K1).
Recordar as tarefas de um tpico lder de teste e de um testador (tester)) (K1).
5.2. Estimativa e Planeamento de Testes (K3)

LO-5.2.1.
LO-5.2.2.
LO-5.2.3.
LO-5.2.4.
LO-5.2.5.
LO-5.2.6.
LO-5.2.7.
LO-5.2.8.
LO-5.2.9.
Identificar os diferentes nveis e objetivos do planeamento de testes (K1).

Resumir o propsito e contedo de documentos de plano de testes, especificao de
conceo de testes e procedimentos de teste de acordo com Standard for Software
Test Documentation (IEEE Std 829-1998) (K2).
Diferenciar entre as diferentes abordagens de teste, tais como: analticas, baseadas
em modelos, metdicas, de conformidade de processos/normas,
dinmicas/heursticas, consultivas e avessas regresso (K2).
Diferenciar entre o assunto do planeamento de testes para um sistema e a
calendarizao da execuo de testes (K2).
Escrever um calendrio de execuo de testes para um conjunto de casos de teste
dados, considerando a priorizao, e as dependncias tcnicas e lgicas (K3).
Preparao de listas de testes e atividades de execuo que devem ser consideradas
durante o planeamento de testes (K1).
Recordar os fatores que tipicamente influenciam o esforo relacionado com testes
(K1).
Diferenciar entre duas abordagens de estimativa conceptualmente diferentes: a
abordagem baseada em mtricas e a abordagem baseada no especialista (K2).
Identificar/justificar critrios de entrada e sada adequados para nveis de teste
especficos e grupos de casos de teste (p. ex. para testes de integrao, testes de
aceitao ou casos de teste de usabilidade) (K2).
5.3. Monitorizao e Controlo de Progresso de Testes (K2)

LO-5.3.1.
LO-5.3.2.
LO-5.3.3.
Recordar as mtricas mais utilizadas na monitorizao da preparao e execuo de

testes (K1).
Explicar e comparar as mtricas de teste para relatrios e controlo de testes (p. ex.
defeitos detetados e corrigidos, e testes que passaram e que falharam) relativamente
sua finalidade e utilizao (K2).
Resumir o objetivo e o contedo do documento de relatrio de teste de acordo com a
norma Standard for Software Test Documentation (IEEE Std 829-1998) (K2).
5.4. Gesto de Configuraes (K2)

LO-5.4.1.
Resumir a forma como a gesto de configuraes suporta a atividade de testes (K2).
5.5. Riscos e Testes (K2)
Verso 2011
Pgina 50 de 85
01-Abr-2011
LO-5.5.1.
LO-5.5.2.
LO-5.5.3.
LO-5.5.4.
LO-5.5.5.
Descrever o risco como um possvel problema que pode ser considerado como
ameaa concretizao de um ou mais objetivos de projeto das partes envolvidas
(K2).
Recordar que o nvel de risco determinado pela probabilidade (de acontecer) e o
impacto (dano resultante caso se concretize) (K1).
Distinguir entre os riscos de projeto e os riscos de produto (K2).
Identificar os riscos de produto e de projeto tpicos (K1).
Descrever, utilizando exemplos, como que a anlise e gesto de riscos podem ser
utilizadas no planeamento de testes (K2).
5.6. Gesto de Incidentes (K3)

LO-5.6.1.
LO-5.6.2.
Verso 2011
Identificar o contedo de um relatrio de incidentes de acordo com a norma Standard

for Software Test Documentation (IEEE Std 829-1998) (K1).
Escrever um relatrio de incidentes cobrindo a observao de uma falha durante os
testes (K3).
Pgina 51 de 85
01-Abr-2011
5.1. Organizao de Testes (K2)
30 minutos
Termos
Testador (tester), lder de teste, gestor de testes
5.1.1.
Organizao e Independncia de Testes (K2)
A eficcia da deteo de defeitos atravs dos testes e revises pode ser melhorada pela utilizao
de testadores (testers) independentes. As escolhas ao nvel da independncia incluem o seguinte:
o No existem testadores (testers) independentes e so os programadores que testam o seu
prprio cdigo.
o Testadores (testers) independentes includos nas equipas de desenvolvimento.
o Uma equipa ou grupo de testes independentes, que fazem parte da organizao, reportam
gesto de projetos ou gesto executiva.
o Testadores (testers) independentes que fazem parte da comunidade de utilizadores ou da
organizao empresarial.
o Especialistas de testes independentes para tipos de teste especficos, tais como:
testadores (testers) de usabilidade, segurana ou certificao (que certificam produtos de
software de acordo com as normas e regulamentaes).
o Testadores (testers) independentes em regime de outsourcing ou simplesmente externos
organizao.
Em projetos de grande dimenso, complexidade ou segurana crtica, aconselhvel ter mltiplos
nveis de teste, com alguns ou todos os nveis efetuados por testadores (testers) independentes. O
pessoal de desenvolvimento pode participar nos testes, em particular nos nveis mais baixos, mas a
sua falta de objetividade muitas vezes limita a sua eficcia. Os testadores (testers) independentes
podem ter a autoridade de definir e exigir processos e regras de teste, mas os testadores (testers)
devem apenas assumir tais funes relacionadas com o processo quando a gesto lhes delega
oficialmente tal tarefa.
As vantagens da independncia incluem:
o Os testadores (testers) independentes tm a capacidade de ver diferentes defeitos, e so
imparciais.
o Um testador (tester) independente pode verificar suposies assumidas durante a
especificao e implementao do sistema.
As desvantagens incluem:
o Isolamento da equipa de desenvolvimento (se tratado como totalmente independente).
o Os programadores podem perder o sentido de responsabilidade pela qualidade.
o Os testadores (testers) independentes podem ser vistos como um ponto de bloqueio ou
como culpados de atrasos no lanamento de verses.
As tarefas de teste podem ser efetuadas por pessoas com funes de teste especficas ou podem
ser feitas por algum com outra funo, como um gestor de projeto, gestor de qualidade,
programador, especialista de negcio ou domnio, operador de infraestruturas ou de TI.
5.1.2.
Tarefas do Lder de Teste e Testador (tester) (K1)
Neste programa, vamos cobrir duas figuras/posies de teste: o lder de teste e o testador (tester).
As atividades e tarefas efetuadas pelas pessoas destas duas funes dependem do projeto e
contexto do produto, das pessoas e da organizao em si.
Por vezes o lder de teste denominado gestor de testes ou coordenador de testes. A funo do
lder de testes pode ser desempenhada por um gestor de projetos, um gestor de desenvolvimento,
Verso 2011
Pgina 52 de 85
01-Abr-2011
um gestor de garantia de qualidade ou pelo gestor de um grupo de testes. Em projetos de maior

dimenso podem existir duas figuras/posies: lder de teste e gestor de testes. Tipicamente, o lder
de teste planeia, monitoriza e controla as atividades de teste e tarefas tal como definido na seco
1.4.
As tarefas tpicas do lder de teste podem incluir:
o Coordenar a estratgia de teste e planear com os gestores de projeto e outros.
o Escrever ou rever a estratgia de teste para o projeto, e a poltica de teste para a
organizao.
o Contribuir com a perspetiva de teste para outras atividades do projeto, tais como, o plano
de integrao.
o Planear os testes considerando o contexto e compreenso de objetivos e riscos de testes
incluindo a seleo de abordagens de teste, efetuar as estimativas de tempo, esforo e
custo de testes, obter os recursos que julgar necessrios ao projeto, definir os nveis de
teste, os ciclos necessrios e planear a gesto de incidentes.
o Iniciar a especificao, preparao, implementao e execuo de testes, monitorizar os
resultados de testes e verificar os critrios de sada.
o Adaptar o plano com base nos resultados e progresso de testes (muitas vezes
documentados nos relatrios de ponto de situao (status)) e tomar qualquer ao
necessria para compensar problemas ocorridos.
o Assegurar a correta gesto de configuraes de testware para a rastreabilidade.
o Introduzir mtricas adequadas para aferir o progresso de testes e a avaliao da qualidade
de testes e do produto.
o Decidir o que deve ser automatizado, em que grau, e como.
o Selecionar as ferramentas de suporte aos testes e organizar as formaes para os
testadores (testers) no uso das mesmas.
o Decidir sobre a implementao do ambiente de teste.
o Escrever os relatrios de teste com base na informao recolhida durante os testes.
As tarefas tpicas do testador (tester) podem incluir:
o Rever e contribuir para os planos de testes.
o Analisar, rever e avaliar os requisitos do utilizador, as especificaes e modelos face sua
testabilidade.
o Criar especificaes de testes.
o Assegurar a criao do ambiente de teste (muitas vezes coordenando com a administrao
de sistemas e com a gesto de redes).
o Preparar e obter os dados de teste.
o Implementar testes em todos os nveis de teste, executar e efetuar registos de testes,
avaliar os resultados e documentar os desvios aos resultados esperados.
o Usar ferramentas de administrao e gesto de testes, assim como ferramentas de
monitorizao de testes, de acordo com o exigido.
o Automatizar os testes (pode ser suportado por um programador ou por um especialista em
automatizao de testes).
o Medir o desempenho (performance) de componentes e sistemas (se aplicvel).
o Rever testes desenvolvidos por outros.
Quem trabalha em anlise de testes, conceo de testes, tipos especficos de testes ou
automatizao de testes pode ser especialista destas funes. Dependendo do nvel de teste e dos
respetivos riscos do produto e projeto, diferentes pessoas podem assumir a funo de testador
(tester), mantendo assim algum grau de independncia. Tipicamente, os testadores (testers) do nvel
de componentes ou integrao so programadores, os testadores (testers) no nvel de testes de
aceitao podem ser especialistas de negcio ou utilizadores, e os testadores (testers) de testes de
aceitao operacionais podem ser operadores.
Verso 2011
Pgina 53 de 85
01-Abr-2011
5.2. Estimativa e Planeamento de Testes (K3)
40 minutos
Termos
Abordagem de teste, estratgia de teste
5.2.1.
Planeamento de Testes (K2)
Esta seco aborda a finalidade do planeamento de testes dentro de projetos de desenvolvimento e

implementao assim como para as atividades de manuteno. Este planeamento pode ser
documentado num plano mestre de testes e em planos de testes separados para nveis de teste tais
como testes de sistema e testes de aceitao. O esboo de um documento de planeamento de
testes coberto pela norma Standard for Software Test Documentation (IEEE Std 829-1998).
O planeamento influenciado pela poltica de teste da organizao, mbito de teste, objetivos,
riscos, limitaes, aspeto crtico, testabilidade e disponibilidade de recursos. Ao longo do progresso
do projeto e do planeamento de testes, mais informao se torna disponvel permitindo a incluso de
mais detalhes no plano.
O planeamento de testes uma atividade contnua e deve ser efetuada ao longo de todos os
processos e atividades do ciclo de vida. O retorno (feedback) das atividades de teste utilizado para
identificar alteraes aos riscos de forma a poder ajustar-se o plano de acordo com os mesmos.
5.2.2.
Atividades de Planeamento de Testes (K3)
As atividades de planeamento de testes de um sistema completo ou de parte do mesmo, podem

incluir:
o Determinar o mbito e riscos assim como identificar os objetivos de teste.
o Definir a abordagem global para os testes, incluindo a definio dos nveis de teste e seus
critrios de entrada e sada.
o Integrar e coordenar as atividades de teste dentro das atividades do ciclo de vida do
software (aquisio, fornecimento, desenvolvimento, operao e manuteno).
o Tomar decises sobre o que testar, quem assumir a responsabilidade da execuo das
atividades de teste, como devem ser feitas, e como devem ser avaliados os resultados de
testes.
o Agendar as atividades de anlise e conceo de teste.
o Agendar a implementao, execuo e avaliao de testes.
o Atribuir recursos s diferentes atividades definidas.
o Definir a dimenso, nvel de detalhe, estrutura e modelos da documentao de testes.
o Selecionar mtricas para a monitorizao e controlo de preparao e execuo de testes,
para a resoluo de defeitos e questes de risco.
o Definir o nvel de detalhe de procedimentos de teste de modo a fornecer informao
suficiente para suportar a preparao e execuo de testes reprodutveis.
5.2.3..
Critrios de Entrada (K2)
Os critrios de entrada definem quando devem comear os testes, o que poder ocorrer no incio de
um nvel de teste ou quando um conjunto de testes est pronto para ser executado.
Tipicamente, os critrios de entrada podem cobrir o seguinte:
o Disponibilidade e prontido do ambiente de teste.
o Prontido da ferramenta de teste no ambiente de teste.
o Disponibilidade do cdigo a testar
o Disponibilidade dos dados de teste.
Verso 2011
Pgina 54 de 85
01-Abr-2011
5.2.4.
Critrios de Sada (K2)
Os critrios de sada definem quando se deve parar de testar, o que pode ocorrer no final de um
nvel de teste ou quando um conjunto de testes alcana um objetivo especfico.
Tipicamente, os critrios de sada podem cobrir o seguinte:
o
o
o
o
o
5.2.5..
Medidas de rigor, tais como: cobertura de cdigo, funcionalidade ou risco

Estimativas de densidade de defeitos ou medidas de fiabilidade.
Custo.
Riscos residuais, tais como, defeitos no corrigidos ou falta de cobertura de teste em certas
reas.
Calendrios baseados em tempos de resposta ao mercado (time to market).
Estimativa de Teste (K2)
Duas abordagens possveis estimativa do esforo de teste so:

o Abordagem baseada nas mtricas: estimar o esforo de teste com base nas mtricas de
projetos anteriores e similares ou com base em valores tpicos.
o Abordagem baseada no especialista: estimar as tarefas com base nas estimativas
efetuadas pelos responsveis (owner) das tarefas ou por especialistas nas mesmas.
Aps a estimativa do esforo de teste, os recursos podem ser identificados e o calendrio pode ser
elaborado.
O esforo de teste pode depender de fatores como:
o Caractersticas do produto: a qualidade da especificao e outra informao utilizada para
modelos de teste (i.e. a base para testes), a dimenso do produto, a complexidade do
domnio do problema, os requisitos de fiabilidade e segurana, e os requisitos de
o
documentao
Caractersticas do processo de desenvolvimento: a estabilidade da organizao,
ferramentas utilizadas, processo de teste, aptido das pessoas envolvidas e presses de
tempo.
Os resultados dos testes: nmero de defeitos e dimenso de retrabalho que envolve
5.2.6.
Estratgia de Teste, Abordagem de Teste (K2)
A abordagem de teste a implementao da estratgia de teste num projeto concreto. Esta

abordagem de teste definida e refinada nos planos e conceo de teste. Normalmente inclui as
decises tomadas com base nos objetivos do projeto (de teste) e na avaliao de riscos. o ponto
de partida para o planeamento do processo de teste, na seleo de tcnicas de conceo de testes
e os tipos de teste a aplicar, bem como, para definir os critrios de entrada e sada.
A seleo da abordagem depende do contexto e pode considerar os riscos, perigos e segurana,
disponibilidade de recursos e aptides, da tecnologia, da natureza do sistema (p. ex. soluo
customizada vs. soluo COTS), objetivos de teste e regulamentaes.
As abordagens tpicas incluem:
o Abordagens analticas, tais como, os testes baseados na avaliao do risco onde os testes
so direcionados para as reas de maior risco.
o Abordagens baseadas em modelos, tais como os testes estocsticos utilizando informao
estatstica sobre a taxa de falhas (tais como modelos de crescimento da fiabilidade) ou uso
(como perfis operacionais).
Verso 2011
Pgina 55 de 85
01-Abr-2011
o
o
Abordagens metdicas, tais como, as baseadas em falha (incluindo antecipar erros e os

ataques a falhas), com base na experincia, com base em listas de verificao, e ainda
com base em caractersticas de qualidade.
Abordagens compatveis com processos ou normas, tais como, as especificadas por
normas de determinadas indstrias ou as vrias metodologias geis.
Abordagens dinmicas e heursticas, tais como, os testes exploratrios onde os testes so
mais reativos (aos eventos) do que previamente planeados, e onde a execuo e a
avaliao so tarefas simultneas.
Abordagens de base mais consultiva, como as que definem que a cobertura de testes
impulsionada principalmente pelo aconselhamento e orientao de tecnologia e/ou
especialistas no domnio do negcio que no pertencem equipa de testes.
Abordagens contrrias regresso, como aquelas que incluem a reutilizao de materiais
de teste existentes, automatizao extensiva de testes de regresso funcionais, e
conjuntos de testes padro.
Podem ainda combinar-se diferentes abordagens, por exemplo, uma abordagem dinmica baseada
no risco.
Verso 2011
Pgina 56 de 85
01-Abr-2011
5.3. Monitorizao e Controlo de Progresso de

Testes (K2)
20 minutos
Termos
Densidade de defeitos, taxa de falhas, controlo de testes, monitorizao de testes, relatrio de

testes
5.3.1.
Monitorizao do Progresso de Testes (K1)
O propsito da monitorizao de testes fornecer retorno (feedback) e visibilidade sobre as

atividades de teste. A informao a monitorar pode ser recolhida manualmente ou automaticamente
e pode ser utilizada para medir os critrios de sada, tais como, a cobertura. As mtricas podem
tambm ser utilizadas para avaliar o progresso relativamente ao planeamento do calendrio e
oramento. Mtricas de teste comuns incluem:
o Percentagem de trabalho feito na preparao dos casos de teste (ou a percentagem de
casos de teste planeados j elaborados).
o Percentagem de trabalho feito na preparao do ambiente de teste.
o Execuo de casos de teste (p. ex. nmero de casos de teste executados/no executados,
e casos de teste que passaram/falharam).
o Informao sobre os defeitos (p. ex. densidade de defeitos, defeitos detetados e corrigidos,
taxa de falhas, e resultados de retestes).
o Cobertura de testes de requisitos, riscos ou cdigo.
o Confiana subjetiva dos testadores (testers) no produto.
o Datas de marcos de testes.
o Custos de testes, incluindo o custo comparado com o beneficio de detetar o prximo defeito
ou de executar o prximo teste.
5.3.2.
Relatrio de Testes (K2)
Os relatrios de testes tm o seu foco no resumo das informaes acerca das diligncias de testes,
incluindo:
o O que aconteceu durante o perodo de testes, tal como, as datas de alcance dos critrios
de sada.
o Informao analisada e mtricas para suportar as recomendaes e decises sobre futuras
aes, tais como, uma avaliao de defeitos ainda remanescentes, o benefcio econmico
da continuidade dos testes, riscos pendentes, e o nvel de confiana no software testado.
O esboo do relatrio de teste dado pela norma Standard for Software Test Documentation (IEEE
Std 829-1998).
As mtricas podem ser recolhidas durante e no final de cada nvel de teste de modo a avaliar:
o A adequao dos objetivos de teste para o respetivo nvel de teste.
o A adequao das abordagens de teste escolhidas.
o A eficcia dos testes relativamente aos objetivos definidos.
5.3.3..
Controlo de Testes (K2)
O controlo de testes descreve as aes de orientao ou corretivas tomadas como resultado da

informao e mtricas recolhidas e comunicadas. As aes podem abranger todas as atividades de
teste e podem afetar qualquer outra atividade ou tarefa do ciclo de vida do software.
Verso 2011
Pgina 57 de 85
01-Abr-2011
Exemplos de aes de controlo de testes so:

o Tomar decises baseadas na informao oriunda da monitorizao de testes.
o Re-priorizar os testes quando ocorre algum risco identificado (por exemplo, entregas de
software fora do prazo definido).
o Alterar a calendarizao de testes devido a disponibilidade ou indisponibilidade do
ambiente de testes.
o Definir um critrio de entrada para as correes que foram retestadas (testes de
confirmao) por um programador antes de aceit-los numa verso (build).
Verso 2011
Pgina 58 de 85
01-Abr-2011
5.4. Gesto de Configuraes (K2)
10 minutos
Termos
Gesto de Configuraes, controlo de verso
Conhecimento
O objetivo da gesto de configuraes estabelecer e manter a integridade dos produtos

(componentes, dados e documentao) do software ou sistema ao longo do projeto e do ciclo de
vida do produto.
Para os testes, a gesto de configuraes pode envolver a garantia do seguinte:
o Todos os itens de testware so identificados, as verses so controladas, as alteraes so
rastreveis (acompanhadas) relacionadas umas com as outras e com os itens de
desenvolvimento (objetos de teste) para que a sua rastreabilidade possa ser mantida
durante todo o processo de testes.
o Todos os documentos e itens de software identificados so referenciados de forma
inequvoca na documentao de testes.
Para o testador (tester), a gesto de configuraes ajuda a identificar (e a reproduzir) os itens
testados, os documentos de teste, os testes e o(s) equipamento(s) de teste.
Os procedimentos de gesto de configuraes e infraestruturas (ferramentas) devem ser escolhidos,
documentados e implementados durante o planeamento de testes.
Verso 2011
Pgina 59 de 85
01-Abr-2011
5.5. Riscos e Testes (K2)
30 minutos
Termos
Risco de produto, risco de projeto, risco, testes baseados na avaliao do risco
Conhecimento
O risco pode ser definido como a hiptese de um evento, perigo, ameaa ou situao que ocorra e
resulte em consequncias indesejveis ou em potenciais problemas. O nvel de risco ser
determinado pela probabilidade de ocorrncia de um evento adverso e seu impacto (o dano
resultante desse evento).
5.5.1..
Riscos de Projeto (K2)
Os riscos de projeto so aqueles que rodeiam a capacidade do projeto de entregar os seus

objetivos, tais como:
o Fatores organizacionais:
Conhecimentos/habilidades, formao e faltas de pessoal.
Questes de pessoal.
Questes polticas, tais como:
o
Problemas com testadores (testers) na comunicao das suas necessidades
e dos resultados de testes.
o
Falha da equipa em dar seguimento informao oriunda da execuo dos
testes e revises (p. ex. no melhorar as prticas de testes e de
desenvolvimento).
o Atitude incorreta para com as expectativas de testes (p. ex. no perceber o real
valor da deteo de defeitos durante os testes).
o Questes tcnicas:
Problemas na definio de requisitos corretos.
A medida em que estes requisitos no podem ser cumpridos, dadas as restries
conhecidas.
O ambiente de teste no estar pronto a tempo.
Atraso na converso de dados, planeamento de migrao e ferramentas de
converso/migrao de dados de teste e de desenvolvimento.
Baixa qualidade da conceo, cdigo, dados de configurao, dados de teste e dos
testes.
o Questes de fornecedor:
Falha de uma terceira parte.
Questes contratuais.
Ao analisar, gerir ou mitigar estes riscos, o gestor de testes segue os princpios de gesto de projeto
estabelecidos. A norma Standard for Software Test Documentation (IEEE Std 829-1998) esboa os
planos de teste exigindo que sejam neles declarados os riscos e contingncias.
5.5.2..
Riscos de Produto (K2)
As potenciais reas de falha (eventos futuros adversos ou perigos) no software ou sistema so

conhecidos como riscos de produto, sendo um risco para a qualidade do produto. Incluindo:
o Propenso para a entrega de software com falhas.
o A potencialidade do software/hardware causar danos a uma pessoa ou empresa.
o Caractersticas pobres do software (p. ex. funcionalidade, fiabilidade, usabilidade e
desempenho).
Verso 2011
Pgina 60 de 85
01-Abr-2011
o
o
Qualidade e integridade de dados pobre (p. ex. questes de migrao de dados, problemas
de converso de dados, problemas de transporte de dados, violao de normas de dados).
Software que no desempenha as funes a que se destina.
Os riscos so utilizados para ajudar na deciso sobre por onde comear a testar e aplicar mais
testes, estes so utilizados para reduzir o risco de ocorrncia de eventos adversos, ou para reduzir o
impacto de um efeito adverso.
Os riscos de produto so um tipo especial de risco relativos ao sucesso do projeto. Os testes, como
atividade de controlo de riscos, fornecem retorno (feedback) sobre os riscos residuais medindo a
eficcia dos planos de contingncia e da eliminao de defeitos crticos.
Uma abordagem de testes baseada na avaliao do risco oferece oportunidades proativas de
reduzir os nveis de risco do produto, logo desde as etapas iniciais do projeto. Envolve a
identificao de riscos de produto e sua utilizao na orientao do planeamento de testes e
controlo, na especificao, preparao e execuo de testes. Numa abordagem baseada na
avaliao do risco, os riscos identificados podem ser utilizados para:
o Determinar as tcnicas de teste a empregar.
o Determinar a extenso dos testes a efetuar.
o Priorizar os testes na tentativa de encontrar defeitos crticos o mais cedo possvel.
o Determinar se existem algumas atividades no relacionadas com testes que possam ser
empregues para reduzir o risco (p. ex. dando formao a analistas menos experientes).
Os testes baseados na avaliao do risco assentam no conhecimento coletivo e perspiccia das
partes interessadas no projeto para determinar os riscos e os nveis de teste necessrios para
enderear esses mesmos riscos.
Para garantir que a hiptese de falha de um produto minimizada, as atividades de gesto de risco
fornecem uma abordagem disciplinada para:
o Avaliar (e reavaliar numa base regular) o que pode correr mal (riscos).
o Determinar quais os riscos mais importantes a tratar.
o Implementar aes para lidar com esses riscos.
Alm disso, os testes podem apoiar a identificao de novos riscos, podem ajudar a determinar
quais os riscos que devem ser minimizados, e podem reduzir a incerteza sobre os riscos.
Verso 2011
Pgina 61 de 85
01-Abr-2011
5.6. Gesto de Incidentes (K3)
40 minutos
Termos
Registo de incidentes, gesto de incidentes, relatrio de incidentes
Conhecimento
Como um dos objetivos de teste detetar defeitos, as discrepncias entre os resultados observados
e os esperados devem ser registadas como incidentes Um incidente deve ser investigado e pode vir
a tornar-se um defeito. Devem ser definidas quais as aes adequadas para eliminar incidentes e
defeitos. Os incidentes e defeitos devem ser acompanhados desde a sua descoberta e classificao
at sua correo e confirmao da resoluo. A fim de gerir todos os incidentes at sua
concluso, uma organizao deve estabelecer um processo de gesto de incidentes e as regras
para a sua classificao.
Os incidentes podem ser levantados durante o desenvolvimento, reviso, testes ou uso de um
produto de software. Podem ser suscitados por problemas no cdigo ou no sistema em uso, ou em
qualquer tipo de documentao incluindo requisitos, documentos de desenvolvimento, documentos
de teste, e informao de utilizador, tais como, guias de instalao ou menus de ajuda (Help).
Os relatrios de incidentes tm os seguintes objetivos:
o Fornecer aos programadores e a outras partes interessadas o retorno (feedback) sobre o
problema para permitir a sua identificao, isolamento e correo conforme necessrio.
o Fornecer aos lderes de teste um meio de rastrear a qualidade do sistema em testes e o
progresso de testes.
o Fornecer ideias para a melhoria de processos de teste.
Detalhes que podem ser includos no relatrio de incidentes so:
o Data de deteo, entidade responsvel e autor.
o Resultados esperados e observados.
o Identificao do item de teste (elemento de configurao) e ambiente.
o
o
o
o
o
o
o
o
o
Processo de ciclo de vida do software ou sistema onde foi observado o incidente

Descrio do incidente para permitir a reproduo e resoluo, incluindo registos (log),
dados da base de dados ou capturas de ecr.
mbito ou grau de impacto sobre os interesses das partes interessadas
Gravidade do impacto sobre o sistema.
Urgncia/prioridade para corrigir.
Estado do incidente (p. ex. aberto, diferido, duplicado, espera de correo, corrigido
espera de reteste, fechado).
Concluses, recomendaes e aprovaes.
Questes globais, tais como, outras reas que podem ser afetadas por uma alterao
resultante de um incidente
Alterao do histrico, tal como, a sequncia de aes tomadas pelos membros da equipa
de projeto relativamente a um incidente para isolar, corrigir e confirmar que este est
corrigido.
Referncias, incluindo a identidade da especificao de caso de teste que revelou o
problema.
A estrutura de um relatrio de incidentes coberta pela norma Standard for Software Test
Documentation (IEEE Std 829-1998).
Verso 2011
Pgina 62 de 85
01-Abr-2011
Referncias
5.1.1 Black, 2001, Hetzel, 1988
5.1.2 Black, 2001, Hetzel, 1988
5.2.5 Black, 2001, Craig, 2002, IEEE Std 829-1998, Kaner 2002
5.3.3. Black, 2001, Craig, 2002, Hetzel, 1988, IEEE Std 829-1998
5.4. Craig, 2002
5.5.2. Black, 2001 , IEEE Std 829-1998
5.6. Black, 2001, IEEE Std 829-1998
Verso 2011
Pgina 63 de 85
01-Abr-2011
6. Ferramentas de Suporte aos Testes (K2) 80 minutos

Objetivos de Aprendizagem para Ferramentas de Suporte aos Testes
mdulo.
6.1. Tipos de Ferramentas de Teste (K2)

LO-6.1.1.
LO-6.1.3.
Classificar os diferentes tipos de ferramentas de teste de acordo com a sua finalidade

e as atividades do processo fundamental de testes assim como do ciclo de vida do
software (K2).
Explicar o termo ferramenta de teste e o propsito de ferramentas de suporte aos
testes (K2).
6.2. Uso efetivo de Ferramentas: Potenciais Vantagens e Riscos (K2)

LO-6.2.1.
LO-6.2.2.
Resumir as vantagens e riscos potenciais da automatizao de testes e ferramentas

de suporte aos testes (K2).
Recordar algumas consideraes especiais sobre as ferramentas de execuo de
testes, anlise esttica e ferramentas de gesto de testes (K1).
6.3. Introduzir uma Ferramenta na Organizao (K1)

LO-6.3.1.
LO-6.3.2.
LO-6.3.3.
Verso 2011
Expor os princpios fundamentais sobre a introduo de ferramentas numa

organizao (K1).
Expor os objetivos de uma prova de conceito para a avaliao de uma ferramenta e
uma fase piloto para a implementao da ferramenta (K1).
Reconhecer que existem outros fatores para alm da aquisio da ferramenta que so
necessrios para estabelecer um suporte eficaz atravs de ferramentas (K1).
Pgina 64 de 85
01-Abr-2011
6.1. Tipos de Ferramentas de Teste (K2)
45 minutos
Termos
Ferramenta de gesto de configurao, ferramenta de cobertura, ferramenta de debugging,

ferramenta de anlise dinmica, ferramenta de gesto de incidentes, ferramenta de teste de carga,
ferramenta de modelao, ferramenta de monitorizao, ferramenta de teste de desempenho, efeito
da monitorizao, ferramenta de gesto de requisitos, ferramenta de reviso, ferramenta de
segurana, ferramenta de anlise esttica, ferramenta de teste de stress, comparador de teste,
ferramenta de preparao de dados de teste, ferramenta de conceo de teste, equipamento de
teste, ferramenta de execuo de teste, ferramenta de gesto de teste, ferramenta de estrutura
(framework) de testes unitrios.
6.1.1..
Ferramentas de Suporte aos Testes (K2)
As ferramentas de teste podem ser utilizadas para uma ou mais atividades de suporte aos testes.
Incluindo:
1. Ferramentas que so utilizadas diretamente nos testes, tais como, ferramentas de execuo
de teste, ferramentas de gerao de dados de teste e ferramentas de comparao de
resultados.
2. Ferramentas que ajudam na gesto do processo de testes, tais como, as utilizadas para
gerir testes, resultados de testes, dados, requisitos, incidentes, defeitos, etc., e para relatrio
e monitorizao da execuo de teste.
3. Ferramentas usadas no reconhecimento, ou num termo mais simples: explorao (p. ex.
ferramentas que monitorizam a atividade de ficheiros para uma aplicao).
4. Qualquer ferramenta que auxilia os testes (uma folha de clculo pode tambm neste sentido
ser considerada uma ferramenta de teste).
Ferramentas de suporte aos testes podem ter um ou mais dos seguintes propsitos dependendo do
contexto:
o
Melhorar a eficincia das atividades de teste, automatizando as atividades repetitivas ou
apoiando atividades manuais de teste como o planeamento, conceo, elaborao de
relatrios e monitorizao de testes.
o
Automatizar atividades que requerem um nmero significativo de recursos quando
executadas manualmente (p. ex. testes estticos).
o
Automatizar atividades que no podem ser executadas manualmente (p. ex. teste de
desempenho de aplicaes cliente-servidor em larga escala).
o
Aumentar a fiabilidade dos testes (p. ex. automatizando comparaes de dados de grande
dimenso ou simulando comportamentos).
O termo Framework frequentemente utilizado na indstria, com pelo menos trs possveis
sentidos:
o
Bibliotecas de teste extensveis e reutilizveis que podem ser utilizadas para construir
ferramentas de teste (tambm denominadas de equipamentos de testes).
o
Um tipo de desenho de automao de testes (p. ex. orientada aos dados (data-driven),
orientada a palavras-chave (keyword-driven)).
o
O processo global de execuo de testes.
Para efeitos deste programa, o termo Frameworks de teste utilizado nos seus dois primeiros
significados conforme descrito na seco 6.1.6.
Verso 2011
Pgina 65 de 85
01-Abr-2011
6.1.2..
Classificao de Ferramentas de Teste (K2)
Existem inmeras ferramentas que suportam os diferentes aspetos dos testes. As ferramentas
podem ser classificadas com base em diversos critrios, tais como a finalidade, modelo de uso
(comercial/livre/cdigo aberto/software partilhado (shareware)), tecnologia usada e assim por diante.
As ferramentas so classificadas neste programa de acordo com as atividades de teste que estas
suportam/apoiam.
Algumas ferramentas favorecem claramente uma atividade, enquanto outras podem suportar mais
do que uma atividade, mas so classificadas no mbito da atividade qual esto mais claramente
associadas. Ferramentas de um nico fornecedor, especialmente as que foram projetadas para
trabalhar em conjunto, podem ser agrupadas num pacote nico.
Alguns tipos de ferramentas de teste podem ser intrusivos, o que significa que podem afetar o
resultado dos testes. Por exemplo, o tempo obtido pode ser diferente atendendo s instrues extra
que so executadas pela ferramenta, ou poder obter-se uma medida diferente da cobertura de
cdigo. A consequncia de ferramentas intrusivas chamada efeito da monitorizao.
Algumas ferramentas oferecem um suporte mais apropriado aos programadores (p. ex. ferramentas
utilizadas durante os testes de componentes ou de integrao de componentes). Estas ferramentas
so marcadas com D na lista abaixo.
6.1.3..
Ferramentas de Suporte aos Testes e sua Gesto (K1)
As ferramentas de gesto so aplicveis a todas as atividades de teste durante todo o ciclo de vida
do software.
Ferramentas de Gesto de Testes
Estas ferramentas oferecem interfaces para a execuo de testes, registo de defeitos e gesto de
requisitos, juntamente com o apoio anlise quantitativa e relatrios de objetos de teste. Tambm
fornecem suporte rastreabilidade de objetos de teste face s especificaes de requisitos e podem
tambm dispor de capacidade de controlo de verso independente ou interface com uma ferramenta
externa.
Ferramentas de Gesto de Requisitos
Estas ferramentas armazenam instrues de requisitos, seus atributos (incluindo prioridades),
fornecem identificadores nicos e possibilitam o rastreamento de requisitos para os testes
individuais. Estas ferramentas podem tambm ajudar a identificar requisitos inconsistentes ou em
falta.
Ferramentas de Gesto de Incidentes (Ferramentas de Registo de Defeitos)
Estas ferramentas armazenam e gerem os relatrios de incidentes, ou seja, os defeitos, falhas,
pedidos de alteraes ou problemas percebidos e anomalias, e ajudam gesto do ciclo de vida dos
incidentes, opcionalmente, com apoio anlise estatstica
Ferramentas de Gesto de Configuraes
Embora no sejam estritamente ferramentas de teste, estas so necessrias ao armazenamento e
gesto de verses do testware e software relacionado, especialmente quando necessrio
configurar mais do que um ambiente de hardware/software, em termos de verses de sistema
operativo, compiladores, browsers, etc.
6.1.4. Ferramentas de Suporte aos Testes Estticos (K1)

As ferramentas de teste esttico so uma forma rentvel de detetar mais defeitos em fases mais
antecipadas do processo de desenvolvimento.
Verso 2011
Pgina 66 de 85
01-Abr-2011
Ferramentas de Reviso
Estas ferramentas ajudam nos processos de reviso, listas de verificao, orientaes para as
revises e so usadas para armazenar e comunicar os comentrios referentes s revises, os
relatrios sobre defeitos e esforo. Ainda podem ser uma ajuda maior ao possibilitar revises online
para equipas grandes ou dispersas geograficamente.
Ferramentas de Anlise Esttica (D)
Estas ferramentas so uma ajuda para programadores e testadores (testers) detetarem defeitos
antes dos testes dinmicos, dando suporte ao reforo do cumprimento de normas de codificao
(incluindo codificao mais segura), anlise de estruturas e dependncias. Podem ainda ajudar no
planeamento ou na anlise de risco, providenciando mtricas de cdigo (p. ex. complexidade).
Ferramentas de Modelao (D)
Estas ferramentas so usadas para validar modelos de software (p. ex. modelo fsico de dados
(PDM) para uma base de dados relacional), enumerando inconsistncias e detetando defeitos. Estas
ferramentas podem muitas vezes ser uma ajuda preciosa na gerao de casos de teste baseados
no modelo.
6.1.5..
Ferramentas de Suporte Especificao de Teste (K1)
Ferramentas de Desenho de Testes

Estas ferramentas so usadas para gerar entradas de teste ou executveis de teste e/ou orculos de
teste a partir de requisitos, interfaces grficas de utilizador, modelos de conceo (estados, dados
ou objetos) ou cdigo.
Ferramentas de Preparao de Dados de Teste
Ferramentas de preparao de dados de teste manipulam bases de dados, ficheiros ou
transmisses de dados para criar dados de teste para uso durante a execuo dos mesmos
garantindo a segurana dos dados mantendo o anonimato.
6.1.6.
(K1)
Ferramentas de Suporte Execuo de Testes e Registo (Logging)
Ferramentas de Execuo de Testes

Estas ferramentas permitem que os testes sejam executados automaticamente, ou
semiautomaticamente, utilizando entradas armazenadas e resultados esperados, atravs de
linguagem de script e proporcionando um registo (log) de teste para cada teste executado. Podem
tambm ser utilizadas para gravar testes, e normalmente suportam linguagem de script ou
configurao baseada em GUI para parametrizao de dados e outras customizaes nos testes.
Equipamento de Teste/Ferramentas de Framework de Testes Unitrios (Unit Test Framework)
(D)
Um equipamento ou estrutura de testes unitrios facilita os testes de componentes, ou partes de um
sistema, pela simulao do ambiente em que o objeto de teste ser executado, atravs de objetos
simulados como simuladores (stubs) ou controladores (drivers).
Comparadores de Teste
Os comparadores de teste determinam as diferenas entre ficheiros, bases de dados ou resultados
de teste. As ferramentas de execuo de testes normalmente incluem comparadores dinmicos,
mas a comparao ps-execuo pode ser feita por uma ferramenta de comparao em separado.
Um comparador de teste pode utilizar um orculo de teste, especialmente se este for automtico.
Ferramentas de Medio de Cobertura (D)
Verso 2011
Pgina 67 de 85
01-Abr-2011
Estas ferramentas medem, atravs de mtodos intrusivos ou no-intrusivos, a percentagem de tipos

especficos de estruturas de cdigo que foram executados (p. ex. instrues, ramos ou decises, e
chamadas de mdulos ou funes) por um conjunto de testes.
Ferramentas de Testes de Segurana
Estas ferramentas so utilizadas para avaliar as caractersticas de segurana do software. Isto inclui
a avaliao da capacidade do software para proteger a confidencialidade, integridade, autenticao,
autorizao, disponibilidade e no-repdio de dados. As ferramentas de segurana so mais
focadas numa determinada tecnologia, plataforma e finalidade.
6.1.7..
Ferramentas de Suporte ao Desempenho e Monitorizao (K1)
Ferramentas de Anlise Dinmica (D)

As ferramentas de anlise dinmica detetam defeitos que so evidentes apenas quando o software
est em execuo, tais como dependncias de tempo ou memrias perdidas. Normalmente, so
utilizadas em testes de componentes e de integrao de componentes, e quando testado
middleware.
Ferramentas de Testes de Desempenho/Carga/Stress
Ferramentas de teste de desempenho monitorizam e informam sobre como o sistema se comporta
numa variedade de condies de uso simuladas, em termos de nmero de utilizadores simultneos,
a sua rampa elevatria padro, frequncia e percentagem relativa de transaes. A simulao de
carga obtida por meio da criao de utilizadores virtuais, que realizam um conjunto selecionado de
transaes, espalhados por vrias mquinas de teste, conhecidos como geradores de carga.
Ferramentas de Monitorizao
As ferramentas de monitorizao analisam, verificam e informam continuamente sobre o uso de
recursos de sistema especficos, e transmitem alertas de possveis problemas de servio.
6.1.8..
Ferramentas de Suporte a Necessidades Especficas de Teste (K1)
Avaliao da Qualidade de Dados

Os dados esto no centro de alguns projetos, tais como os de converso/migrao de dados e
aplicaes como armazns de dados e os seus atributos podem variar em termos de criticidade e
volume. Em tais contextos, as ferramentas precisam de ser empregues para avaliao da qualidade
de dados para rever e verificar a converso de dados e regras de migrao para garantir que os
dados processados esto corretos, completos e obedecem a uma norma de contexto especfico
pr-definido.
Existem outras ferramentas de testes para os testes de usabilidade.
Verso 2011
Pgina 68 de 85
01-Abr-2011
6.2. Uso efetivo de Ferramentas: Potenciais

Vantagens e Riscos (K2)
20 minutos
Termos
Teste orientado a dados (Data-driven), teste orientado a palavras-chave (keyword-driven),

linguagem de script
6.2.1.. Potenciais Vantagens e Riscos do uso de Ferramentas de Suporte

aos Testes (para todas as ferramentas) (K2)
A simples aquisio ou locao financeira de uma ferramenta no garante o sucesso de tal
ferramenta. Cada tipo de ferramenta exige um esforo adicional para obter vantagens reais e
duradouras. Existem vantagens e oportunidades potenciais com a utilizao de ferramentas de
teste, mas tambm existem riscos.
Potenciais vantagens do uso de ferramentas incluem:
o Reduo de trabalho repetitivo (p. ex. executar testes de regresso, reintroduzir os
mesmos dados de teste, e verificao face a normas de codificao).
o Maior consistncia e repetibilidade (p. ex. testes executados por uma ferramenta numa
determinada ordem e com a mesma frequncia, e testes derivados de requisitos).
o Avaliao objetiva (p. ex. medidas estticas, cobertura).
o Facilidade no acesso informao sobre os testes (p. ex. estatsticas e grficos sobre o
progresso de testes, taxas de incidentes e desempenho).
Riscos do uso de ferramentas incluem:
o Expectativas irreais sobre a ferramenta (incluindo funcionalidade e facilidade de uso).
o Subestimar o tempo, custo e esforo para a introduo inicial de uma ferramenta (incluindo
a formao e competncias externas).
o Subestimar o tempo e o esforo necessrios para alcanar vantagens significativas e
contnuas a partir da ferramenta (incluindo a necessidade de mudanas no processo de
testes e na melhoria contnua da forma como a ferramenta usada).
o Subestimar o esforo necessrio para manter os ativos de teste gerados pela ferramenta.
o Excesso de confiana na ferramenta (substituindo a conceo de teste ou uso de testes
automatizados onde os testes manuais seriam mais aconselhveis).
o Negligenciar o controlo de verso dos ativos de teste dentro da ferramenta.
o Negligenciar as questes de relacionamento e de interoperabilidade entre as ferramentas
crticas, tais como: ferramentas de gesto de requisitos, ferramentas de controlo de verso,
ferramentas de gesto de incidentes, ferramentas de registo de defeitos e ferramentas de
vrios fornecedores.
o Risco de um fornecedor sair do negcio, descontinuando a ferramenta ou vendendo-a a
outro fornecedor.
o Resposta insuficiente por parte do vendedor no que diz respeito ao suporte, atualizaes e
correo de defeitos.
o Risco de suspenso quando so solues de cdigo aberto ou gratuitas.
o Imprevistos, como a incapacidade de sustentar uma nova plataforma.
6.2.2
Consideraes Especiais para alguns Tipos de Ferramentas (K1)
Ferramentas de Execuo de Testes

As ferramentas de execuo de testes executam os objetos de teste atravs de guies de teste
automatizados. Este tipo de ferramenta exige muitas vezes um esforo considervel para alcanar
vantagens significativas.
Verso 2011
Pgina 69 de 85
01-Abr-2011
Capturar os testes gravando as aes de um testador (tester) parece atrativo, mas esta abordagem
no se adapta a um grande nmero de guies de teste automatizados. Um guio de captura uma
representao linear com dados e aes especficas como parte de cada guio. Este tipo de guio
pode ser instvel quando ocorrem eventos inesperados.
Uma abordagem de teste orientado a dados normalmente separa as entradas de teste (os dados)
numa folha de clculo, e usa um guio de teste mais genrico que possa ler os dados de entrada e
executar o mesmo guio de teste com dados diferentes. Testadores (testers) que no esto
familiarizados com a linguagem de script podem ento criar os dados de teste para esses scripts
predefinidos.
Existem outras tcnicas empregues nas tcnicas orientadas aos dados (data-driven), onde em vez
de manter as combinaes de dados hard-coded na folha de clculo, os dados so gerados usando
algoritmos baseados em parmetros configurveis, em tempo de execuo e fornecidos pela
aplicao. Por exemplo, uma ferramenta pode usar um algoritmo, que gera uma identificao de
utilizador aleatoriamente, e por questes de repetibilidade padro, a gerao utilizada para
controlar a aleatoriedade.
Na abordagem de testes orientada a palavras-chave (keyword-driven), a folha de clculo contm
palavras-chave que descrevem as aes a tomar (tambm chamadas palavras-ao), e dados de
teste. Os testadores (testers) (mesmo que no estejam familiarizados com a linguagem de script)
podem definir testes usando palavras-chave, que podem ser adaptadas medida da aplicao a
testar.
necessrio algum conhecimento tcnico na linguagem de script para todas as abordagens (tanto
pelos testadores (testers) como por especialistas em automatizao de teste).
Independentemente da tcnica de script utilizada, os resultados esperados para cada teste precisam
de ser armazenados para posterior comparao.
Ferramentas de Anlise Esttica
Estas ferramentas aplicadas ao cdigo-fonte podem impor padres de codificao, mas se aplicadas
a um cdigo j existente podem gerar uma quantidade imensa de mensagens. Estas mensagens de
aviso no impedem o cdigo de ser traduzido em programas executveis, mas idealmente devem
ser endereadas de forma a possibilitar uma manuteno do cdigo facilitada no futuro. Uma
abordagem a este tema mais eficaz definir uma implementao gradual da ferramenta de anlise
que numa fase inicial estabelea alguns filtros de forma a excluir algumas mensagens.
Ferramentas de Gesto de Testes
Estas ferramentas precisam de estabelecer uma interface com outras ferramentas ou folhas de
clculo de modo a produzir informao til num formato que se adapte e responda s necessidades
da organizao.
Verso 2011
Pgina 70 de 85
01-Abr-2011
6.3 Introduzir uma Ferramenta na Organizao

(K1)
15 minutos
Termos
No existem termos especficos.
Conhecimento
As principais consideraes a ter em conta quando selecionamos uma ferramenta para uma
organizao incluem:
o Avaliao do nvel de maturidade organizacional, pontos fortes e fracos e identificar
oportunidades para uma melhoria do processo de testes suportada por ferramentas.
o Avaliao de acordo com requisitos claros e critrios objetivos.
o Fazer uma prova de conceito, usando uma ferramenta de teste durante a fase de avaliao
de forma a estabelecer se esta trabalha de forma eficaz sobre o software em testes e na
infraestrutura atual ou para identificar alteraes necessrias a essa mesma infraestrutura
para se poder, de facto, utilizar a ferramenta.
o Avaliao do fornecedor (incluindo suporte, formao e aspetos comerciais) ou prestadores
de servio de suporte no caso de ferramentas no comerciais.
o Identificao de requisitos internos para coaching e orientao no uso da ferramenta.
o Avaliao de necessidades de formao, considerando as atuais competncias de
automao de testes da equipa de testes.
o Estimativa da relao custo-benefcio com base num caso de negcio concreto.
Introduzir as ferramentas selecionadas numa organizao comea com um projeto-piloto, que deve
ter os seguintes objetivos:
o Aprender mais detalhes sobre a ferramenta.
o Avaliar como a ferramenta se encaixa com processos e prticas existentes, e determinar o
que ser necessrio mudar.
o Decidir formas padro de utilizao, gesto, armazenamento e manuteno da ferramenta
e dos ativos de teste (p. ex. decidindo convenes de nomenclatura de ficheiros e testes,
criando bibliotecas e definindo a modularidade de conjuntos de testes).
o Avaliar se os benefcios a alcanar tm um custo razovel.
Fatores de sucesso no arranque da ferramenta dentro de uma organizao incluem:
o Disponibilizar a ferramenta a toda a organizao de forma incrementada.
o Adaptar e melhorar processos de forma que se ajustem utilizao da ferramenta.
o Proporcionar a formao e coaching/mentoring para os novos utilizadores.
o Definir as orientaes de utilizao.
o Implementar uma forma de recolher informaes sobre a utilizao a partir da utilizao
real.
o Monitorizar a utilizao e benefcios da ferramenta.
o Fornecer suporte equipa de testes na utilizao de uma ferramenta.
o Recolher lies apreendidas por todas as equipas envolvidas.
Referncias
6.2.2. Buwalda, 2001, Fewster, 1999

6.3. Fewster, 1999
Verso 2011
Pgina 71 de 85
01-Abr-2011
7. Referncias
Normas
o
o
ISTQB Glossary of terms used in Software Testing Version 2.1

[CMMI] Chrissis, M.B., Konrad, M. and Shrum, S. (2004) CMMI, Guidelines for Process
Integration and Product Improvement, Addison Wesley: Reading, MA
Ver seco 2.1
[IEEE Std 829-1998] IEEE Std 829 (1998) IEEE Standard for Software Test
Documentation ver seces 2.3 , 2.4 , 4.1 , 5.2 , 5.3 , 5.5 , 5.6
[IEEE 1028] IEEE Std 1028 (2008) IEEE Standard for Software Reviews and Audits ver
seco 3.2
[IEEE 12207] IEEE 12207/ISO/IEC 12207-2008, Software life cycle processes ver seco
2.1
[ISO 9126] ISO/IEC 9126-1:2001, Software Engineering Software Product Quality ver
seco 2.3
Livros
o
[Beizer, 1990] Beizer, B. (1990) Software Testing Techniques (2nd edition), Van Nostrand
Reinhold:
Boston
Ver seces 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 seces 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 seco 6 2
[Copeland, 2004] Copeland, L. (2004) A Practitioners Guide to Software Test Design, Artech
House: Norwood, MA
Ver seces 2.2 , 2.3 , 4.2 , 4.3 , 4.4 , 4.6

[Craig, 2002] Craig, Rick D. and Jaskiel, Stefan P. (2002) Systematic Software Testing,
Artech House: Norwood, MA
Ver seces 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 seco 6 2.
[Gilb, 1993]: Gilb, Tom and Graham, Dorothy (1993) Software Inspection, Addison Wesley:
Reading, MA
Ver seco 3.2.2., 3.2.4.
[Hetzel, 1988] Hetzel, W. (1988) Complete Guide to Software Testing, QED: Wellesley, MA
Ver seces 1.3 , 1.4 , 1.5 , 2.1 , 2.2 , 2.3 , 2.4 , 4.1 , 5.1 , 5.3
Verso 2011
Pgina 72 de 85
01-Abr-2011
[Kaner, 2002] Kaner, C., Bach, J. and Pettticord, B. (2002) Lessons Learned in Software
Testing, John Wiley & Sons: New York
Ver seces 1.1., 4.5., 5.2.
[Myers 1979] Myers, Glenford J. (1979) The Art of Software Testing, John Wiley & Sons: New
York
Ver seces 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 seces 3.2., 3.3.
Verso 2011
Pgina 73 de 85
01-Abr-2011
8. Apndice A Origem do Syllabus

Histrico deste Documento
Este documento foi preparado entre 2004 e 2007 por uma equipa de trabalho com membros
apontados pelo ISTQB (International Software Testing Qualifications Board) Foi inicialmente revisto
por um painel de reviso selecionado, e de seguida por representantes da comunidade internacional
de testes de software. As regras utilizadas na produo deste documento esto disponveis no
Apndice C.
Este documento o programa para o Certificado Internacional de nvel Foundation em Testes de
Software, a primeira qualificao de nvel internacional aprovado pelo ISTQB. (www.istqb.org).
Objetivos da Qualificao de Certificao de nvel Foundation

o
o
o
o
o
o
Obter o reconhecimento de que os testes so uma rea essencial e profissional na

especializao em engenharia de software.
Fornecer uma estrutura (framework) padro no desenvolvimento da carreira dos testadores
(testers).
Permitir que os testadores (testers) profissionalmente qualificados sejam reconhecidos
pelos empregadores, clientes e pares, bem como valorizar o perfil dos testadores (testers).
Promover as boas prticas de testes e sua consistncia no mbito das disciplinas de
engenharia de software.
Identificar tpicos de teste relevantes e de valor indstria.
Permitir aos fornecedores de software contratarem testadores (testers) certificados,
ganhando dessa forma vantagens comerciais sobre os seus concorrentes, dando a
conhecer a sua poltica de recrutamento de testadores (testers).
Dar uma oportunidade aos testadores (testers), bem como s pessoas com interesse na
rea dos testes, de adquirir uma qualificao internacionalmente reconhecida na indstria.
Objetivos da Qualificao Internacional (adaptado da reunio do ISTQB

em Sollentuna, novembro 2001)
o
o
o
o
o
o
o
o
o
o
Ser possvel comparar as capacidades dos testadores (testers) entre os vrios pases.
Permitir aos testadores (testers) deslocar-se entre pases mais facilmente.
Permitir nos projetos multinacionais/internacionais um entendimento comum no contexto
de teste.
Aumentar o nmero de testadores (testers) qualificados mundialmente.
Reforar o impacto/valor como iniciativa baseada internacionalmente versus uma
abordagem especfica por pas.
Desenvolver um corpo comum internacional de entendimento e conhecimento sobre testes
atravs do programa e da terminologia, bem como aumentar o nvel de conhecimento
sobre testes de todos os participantes.
Promover a prtica de testes como profisso em mais pases.
Permitir que os testadores (testers) adquiram qualificaes reconhecidas na sua lngua
materna.
Permitir a partilha de conhecimento e recursos entre os pases.
Obter reconhecimento internacional, tanto dos testadores (testers), como da qualificao,
atravs da participao de mais pases.
Verso 2011
Pgina 74 de 85
01-Abr-2011
Requisitos de Acesso a esta Qualificao

O critrio de acesso ao exame do Certificado de nvel Foundation em Testes de Software do ISTQB
o interesse genuno que os candidatos devero ter nos testes de software. No entanto,
fortemente recomendado que os candidatos:
o Apresentem um perfil mnimo no mbito do desenvolvimento ou de testes de software, tal
como: seis meses de experincia como testador (tester) de sistemas ou de aceitao de
utilizador ou como programador de software.
o Participem num curso que tenha sido acreditado pelo ISTQB (por um dos Conselhos
Nacionais reconhecidos pelo ISTQB).
Perfil e Histria do Certificado de nvel Foundation em Testes de

Software
A certificao independente de testadores (testers) de software comeou no Reino Unido com o
Information Systems Examination Board (ISEB) da British Computer Society, quando o Conselho de
Testes de Software foi criado em 1998 (www.bcs.org.uk/iseb). Em 2002, o ASQF, na Alemanha,
comeou a apoiar um programa de qualificao de testador (tester) alemo. Este programa
baseado tanto no programa do ISEB como no do ASQF, e inclui contedos reorganizados,
atualizados e adicionais, dando nfase a tpicos que promovem a prtica dos testadores (testers).
Um Certificado de nvel Foundation em Testes de Software existente (p. ex. emitido pelo ISEB,
ASQF ou um Conselho Nacional reconhecido pelo ISTQB) que tenha sido concedido antes do
Certificado Internacional, reconhecido como seu equivalente. O Certificado de nvel Foundation
no expirar nem carece de renovao. A data em que foi concedido ser exibida no Certificado.
Em cada pas participante, compete ao Conselho Nacional de Testes de Software, reconhecido pelo
ISTQB, controlar os aspetos locais. Os deveres dos Conselhos Nacionais so especificados pelo
ISTQB e implementados dentro de cada pas. Eles incluem a acreditao das entidades formadoras
bem como a marcao de exames.
Verso 2011
Pgina 75 de 85
01-Abr-2011
9. Apndice B Objetivos de Aprendizagem/Nvel

Cognitivo de Conhecimento
Os seguintes objetivos de aprendizagem so definidos como aplicveis a este programa. Cada
tpico ser examinado de acordo com o objetivo de aprendizagem definido para o mesmo.
Nvel 1: Lembrar (K1)

O candidato dever reconhecer, lembrar e recordar um termo ou conceito.
Palavras-Chave: Lembrar, recuperar, recordar, reconhecer, saber
Exemplo
Consegue reconhecer a definio de falha como:
o A no entrega de servio a um utilizador final ou a qualquer outra das partes interessadas,
ou
o Um verdadeiro desvio do componente ou sistema da sua entrega, servio ou resultado
esperado.
Nvel 2: Compreender (K2)

O candidato consegue selecionar as razes ou explicaes para instrues relacionadas com o
tpico, e consegue resumir, comparar, classificar, categorizar e dar exemplos para o conceito de
testes.
Palavras-Chave: Resumir, generalizar, abstrato, classificar, comparar, mapear, contrastar,
exemplificar, interpretar, traduzir, representar, deduzir, concluir, categorizar, construir modelos.
Exemplo
Consegue explicar a razo pela qual os testes devem ser desenhados o mais cedo possvel:
o Para detetar defeitos quando so mais baratos de remover.
o Para detetar os defeitos mais importantes primeiro.
Consegue explicar as semelhanas e diferenas entre integrao e testes de sistema:
o Semelhanas: Testes a mais do que um componente, e podero ser testados aspetos no
funcionais.
o Diferenas: Os testes de integrao concentram-se nas interfaces e interaes, e testes de
sistema concentram-se nos aspetos gerais de todo o sistema, tal como processamento
ponto-a-ponto.
Nvel 3: Aplicar (K3)

O candidato consegue selecionar a aplicao correta de um conceito ou tcnica e aplic-la a um
dado contexto.
Palavras-Chave: Implementar, executar, utilizar, seguir um procedimento, aplicar um procedimento.
Exemplo
o Consegue identificar valores fronteira para parties vlidas e invlidas.
o Consegue selecionar casos de teste a partir de um diagrama de transio de estados de
forma a cobrir todas as transies possveis
Verso 2011
Pgina 76 de 85
01-Abr-2011
Nvel 4: Analisar (K4)

O candidato consegue separar informao relacionada com um procedimento ou tcnica nas suas
partes constituintes para melhor compreenso, e consegue distinguir entre factos e inferncias. A
aplicao tpica analisar um documento, software ou situao de projeto e propor aes
apropriadas para resolver um problema ou tarefa.
Palavras-Chave: Analisar, organizar, encontrar coerncia, integrar, esboar, interpretar, estruturar,
atribuir, desconstruir, diferenciar, discriminar, distinguir, focar, selecionar.
Exemplo
o Analisar riscos de produto e propor atividades de mitigao preventivas e corretivas.
o Descrever que partes de um relatrio de incidentes so factuais e quais so deduzidas a
partir de resultados.
Referncia
(Para os nveis cognitivos dos objetivos de aprendizagem)

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 2011
Pgina 77 de 85
01-Abr-2011
10. Apndice C Regras aplicadas ao ISTQB

Programa de nvel Foundation
As regras aqui listadas foram utilizadas no desenvolvimento e reviso deste programa. (Uma TAG
exibida aps cada regra como uma abreviatura da regra).
10.1.1 Regras Gerais

SG1. O programa dever ser compreensvel e absorvvel por pessoas com 0-6 meses (ou mais) de
experincia em testes (6-MONTH).
SG2. O programa dever ser mais prtico do que terico. (PRACTICAL)
SG3. O programa dever ser claro, no devendo apresentar-se ambguo aos leitores. (CLEAR)
SG4. O programa dever ser compreensvel a pessoas de diferentes pases, e facilmente traduzvel
para vrias lnguas. (TRANSLATABLE)
SG5. O programa dever utilizar Ingls Americano. (AMERICAN-ENGLISH)
10.1.2 Contedos Atuais

SC1. O programa dever incluir conceitos de teste recentes e dever refletir as melhores prticas
atuais em testes de software. O programa sujeito a reviso a cada trs a cinco anos. (RECENT)
SC2. O programa dever minimizar questes relacionadas com tempo, tais como: condies atuais
do mercado, permitindo dessa forma que tenha um tempo de vida til de trs a cinco
anos.(SHELF-LIFE).
10.1.3 Objetivos de Aprendizagem

LO1. Os objetivos de aprendizagem devem distinguir entre itens a serem reconhecidos/lembrados
(nvel cognitivo K1), itens que o candidato dever perceber conceptualmente (K2), itens que o
candidato dever ser capaz de praticar/utilizar (K3) e itens que o candidato dever ser capaz de
utilizar para analisar um documento, software, situao de projeto num determinado contexto (K4).
LO2. A descrio do contedo dever ser consistente com os objetivos de aprendizagem.
(LOCONSISTENT)
LO3. Para ilustrar os objetivos de aprendizagem, devero ser entregues, juntamente com o
programa, exemplos de questes de exame para cada seco principal. (LO-EXAM)
10.1.4 Estrutura Global

ST1. A estrutura do programa dever ser clara e permitir o cruzamento de e a partir de outras partes,
de questes de exame e de outros documentos relevantes. (CROSS-REF)
ST2. Sobreposies entre seces do programa devero ser minimizadas. (OVERLAP)
ST3. Cada seco do programa dever ter a mesma estrutura. (STRUCTURE-CONSISTENT)
ST4. O programa dever conter a verso, data de publicao e nmero de pgina em todas as
pginas. (VERSION)
ST5. O programa dever incluir uma diretriz para a quantidade de tempo a ser dispensado em cada
seco (para refletir a importncia relativa de cada tpico). (TIME-SPENT)
Referncias
SR1. Fontes e referncias devero ser dadas para conceitos no programa para ajudar as entidades
formadoras a encontrar mais informaes sobre o tpico. (REFS)
SR2. Quando no existirem fontes claras e facilmente identificveis, devero ser fornecidos mais
detalhes no programa. Por exemplo, as definies esto no glossrio, portanto, apenas os termos
sero listados no programa. (NON-REF DETAIL)
Fontes de Informao
Verso 2011
Pgina 78 de 85
01-Abr-2011
Os termos utilizados no programa so definidos no Glossrio de Termos utilizados em Testes de

Software do ISTQB. Uma verso do glossrio est disponvel pelo ISTQB.
Uma lista de livros recomendados em testes de software ser tambm emitida em paralelo com este
programa A lista principal de livros faz parte da seco de referncias.
Verso 2011
Pgina 79 de 85
01-Abr-2011
11. Apndice D - Aviso s Entidades Formadoras

A cada assunto principal do programa atribudo um tempo em minutos. O propsito disto tanto
dar orientao sobre a proporo relativa de tempo a ser alocado a cada seco de um curso
acreditado, bem como dar um tempo mnimo aproximado para o ensino de cada seco. Entidades
formadoras podero demorar mais tempo que o indicado e os candidatos podero dispensar mais
tempo novamente na leitura e investigao. O currculo de um curso no ter necessariamente de
seguir a mesma ordem do programa
O programa contm referncias a normas estabelecidas, que devem ser utilizadas na preparao do
material de formao. Cada norma utilizada dever ser a verso citada na verso atual deste
programa Outras publicaes, templates ou normas no referenciados neste programa tambm
podem ser utilizados e referenciados, mas no sero examinados.
Todos os objetivos de aprendizagem K3 e K4 requerem a insero de exerccios prticos nos
materiais de formao.
Verso 2011
Pgina 80 de 85
01-Abr-2011
12. Apndice E Notas de Lanamento do Programa

Verso 2010
1.
2.
3.
4.
5.
6.
7.
8.
9.
As alteraes efetuadas aos objetivos de aprendizagem (LO) incluem alguma clarificao.

a. Redao alterada para os seguintes LOs (contedo e nvel de LO mantm-se
inalterado): LO-1.2.2., LO-1.4.1., LO-2.1.1 , LO-2.1.3 , LO-4.6.1 , LO-6.3.2
b. K4 foi adicionado. Razo: alguns requisitos (LO-4.4.4. e LO-5.6.2.) j foram escritos
numa forma K4 e as questes do LO-4.6.1. so mais fceis de escrever e examinar
no nvel K4.
c. O LO-1.1.5. foi redigido e atualizado para K2. Devido comparao de termos de
defeito, termos relacionados podem ser esperados.
d. LO-1.2.3. Explicar a diferena entre as duas atividades, debugging e testes, um
novo LO. O contedo j estava coberto.
e. LO-3.1.3. Questes de comparao cobertas.
f.
O LO-3.1.4. foi removido. Parcialmente redundante com o LO-3.1.3.
g. LO-3.2.1 Consistncia com contedo.
h. O LO-3.3.2. foi atualizado para K2 de forma a ser consistente com o LO-3.1.2.
i.
O LO-6.1.2. foi removido uma vez que parte integrante do LO-6.1.3., que foi redigido
devido ao uso no apropriado de uma palavra-chave K2.
Uso consistente para abordagem de teste de acordo com a definio disponvel no glossrio. O
termo estratgia de teste no ser necessrio como um termo a recordar.
O captulo 1.4. contm agora o conceito de rastreabilidade entre bases para testes e casos de
teste.
O captulo 2 contm agora objetos de teste e bases para testes.
Retestes agora o termo principal disponvel no glossrio e no testes de confirmao.
O aspeto de qualidade de dados e testes foi adicionado em vrios stios no programa:
qualidade de dados e risco nos captulos 2.2., 5.5., 6.1.8.
Captulo 5.2.3. Critrios de entrada so adicionados como um novo subcaptulo. Razo:
Consistncia com critrios de sada (-> critrios de entrada adicionados ao LO-5.2.9.).
Uso consistente dos termos estratgia de teste e abordagem de teste com a sua definio no
glossrio.
O captulo 6.1. foi encurtado devido s descries de ferramentas serem demasiado grandes
para uma lio de 45 minutos.
10. A IEEE Std 829:2008 foi lanada Esta verso do programa no considera ainda esta nova
edio. A seco 5.2. refere-se ao documento do Plano Mestre de Testes. O contedo do Plano
Mestre de Testes coberto pelo conceito que o documento Plano de Testes cobre diferentes
nveis de planeamento: Planos de teste para os nveis de teste podem ser criados bem como
um plano de testes ao nvel de projeto cobrindo mltiplos nveis de teste. Este ltimo
denominado Plano Mestre de Testes neste programa bem como no glossrio do ISTQB.
11. O cdigo de tica foi movido do CTAL para o CTFL
Verso 2011
As alteraes efetuadas na verso de manuteno de 2011
1. De forma geral: Substituio da referncia Grupo de Trabalho Working Party por Grupo de
Trabalho Working Group
2. Substituio de ps-condies por ps condies de forma a estar consistente com o
Glossrio 2.1.
Verso 2011
Pgina 81 de 85
01-Abr-2011
3. Primeira ocorrncia: substituio ISTQB por ISTQB

4. Introduo a este programa: Foi removida a descrio dos niveis de conhecimento
cognitivos, por estar redundante com o Apndice B.
5. Seco 1.6: Remoo do nvel cognitivo desta seco atendendo a que o objetivo no era
definir um objetivo de aprendizagem para o Cdigo de tica.
6. Seco 2.2.1, 2.2.2, 2.2.3, 2.2.4 e 3.2.3: Resolvidos problemas de formatao nas listas.
7. Seco 2.2.2: A palavra falha no era a mais adequada para falhas isoladas num
determinado componente, .foi assim substituda por defeito nesta frase.
8. Seco 2.3: Correo no formato dos bullets da lista de objetivos de teste relacionados com
os termos de testes na seco de Tipos de Teste (K2).
9. Seco 2.3.4: Atualizao da descrio de debugging de forma a ser consistente com a
verso 2.1 do Glossrio.
10. Seco 2.4: Remoo da palavra extensivo de inclui regresso de testes extensiva,
porque a extenso depende da alterao (dimenso, riscos, valor, etc.) tal como escrito na
frase seguinte.
11. Seco 3.2: A palavra incluindo foi removida de modo a clarificar a frase.
12. Seco 3.2.1: Atendendo a que as atividades das revises formais foram incorretamente
formatadas, o processo de reviso tinha 12 atividades primrias em vez das seis
pretendidas. Foi alterado para seis, que torna esta seco compliance com o Syllabus 2007
e com o ISTQB Syllabus do Nvel Avanado 2007.
13. Seco 4: A palavra desenvolvido foi substituda por definido porque os casos de teste
so definidos e no desenvolvidos
14. Seco 4.2: Alterao de texto para clarificar como que os testes caixa preta e de caixa
branca podem ser usados em conjuno com as tcnicas baseadas na experincia.
15. Seco 4.3.5: Alterao de texto entre atores, incluindo utilizadores e sistemas... para
entra atores (utilizadores e sistemas)...
16. Seco 4.3.5: caminho alternativo substitudo por cenrio alternativo
17. Seco 4.4.2: de modo a clarificar o termo testes de ramo na seco 4.4 a frase para
clarificar o focus do testes de ramo foi alterada.
18. Seco 4.5, seco 5.2.6: O termo baseado na experincia (experienced-based) foi
substitudo por (experience-based) no relevante na verso Portuguesa
19. Seco 6.1: cabealho 6.1.1 compreendendo o significado e propsito das ferramentas de
suporte aos testes (K2) substitudo por 6.1.1 ferramentas de suporte aos testes
20. Seco 7/ Livros: A terceira edio de (Black, 2001) listada foi substituda pela 2 edio.
21. Apndice D: Captulos que requerem exerccios foram substitudos pelo requisito genrico
que todos os Objetivos de aprendizagem K3 e acima requerem exerccios. Este um
requisito especificado no processo de acreditao do ISTQB (verso 1.26).
22. Apndice E: Os objetivos de aprendizagem alterados entre a verso 2007 e 2010 foram
agora listados corretamente.
Verso 2011
Pgina 82 de 85
01-Abr-2011
13. ndice remissivo

A

acompanhamento
(walkthrough)

!
"#$%&'( )( &*+",-.
/ 01
2345678 98 :25;< =<;3> 86<2
? @@
M
M
ABCDEFGAH DHHIJ
K L K N
OPQRSTUTRPO
V WX
YZY[\] Y ^Y_`Y a^Y\_Z YZZYbcd
e fg
v
hijk jlhlmn lm ophqmhrmqis lm i mni mn
t u

B
wxyz {x|x }zy}zy
~

!
desenvolvimento" #$" ##
desenvolvimento
software% &&
'()*+,-+.(,) '+ /,'de
(0(,'1,2/+3 45
67789 :;9 ::9 <=

>?@ABC>D E? FG@HI@E? J> F>?F>K LM
NOPQRSPQTS UN PNOPNV WW
XYXZ[\]^ _X `Xa`Xab cdb ef
ghijh
k lm
nopqrst us tvwsttq z
xy
{|}}~|~ | |

Verso 2011
Pgina 83 de 85
01-Abr-2011

! "
#$%&'( )$ *(+,-./0123456 78
9:;<=> ?: @AB@?:A<:;C DE
FGHIJK LG IGHIGHM NO
PQRPSTQUT X
VW
inspeoY Z[
\]^_àbcde
f gh
ijklmnopil oqr stllrqtjkr jr mlurjiprvwm z
xy
{|} ~

nveis de teste

! ""
#$%&'%('&)* +' )',)',- ./- 01- 0.- 02
34567 89 :9;:9;< =>
?@ABCDEFGH IGH JKHJKHL MNL MO
PQRSTUUR VT VTUTWXRYXZ[TW\R VT \TU\TU] ^_
àbcde`f gh
ijklmniop qj mjrmjrs tu
vwxyz{x|}~~|wx

Verso 2011
Pgina 84 de 85
01-Abr-2011
reviso informal
reviso tcnica

!"#$ %&
'()*+),- ./ ./-/*01 2,-/,.,- *, /-'34'43,5 67
89:;<:=> ?>8@8<:=>A BBA BCA DEA FG
HIJH KLMN OP
QRSQTUVW XQRSQRWYZ [\Z []Z [^
_à_à bcdbe fg
hijhij kljilmnj io hlkiplj mi miqrjsnt uu
vwxvwx yw z{w|vz}~

! ! "#$ %&'"! & (&)&*#&!+,-./0 1203456789:;<=>? B
@A
CDECDE FGHCIJHKE LFGHC CDEC MJNODPKJQR
S TU
VWXYZ [\ ]\^^_`\aV_Z [\ V \ZV \ d
b c b ce
i
tipos de testef ghf g
V
jklmnkopqr ss
tuvwxwyz{|}~
Verso 2011
Pgina 85 de 85
01-Abr-2011

PSTQB SyllabusFoundation v2011 PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

PSTQB SyllabusFoundation v2011 PDF

Enviado por

Direitos autorais:

Formatos disponíveis

Programa de Certificao

de Testador (Tester) de Nvel

International Software Testing Qualifications Board

Anuncio sobre Direitos de Autor

International Software Testing Qualifications Board

Programa de Certificao de Testador (Tester) de

International Software Testing Qualifications Board

Objetivo deste documento.................................................................................................................. 8

3.2.2 Funes e Responsabilidades (K1) ............................................................................... 36

International Software Testing Qualifications Board

O Processo de Desenvolvimento de Testes (K3) .................................................................. 42

Particionar por Equivalncias (K3) ................................................................................. 44

4.3.5 Testes de Casos de Uso (K2)......................................................................................... 45

Critrios de Entrada (K2)................................................................................................ 54

5.2.5 Estimativa de Teste (K2)................................................................................................. 55

Riscos de Projeto (K2).................................................................................................... 60

5.5.2 Riscos de Produto (K2) .................................................................................................. 60

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

Ferramentas de Suporte aos Testes (K2) ...................................................................... 65

Classificao de Ferramentas de Teste (K2) ................................................................. 66

6.1.3 Ferramentas de Suporte aos Testes e sua Gesto (K1) ............................................. 66

Ferramentas de Suporte Especificao de Teste (K1)................................................ 67

Ferramentas de Suporte ao Desempenho e Monitorizao (K1)................................... 68

6.1.8 Ferramentas de Suporte a Necessidades Especficas de Teste (K1)............................ 68

Potenciais Vantagens e Riscos do uso de Ferramentas de Suporte aos Testes (para

International Software Testing Qualifications Board

6.2.2 Consideraes Especiais para alguns Tipos de Ferramentas (K1) ............................... 69

International Software Testing Qualifications Board

International Software Testing Qualifications Board

O Testador (Tester) Certificado de Nvel Foundation em Testes de

Objetivos de Aprendizagem/Nvel Cognitivo de Conhecimento

International Software Testing Qualifications Board

Objetivos gerais de instruo descrevendo a inteno do nvel Foundation

O contedo programtico no uma descrio exaustiva da rea de conhecimento de testes de

Como est o Programa Organizado

2. Testes atravs do Ciclo de Vida de Software (K2)

International Software Testing Qualifications Board

1. Fundamentos de Testes (K2)

Objetivos de Aprendizagem para Fundamentos de Testes

1.1.. Porque precisamos de Testes? (K2)

Descrever e exemplificar a forma como um defeito de software pode causar danos a

1.2. O que so Testes? (K2)

Recordar os objetivos comuns dos testes (K1).

1.3. Os Sete Princpios dos Testes (K2)

LO-1.3.1. Explicar os sete princpios dos testes (K2).

1.4. Processo de Teste Fundamental (K1)

Recordar as cinco atividades fundamentais de teste e respetivas tarefas do

1.5. A Psicologia dos Testes (K2)

Recordar os fatores psicolgicos que influenciam o sucesso dos testes (K1).

International Software Testing Qualifications Board

1.1. Porque Precisamos de Testes (K2)

Contexto de Sistemas de Software (K1)

Causas de Defeitos de Software (K2)

1.1.3. Funo dos Testes no Desenvolvimento, Manuteno e Operaes de

Testes e Qualidade (K2)

International Software Testing Qualifications Board

potencialmente a recorrncia de defeitos e, em consequncia, melhorando a qualidade de futuros

Qual a Quantidade Suficiente de Testes? (K2)

International Software Testing Qualifications Board

1.2. O que so os Testes? (K2)

Debugging, requisito, reviso, caso de teste, testes, objetivo de teste

International Software Testing Qualifications Board

1.3. Os Sete Princpios dos Testes (K2)