Syllabus CTAL TA 2012br PDF

Certified Tester
Advanced Level Syllabus

Test Analyst (TA)
Verso 2012br
Comisso Internacional para Qualificao de Teste de Software
Responsvel pela traduo: BSTQB/TAG01 Documentao

Baseada na verso 2012 do CTAL Syllabus do ISTQB.
Brazilian Software Testing Qualifications Board
Nota de direitos autorais
O presente documento pode ser reproduzido total ou parcialmente mediante citao da fonte.
Copyright Comisso Internacional para Qualificao de Teste de Software (doravante denominada ISTQB)
Subgrupo de trabalho de analistas de testes de nvel avanado: Judy McKay (presidenta), Mike Smith, Erik Van Veenendaal,
2010-2012.
Certified Tester Advanced Level

[TA] Test Analyst Syllabus
Histrico de revises
Verso
Data
Observaes
ISEB v1.1
04/09/01
ISEB Practitioner Syllabus.
ISTQB 1.2E
Setembro
de 2003
ISTQB Advanced Level Syllabus do Grupo de Software da Organizao

Europeia para a Qualidade (EOQ-SG, na sigla em ingls).
V2007
12/10/07
Verso de 2007 do Certified Tester Advanced Level Syllabus.
D100626
26/06/10
Incorporao das alteraes aceitas em 2009 e diviso de captulos por mdulos

diferentes.
D101227
27/12/10
Aceitao de alteraes no formato e correes que no afetam o significado

das frases.
D2011
23/10/11
Diviso do syllabus, reviso dos objetivos de aprendizagem e alteraes no

texto para manter a coerncia com os objetivos de aprendizagem. Acrscimo
de resultados comerciais.
Alfa 2012
09/03/12
Incorporao de todos os comentrios das comisses nacionais recebidos em

funo do lanamento da verso de outubro.
Beta 2012
07/04/12
Incorporao de todos os comentrios das comisses nacionais recebidos em

funo do lanamento da verso alfa.
Beta 2012
07/04/12
Envio da verso beta Assembleia Geral.
Beta 2012
08/06/2012
Envio da verso revisada s comisses nacionais.
Beta 2012
27/06/12
Incorporao de comentrios do EWG e glossrio.
RC 2012
15/08/12
Lanamento de rascunho incluso de edies finais das comisses nacionais.
GA 2012
19/10/12
Edies e correes finais para lanamento por parte da Assembleia Geral.
Verso 2012br
Advanced Level Syllabus - Test Analyst
Pgina 2 de 73

ndice
0.
Introduo ao syllabus ............................................................................................. 7

0.1
Objeto do documento .......................................................................................................... 7
0.2
Panorama ............................................................................................................................ 7
0.3
Objetivos de aprendizagem sujeitos avaliao ................................................................. 7
Processo de teste 300 minutos .............................................................................. 8
1.
1.1
Introduo ........................................................................................................................... 9
1.2
Teste no ciclo de vida de desenvolvimento de software ..................................................... 9
1.3
Planejamento, monitoramento e controle de testes ........................................................... 11
1.3.1 Planejamento de testes ...................................................................................................... 11

1.3.2 Monitoramento e controle de testes .................................................................................. 12
1.4
Anlise de testes ................................................................................................................ 12
1.5
Modelagem de testes ......................................................................................................... 13
1.5.1 Casos de teste concretos e lgicos .................................................................................... 14

1.5.2 Criao de casos de teste................................................................................................... 14
1.6
Implementao de testes ................................................................................................... 16
1.7
Execuo de testes ............................................................................................................ 18
1.8
Avaliao de critrios de sada e divulgao .................................................................... 19
1.9
Atividades de fechamento de teste .................................................................................... 20
Gesto de testes: responsabilidades do Test Analyst (TA) 90 minutos ............. 22
2.
2.1
Introduo ......................................................................................................................... 23
2.2
Monitoramento e controle do andamento dos testes ......................................................... 23
2.3
Teste distribudo, terceirizado e internalizado .................................................................. 24
2.4
As tarefas do Test Analyst (TA) nos testes baseados em riscos ....................................... 25
2.4.1 Panorama .......................................................................................................................... 25

2.4.2 Identificao de riscos....................................................................................................... 25
2.4.3 Avaliao de riscos ........................................................................................................... 25
2.4.4 Mitigao de riscos ........................................................................................................... 26
Tcnicas de teste 825 minutos ............................................................................ 28
3.
3.1
Introduo ......................................................................................................................... 30
Verso 2012br
Pgina 3 de 73

3.2
Tcnicas baseadas em especificaes ............................................................................... 30
3.2.1 Partio de equivalncia ................................................................................................... 30

3.2.2 Anlise de valores-limite .................................................................................................. 31
3.2.3 Tabelas de deciso ............................................................................................................ 32
3.2.4 Grficos de causa e efeito ................................................................................................. 33
3.2.5 Teste de transio de estados ............................................................................................ 34
3.2.6 Tcnicas de testes combinatrios ...................................................................................... 35
3.2.7 Teste de caso de uso .......................................................................................................... 37
3.2.8 Teste de estria de usurio ................................................................................................ 38
3.2.9 Combinao de tcnicas .................................................................................................... 39
3.3
Tcnicas baseadas em defeitos .......................................................................................... 40
3.3.1 Uso das tcnicas baseadas em defeitos ............................................................................. 40

3.3.2 Taxonomias de defeitos .................................................................................................... 41
3.4
Tcnicas baseadas na experincia ..................................................................................... 42
3.4.1 Suposio de erros ............................................................................................................ 42

3.4.2 Teste baseado em checklist ............................................................................................... 43
3.4.3 Teste exploratrio ............................................................................................................. 44
3.4.4 Aplicao da melhor tcnica ............................................................................................. 45
Teste de caractersticas de qualidade do software 120 minutos ......................... 46
4.
4.1
Introduo ......................................................................................................................... 47
4.2
Caractersticas de qualidade para teste de domnio de negcios....................................... 48
4.2.1 Teste de acurcia ............................................................................................................... 49

4.2.2 Teste de adequao ........................................................................................................... 49
4.2.3 Teste de interoperabilidade ............................................................................................... 49
4.2.4 Teste de usabilidade .......................................................................................................... 50
4.2.5 Teste de acessibilidade ...................................................................................................... 53
Revises 165 minutos......................................................................................... 54
5.
5.1
Introduo ......................................................................................................................... 55
5.2
Utilizao de checklists em revises ................................................................................. 55
Gesto de defeitos 120 minutos.......................................................................... 58
6.
6.1
Introduo ......................................................................................................................... 59
6.2
Quando possvel detectar um defeito? ........................................................................... 59

Verso 2012br
Pgina 4 de 73

6.3
Campos dos relatrios de defeito ...................................................................................... 59
6.4
Classificao de defeitos ................................................................................................... 60
6.5
Anlise de causa-raiz ........................................................................................................ 61
Ferramentas de teste 45 minutos ........................................................................ 63
7.
7.1
Introduo ......................................................................................................................... 64
7.2
Ferramentas e automao de testes ................................................................................... 64
7.2.1 Ferramentas de modelagem de testes ................................................................................ 64

7.2.2 Ferramentas de preparao de dados de testes .................................................................. 64
8.
9.
Referncias ............................................................................................................ 69
8.1
Normas .............................................................................................................................. 69
8.2
Documentos do ISTQB ..................................................................................................... 69
8.3
Livros ................................................................................................................................ 69
8.4
Outras referncias ............................................................................................................. 70
ndice remissivo .................................................................................................... 71
Verso 2012br
Pgina 5 de 73

Agradecimentos
O presente documento foi elaborado pelo grupo principal do subgrupo de trabalho de nvel avanado da
International Software Testing Qualifications Board Advanced Test Analyst (TA) composto por Judy
McKay (presidenta), Mike Smith e Erik Van Veenendaal.
O grupo principal gostaria de agradecer equipe de reviso e s comisses nacionais por suas sugestes e
contribuies.
Quando o Advanced Level Syllabus foi concludo, o Grupo de Trabalho de Nvel Avanado contava com os
seguintes integrantes (em ordem alfabtica):
Graham Bath, Rex Black, Maria Clara Choucair, Debra Friedenberg, Bernard Homs (vice-presidente), Paul
Jorgensen, Judy McKay, Jamie Mitchell, Thomas Mueller, Klaus Olsen, Kenji Onishi, Meile Posthuma, Eric
Riou du Cosquer, Jan Sabak, Hans Schaefer, Mike Smith (presidente), Geoff Thompson, Erik van Veenendaal,
Tsuyoshi Yumoto.
As seguintes pessoas revisaram, comentaram e escolheram este syllabus: Graham Bath, Arne Becher, Rex
Black, Piet de Roo, Frans Dijkman, Mats Grindal, Kobi Halperin, Bernard Homs, Maria Jnsson, Junfei Ma,
Eli Margolin, Rik Marselis, Don Mills, Gary Mogyorodi, Stefan Mohacsi, Reto Mueller, Thomas Mueller,
Ingvar Nordstrom, Tal Pe'er, Raluca Madalina Popescu, Stuart Reid, Jan Sabak, Hans Schaefer, Marco
Sogliani, Yaron Tsubery, Hans Weiberg, Paul Weymouth, Chris van Bael, Jurian van der Laar, Stephanie van
Dijk, Erik van Veenendaal, Wenqiang Zheng e Debi Zylbermann.
A Assembleia Geral do ISTQB lanou este documento formalmente no dia 19 de outubro de 2012.
Verso 2012br
Pgina 6 de 73

0. Introduo ao syllabus
0.1 Objeto do documento
O presente syllabus forma a base para a qualificao internacional de testes de software no nvel avanado
para o Test Analyst (TA). O ISTQB fornece o syllabus:
1. s comisses nacionais a fim de traduzi-lo para o idioma local e com a finalidade de credenciar os
provedores de treinamento.
2. As comisses nacionais podem adaptar o syllabus s suas necessidades lingusticas especficas e
modificar as referncias para adapt-las s publicaes locais;
3. s comisses avaliadoras para a elaborao de perguntas no idioma local adaptadas aos objetivos de
aprendizagem de cada syllabus;
4. Aos provedores de treinamento para produzirem os materiais dos cursos e definirem os mtodos
adequados de ensino;
5. Aos candidatos certificao para prepar-los para a avaliao (em funo de um curso de treinamento
ou independentemente disso);
6. comunidade internacional de engenharia de software e sistemas para fomentar o desenvolvimento
da profisso de teste de software e sistemas e servir de base para livros e artigos.
O ISTQB pode permitir que outras entidades utilizem este syllabus para outras finalidades, contanto que
procurem e obtenham uma autorizao prvia por escrito.
0.2 Panorama
O nvel avanado composto por trs syllabi diferentes:
Test Manager (TM);

Test Analyst (TA);
Technical Test Analyst (TTA).
O documento que faz um panorama do nvel avanado [ISTQB_AL_OVIEW] contm as seguintes

informaes:
Os resultados comerciais de cada syllabus;

Um resumo de cada syllabus;
Os relacionamentos entre os syllabi;
Uma descrio dos nveis cognitivos (nveis K);
Os anexos.
0.3 Objetivos de aprendizagem sujeitos avaliao

Os objetivos de aprendizagem fundamentam os resultados comerciais e so utilizados na criao de avaliaes
para a obteno da certificao Advanced Test Analyst Certification. Em geral, todas as partes deste syllabus
esto sujeitas a uma avaliao no nvel K1. Isto , o candidato reconhecer e se lembrar de um termo ou de
um conceito. Os objetivos de aprendizagem nos nveis K2, K3 e K4 aparecem no comeo do captulo
pertinente.
Verso 2012br
Pgina 7 de 73

1. Processo de teste 300 minutos

Palavras-chave
caso de teste concreto, critrio de sada, caso de teste de alto nvel, caso de teste lgico, caso de teste de baixo
nvel, controle de testes, modelagem de testes, execuo de testes, implementao de testes, planejamento de
testes
Objetivos de aprendizagem do processo de teste

1.2
Teste no ciclo de vida de desenvolvimento de software
TA-1.2.1 (K2) Explica-se como e por qu a oportunidade e o nvel do envolvimento do Test Analyst (TA)
variam quando ele trabalha com diferentes modelos de ciclo de vida.
1.3
Planejamento, monitoramento e controle de testes
TA-1.3.1 (K2) Resumem-se as atividades realizadas pelo Test Analyst (TA) para fundamentar o planejamento
e o controle de testes.
1.4
Anlise de testes
TA-1.4.1 (K4) Analisa-se determinada situao, inclusive uma descrio de projeto e um modelo de ciclo de
vida, para definir as tarefas adequadas para o Test Analyst (TA) durante as fases de anlise e modelagem.
1.5
Modelagem de testes
TA-1.5.1 (K2) Explica-se por qu as condies de teste devem ser compreendidas pelos stakeholders.
TA-1.5.2 (K4) Analisa-se a situao de um projeto para determinar o uso mais adequado de casos de teste de
baixo nvel (concretos) e de alto nvel (lgicos).
1.6
Implementao de testes
TA-1.6.1 (K2) Descrevem-se os critrios de sada normais para a anlise e a modelagem de testes e explicase como o atendimento de tais critrios afeta a implementao de testes.
1.7
Execuo de testes
TA-1.7.1 (K3) Em determinada situao, definem-se as etapas e as consideraes que devem ser levadas em
conta na execuo de testes.
1.8
Avaliao de critrios de sada e divulgao
TA-1.8.1 (K2) Explica-se por qu importante contar com informaes exatas sobre a situao da execuo de
casos de teste.
1.9
Atividades de fechamento de teste
TA-1.9.1 (K2) Do-se exemplos de produtos de trabalho que devem ser entregues pelo Test Analyst (TA)
durante as atividades de fechamento de teste.
Verso 2012br
Pgina 8 de 73

1.1 Introduo
No syllabus do nvel fundamental do ISTQB, o processo de teste fundamental contm as seguintes atividades:
Planejamento, monitoramento e controle;

Anlise e modelagem;
Implementao e execuo;
Avaliao de critrios de sada e divulgao;
Atividades de fechamento de teste.
No nvel avanado, algumas destas atividades so consideradas parte para refinar e otimizar mais os
processos, se adequar melhor ao ciclo de vida de desenvolvimento de software e facilitar o monitoramento e
o controle eficazes de testes. Neste nvel, as atividades so as seguintes:
Planejamento, monitoramento e controle;

Anlise;
Modelagem;
Implementao;
Execuo;
Avaliao de critrios de sada e divulgao;
Atividades de fechamento de teste.
As atividades podem ser implementadas sequencialmente ou algumas podem ser implementadas

paralelamente, por exemplo, a modelagem pode ser realizada junto com a implementao (por exemplo, teste
exploratrio). A definio, a modelagem e a execuo dos testes e dos casos de teste corretos so as principais
reas de concentrao do Test Analyst (TA). Embora seja importante compreender as demais etapas do
processo de teste, boa parte do trabalho do Test Analyst (TA) costuma ser feita durante as atividades de anlise,
modelagem, implementao e execuo do projeto de teste.
Os testadores de nvel avanado enfrentam uma srie de desafios ao introduzir os diferentes aspectos de teste
descritos neste syllabus no contexto de suas reas, suas equipes e suas atribuies. importante levar em
considerao tanto os diferentes ciclos de vida de desenvolvimento de software quanto o tipo de sistema
testado, j que tais fatores podem influenciar a abordagem ao teste.
1.2 Teste no ciclo de vida de desenvolvimento de software

A abordagem aos testes segundo o ciclo de vida a longo prazo deve ser considerada e definida nos termos da
estratgia de teste. O momento do envolvimento do Test Analyst (TA) muda de acordo com os vrios ciclos de
vida e o envolvimento, o tempo necessrio, as informaes disponveis e as expectativas podem variar bastante
tambm. Como os processos de teste no so realizados isoladamente, o Test Analyst (TA) precisa saber quando
as informaes podem ser fornecidas a outras reas organizacionais relacionadas como:
Engenharia e gesto de requisitos: avaliao de requisitos;

Gesto de projetos: contribuio para o cronograma;
Gesto de configuraes e alteraes: elaborao de testes de verificao e controle de verses;
Desenvolvimento de software: previses e expectativas;
Manuteno de software: gesto de defeitos e tempo de resposta (por exemplo, o tempo que vai da
deteco soluo de um defeito);
Verso 2012br
Pgina 9 de 73

Suporte tcnico: documentao exata das solues de contorno;

Elaborao de documentos tcnicos (por exemplo, especificaes de modelagem de bancos de dados):
contribuies para os documentos e avaliao tcnica dos documentos.
As atividades de teste precisam combinar com o modelo escolhido de ciclo de vida de desenvolvimento de
software, cuja natureza pode ser sequencial, iterativa ou incremental. Por exemplo, no modelo V sequencial,
o processo de teste fundamental do ISTQB aplicado ao nvel de teste de sistema pode ser adequado da
seguinte maneira:
O planejamento de testes de sistema acontece junto com o planejamento de projetos e o controle de

testes continua at a concluso da execuo e do fechamento de testes de sistema;
A anlise e a modelagem de testes de sistema acontecem junto com as especificaes de requisitos, de
modelagem de sistemas e arquiteturas (de alto nvel) e de modelagem de componentes (de baixo
nvel);
A implementao de ambientes de teste de sistema (por exemplo, bancos e equipamentos de teste)
pode ter incio durante a modelagem de sistemas, embora boa parte dela ocorra junto com o teste de
cdigos e componentes, sendo que, frequentemente, os trabalhos de implementao de testes de
sistema duram at poucos dias antes do comeo da execuo de testes de sistema;
A execuo de testes de sistema comea quando os critrios de entrada dos testes de sistema so
atendidos (ou desconsiderados), o que, normalmente, significa que pelo menos o teste de componente
e, frequentemente, o teste de integrao de componentes foram concludos; A execuo de testes de
sistema continua at o cumprimento dos critrios de sada dos testes de sistema;
A avaliao dos critrios de sada dos testes de sistema e a divulgao dos resultados dos testes de
sistema ocorrem durante a execuo de testes de sistema, geralmente com uma frequncia e uma
urgncia maior quando os prazos dos projetos se aproximam;
As atividades de fechamento de testes de sistema ocorrem depois que os critrios de sada dos testes
de sistema foram atendidos e a execuo de testes de sistema foi concluda, embora, s vezes, possam
ser atrasadas at a concluso dos testes de aceitao e a finalizao de todas as atividades do projeto.
Pode ser que os modelos iterativos e incrementais no sigam a mesma ordem de tarefas e talvez excluam
algumas tarefas. Por exemplo, um modelo iterativo pode utilizar um nmero menor de processos de teste
padro para cada iterao. A anlise, a modelagem, implementao, a execuo e a divulgao podem ser
realizadas para cada iterao, enquanto o planejamento feito no incio do projeto e a divulgao do
fechamento realizada no final. Em um projeto gil, so comuns a utilizao de um processo menos
formalizado e um relacionamento de trabalho muito mais entrosado para facilitar as mudanas no projeto.
Como o processo gil leve, h menos documentos de teste abrangentes a favor de um mtodo mais rpido
de comunicao, como reunies dirias em p (porque, como so muito rpidas, normalmente de 10 a 15
minutos, ningum precisa se sentar e todos continuam envolvidos).
De todos os modelos de ciclo de vida, os projetos geis so os que mais exigem o envolvimento precoce do
Test Analyst (TA). O Test Analyst (TA) deve esperar o envolvimento desde o comeo do projeto e a colaborao
com os desenvolvedores medida que constroem a arquitetura inicial e fazem a modelagem. Pode ser que as
avaliaes no sejam formalizadas, mas so contnuas, j que o software evolui. Espera-se o envolvimento ao
longo do projeto e o Test Analyst (TA) deve ficar disposio da equipe. Em funo de tal imerso, os
integrantes das equipes geis normalmente se dedicam a um s projeto e participam totalmente de todos os
aspectos do projeto.
Os modelos iterativos / incrementais vo da abordagem gil, onde alteraes so esperadas medida que o
software evolui, a modelos iterativos / incrementais de desenvolvimento que existem no Modelo V (s vezes
Verso 2012br
Pgina 10 de 73

chamado de iterativo incorporado). Em caso de um modelo iterativo incorporado, espera-se que o Test Analyst
(TA) participe dos aspectos normais de planejamento e modelagem, mas depois assuma uma funo mais
interativa medida que o software desenvolvido, testado, alterado e implantado.
Independentemente do ciclo de vida de desenvolvimento de software utilizado, importante que o Test Analyst
(TA) compreenda as expectativas de envolvimento e a oportunidade de tal participao. H muitos modelos
hbridos em uso, como o iterativo no modelo V supracitado. Frequentemente, o Test Analyst (TA) precisa
determinar a funo e o trabalho mais eficazes para tal em vez de depender da definio de determinado
modelo para indicar o momento adequado do envolvimento.
1.3 Planejamento, monitoramento e controle de testes

Esta parte trata dos processos de planejamento, monitoramento e controle de testes.
1.3.1 Planejamento de testes

Em sua maioria, o planejamento de testes acontece no incio dos testes e envolve a identificao e o
planejamento de todas as atividades e todos os recursos necessrios para cumprir a misso e realizar os objetivos
identificados nesta estratgia de teste. Durante o planejamento de testes, importante que o Test Analyst (TA),
em colaborao com o Test Manager (TM), leve em considerao e faa planos para o seguinte:
Certifique-se de que os planos do teste no se limitam ao teste funcional. Todos os tipos de teste devem
ser levados em considerao no plano de testes e assim agendados. Por exemplo, alm do teste
funcional, o Test Analyst (TA) pode ser responsvel pelo teste de usabilidade. O documento do plano
do teste tambm deve abranger tal tipo de teste;
Revise as estimativas de teste junto ao Test Manager (TM) e certifique-se de que h tempo suficiente
para a obteno e a validao do ambiente de teste;
Faa plano para o teste de configuraes. Se vrios tipos de processadores, sistemas operacionais,
mquinas virtuais, navegadores e diversos perifricos puderem ser combinados em muitas possveis
configuraes, faa planos para aplicar as tcnicas de teste que proporcionaro uma cobertura
adequada a tais combinaes;
Faa planos para testar a documentao. Os usurios recebem o software com a documentao.
A documentao precisa ser exata para ser eficaz. O Test Analyst (TA) deve reservar tempo para
verificar a documentao e pode ter que trabalhar com a equipe de redao tcnica a fim de preparar
os dados que sero utilizados em capturas de tela e videoclipes;
Faa planos para testar os procedimentos de instalao. Os procedimentos de instalao, de back-up e
de restaurao devem ser testados o bastante. Tais procedimentos podem ser mais importantes do que
o prprio software. Se o software no puder ser instalado, no ser nem sequer utilizado. Pode ser
difcil planejar isto, j que, frequentemente, o Test Analyst (TA) faz os testes iniciais em um sistema
que foi pr-configurado sem a implementao dos processos finais de instalao;
Faa planos para que o teste se adapte ao ciclo de vida do software. A execuo sequencial de tarefas
no combina com a maioria dos cronogramas. Frequentemente, muitas tarefas precisam ser realizadas
ao mesmo tempo (pelo menos parte delas);
O Test Analyst (TA) precisa estar ciente do ciclo de vida escolhido e das expectativas de envolvimento
durante a concepo, o desenvolvimento e a implementao do software. Isto tambm inclui reservar
tempo para testes de confirmao e regresso;
Reserve tempo suficiente para a identificao e a anlise de riscos com a equipe interfuncional;
Verso 2012br
Pgina 11 de 73

Embora normalmente no seja responsvel pela organizao das sesses de gesto de risco, espera-se
que o Test Analyst (TA) participe ativamente de tais atividades.
Podem existir relacionamentos complexos entre a base de teste, as condies de teste e os casos de teste, de
modo que muitos relacionamentos podem existir entre tais produtos de trabalho. Eles precisam ser assimilados
para possibilitar a implementao eficaz do planejamento e do controle de testes. Normalmente, o Test Analyst
(TA) a pessoa mais indicada para determinar tais relacionamentos e separar as dependncias o mximo
possvel.
1.3.2 Monitoramento e controle de testes

Embora normalmente o Test Manager (TM) seja responsvel pelo monitoramento e pelo controle de testes, o
Test Analyst (TA) contribui com as medies que possibilitam o controle.
Vrios dados quantitativos devem ser coletados ao longo do ciclo de vida de desenvolvimento de software
(por exemplo, a porcentagem de atividades de planejamento concludas, a porcentagem de cobertura atingida,
o nmero de casos de teste que foram aprovados e reprovados). Em cada caso, uma baseline (isto , uma
referncia) precisa ser definida. Ento, o progresso deve ser rastreado em relao baseline. Enquanto o Test
Manager (TM) se responsabiliza pela compilao e pela divulgao do resumo de mtricas, o Test Analyst
(TA) coleta as informaes referentes a cada mtrica.
Cada caso de teste concludo, cada relatrio de defeito escrito, cada marca atingida sero incorporados s
mtricas gerais do projeto. importante que as informaes introduzidas nas diversas ferramentas de
rastreamento sejam as mais exatas possveis para que as mtricas reflitam a realidade.
Mtricas exatas permitem que os gestores coordenem projetos (monitoramento) e faam as alteraes
necessrias (controle). Por exemplo, um nmero alto de defeitos em uma rea do software pode indicar que
so necessrios mais testes naquela rea. Os requisitos e as informaes da cobertura do risco (rastreabilidade)
podem ser utilizados para a priorizao do trabalho restante e a alocao de recursos. As causas-raiz so
utilizadas para determinar as reas para o aprimoramento de processos. Se os dados registrados forem exatos,
o projeto pode ser controlado e informaes de estado precisas podem ser repassadas aos stakeholders. Futuros
projetos podem ser planejados com maior eficcia quando o planejamento levar em considerao os dados
coletados de projetos passados. Os dados exatos podem ser utilizados de muitas maneiras. Uma das atribuies
do Test Analyst (TA) a de se certificar de que os dados sejam exatos, oportunos e objetivos.
1.4 Anlise de testes

Durante o planejamento de testes, a abrangncia do projeto de teste definida. O Test Analyst (TA) utiliza a
definio da abrangncia para:
Analisar a base de teste;

Identificar as condies de teste.
Para que o Test Analyst (TA) proceda anlise do teste com eficcia, os seguintes critrios de entrada precisam
ser atendidos:
H um documento que descreve o objeto de teste que pode servir de base de teste;
Tal documento foi revisado e obteve resultados razoveis. Aps a reviso, recebeu as atualizaes
necessrias;
Verso 2012br
Pgina 12 de 73

H um oramento e um cronograma razovel para a realizao do trabalho restante de teste referente

a este objeto de teste.
Normalmente, as condies de teste so identificadas pela anlise da base de teste e dos objetivos de teste.
Dependendo da situao, por exemplo, quando os documentos esto velhos ou no existem, as condies de
teste podem ser identificadas atravs de uma conversa com os stakeholders pertinentes (por exemplo, em
workshops ou durante uma sesso de planejamento-relmpago). Ento, tais condies so usadas para
determinar o que testar com tcnicas de modelagem de testes identificadas na estratgia e /ou no plano de teste.
Embora as condies de teste costumem ser prprias do item testado, normalmente o Test Analyst (TA) precisa
levar o seguinte em considerao:
Normalmente, aconselhvel definir as condies de teste em nveis diferentes de detalhe. A

princpio, as condies de alto nvel so identificadas para a definio dos objetivos gerais do teste,
como a funcionalidade da tela x. Em seguida, condies mais detalhadas so identificadas e servem
de base para casos de teste especficos, como a tela x recusa nmeros de conta que ficam um dgito
abaixo do comprimento correto. Com este tipo de abordagem hierrquica para a definio das
condies de teste, possvel garantir que haja cobertura suficiente para os itens de alto nvel;
Se os riscos de produto foram definidos, as condies de teste, que existem necessariamente para lidar
com cada risco de produto, precisam ser identificadas e devolvidas a tal item de risco.
Quando as atividades de anlise de testes forem concludas, o Test Analyst (TA) deve saber quais testes
especficos precisam ser modelados para atender s necessidades das reas atribudas do projeto de teste.
1.5 Modelagem de testes

Ainda de acordo com a abrangncia definida durante o planejamento de testes, o processo de teste continua
com o Test Analyst (TA), que modela os testes que sero implementados e executados. O processo de
modelagem de testes inclui as seguintes atividades:
Determinar em quais reas de teste os casos de teste de baixo nvel (concretos) ou de alto nvel
(lgicos) so mais adequados;
Determinar a/s tcnica/s de modelagem de casos de teste que propiciam a cobertura de teste necessria;
Criar os casos de teste que exercem as condies de teste identificadas.
Os critrios de priorizao identificados durante a anlise de riscos e o planejamento de testes devem ser
aplicados no processo inteiro, da anlise implementao, passando pela modelagem e pela execuo.
Dependendo dos tipos de testes modelados, um dos critrios de entrada para a modelagem de testes pode ser
a disponibilidade das ferramentas que sero utilizadas durante os trabalhos de modelagem.
Ao modelar testes, importante lembrar do seguinte:
possvel tratar de alguns itens de teste com maior facilidade mediante a definio somente das
condies de teste em vez da definio de testes com script. Neste caso, as condies de teste devem
ser definidos para a utilizao como guia para os testes com script;
Os critrios de aprovao / reprovao devem ser claramente identificados;
Os testes devem ser modelados de modo que possam ser compreendidos por outros testadores e no
s o autor. Se o autor no for a pessoa que executa o teste, outros testadores precisaro ler e assimilar
os testes especificados anteriormente para compreenderem os objetivos do teste e a importncia
relativa dele;
Verso 2012br
Pgina 13 de 73

Alm disso, outros stakeholders, como os desenvolvedores, os quais avaliaro os testes, e os auditores,
que talvez tenham que aprov-los, precisam poder compreender os testes;
Os testes devem ser modelados para que cubram todas as interaes do software com os atores (por
exemplo, usurios finais, outros sistemas) e no s as interaes que ocorrem atravs da interface
visvel para o usurio. A comunicao entre processos, a execuo por lotes e outras interrupes
tambm interagem com o software e podem conter defeitos. Assim, o Test Analyst (TA) precisa
modelar testes para mitigar tais riscos;
Os testes devem ser modelados para testar as interfaces entre os diversos objetos de teste.
1.5.1 Casos de teste concretos e lgicos

Uma das atribuies do Test Analyst (TA) consiste em determinar os melhores tipos de casos de teste em
determinada situao. Os casos de teste concretos fornecem todas as informaes especficas e os
procedimentos necessrios para que o testador execute o caso de teste (inclusive quaisquer exigncias de
dados) e verifique os resultados. Os casos de teste concretos so teis quando os requisitos so bem definidos,
quando o pessoal da rea de teste menos experiente e quando a verificao externa dos testes, como
auditorias, exigida. Os casos de teste concretos proporcionam uma reprodutibilidade excelente (isto , outro
testador obter os mesmos resultados), mas tambm exige muitos trabalhos de manuteno e tende a tolher a
engenhosidade do testador durante a execuo.
Os casos de teste lgicos fornecem orientaes referentes ao que deve ser testado, mas permitem que o Test
Analyst (TA) varie os dados reais ou at mesmo o procedimento seguido durante a execuo do teste. Os casos
de teste lgicos podem propiciar uma cobertura melhor do que os casos de teste concretos porque variam um
pouco sempre que so executados. Isto tambm leva perda de reprodutibilidade. Os casos de teste lgicos
so teis quando os requisitos no so bem definidos, quando o Test Analyst (TA) que executar o teste
experiente tanto com o teste quanto com o produto e quando a documentao formal no exigida (por
exemplo, nenhuma auditoria ser realizada). Os casos de teste lgicos podem ser definidos nos momentos
iniciais do processo de requisitos quando eles ainda no esto bem definidos. Tais casos de teste podem ser
utilizados para o desenvolvimento de casos de teste concretos quando os requisitos ficarem mais definidos e
estveis. Neste caso, a criao de casos de teste realizada sequencialmente, fluindo do lgico para o concreto
apenas com os casos de teste concretos utilizados na execuo.
1.5.2 Criao de casos de teste

Os casos de teste so modelados pela elaborao e pelo refinamento por etapas das condies de teste
identificadas atravs da utilizao das tcnicas de modelagem de testes (vide o captulo 3) identificadas na
estratgia e / ou no plano de teste.
Os casos de teste devem poder ser repetidos e verificados e sua origem deve poder ser determinada de acordo
com a base de teste (por exemplo, requisitos), conforme definido pela estratgia de teste utilizada.
A modelagem de casos de teste inclui a identificao do seguinte:
Objetivo;
Pr-condies, como requisitos de projeto ou de ambiente de teste localizado e os planos de entrega,
estado do sistema etc.;
Requisitos de dados de teste (tanto os dados de entrada do caso de teste quanto os dados que devem
existir no sistema para a execuo do caso de teste);
Verso 2012br
Pgina 14 de 73

Resultados esperados;
Ps-condies, como dados afetados, estado do sistema, causas de processamento subsequente etc.
O nvel do detalhe nos casos de teste, que afeta tanto o custo do desenvolvimento quanto o nvel de repetio
durante a execuo, deve ser definido antes da criao dos casos de teste. Menos detalhes no caso de teste
proporcionam ao Test Analyst (TA) mais flexibilidade na execuo de casos de teste e lhe d a oportunidade
de investigar reas de possvel interesse. Contudo, menos detalhes tambm tendem a diminuir a
reprodutibilidade.
Frequentemente, um desafio em particular a definio do resultado esperado de um teste. Calcular isto
manualmente muitas vezes tedioso e tende ao erro. Se possvel, prefervel encontrar ou criar um orculo
de testes automatizados. Ao identificar os resultados esperados, os testadores se preocupam no s as sadas
na tela, mas tambm com os dados e as ps-condies ambientais. Se a base de teste for claramente definida,
a identificao do resultado correto, na teoria, deve ser simples. No entanto, frequentemente as bases de teste
so vagas, contraditrias, carentes de cobertura para reas importantes ou totalmente inexistentes. Em tais
casos, o Test Analyst (TA) deve ter expertise no assunto ou contar com acesso a ela. Alm disso, mesmo quando
a base de teste bem especificada, as interaes complexas de estmulos e respostas complexos podem
dificultar a definio dos resultados esperados. Portanto, essencial dispor de um orculo de teste. A execuo
do caso de teste, sem nenhuma maneira de determinar se os resultados esto corretos, agrega muito pouco
valor ou benefcio, gerando, frequentemente, relatrios falsos de falhas ou desconfiana no sistema.
As atividades supracitadas podem ser aplicadas em todos nveis de teste, embora a base de teste varie. Por
exemplo, os testes de aceitao do usurio podem se fundamentar principalmente nas especificaes de
requisitos, nos casos de uso e nos processos de negcios definidos, enquanto os testes de componente podem
se basear principalmente nas especificaes de modelagem de baixo nvel, nas estrias de usurios e no prprio
cdigo. importante se lembrar de que tais atividades acontecem em todos os nveis de teste, embora o alvo
dos testes possa variar. Por exemplo, o teste funcional no nvel da unidade foi modelado para garantir que
determinado componente lhe proporcione a funcionalidade especificada na modelagem detalhada do
componente. O teste funcional no nvel de integrao serve para verificar se os componentes interagem em
conjunto so funcionais ao longo da interao. No nvel do sistema, a funcionalidade integrada deve ser o alvo
do teste. Ao analisar e modelar os testes, importante se lembrar do nvel do alvo do teste e o objetivo do
teste. Isto ajuda a determinar o nvel dos detalhes necessrios e as ferramentas necessrias (por exemplo,
controladores e simuladores no nvel do teste de componente).
Durante o desenvolvimento das condies de teste e dos casos de teste, normalmente alguns documentos so
criados, o que resulta em produtos de trabalho de teste. Na prtica, a documentao dos produtos de trabalho
de teste varia bastante. Ela pode ser afetada por qualquer uma das seguintes alternativas:
Riscos do projeto (o que deve / o que no deve ser documentado);

O valor agregado que a documentao proporciona ao projeto;
As normas que devem ser seguidas e / ou os regulamentos que precisam ser cumpridos;
O modelo de ciclo de vida utilizado (por exemplo, uma abordagem gil procura a documentao
suficiente);
O requisito de rastreabilidade da base de teste atravs da anlise e da modelagem de testes.
Dependendo da abrangncia do teste, a anlise e a modelagem de testes lidam com as caractersticas de

qualidade do/s objeto/s de teste. A norma ISO 25000 [ISO25000] (que suplanta a ISO 9126) contm
referncias teis. Ao testar sistemas de hardware / software, outras caractersticas podem ser aplicadas.
Verso 2012br
Pgina 15 de 73

Os processos de anlise e modelagem de testes podem ser aprimorados ao entrela-los com as avaliaes e
as anlises estticas. Na verdade, a realizao da anlise e da modelagem de testes frequentemente uma
forma de teste esttico porque possvel encontrar problemas nos documentos da base durante este processo.
A anlise e a modelagem de testes com base nas especificaes de requisitos uma maneira excelente de fazer
preparativos para a reunio de avaliao de requisitos. A leitura dos requisitos para que sejam utilizados na
criao de testes exige a compreenso dos requisitos e a capacidade de determinar uma maneira para a avaliar
o cumprimento deles. Frequentemente, esta atividade descobre requisitos que no so claros, no so passveis
de teste ou no contam com critrios de aceitao definidos. Igualmente, os produtos de trabalho de teste,
como os casos de teste, as anlises de risco e os planos de teste, ficam sujeitos a avaliaes.
Alguns projetos, como os que seguem um ciclo de vida gil, podem ter apenas requisitos minimamente
documentados. s vezes, aparecem na forma de estrias de usurio, que descrevem partes pequenas, mas
demonstrveis, da funcionalidade. As estrias de usurio devem incluir a definio dos critrios de aceitao.
Se o software conseguir demonstrar que os critrios de aceitao foram atendidos, normalmente considera-se
que est pronto para a integrao com as demais funcionalidades concludas ou j pode ter sido integrado para
demonstrar sua funcionalidade.
Durante a modelagem de testes, possvel definir os requisitos necessrios de detalhamento da infraestrutura
de teste, embora, na prtica, s sejam finalizados na implementao do teste. Vale lembrar que a infraestrutura
de teste vai alm dos objetos de teste e do testware. Por exemplo, os requisitos da infraestrutura podem incluir
salas, equipamentos, pessoal, software, ferramentas, perifricos, equipamentos de comunicao, autorizaes
de usurio e todos os demais itens necessrios para a execuo dos testes.
Os critrios de sada da anlise e modelagem de testes variaro dependendo dos parmetros do projeto, mas
todos os itens discutidos nestas duas sees devem ser levados em considerao para que sejam includos nos
critrios de sada definidos. importante que os critrios sejam mensurveis e preciso garantir que todas as
informaes e os preparativos necessrios para as etapas seguintes tenham sido providenciados.
1.6 Implementao de testes

A implementao do teste a realizao da modelagem do teste. Ela inclui a criao de testes automatizados,
a organizao de testes (manuais e automatizados) por ordem de execuo, a finalizao dos dados do teste e
dos ambientes de teste e a elaborao de um cronograma de execuo de testes, inclusive a alocao de
recursos, para possibilitar o incio da execuo dos casos de teste. Isto tambm inclui a verificao de critrios
de entrada explcitos e implcitos para o nvel de teste em questo e garante que os critrios de sada das etapas
anteriores no processo foram atendidos. Se os critrios de sada foram pulados, ou por causa do nvel do teste
ou por conta de uma etapa no processo de teste, os trabalhos de implementao provavelmente sero afetados
com atrasos no cronograma, qualidade insuficiente e esforos extra inesperados. importante garantir que
todos os critrios de sada tenham sido atendidos antes de dar incio aos trabalhos de implementao de testes.
Ao determinar a ordem de execuo, muitas questes podem vir tona. Em alguns casos, talvez faa sentido
organizar os casos de teste em sutes de teste (isto , grupos de casos de teste). Isto pode contribuir para a
organizao do teste. Assim, casos de teste relacionados so executados juntos. Se uma estratgia de teste
baseada em risco for utilizada, a ordem de prioridade dos riscos pode determinar a ordem de execuo para os
casos de teste. Outros fatores podem determinar a ordem, como a disponibilidade das pessoas certas, os
equipamentos, os dados e as funcionalidades que devem ser testadas. No incomum que o cdigo seja
lanado em sees e os trabalhos de teste precisam ser coordenados a ordem segundo a qual o software fica
disponvel para o teste. Particularmente em modelos de ciclo de vida incrementais, importante que o Test
Verso 2012br
Pgina 16 de 73

Analyst (TA) se coordene com a equipe de desenvolvimento para garantir o lanamento do software para teste
por ordem testvel.
Durante a implementao do teste, o Test Analyst (TA) deve finalizar e confirmar a ordem segundo a qual os
testes manuais e automatizados sero executados, verificando cuidadosamente as restries que possam exigir
a execuo dos testes de acordo com uma ordem especfica. As dependncias precisam ser documentadas e
verificadas.
O nvel de detalhe e complexidade relacionada referente ao trabalho realizado durante a implementao de
testes pode ser influenciado pelo detalhamento dos casos e das condies de teste. Em alguns casos, preciso
cumprir certos regulamentos e os testes devem fornecer provas de conformidade com as normas pertinentes,
como a DO-178B/ED 12B [RTCA DO-178B/ED-12B] da Agncia Nacional de Aviao Civil dos Estados
Unidos.
Conforme especificado acima, os dados do teste precisam ser testados e, em alguns casos, tais conjuntos de
dados podem ser bastante grandes. Durante a implementao, o Test Analyst (TA) cria dados de entrada e de
ambiente para que sejam carregados nos bancos de dados e em outros repositrios. O Test Analyst (TA) tambm
cria dados que sero utilizados com testes automatizados e testes manuais orientados para dados.
A implementao de testes tambm se responsabiliza pelo/s ambiente/s de teste. Durante esta etapa, o/s
ambiente/s devem ser totalmente preparados e verificados antes da execuo de testes. O ambiente de teste de
adequao essencial. Em outras palavras, o ambiente de teste deve possibilitar a descoberta de defeitos
presentes durante o teste controlado, funcionar normalmente quando no houver nenhuma falha e replicar
adequadamente, se necessrio, o ambiente de produo ou do usurio final para nveis superiores de teste.
Talvez sejam necessrias mudanas no ambiente de teste durante a execuo dos testes, dependendo de
imprevistos nas alteraes, nos resultados dos testes ou outras consideraes. Se houver alguma mudana no
ambiente durante a execuo, importante avaliar o impacto das mudanas nos testes que j foram executados.
Durante a implementao de testes, os testadores precisam garantir que os responsveis pela criao e pela
manuteno do ambiente de testes sejam conhecidos e estejam disposio e que todo o testware e todas as
ferramentas de suporte ao teste e processos relacionados estejam prontos para o uso. Isto inclui a gesto de
configuraes, a gesto de defeitos e o registro e a gesto de testes. Alm disso, o Test Analyst (TA) deve
verificar os procedimentos que coletam dados para a avaliao de critrios de sada e a divulgao dos
resultados dos testes.
A realizao de uma abordagem equilibrada implementao dos testes, conforme determinado durante o
planejamento de testes, uma sbia deciso. Por exemplo, as estratgias de testes analticos baseados em risco
frequentemente se misturam com as estratgias de testes dinmicos. Neste caso, uma porcentagem dos
trabalhos de implementao de testes alocada ao teste, que no segue scripts predeterminados (sem script).
Os testes sem script no devem ser nem ad hoc nem despropositados, j que a durao e a cobertura deles
podem ser imprevisveis, a menos que um cronograma seja definido e os testes sejam credenciados. Ao longo
dos anos, os testadores desenvolveram uma variedade de tcnicas baseadas na experincia, como ataques,
suposio de erros [Myers79] e testes exploratrios. A anlise, a modelagem e a implementao de testes ainda
ocorrem, mas acontecem principalmente durante a execuo de testes.
Ao seguir tais estratgias de testes dinmicos, os resultados de cada teste influenciam a anlise, a modelagem
e a implementao dos testes seguintes. Embora tais estratgias sejam leves e, frequentemente, eficazes na
descoberta de defeitos, alguns contratempos existem. As tcnicas exigem expertise do Teste Analyst. A
durao pode ser difcil de prever, a cobertura pode ser difcil de rastrear e a repetio pode se perder sem uma
boa documentao ou um bom suporte das ferramentas.
Verso 2012br
Pgina 17 de 73

1.7 Execuo de testes
A execuo do teste comea assim que o objeto de teste entregue e os critrios de entrada para a execuo
do teste so atendidos (ou desconsiderados). Os testes devem ser executados de acordo com o plano
determinado durante a implementao de testes, mas o Test Analyst (TA) deve ter tempo o suficiente para
garantir a cobertura de outros cenrios e comportamentos interessantes de teste que so observados durante o
teste (qualquer falha detectada durante tais desvios deve ser descrita, inclusive as variaes do caso de teste
com script, as quais so necessrias para reproduzir a falha). Tal integrao de tcnicas de teste com e sem
script (por exemplo, testes exploratrios) ajudam a criar uma proteo contra as fugas de teste devido a lacunas
na cobertura com script e a evitar o paradoxo do pesticida.
A comparao dos resultados reais com os resultados esperados a alma da atividade de execuo de testes.
O Test Analyst (TA) deve prestar ateno a estas tarefas e se concentrar nelas, seno todos os trabalhos de
modelagem e implementao de testes podem ser em vo quando as falhas no so detectadas (resultado falso
negativo) ou um comportamento correto classificado como incorreto (resultado falso positivo). Se os
resultados esperados e os reais no baterem, houve um incidente. Os incidentes devem ser examinados com
cuidado para determinar a causa (que talvez seja um defeito no objeto de teste) e coletar dados para facilitar a
resoluo do incidente (vide o captulo 6 para obter mais detalhes sobre a gesto de defeitos).
Quando uma falha identificada, os documentos de teste (as especificaes de teste, os casos de teste etc.)
devem ser cuidadosamente avaliados para ter a certeza de que esto corretos. Um documento de teste pode
estar incorreto por uma srie de motivos. Se estiver incorreto, deve ser corrigido e o teste deve ser executado
novamente. Como as mudanas na base de teste e no objeto de teste podem deixar um caso de teste incorreto
esmo depois de o teste ser executado com sucesso vrias vezes, os testadores devem estar cientes da
possibilidade de que os resultados observados se devam a um teste incorreto.
Durante a execuo do teste, os resultados do teste devem ser devidamente registrados. Os testes executados
cujos resultados no foram registram talvez tenham que ser repetidos para identificar o resultado correto, o
que leva a ineficincia e atrasos. (Repare que o registro adequado pode lidar com as questes de cobertura e
repetibilidade relacionadas s tcnicas de teste, como os testes exploratrios.) Como o objeto de teste, o
testware e o ambiente de teste podem estar evoluindo, o registro deve identificar as verses especficas que
foram testadas e as configuraes especficas do ambiente. O registro de testes faz um cronograma dos detalhes
relevantes sobre a execuo dos testes.
O registro de resultados vale tanto para testes individuais quanto para atividades e eventos. Cada teste deve ter
uma identificao nica e o status deve ser cadastrado medida que o teste executado. Todo e qualquer
evento que afetar a execuo de testes deve ser registrado. Um nmero suficiente de informaes deve ser
registrado para medir a cobertura do teste e documentar os motivos de atrasos e interrupes no teste. Alm
disso, as informaes devem ser registradas para apoiar o controle de testes, a divulgao do andamento dos
testes, a medio dos critrios de sada e o aprimoramento do processo de teste.
O cadastramento varia dependendo do nvel de teste e da estratgia. Por exemplo, se o teste automatizado de
componente estiver sendo realizando, os testes automatizados devem produzir boa parte das informaes de
registro. Se o teste manual estiver sendo realizado, o Test Analyst (TA) registrar as informaes referentes
execuo do teste, frequentemente em uma ferramenta de gesto de testes que rastrear as informaes de
execuo dos testes. Em alguns casos, como na implementao de testes, o nmero registrado de informaes
sobre a execuo de testes influenciado por exigncias dos regulamentos ou das auditorias.
Verso 2012br
Pgina 18 de 73

Em alguns casos, os usurios ou os clientes podem participar da execuo de testes. Isto pode servir para criar
confiana no sistema, embora isto suponha que os testes detectaram poucos defeitos. Tal suposio
frequentemente invlida nos nveis iniciais de teste, mas pode ser vlida durante o teste de aceitao.
Seguem algumas reas especficas que devem ser levadas em considerao durante a execuo de testes:
Detectar e explorar singularidades irrelevantes. As observaes ou os resultados que podem parecer

irrelevantes costumam indicar defeitos que (como os icebergs) ficam abaixo da superfcie;
Verifique se o produto no est fazendo o que no deveria estar fazendo. Verificar se o produto est
fazendo o que deve estar fazendo o foco normal do teste, mas o Test Analyst (TA) tambm deve
garantir que o produto no tenha um comportamento inadequado por fazer algo que no deveria estar
fazendo (por exemplo, outras funes indesejadas);
Crie a sute de testes, que crescer e mudar com o tempo. O cdigo evoluir e ser necessrio
implementar outros testes para cobrir estas novas funcionalidades e verificar regresses em outras
reas do software. As lacunas nos testes so frequentemente descobertas durante a execuo. A
elaborao de uma sute de testes um processo contnuo;
Tome notas para o prximo teste. As tarefas do teste no acabam quando o software fornecido ao
usurio ou distribudo no mercado. Uma nova verso ou release do software ser provavelmente
produzido, ento, o conhecimento deve ser armazenado e transferido aos testadores responsveis pelo
prximo teste;
No espere uma nova execuo de todos os testes manuais. No realista esperar que todos os testes
manuais sejam executados novamente. Se houver suspeita de algum problema, o Test Analyst (TA)
deve investig-lo e observ-lo e no supor que ser detectado em uma execuo futura dos casos de
teste;
Minere dados na ferramenta de rastreamento de defeitos para obter outros casos de teste. Crie casos
de teste para defeitos descobertos durante testes sem script ou exploratrios e acrescente-os sute de
testes de regresso;
Encontre os defeitos antes do teste de regresso. Frequentemente, o tempo do teste de regresso
limitado e encontrar falhas durante o teste de regresso pode levar a atrasos no cronograma.
Geralmente, os testes de regresso no detectam boa parte dos defeitos e isso acontece muito porque
so testes que j foram executados (por exemplo, para uma verso anterior do mesmo software) e os
defeitos j deveriam ter sido detectados nos testes anteriores. Isto no quer dizer que os testes de
regresso devam ser totalmente eliminados e sim que a eficcia dos testes de regresso em termos de
capacidade de deteco de novos defeitos inferior dos outros testes.
1.8 Avaliao de critrios de sada e divulgao

Do ponto de vista do processo de teste, o monitoramento do andamento dos testes garante a coleta das
informaes adequadas para atender aos requisitos de divulgao. Isto inclui a medio do andamento at a
concluso. Quando os critrios de sada so definidos nas etapas de planejamento, os critrios
imprescindveis e indicados podem ser detalhados. Por exemplo, os critrios podem declarar que no
dever haver nenhum bug em aberto de Prioridade 1 ou Prioridade 2 e que deve existir uma nota de corte de
95% em todos os casos de teste. Neste caso, o descumprimento dos critrios imprescindveis (dever) deve
provocar a reprovao dos critrios de sada, enquanto uma nota de 93% ainda permitiria que o projeto passasse
ao nvel seguinte. Os critrios de sada devem ser claramente definidos para que possam ser avaliados
objetivamente.
Verso 2012br
Pgina 19 de 73

O Test Analyst (TA) responsvel por fornecer as informaes utilizadas pelo Test Manager (TM) para a
avaliao do progresso at o cumprimento dos critrios de sada e por garantir a exatido dos dados. Se, por
exemplo, o sistema de gesto de testes fornece os seguintes cdigos de status para a concluso do caso de
teste:
Aprovado;
Reprovado;
Aprovado com ressalva.
Ento, o Test Analyst (TA) precisa ser muito claro em relao ao que cada um destes termos significa e dever
aplicar o status com coerncia. Aprovado com ressalva significa que um defeito foi detectado, mas ele no
afeta a funcionalidade do sistema? E o defeito de usabilidade que deixa o usurio confuso? Se a nota de corte
for um critrio de sada imprescindvel, reprovar um caso de teste em vez de aprov-lo com ressalva vira um
fator crucial. Tambm devem ser levados em considerao os casos que foram reprovados, mas cuja causa de
reprovao no um defeito (por exemplo, o ambiente de teste foi configurado inadequadamente). Se houver
alguma confuso referente s mtricas rastreadas ou ao uso dos valores de status, o Test Analyst (TA) deve
esclarecer isto junto ao Test Manager (TM) para que as informaes possam ser rastreadas com exatido e
coerncia ao longo do projeto.
No incomum que o Test Analyst (TA) receba um pedido de relatrio de status durante os ciclos de teste e
uma solicitao de contribuio para o relatrio final quando o teste for concludo. Talvez isto exija a coleta
de mtricas dos sistemas de gesto de defeitos e testes e uma avaliao da cobertura e do andamento geral. O
Test Analyst (TA) deve conseguir usar as ferramentas de divulgao e proporcionar as informaes solicitadas
para que o Test Manager (TM) obtenha as informaes necessrias.
1.9 Atividades de fechamento de teste

Assim que se determinar a concluso da execuo do teste, as principais sadas dos trabalhos de teste devem
ser captadas e repassadas ao responsvel ou arquivadas. Coletivamente, so as chamadas atividades de
fechamento de teste. Espera-se que o Test Analyst (TA) participe da entrega de produtos de trabalho aos que
precisarem deles. Por exemplo, defeitos conhecidos que tenham sido delegados ou aceitos devem ser
comunicados s pessoas que utilizaro e apoiaro o uso do sistema. Os testes e os ambientes de teste devem
ser propiciados aos responsveis pelos testes de manuteno. Entre os outros produtos de trabalho tambm
est o conjunto de testes de regresso (quer automatizados, quer manuais). As informaes sobre os produtos
de trabalho de teste devem ser claramente documentadas, inclusive os links adequados, e os devidos direitos
de acesso devem ser concedidos.
Tambm se espera que o Test Analyst (TA) participe de reunies retrospectivas (aprendizados) em que as lies
importantes (do projeto de teste e de todo o ciclo de vida de desenvolvimento de software) podem ser
documentadas e planos podem ser definidos para ressaltar o bom e eliminar, ou pelo menos controlar, o ruim.
O Test Analyst (TA) uma profunda fonte de informaes para tais reunies e dever participar para que as
informaes vlidas de melhoria de processos sejam coletadas. Se o Test Manager (TM) participar da reunio,
o Test Analyst (TA) dever repassar as informaes pertinentes ao Test Manager (TM) para a apresentao de
um panorama exato do projeto.
O arquivamento de resultados, registros, relatrios e outros documentos e produtos de trabalho no sistema de
gesto de configuraes tambm deve ser realizado. Esta tarefa frequentemente responsabilidade do Test
Analyst (TA) e uma atividade importante de fechamento, particularmente se um futuro projeto precisar
utilizar estas informaes.
Verso 2012br
Pgina 20 de 73

Embora o Test Manager (TM) normalmente determine quais informaes devem ser arquivadas, o Test Analyst
(TA) tambm deve pensar em quais informaes seriam necessrias se o projeto tivesse que ser reiniciado no
futuro. Pensar em tais informaes no final de um projeto pode evitar o desperdcio de meses de trabalho
quando o projeto for recomeado no futuro ou com outra equipe.
Verso 2012br
Pgina 21 de 73

2. Gesto de testes: responsabilidades do Test Analyst (TA) 90

minutos
Palavras-chave
risco de produto, anlise de risco, identificao de riscos, nvel de risco, gesto de risco, mitigao de risco,
teste baseado em risco, monitoramento de testes, estratgia de teste
Objetivos de aprendizagem da gesto de testes: responsabilidades do Test Analyst

(TA)
2.2
Monitoramento e controle do andamento dos testes
TA-2.2.1 (K2) Explicam-se os tipos de informaes que devero ser rastreados durante o teste para possibilitar
o devido monitoramento e controle do projeto.
2.3
Teste distribudo, terceirizado e internalizado
TA-2.3.1 (K2) So dados exemplos de boas prticas de comunicao quando se trabalha em um ambiente de
teste 24 horas por dia.
2.4
As tarefas do Test Analyst (TA) nos testes baseados em riscos
TA-2.4.1 (K3) Em determinada situao de projeto, participa-se da identificao de riscos, a avaliao de risco
realizada e a devida mitigao de risco proposta.
Verso 2012br
Pgina 22 de 73

2.1 Introduo
Embora existam muitas reas nas quais o Test Analyst (TA) interage com o Test Manager (TM) e lhe fornece
dados, esta parte se concentra nas reas especficas do processo de teste nas quais o Test Analyst (TA) um
grande contribuinte. Espera-se que o Test Manager (TM) busque as informaes necessrias do Test Analyst
(TA).
2.2 Monitoramento e controle do andamento dos testes

Existem cinco dimenses principais nas quais o andamento dos testes monitorado:
Riscos de produto (qualidade);

Defeitos;
Testes;
Cobertura;
Confiana.
Os riscos de produto, os defeitos, os testes e a cobertura podem ser e frequentemente so medidos e divulgados
de modos especficos durante o projeto ou a atividade pelo Test Analyst (TA). A confiana, embora mensurvel
atravs de pesquisas, costuma ser divulgada subjetivamente. A coleta das informaes necessrias para apoiar
estas mtricas faz parte do trabalho dirio do Test Analyst (TA). importante se lembrar de que a preciso de
tais dados crucial, j que dados inexatos criaro informaes equivocadas sobre as tendncias e podem levar
a concluses incorretas. Na pior das hipteses, dados inexatos resultaro em decises incorretas por parte da
administrao e prejudicaro a credibilidade da equipe de teste.
Ao utilizar uma abordagem de teste baseado em risco, o Test Analyst (TA) deve rastrear:
Quais riscos foram mitigados pelo teste;

Quais riscos so considerados no mitigados.
O rastreamento da mitigao de riscos realizado frequentemente com uma ferramenta que tambm rastreia a
concluso do teste (por exemplo, ferramentas de gesto de testes). Isto exige que os riscos identificados sejam
mapeados nas condies de teste, que so mapeadas nos casos de teste, que mitigaro os riscos se os casos de
teste forem executados e aprovados. Desta maneira, as informaes sobre a mitigao de riscos so atualizadas
automaticamente medida que os casos de teste so atualizados. Isto pode ser feito para os testes manuais e
os automatizados.
O rastreamento de defeitos costuma ser realizado com uma ferramenta de rastreamento de defeitos. Quando
os defeitos so registrados, as informaes especficas sobre a classificao de cada defeito so registradas
tambm. Tais informaes so utilizadas para produzir tendncias e grficos que indicam o andamento do teste
e a qualidade do software. As informaes sobre a classificao so discutidas mais detalhadamente no
captulo sobre Gesto de defeitos. O ciclo de vida pode afetar a quantidade registrada de documentos sobre
defeitos e os mtodos usados para registrar as informaes.
medida que os testes vo sendo realizados, as informaes sobre a situao do caso de teste devem ser
registradas. Isto costuma ser feito com a ferramenta de gesto de testes, mas pode ser realizado manualmente,
se necessrio. As informaes sobre os casos de teste podem incluir:
A situao da criao do caso de teste (por exemplo, modelado, avaliado);

A situao da execuo do caso de teste (por exemplo, aprovado, reprovado, bloqueado, pulado);
Verso 2012br
Pgina 23 de 73

Informaes sobre a execuo do caso de teste (por exemplo, data e hora, nome do testador, dados
utilizados);
Itens de execuo do caso de teste (por exemplo, capturas de tela, registros de acompanhamento).
maneira dos itens de risco identificados, os casos de teste devem ser mapeados nos itens dos requisitos
testados. importante que o Test Analyst (TA) lembre-se de que, se o caso de teste A for mapeado no requisito
A e este for o nico caso de teste mapeado naquele requisito, quando o caso de teste A for executado e
aprovado, o requisito A ser considerado atendido. Isto pode ser correto ou incorreto.
Em muitos casos, mais casos de teste so necessrios pra testar um requisito totalmente, mas, por conta da
limitao de tempo, apenas um subgrupo de tais testes realmente criado. Por exemplo, se 20 casos de teste
eram necessrios para testar totalmente a implementao de determinado requisito, mas apenas 10 foram
criados e executados, as informaes sobre a cobertura dos requisitos indicaro 100% de cobertura quando, na
verdade, foi obtida uma cobertura de apenas 50%. O rastreamento exato da cobertura e das situaes avaliadas
dos prprios requisitos pode ser utilizado como medida de confiana.
A quantidade (e o nvel de detalhe) das informaes registradas depende de diversos fatores, inclusive o
modelo de ciclo de vida de desenvolvimento de software. Por exemplo, em projetos geis, normalmente menos
informaes sobre situaes sero registradas devido interao prxima da equipe e a uma maior
comunicao em pessoa.
2.3 Teste distribudo, terceirizado e internalizado

Em muitos casos, nem todos os trabalhos de teste so realizados por uma nica equipe de teste composta por
colaboradores do resto da equipe de projetos no mesmo local que o resto da equipe de projetos. Se os trabalhos
de teste acontecerem em vrios locais, os trabalhos de teste se chamam distribudos. Se acontecerem em um
s local, podem ser chamados de centralizados. Se os trabalhos de teste forem realizados em um ou mais locais
por pessoas que no so colegas do resto da equipe de projetos e no dividem o mesmo local com a equipe de
projetos, podem ser chamados de terceirizados. Se os trabalhos de teste forem realizados por pessoas que
dividem o mesmo local com a equipe de projetos, mas que no so seus colegas, podem ser chamados de
internalizados.
Ao trabalhar em um projeto em que parte da equipe de teste se distribui em vrios locais ou at mesmo em
vrias empresas, o Test Analyst (TA) precisa prestar ateno especial eficcia da comunicao e
transferncia de informaes. Algumas organizaes trabalham de acordo com um modelo de teste 24 horas
no qual se espera que a equipe em um fuso horrio entregue o trabalho equipe de outro fuso horrio para
permitir que o teste continue 24 horas por dia. Isto exige planejamento especial por parte do Test Analyst (TA),
que entregar e receber trabalho. O bom planejamento importante para entender as responsabilidades, mas
vital garantir a disponibilidade das informaes adequadas.
Quando a comunicao verbal no for possvel, a comunicao por escrito deve bastar. Isto quer dizer que o
e-mail, relatrios de situao e o uso eficaz das ferramentas de gesto de testes e de rastreamento de defeitos
devem ser empregados. Se a ferramenta de gesto de testes permitir a atribuio de testes a indivduos, tambm
pode funcionar como ferramenta de agendamento e uma maneira fcil de transferir trabalho entre as pessoas.
Os defeitos que forem registrados exatamente podem ser repassados aos colaboradores para o
acompanhamento, quando necessrio. A utilizao eficaz de tais sistemas de comunicao vital para uma
organizao que no pode depender da interao pessoal todo dia.
Verso 2012br
Pgina 24 de 73

2.4 As tarefas do Test Analyst (TA) nos testes baseados em riscos
2.4.1 Panorama
No geral, o Test Manager (TM) frequentemente tem a responsabilidade de definir e gerenciar uma estratgia
de testes baseados em riscos. Normalmente, o Test Manager (TM) solicita o envolvimento do Test Analyst
(TA) para garantir que a abordagem baseada em riscos seja implementada corretamente.
O Test Analyst (TA) deve estar envolvido ativamente nas seguintes tarefas de testes baseados em riscos:
Identificao de riscos;
Avaliao de riscos;
Mitigao de riscos.
Estas tarefas so realizadas iterativamente ao longo do ciclo de vida do projeto para lidar com os riscos que
surgirem e as mudanas de prioridades e para avaliar e comunicar as situaes de risco com regularidade.
O Test Analyst (TA) deve trabalhar com a estrutura de testes baseados em riscos definida pelo Test Manager
(TM) para o projeto. Ele deve compartilhar seu conhecimento dos riscos de domnios de negcios que so
inerentes ao projeto, como riscos relacionados a questes comerciais, econmicas e de segurana e a fatores
polticos.
2.4.2 Identificao de riscos

Ao recorrer ao maior nmero possvel de stakeholders, o processo de identificao de riscos provavelmente
detectar o maior nmero possvel de riscos significativos. Como, frequentemente, o Test Analyst (TA) possui
conhecimentos singulares sobre o domnio de negcios especfico do sistema testado, particularmente
indicado para a realizao de entrevistas com especialistas e usurios do domnio, a realizao de avaliaes
independentes, a utilizao e a facilitao do uso de modelos de risco, a realizao de workshops sobre risco,
a realizao de sesses de brainstorming com possveis usurios e usurios atuais, a definio de listas de
verificao de teste e o recurso a experincias passadas com sistemas ou projetos parecidos. Em particular, o
Test Analyst (TA) deve colaborar com os usurios e outros especialistas em domnios para determinar as reas
de risco operacional que devem ser tratadas durante o teste. O Test Analyst (TA) tambm pode ser
particularmente til na identificao de possveis efeitos de risco sobre usurios e stakeholders.
Entre os exemplos de riscos que podem ser identificados em um projeto esto:
Problemas de acurcia na funcionalidade do software, por exemplo, clculos incorretos;

Problemas de usabilidade, por exemplo, teclas de atalho insuficientes;
Problemas de assimilao, por exemplo, falta de instrues para o usurio em pontos de deciso
fundamentais;
Consideraes a respeito do teste de caractersticas de qualidade especficas so discutidas no captulo
4 deste syllabus.
2.4.3 Avaliao de riscos

Embora a identificao de riscos procure identificar o maior nmero possvel de riscos pertinentes, a avaliao
de riscos o estudo dos riscos identificados. Especificamente, a categorizao de cada risco e a determinao
da probabilidade e do impacto relacionado a cada risco.
Verso 2012br
Pgina 25 de 73

A determinao do nvel de risco normalmente envolve a avaliao da probabilidade de ocorrncia e do
impacto aps a ocorrncia de cada item de risco. A probabilidade de ocorrncia costuma ser interpretada como
a probabilidade de que o problema possa existir no sistema testado e ser observada quando o sistema estiver
sendo produzido. Em outras palavras, provm do risco tcnico. O Technical Test Analyst (TTA) deve contribuir
com a descoberta e a compreenso do possvel nvel de risco tcnico para cada item de risco, enquanto o Test
Analyst (TA) contribui com a compreenso do possvel impacto comercial do problema se ele vir a ocorrer.
O impacto aps a ocorrncia costuma ser interpretado como a gravidade do efeito sobre os usurios, os clientes
ou outros stakeholders. Em outras palavras, provm do risco operacional. O Test Analyst (TA) deve contribuir
com a identificao e a avaliao do possvel impacto de cada item de risco sobre o domnio de negcios ou o
usurio. Entre os fatores que influenciam o risco operacional esto:
Frequncia de uso da caracterstica afetada;

Perda de negcios;
Possvel perda ou responsabilidade financeira, ecolgica ou social;
Sanes legais civis ou penais;
Questes de segurana;
Multas e cassao de licena;
Falta de solues de contorno razoveis;
Visibilidade da caracterstica;
Visibilidade da falha que levou publicidade negativa e a um possvel impacto negativo na reputao;
Perda de clientela.
Aps receber as informaes de risco disponveis, o Test Analyst (TA) precisa definir os nveis de risco
operacional de acordo com as diretrizes estabelecidas pelo Test Manager (TM). Eles podem ser classificados
com palavras (por exemplo, baixo, mdio, alto) ou nmeros. A menos que haja uma forma de medir
objetivamente o risco em uma escala definida, no pode ser uma medida verdadeiramente quantitativa. Medir
a probabilidade e o custo / a consequncia com preciso costuma ser difcil, ento, normalmente, o nvel de
risco determinado qualitativamente.
Nmeros podem ser atribudos ao valor qualitativo, mas isso no o torna uma verdadeira medida quantitativa.
Por exemplo, o Test Manager (TM) pode determinar que o risco operacional deve ser categorizado com um
valor que v de 1 a 10, sendo que 1 o impacto mais alto e, portanto, o de maior risco no negcio. Assim que
a probabilidade (a avaliao do risco tcnico) e o impacto (a avaliao do risco operacional) forem atribudos,
tais valores podem ser multiplicados para definir a classificao geral de risco de cada item de risco. Depois,
a classificao geral utilizada para priorizar as atividades de mitigao de risco. Alguns modelos de testes
baseados em riscos, como o PRISMA [vanVeenendaal12], no combinam os valores de risco e permitem que
a abordagem ao teste trate dos riscos tcnico e operacional separadamente.
2.4.4 Mitigao de riscos

Durante o projeto, o Test Analyst (TA) deve procurar fazer o seguinte:
Reduzir o risco de produto com casos de teste bem modelados que demonstrem, sem sombra de
dvida, se os itens de teste foram aprovados ou reprovados e participar em avaliaes de itens de
software, como requisitos, modelagens e documentos de usurio;
Implementar as atividades adequadas de mitigao de risco identificadas na estratgia de teste e no
plano de teste;
Verso 2012br
Pgina 26 de 73

Reavaliar riscos conhecidos com base em outras informaes coletadas medida que o projeto
implantado, ajustando, conforme for o caso, a probabilidade, o impacto ou os dois;
Reconhecer novos riscos identificados pelas informaes obtidas durante o teste.
Quando se fala de risco de produto (qualidade), o teste uma forma de mitigao de tais riscos. Ao detectar
os defeitos, os testadores reduzem o risco ao ficarem cientes dos defeitos e das oportunidades para lidar com
os defeitos antes do lanamento. Se os testadores no encontrarem nenhum defeito, o teste passa a reduzir o
risco ao garantir que, em certas condies (isto , as condies testadas), o sistema funcione corretamente. O
Test Analyst (TA) ajuda a determinar as opes de mitigao de risco ao investigar as oportunidades de coleta
de dados de teste exatos, criando e testando cenrios de usurio realistas e realizando ou supervisionando os
estudos de usabilidade.
2.4.4.1 Priorizao dos testes

O nvel do risco tambm utilizado para priorizar os testes. Um Test Analyst (TA) pode determinar que h um
alto risco na rea de acurcia transacional em um sistema de contabilidade. Consequentemente, para mitigar
tal risco, o testador pode trabalhar com outros especialistas em domnios de negcios para coletar uma boa
amostra de dados, cuja exatido pode ser processada e verificada. Igualmente, o Test Analyst (TA) pode
determinar que os problemas de usabilidade representam um grande risco para um novo produto. Em vez de
aguardar o teste de aceitao do usurio para descobrir qualquer problema, o Test Analyst (TA) pode priorizar
a realizao de um teste antecipado de usabilidade durante o nvel de integrao para ajudar a identificar e
resolver os problemas de usabilidade no incio do teste. Tal priorizao deve ser considerada o quanto antes
nas etapas de planejamento para que o cronograma consiga contemplar os testes necessrios no devido tempo.
Em alguns casos, todos os testes de risco mais alto so executados antes de quaisquer testes de risco mais
baixo e os testes so executados por uma ordem estrita de risco (chamada frequentemente de primeiro por
contedo). Em outros casos, uma amostragem utilizada para selecionar uma amostra de testes com todos os
riscos identificados, usando o risco para ponderar a seleo e, ao mesmo tempo, garantindo a cobertura de
todos os riscos pelo menos uma vez (chamada frequentemente de primeiro por abrangncia).
Tanto faz se o teste baseado em risco executado primeiro por contedo ou primeiro por abrangncia,
possvel que o tempo alocado para o teste termine sem que todos os testes sejam executados. O teste baseado
em risco permite que os testadores divulguem os riscos administrao em termos do nvel de risco restante
em determinado momento e permite que a administrao decida se vai prorrogar o teste ou repassar o risco
restante aos usurios, aos clientes, ao helpdesk / suporte tcnico e /ou equipe operacional.
2.4.4.2 Ajuste de testes para futuros ciclos de teste

A avaliao de risco no uma atividade nica realizada antes do incio da implementao de testes. Trata-se
de um processo contnuo. Cada futuro ciclo de vida planejado deve passar por uma nova anlise de risco para
levar em conta fatores como:
Qualquer risco de produto novo ou consideravelmente alterado;

reas de instabilidade ou propensas a defeitos detectadas durante o teste;
Riscos advindos de defeitos corrigidos;
Defeitos tpicos encontrados durante o teste;
reas que no foram testadas o suficiente (baixa cobertura do teste).
Se o teste receber mais tempo, possvel expandir a cobertura dos riscos para reas de menor risco.
Verso 2012br
Pgina 27 de 73

3. Tcnicas de teste 825 minutos

Palavras-chave
anlise de valor limite, grfico de causa e efeito, teste baseado em checklist, mtodo de classificao por rvore,
teste combinatrio, teste de tabela de deciso, taxonomia de defeitos, tcnica baseada em defeitos, anlise de
domnios, suposio de erros, partio de equivalncia, tcnica baseada em experincia, teste exploratrio,
arranjo ortogonal, teste de arranjo ortogonal, teste alternado, teste baseado em requisitos, tcnica baseada em
especificaes, teste de transio de estado, carta de teste, teste de caso de uso, teste de estria de usurio
Objetivos de aprendizagem das tcnicas de teste

3.2
Tcnicas baseadas em especificaes
TA-3.2.1 (K2) Explica-se o uso dos grficos de causa e efeito.

TA-3.2.2 (K3) Redigem-se casos de teste para determinado item de especificao mediante a aplicao da
tcnica de modelagem de testes de partio de equivalncia para definir um nvel de cobertura.
tcnica de modelagem de testes de anlise de valores-limite para definir um nvel de cobertura.
tcnica de modelagem de testes da tabela de deciso para definir um nvel de cobertura.
tcnica de modelagem de testes de transio de estado para definir um nvel de cobertura.
tcnica de modelagem de testes de classificao por rvore para definir um nvel de cobertura.
tcnica de modelagem de testes de caso de uso para definir um nvel de cobertura.
TA-3.2.8 (K2) Explica-se como as estrias de usurio so utilizadas para orientar os testes em um projeto gil.
tcnica de modelagem de testes de anlise de domnios para definir um nvel de cobertura.
TA-3.2.10 (K4) Analisam-se o sistema ou as especificaes de requisitos para determinar os provveis tipos
de defeitos detectados e selecionam-se as tcnicas baseadas em especificaes adequadas.
3.3
Tcnicas baseadas em defeitos
TA-3.3.1 (K2) Descreve-se a aplicao das tcnicas de teste baseado em defeitos e diferencia-se o uso das
tcnicas baseadas em especificaes.
TA-3.3.2 (K4) Analisa-se determinada taxonomia de defeitos para a aplicabilidade em determinada situao
com critrios para uma boa taxonomia.
3.4
Tcnicas baseadas na experincia
TA-3.4.1 (K2) Explicam-se os princpios de tcnicas baseadas na experincia e comparam-se os prs e os

contras com as tcnicas baseadas em especificaes e defeitos.
Verso 2012br
Pgina 28 de 73

TA-3.4.2 (K2) Explicam-se os princpios de tcnicas baseadas na experincia e comparam-se os prs e os
contras com as tcnicas baseadas em check-lists.
TA-3.4.3 (K3) Em determinada situao, especificam-se testes exploratrios e explica-se como os resultados
podem ser divulgados.
TA-3.4.4 (K4) Em determinada situao de projeto, determinam-se as tcnicas baseadas em especificaes,
em defeitos ou na experincia que devem ser aplicadas para atingir metas especficas.
Verso 2012br
Pgina 29 de 73

3.1 Introduo
As tcnicas de modelagem de testes consideradas neste captulo so divididas nas seguintes categorias:
Tcnicas baseadas em especificaes (ou baseadas em comportamentos ou caixa-preta);

Tcnicas baseadas em defeitos;
Tcnicas baseadas na experincia.
As tcnicas so complementares e podem ser utilizadas conforme for o caso em qualquer atividade de teste,
independentemente do nvel de teste realizado.
As trs categorias de tcnicas podem ser utilizadas para testar as caractersticas de qualidade funcionais ou no
funcionais. O teste de caractersticas no funcionais discutido no captulo seguinte.
As tcnicas de modelagem de testes discutidas nestas partes podem se concentrar principalmente na
determinao de dados de testes ideais (por exemplo, parties de equivalncia) ou na obteno de sequncias
de teste (por exemplo, modelos de estados). A combinao de tcnicas para a criao de casos de teste
completos comum.
3.2 Tcnicas baseadas em especificaes

As tcnicas baseadas em especificaes so aplicadas s condies de teste para obter casos de teste baseados
em uma anlise da base de teste referente a um componente ou um sistema sem aluso sua estrutura interna.
Entre as caractersticas comuns das tcnicas baseadas em especificaes esto:
Modelos, por exemplo, diagramas de transio de estado e tabelas de deciso, so criados durante a
modelagem de testes de acordo com a tcnica de teste;
As condies de testes so obtidas sistematicamente destes modelos.
Algumas tcnicas tambm dispem de critrios de cobertura, que podem ser utilizados para medir as atividades
de modelagem e execuo de testes. O atendimento total aos critrios de cobertura no significa que todos os
testes foram concludos e, sim, que o modelo deixou de recomendar testes para aumentar a cobertura com base
em tal tcnica.
Os testes baseados em especificaes costumam se fundamentar nos documentos de requisitos do sistema.
Como as especificaes de requisitos devem especificar como o sistema deve se comportar, particularmente
na rea da funcionalidade, a obteno de testes a partir dos requisitos frequentemente faz parte do teste do
comportamento do sistema. Em alguns casos, os requisitos podem no estar documentados, mas existem
requisitos implcitos, como a substituio da funcionalidade de um sistema legado.
H uma srie de tcnicas de teste baseadas em especificaes. As tcnicas tm como objetivo tipos diferentes
de software e cenrios. As sees abaixo mostram a aplicabilidade de cada tcnica, algumas limitaes e
dificuldades com as quais o Test Analyst (TA) pode se deparar, o mtodo de medio da cobertura de teste e
os tipos de defeitos almejados.
3.2.1 Partio de equivalncia

A partio de equivalncia utilizada para reduzir o nmero necessrio de casos de teste para testar com
eficcia o tratamento de entradas, sadas, valores internos e valores relacionados ao tempo. A partio
Verso 2012br
Pgina 30 de 73

utilizada para criar classes de equivalncia (frequentemente chamadas de parties de equivalncia), que so
criadas a partir de conjuntos de valores processados da mesma maneira. Ao selecionar um valor representativo
de uma partio, supe-se a cobertura de todos os itens da mesma partio.
Aplicabilidade
Esta tcnica pode ser aplicada a qualquer nvel de teste e adequada quando se espera que todas as partes de
um conjunto de valores a ser testado sero tratadas da mesma maneira e quando os conjuntos de valores
utilizados na aplicao no interagem entre si.
A seleo dos conjuntos de valores vale para parties vlidas e invlidas (isto , parties que contenham
valores que devem ser considerados invlidos para o software testado). Esta tcnica funciona melhor quando
for utilizada junto com a anlise de valores-limite, que expande os valores de teste e inclui os que ficam nos
limites das parties. Normalmente, esta tcnica utilizada em testes bsicos de um novo pacote ou um novo
release j que ela determina se a funcionalidade bsica est funcionando.
Limitaes / dificuldades
Se a suposio for incorreta e os valores na partio no forem tratados exatamente da mesma maneira, a
tcnica pode acabar ignorando os defeitos. Tambm importante escolher as parties com cuidado. Por
exemplo, um campo de entrada que aceitar nmeros positivos e negativos seria mais bem testado como duas
parties vlidas, uma para os nmeros positivos e outra para os negativos, em funo da probabilidade de
diferena no tratamento. Pode haver outra partio dependendo da admisso do zero. importante que o Test
Analyst (TA) entenda o processamento subjacente para determinar a melhor partio dos valores.
Cobertura
Determina-se a cobertura pegando o nmero de parties para o qual o valor foi testado e dividindo-o pelo
nmero identificado de parties. O uso de vrios valores para uma partio no aumenta a porcentagem da
cobertura.
Tipos de defeitos
Esta tcnica encontra defeitos funcionais no tratamento de diversos valores de dados.
3.2.2 Anlise de valores-limite

A anlise de valores-limite usada para testar os valores que existem nos limites das parties de equivalncia
ordenadas. Existem duas maneiras de abordar a anlise de valores-limite: teste com dois ou trs valores. No
teste com dois valores, o valor-limite (no limite) e o valor que fica um pouco acima do limite (pelo menor
incremento possvel) so utilizados. Por exemplo, se a partio incluir valores de 1 a 10 em incrementos de
0,5, os valores do teste com dois valores referentes ao limite superior seriam 10 e 10,5. Os valores de teste do
limite inferior seriam 1 e 0,5. Os limites so definidos pelos valores mximos e mnimos na partio de
equivalncia definida.
Nos testes com trs valores, os valores antes do limite, no limite e acima do limite so utilizados. No exemplo
anterior, os testes de limite superior incluem 9,5, 10 e 10,5. Os testes de limite inferior incluem 1,5, 1 e 0,5. A
deciso de usar dois ou trs valores-limite deve se basear no risco relacionado ao item testado, sendo que a
abordagem de trs limites usada para os itens de maior risco.
Verso 2012br
Pgina 31 de 73

Aplicabilidade
Esta tcnica vale em qualquer nvel de teste e adequada na presena de parties de equivalncia ordenadas.
A ordenao necessria em funo do conceito de estar no limite e acima dele. Por exemplo, uma variedade
de nmero uma partio ordenada. Uma partio que consiste em todos os objetos retangulares no uma
partio ordenada e no tem valores-limite. Alm das variedades de nmeros, a anlise de valores-limite pode
ser aplicada ao seguinte:
Atributos numricos de variveis no numricas (por exemplo, comprimento);

Laos, inclusive os que existem em casos de uso;
Estruturas de dados armazenados;
Objetos fsicos (inclusive a memria);
Atividades determinadas pelo tempo.
Como a acurcia desta tcnica depende da identificao precisa das parties de equivalncia, fica sujeito s
mesmas limitaes e dificuldades.
O Test Analyst (TA) tambm deve estar ciente dos incrementos nos valores vlidos e invlidos para conseguir
determinar exatamente os valores que sero testados. Apenas as parties ordenadas podem ser utilizadas para
a anlise de valores-limite, mas no se limitam a uma variedade de entradas vlidas. Por exemplo, quando um
teste realizado com o nmero de clulas suportado por uma planilha, h uma partio que contm o nmero
de clulas que chega ao mximo permitido (o limite) e outra partio que comea pela clula acima do mximo
(acima do limite).
Cobertura
Determina-se a cobertura pegando o nmero de condies-limite que foram testadas e dividindo-o pelo nmero
de condies-limite identificadas (quer com o mtodo dos dois valores, quer com o de trs valores). Isto
estipular a porcentagem de cobertura do teste de valores-limite.
Tipos de defeitos
A anlise de valores-limite detecta, de maneira confivel, o deslocamento ou a omisso de limites e pode
encontrar casos de limites extra. Esta tcnica detecta defeitos relacionados ao tratamento dos valores-limite,
particularmente erros com lgica menor e maior (isto , o deslocamento). Tambm pode ser utilizada para
detectar defeitos no funcionais, por exemplo, a tolerncia de limites de carga (por exemplo, o sistema suporta
10.000 usurios ao mesmo tempo).
3.2.3 Tabelas de deciso

As tabelas de deciso so utilizadas para testar a interao entre as combinaes de condies. As tabelas de
deciso so um mtodo claro para verificar a realizao de testes com todas as combinaes de condies
pertinentes e para garantir que todas as possveis combinaes sejam tratadas pelo software em teste. A meta
do teste de tabela de deciso consiste em garantir que todas as combinaes de condies, relacionamentos e
restries sejam testadas. Ao tentar testar todas as combinaes possveis, as tabelas de deciso podem ficar
bem grandes. Um mtodo para a reduo inteligente do nmero de combinaes de todas as possibilidades
para as que so interessantes se chama teste de tabela de deciso recolhida. Quando esta tcnica utilizada,
as combinaes so reduzidas para que produzem sadas diferentes ao remover conjuntos de condies que
no so relevantes para o resultado. So removidos os testes redundantes ou os testes nos quais a combinao
Verso 2012br
Pgina 32 de 73

de condies no possvel. A deciso de utilizar tabelas de deciso cheias ou recolhidas costuma se estar
baseada no risco. [Copeland03]
Aplicabilidade
Esta tcnica costuma ser aplicada aos nveis de teste de integrao, sistema e aceitao. Dependendo do cdigo,
tambm pode valer para teste de componentes quando um componente for responsvel por um conjunto de
lgicas decisrias. A tcnica particularmente til quando os requisitos so apresentados na forma de
fluxogramas ou tabelas de regras de negcios. As tabelas de deciso tambm so uma tcnica de definio de
requisitos e algumas especificaes de requisitos podem j estar neste formato. Mesmo quando os requisitos
no so apresentados em forma de tabela ou fluxograma, as combinaes de condies costumam ser
encontradas no memorial descritivo. Ao projetar tabelas de deciso, importante considerar as combinaes
de condies definidas e as que no foram expressamente definidas, mas que existem. Para modelar uma tabela
de deciso vlida, o testador deve obter todas as consequncias de todas as combinaes de condies das
especificaes ou do orculo de teste. Apenas quando todas as condies de interao forem consideradas, a
tabela de deciso pode ser utilizada como boa ferramenta de modelagem de testes.
Encontrar todas as condies que interagem entre si pode ser difcil, especialmente quando os requisitos no
so bem definidos ou no existem. No incomum preparar um conjunto de condies e determinar que o
resultado esperado desconhecido.
Cobertura
A cobertura mnima de teste para uma tabela de deciso consiste em ter um caso de teste para cada coluna.
Isto supe a inexistncia de condies compostas e que todas as combinaes de condies possveis podem
ser registradas em uma coluna.
Ao determinar os testes de uma tabela de deciso, tambm importante pensar nas condies-limite que devem
ser testadas. As condies-limite podem levar a um aumento do nmero necessrio de casos de teste para testar
o software adequadamente. A anlise de valores-limite e a partio de equivalncia complementam a tcnica
da tabela de deciso.
Tipos de defeitos
Entre os defeitos comuns esto o processamento incorreto com base em combinaes especficas de condies
que produzem resultados inesperados. Durante a criao das tabelas de deciso, os defeitos podem ser
encontrados no documento de especificaes. Os tipos mais comuns de defeitos so as omisses (no h
nenhuma informao referente ao que realmente deve acontecer em determinada situao) e as contradies.
O teste tambm pode encontrar problemas nas combinaes de condies que no so tratadas ou que no so
bem tratadas.
3.2.4 Grficos de causa e efeito

Os grficos de causa e efeito podem ser gerados a partir de qualquer fonte que descreva a lgica funcional
(isto , as regras) de um programa, como estrias de usurios ou fluxogramas. Podem ser teis para obter
um panorama grfico da estrutura lgica de um programa e normalmente servem de base para a criao de
tabelas de deciso. A captura das decises em grficos de causa e efeito e / ou tabelas de deciso possibilita a
cobertura sistemtica de teste da lgica do programa.
Verso 2012br
Pgina 33 de 73

Aplicabilidade
Os grficos de causa e efeito so aplicados nas mesmas situaes que as tabelas de deciso e tambm valem
para os mesmos nveis de teste. Em particular, um grfico de causa e efeito mostra combinaes de condies
que produzem resultados (causalidade), combinaes de condies que excluem resultados (no), condies
mltiplas que devem ser verdadeiras para produzirem um resultado (e) e condies alternativas que podem ser
verdadeiras para produzirem um resultado especfico (ou). Pode ser mais fcil visualizar os relacionamentos
em um grfico de causa e efeito do que um memorial descritivo.
Os grficos de causa e efeito exigem mais tempo e esforo para a assimilao em comparao com outras
tcnicas de modelagem de testes. Alm disso, exigem suporte das ferramentas. Os grficos de causa e efeito
possuem uma notao especfica que deve ser compreendida pelo autor e pelo leitor do grfico.
Cobertura
Cada linha de causa e efeito possvel deve ser testada, inclusive as condies de combinao, para alcanar a
cobertura mnima. Os grficos de causa e efeito incluem um meio para definir as restries nos dados e no
fluxo da lgica.
Tipos de defeitos
Tais grficos detectam os mesmos tipos de defeitos combinatrios encontrados com as tabelas de deciso.
Alm disso, a criao dos grficos facilita a definio do nvel necessrio de detalhe na base de teste e, assim,
contribui com o aprimoramento do o detalhamento e da qualidade da base de teste e facilita a identificao de
requisitos ausentes por parte do testador.
3.2.5 Teste de transio de estados

O teste de transio de estados utilizado para testar a capacidade que o software tem de entrar em e sair de
estados definidos atravs de transies vlidas e invlidas. Os eventos provocam a transio do software de
um estado para outro e a realizao de aes. Os eventos podem ser qualificados por condies (chamadas s
vezes de condies de proteo ou protees de transio), que influenciam o caminho da transio a ser
tomado. Por exemplo, um evento de login com uma combinao vlida de usurio / senha resultar em uma
transio diferente de um evento de login com uma senha invlida.
As transies de estado so rastreadas em um diagrama de transio de estados que mostra todas as transies
vlidas entre estados em formato grfico ou uma tabela de estados que mostra todas as possveis transies,
tanto as vlidas quanto as invlidas.
Aplicabilidade
O teste de transio de estado vale para qualquer software que tenha estados definidos e eventos que causaro
as transies entre estados (por exemplo, a mudana de telas). O teste de transio de estado pode ser utilizado
em qualquer nvel do teste. Software embarcado, web software e qualquer tipo de software transacional so
bons candidatos para este tipo de teste. Os sistemas de controle, isto , os controladores de semforos, tambm
so bons candidatos para este tipo de teste.
A determinao dos estados frequentemente a parte mais difcil da definio da tabela ou do diagrama de
estados. Quando o software possui uma interface de usurio, as diversas telas exibidas ao usurio so
Verso 2012br
Pgina 34 de 73

frequentemente utilizadas para definir os estados. Em relao ao software embarcado, os estados podem
depender dos estados com os quais o hardware lidar.
Alm dos prprios estados, a unidade bsica do teste de transio de estados a transio individual, tambm
conhecida como 0-switch. O simples teste com todas as transies detectar alguns tipos de defeitos na
transio de estados, porm outros podem ser descobertos ao testar as sequncias de transaes. Uma
sequncia de duas transies sucessivas chamada de 1-switch. Uma sequncia de trs transies sucessivas
se chama 2-switch e assim por diante. [s vezes, as switches so chamadas de N-1 switches, onde o N
representa o nmero de transies que ser realizado. Uma nica transio, por exemplo (uma 0-switch) seria
uma 1-1 switch.] [Bath08]
Cobertura
maneira de outros tipos de tcnicas de teste, existe uma hierarquia de nveis de cobertura de teste. O grau
mnimo aceitvel de cobertura consiste em ter visitado todos os estados e ter realizado todas as transies.
Uma cobertura de transio de 100% (tambm conhecida como cobertura 0-switch 100% ou cobertura de
desvio lgico 100%) garantir que todos os estados sero visitados e todas as transies sero realizadas, a
menos que o modelo de modelagem de sistemas ou de transio de dados (diagrama ou tabela) tenha algum
defeito. Dependendo dos relacionamentos entre estados e transies, talvez seja necessrio realizar algumas
transies mais de uma vez para executar outras transies uma s vez.
O termo cobertura N-switch diz respeito ao nmero de transies cobertas. Por exemplo, uma cobertura 1switch 100% exige que todas as sequncias vlidas de duas transies sucessivas tenham sido testadas pelo
menos uma vez. Tal teste pode provocar alguns tipos de falhas que a cobertura 0-switch 100% teria ignorado.
A cobertura de ida e volta corresponde s situaes em que as sequncias de transies formam loops ou laos.
A cobertura de ida e volta 100% alcanada quando todos os laos de qualquer estado de volta ao mesmo
estado foram testados. Todos os estados includos nos laos precisam ser testados.
Em relao a qualquer uma de estas abordagens, um grau ainda maior de cobertura tentar incluir todas as
transies invlidas. Os requisitos de cobertura e os conjuntos de cobertura para o teste de transio de estado
devem verificar a incluso de transies invlidas.
Tipos de defeitos
Entre os defeitos comuns esto o processamento incorreto no estado atual, que um resultado do
processamento ocorrido no estado anterior, de transies incorretas ou no suportadas, de estados sem sadas
e da necessidade de estados ou transies que no existem. Durante a criao do modelo da mquina de estado,
os defeitos podem ser encontrados no documento de especificaes. Os tipos mais comuns de defeitos so as
omisses (no h nenhuma informao referente ao que realmente deve acontecer em determinada situao) e
as contradies.
3.2.6 Tcnicas de testes combinatrios

O teste combinatrio utilizado quando o software testado com diversos parmetros, cada qual com diversos
valores, o que gera mais combinaes do que possvel testar dentro do prazo.
Os parmetros devem ser independentes e compatveis no sentido de que qualquer opo de qualquer fator
pode ser combinada com qualquer opo de qualquer outro fator. As rvores de classificao permitem a
excluso de algumas combinaes se certas opes forem incompatveis. Isto no parte da premissa de que os
fatores combinados no afetaram um ao outro. bem possvel que isto acontea, mas eles devem afetar um
ao outro de uma maneira aceitvel.
Verso 2012br
Pgina 35 de 73

O teste combinatrio serve para identificar um subconjunto propcio de tais combinaes para atingir um nvel
pr-determinado de cobertura. O nmero de itens que devem ser includos nas combinaes pode ser
selecionado pelo Test Analyst (TA), inclusive itens nicos, pares, trios ou mais [Copeland03]. H uma srie de
ferramentas disponveis para ajudar o Test Analyst (TA) nesta tarefa (vide www.pairwise.org para obter
amostras). As ferramentas exigem a listagem dos parmetros e de seus valores (teste alternado e teste de arranjo
ortogonal) ou a sua representao em formato grfico (rvores de classificao) [Grochtmann94]. O teste
alternado um mtodo aplicado nos testes com pares de variveis em combinao. Os arranjos ortogonais,
tabelas matematicamente exatas que permitem que o Test Analyst (TA) substitua os itens que sero testados
pelas variveis no arranjo, produzindo um conjunto de combinaes que atingir um nvel de cobertura quando
testado [Koomen06], so predefinidos. As ferramentas da classificao por rvores permitem que o Test
Analyst (TA) defina o tamanho das combinaes que sero testadas (isto , combinaes de dois valores, trs
valores etc.).
Aplicabilidade
O problema de ter combinaes de valores de parmetros demais se manifesta em pelo menos duas situaes
diferentes que dizem respeito ao teste. Alguns casos de teste contm diversos parmetros, cada qual com uma
srie de valores possveis, por exemplo, uma tela com diversos campos de entrada. Neste caso, as combinaes
de valores de parmetros foram os dados de entrada para os casos de teste. Alm disso, alguns sistemas podem
ser configurados em uma srie de dimenses, o que resulta em um espao de configurao possivelmente
grande. Em ambas as situaes, o teste combinatrio pode ser utilizado para identificar um subconjunto de
combinaes exequveis em tamanho.
Em relao a parmetros com um grande nmero de valores, a partio de equivalncia de classes ou algum
outro mecanismo de seleo pode ser aplicado em cada parmetro individualmente para reduzir o nmero de
valores para cada parmetro antes que o teste combinatrio seja aplicado para reduzir o conjunto de
combinaes resultantes.
Estas tcnicas costumam ser aplicadas aos nveis de teste de integrao, sistema e integrao de sistemas.
A grande limitao destas tcnicas a premissa de que os resultados de alguns testes representam todos os
testes e de que esses poucos testes representam o uso esperado. Se houver uma interao inesperada entre
certas variveis, pode passar despercebida com este tipo de teste se a combinao especfica no for testada.
Talvez seja difcil explicar estas tcnicas para um pblico leigo, j que a reduo lgica dos testes talvez no
seja compreendida.
A identificao dos parmetros e de seus respectivos valores difcil s vezes. difcil encontrar manualmente
um conjunto mnimo de combinaes para satisfazer certo nvel de cobertura. Normalmente, as ferramentas
so utilizadas para encontrar um conjunto mnimo de combinaes. Algumas ferramentas apoiam a capacidade
de forar a incluso ou excluso de algumas (sub)combinaes na / da seleo final de combinaes. Este
recurso pode ser utilizado pelo Test Analyst (TA) para enfatizar fatores com base no conhecimento de domnios
ou nas informaes sobre o uso do produto ou tirar nfase deles.
Cobertura
Existem diversos nveis de cobertura. O nvel mais baixo de cobertura se chama 1-wise ou cobertura nica.
Ele exige a presena de cada valor de cada parmetro em pelo menos uma das combinaes escolhidas. O
nvel seguinte de cobertura se chama 2-wise ou cobertura alternada. Exige a incluso de todos os pares de
valores de dois parmetros em pelo menos uma combinao. Esta ideia pode ser generalizada para abranger a
Verso 2012br
Pgina 36 de 73

cobertura N-wise, que exige a incluso de todas as sub combinaes de valores de qualquer conjunto de
parmetros N no conjunto de combinaes selecionadas.
Quanto maior o N, mais combinaes so necessrias para chegar a 100% de cobertura. A cobertura mnima
com estas tcnicas consiste em ter um caso de teste para cada combinao produzida pela ferramenta.
Tipos de defeitos
O tipo de defeito mais comum detectado com este tipo de teste o relacionado aos valores combinados de
diversos parmetros.
3.2.7 Teste de caso de uso

O teste de caso de uso realiza testes transacionais baseados em cenrios que devem emular o uso do sistema.
Os casos de uso so definidos em termos de interaes entre os atores e o sistema que atingem alguma meta.
Os atores podem ser os usurios ou sistemas externos.
Aplicabilidade
O teste de caso de uso costuma ser aplicado aos nveis de teste de sistema e aceitao. Pode ser utilizado no
teste de integrao dependendo do nvel de integrao e at mesmo no teste de componente dependendo do
comportamento do componente. Frequentemente, os casos de uso tambm servem de base para o teste de
desempenho porque retratam o uso realista do sistema. Os cenrios descritos nos casos de uso podem ser
atribudos a usurios virtuais para a criao de uma carga realista no sistema.
Para serem vlidos, os casos de uso devem retratar transaes de usurio realistas. Esta informao deve partir
de um usurio ou um representante de usurio. O valor de um caso de uso reduzido se o caso de uso no
refletir com preciso as atividades do usurio real. Uma definio precisa dos diversos caminhos alternativos
(fluxos) importante para que a cobertura do teste seja completa. Os casos de uso devem ser considerados
diretrizes, mas no uma definio completa do que deve ser testado, j que talvez no sejam uma definio
clara do conjunto total de requisitos. Alm disso, talvez seja favorvel criar outros modelos, como
fluxogramas, a partir do memorial de casos de uso para aprimorar a acurcia do teste e verificar o prprio caso
de uso.
Cobertura
A cobertura mnima de um caso de uso consiste em ter um caso de teste para o caminho principal (positivo) e
um caso de teste para cada caminho ou fluxo alternativo. Os caminhos alternativos incluem os caminhos de
exceo e falha. s vezes, os caminhos alternativos aparecem como extenses do caminho principal. A
porcentagem de cobertura determinada pegando o nmero de caminhos testados e dividindo-o pelo nmero
total de caminhos principal e alternativos.
Tipos de defeitos
Entre os defeitos esto o tratamento inadequado de cenrios definidos, o tratamento inexistente de caminhos
alternativos, o processamento incorreto das condies apresentadas e a notificao estranha ou incorreta de
erros.
Verso 2012br
Pgina 37 de 73

3.2.8 Teste de estria de usurio
Em algumas metodologias geis, como a SCRUM, os requisitos so preparados na forma de estrias de usurio
que descrevem pequenas unidades funcionais que podem ser modeladas, desenvolvidas, testadas e
demonstradas em uma nica iterao [Cohn04]. As estrias de usurio incluem uma descrio da
funcionalidade a ser implementada e qualquer critrio no funcional e tambm incluem critrios de aceitao
que precisam ser atendidos para que a estria de usurio seja considerada completa.
Aplicabilidade
As estrias de usurio so utilizadas principalmente em ambientes iterativos e incrementais geis e afins. So
usadas em testes funcionais e no funcionais. As estrias de usurio so usadas em testes de todos os nveis
com a expectativa de que o desenvolvedor demonstre a funcionalidade implementada para a estria de usurio
antes da entrega do cdigo aos integrantes da equipe com o prximo nvel de tarefas de teste (por exemplo,
testes de integrao e de desempenho).
Como as estrias so pequenos incrementos de funcionalidade, pode haver um requisito para a produo de
controladores e simuladores a fim de realmente testar a funcionalidade entregue. Isto costuma exigir a
capacidade de programar e utilizar ferramentas que facilitaro o teste, como ferramentas de teste de interface
de programao de aplicativos (API, na sigla em ingls). O desenvolver normalmente responsvel pela
criao dos controladores e dos simuladores, embora um Technical Test Analyst (TTA) tambm possa estar
envolvido na produo do cdigo e na utilizao de ferramentas de teste API. Se um modelo de integrao
contnua for utilizado, como acontece com a maioria dos projetos geis, a necessidade de controladores e
simuladores minimizada.
Cobertura
A cobertura mnima de uma estria de usurio serve para verificar se todos os critrios de aceitao
especificados foram atendidos.
Tipos de defeitos
Normalmente, os defeitos so funcionais, o que quer dizer que o software deixa de executar a funcionalidade
especificada. Alm disso, existem defeitos com problemas de integrao da funcionalidade nova estria com
a funcionalidade que j existe. Como as estrias podem ser desenvolvidas independentemente, podem existir
problemas de desempenho, interface e tratamento de erros. importante que o Test Analyst (TA) teste a
funcionalidade individual fornecida e a integrao sempre que uma nova estria for liberada para teste.
3.2.9 Anlise de domnios

Um domnio um conjunto definido de valores. O conjunto pode ser definido como uma faixa de valores de
uma nica varivel (um domnio unidimensional, por exemplo, homens com mais de 24 anos e menos de 66
anos) ou como faixas de valores de variveis que interagem entre si (um domnio multidimensional, por
exemplo, homens com mais de 24 anos e menos de 66 anos E que pesem mais de 69 kg e menos de 90 kg).
Cada caso de teste de um domnio multidimensional deve incluir os valores adequados de cada varivel
envolvida.
A anlise de domnios de um domnio unidimensional normalmente usa a partio de equivalncia e a anlise
de valores-limite. Assim que as parties forem definidas, o Test Analyst (TA) seleciona os valores de cada
partio que representam um valor que est dentro da partio (IN), fora da partio (OUT), no limite da partio
Verso 2012br
Pgina 38 de 73

(ON) e um pouco fora do limite da partio (OFF). Ao determinar estes valores, cada partio testada junto
com as condies-limite. [Black07]
Com os domnios multidimensionais, o nmero de casos de teste gerados por estes mtodos aumenta
exponencialmente com o nmero de variveis envolvidas, enquanto uma abordagem baseada na teoria dos
domnios leva a um crescimento linear. Alm disso, como a abordagem formal incorpora a teoria dos defeitos
(um modelo de falha), o que a partio de equivalncia e a anlise de valores-limite no tm, seu conjunto
menor de testes encontrar defeitos em domnios multidimensionais que o conjunto de testes heurstico maior
provavelmente ignoraria. Ao lidar com domnios multidimensionais, o modelo de teste pode ser construdo
como tabela de deciso (ou matriz de domnios). A identificao dos valores de casos de teste referentes a
domnios multidimensionais acima de trs dimenses provavelmente exigir suporte computacional.
Aplicabilidade
A anlise de domnios combina as tcnicas utilizadas nas tabelas de deciso, a partio de equivalncia e
anlise de valores-limite para criar um conjunto menor de testes que ainda cobre as reas importantes e as
provveis reas de falha. frequentemente aplicada nos casos em que as tabelas de deciso seriam um
incmodo por conta do grande nmero de variveis que possivelmente interagiriam entre si. A anlise de
domnios pode ser realizada em qualquer nvel de teste, mas mais frequentemente aplicada nos nveis de
teste de integrao e de sistemas.
A realizao de anlises de domnios completas exige uma boa compreenso do software para identificar os
diversos domnios e a possvel interao entre os domnios. Se um domnio no for identificado, o teste pode
ficar bastante incompleto, mas provvel que o domnio seja detectado porque as variveis OFF e OUT podem
aparecer do domnio no detectado. A anlise de domnios uma boa tcnica na hora de trabalhar com um
desenvolvedor para definir as reas de teste.
Cobertura
A cobertura mnima da anlise de domnios consiste em ter um teste para cada valor IN, OUT, ON e OFF em
cada domnio. Quando os valores se sobrepuserem (por exemplo, o valor OUT de um domnio um valor IN
em outro domnio), no h nenhuma necessidade de duplicar os testes. Por conta disto, os testes que so
realmente necessrios frequentemente ficam abaixo de quatro por domnio.
Tipos de defeitos
Entre os defeitos esto problemas funcionais no domnio, o tratamento de valores-limite, problemas de
interao entre as variveis e o tratamento de erros (particularmente os valores que no aparecem em um
domnio vlido).
3.2.10 Combinao de tcnicas

s vezes as tcnicas so combinadas para criar casos de teste. Por exemplo, as condies identificadas em
uma tabela de deciso podem ficar sujeitas partio de equivalncia para a deteco de vrias maneiras de
cumprimento de uma condio. Ento, os casos de teste cobririam no s todas as combinaes de condies,
mas tambm, para as condies que foram partilhadas, outros casos de teste seriam gerados para cobrir as
parties de equivalncia. Ao selecionar a tcnica especfica a ser aplicada, o Test Analyst (TA) deve considerar
a aplicabilidade da tcnica, as limitaes e as dificuldades e as metas do teste em termos de cobertura e defeitos
a serem detectados. Talvez a melhor tcnica para determinada situao no exista. A combinao de tcnicas
Verso 2012br
Pgina 39 de 73

frequentemente proporcionar a cobertura mais completa, contanto que existam tempo e habilidade suficientes
para aplicar as tcnicas corretamente.
3.3 Tcnicas baseadas em defeitos

3.3.1 Uso das tcnicas baseadas em defeitos
Uma tcnica de modelagem de testes baseada em defeitos aquela em que o tipo de defeito procurado serve
de base para a modelagem de testes, sendo que os testes so obtidos sistematicamente do que se sabe sobre o
tipo de defeito. Diferentemente do teste baseado em especificaes, que obtm os testes das especificaes, o
teste baseado em defeitos obtm os testes das taxonomias de defeitos (isto , listas divididas em categorias)
que podem ser completamente independentes do software testado. As taxonomias podem incluir relaes de
tipos de defeitos, causas-raiz, sintomas de falha e outros dados relacionados a defeitos. O teste baseado em
defeitos tambm pode utilizar listas de riscos identificados e cenrios de risco como base para a objetivao
dos testes. Esta tcnica de teste permite que o testador objetive um tipo especfico de defeito ou trabalhe
sistematicamente com uma taxonomia de defeitos conhecidos e comuns de um tipo especfico. O Test Analyst
(TA) utiliza os dados da taxonomia para determinar a meta do teste, que consiste em detectar um tipo especfico
de defeito. Com base nestas informaes, o Test Analyst (TA) criar os casos de teste e as condies de teste
que provocaro a manifestao do defeito, se ele existir.
Aplicabilidade
O teste baseado em defeitos pode ser aplicados em qualquer nvel de teste, mas, normalmente, aplicado
durante o teste de sistema. Existem taxonomias padro que correspondem a vrios tipos de software. Este tipo
especfico de teste com no-produtos contribui para o aproveitamento dos conhecimentos do setor para a
obteno de testes especficos. Ao aderir s taxonomias prprias do setor, as mtricas referentes ocorrncia
de defeitos podem ser rastreadas em diversos projetos e at mesmo em diversas organizaes.
Existem vrias taxonomias de defeitos e elas podem se concentrar em tipos especficos de teste, como a
usabilidade. importante escolher uma taxonomia que possa ser aplicada ao software testado, se houver
disponibilidade. Por exemplo, talvez no haja nenhuma taxonomia disponvel para um software inovador.
Algumas organizaes compilaram suas prprias taxonomias de defeitos provveis ou frequentemente vistos.
Independentemente da taxonomia utilizada, importante definir a cobertura esperada antes de dar incio ao
teste.
Cobertura
A tcnica estipula os critrios de cobertura que so utilizados para determinar quando todos os casos de teste
teis foram identificados. Na prtica, os critrios de cobertura de tcnicas baseadas em defeitos tendem a ser
menos sistemticos do que as tcnicas baseadas em especificaes, j que apenas as regras gerais de cobertura
so determinadas e a deciso especfica sobre o que constitui o limite da cobertura til discricionria.
maneira de outras tcnicas, os critrios de cobertura no significam que todo o conjunto de testes est
completo, mas que os defeitos considerados deixaram de indicar testes teis baseados em tal tcnica.
Tipos de defeitos
Os tipos de defeitos descobertos costuma depender da taxonomia utilizada. Se a taxonomia da interface de
usurio for utilizada, a maioria dos defeitos descobertos provavelmente manteria relao com a interface de
usurio, mas outros defeitos podem ser descobertos como subproduto do teste especfico.
Verso 2012br
Pgina 40 de 73

3.3.2 Taxonomias de defeitos
As taxonomias de defeitos so relaes (listas) de tipos de defeitos dividas em categorias. As listas podem ser
muito gerais e servem de diretrizes de alto nvel ou podem ser muito especficas. Por exemplo, a taxonomia
dos defeitos da interface do usurio pode conter itens gerais, como funcionalidade, tratamento de erros,
visualizao de grficos e desempenho. Uma taxonomia detalhada pode incluir uma lista de todas os possveis
objetos da interface de usurio (particularmente quando se trata de uma interface de usurio grfica) e designar
o tratamento inadequado de tais objetos, como:
Campo de texto
Os dados vlidos no so aceitos;

Os dados invlidos so aceitos;
O comprimento da entrada no verificado;
Os caracteres especiais no so detectados;
As mensagens de erro do usurio no so informativas;
O usurio no consegue corrigir dados errneos;
As regras no so aplicadas.
Campo de dados
Os dados vlidos no so aceitos;

Os dados invlidos no so rejeitados;
As faixas de dados no so verificadas;
Os dados de preciso no so tratados corretamente (por exemplo, hh:mm:ss);
O usurio no consegue corrigir dados errneos;
As regras no so aplicadas (por exemplo, a data final deve ser posterior data de incio).
Muitas taxonomias de defeitos esto disponveis e vo de taxonomias formais que podem ser adquiridas s
modeladas para fins especficos por diversas organizaes. As taxonomias de defeitos desenvolvidas
internamente tambm podem ser utilizadas para objetivar defeitos especficos normalmente encontrados na
organizao. Ao criar uma nova taxonomia de defeitos ou customizar uma disponvel, importante definir
primeiro as metas ou os objetivos da taxonomia. Por exemplo, a meta pode ser a de identificar problemas na
interface de usurio que tenham sido descobertos em sistemas de produo ou identificar problemas
relacionados ao tratamento dos campos de entrada.
Para a criao de uma taxonomia:
1. Crie uma meta e defina o nvel desejado de detalhamento;
2. Selecione determinada taxonomia para servir de base;
3. Defina valores e defeitos comuns que a organizao presencia e /ou que so encontrados na prtica
externamente.
Quanto mais detalhada for a taxonomia, mais tempo levar para desenvolv-la e mant-la, mas resultar em
um nvel maior de reprodutibilidade nos resultados dos testes. Taxonomias detalhadas podem ser redundantes,
mas permitem que a equipe de teste divida o teste sem perda de informaes ou cobertura.
Assim que a taxonomia adequada tiver sido selecionada, pode ser utilizada para criar condies de teste e
casos de teste. Uma taxonomia baseada em risco pode ajudar o teste a se concentrar em uma rea de risco
especfica. As taxonomias tambm podem ser utilizadas em reas no funcionais, como usabilidade,
Verso 2012br
Pgina 41 de 73

desempenho etc. As listas de taxonomia esto disponveis em vrias publicaes do Instituto de Engenheiros
Eletricistas e Eletrnicos (IEEE) e na Internet.
3.4 Tcnicas baseadas na experincia

Os testes baseados na experincia utilizam a habilidade e a intuio dos testadores, juntamente com sua
experincia com aplicaes ou tecnologias parecidas. Os testes so eficazes na hora de detectar defeitos, mas
no to adequados quanto outras tcnicas para atingir nveis especficos de cobertura de teste ou gerar
procedimentos de teste reutilizveis. Quando a documentao do sistema for ruim, o tempo de teste for bem
limitado ou a equipe de teste tiver um timo conhecimento do sistema a ser testado, o teste baseado na
experincia pode ser uma boa alternativa a abordagens mais estruturadas. O teste baseado na experincia pode
ser inadequado em sistemas que exigem detalhamento na documentao de testes, altos nveis de repetibilidade
ou a capacidade de avaliar a cobertura de teste com preciso.
Ao utilizar abordagens dinmicas e heursticas, os testadores normalmente usam testes baseados na
experincia e o teste mais reativo a eventos do que abordagens de teste pre-planejadas. Alm disso, a
execuo e a avaliao so tarefas concomitantes. Algumas abordagens estruturadas aos testes baseados na
experincia no so totalmente dinmicos, isto , os testes no so totalmente criados ao mesmo tempo em
que o testador executa o teste.
Repare que, embora algumas ideias sobre a cobertura mantenham relao com as tcnicas ora discutidas, as
tcnicas baseadas na experincia no possuem critrios formais de cobertura.
3.4.1 Suposio de erros

Ao utilizar a tcnica de suposio de erros, o Test Analyst (TA) utiliza a experincia para supor os possveis
erros que poderiam ter sido cometidos quando o cdigo foi projetado e desenvolvido. Quando os erros
esperados so identificados, o Test Analyst (TA) determina os melhores mtodos para descobrir os defeitos
resultantes. Por exemplo, se o Test Analyst (TA) espera que o software exiba falhas quando uma senha invlida
for digitada, os testes sero modelados para que vrios valores diferentes sejam digitados no campo de senha
para comprovar se o erro foi realmente cometido e resultou em um defeito que pode ser considerado uma falha
quando os testes forem executados.
Alm de ser utilizada como tcnica de teste, a suposio de erros tambm til durante a anlise de risco para
identificar possveis modos de falha. [Myers79]
Aplicabilidade
A suposio de erros realizada principalmente durante o teste de integrao e de sistema, mas pode ser
utilizada em qualquer nvel de teste. Esta tcnica frequentemente usada com outras tcnicas e contribui para
a ampliao da abrangncia dos casos de teste existentes. A suposio de erros tambm pode ser utilizada com
eficcia ao testar os erros comuns de um novo release de software antes de dar incio a testes mais rigorosos
com script. As checklists e as taxonomias podem ser teis na hora de orientar o teste.
difcil avaliar a cobertura e ela varia bastante dependendo da capacidade e da experincia do Test Analyst
(TA). mais bem utilizada por testadores experientes que conhecem os tipos de defeitos que normalmente so
introduzidos no tipo de cdigo testado.
Verso 2012br
Pgina 42 de 73

A suposio de erros normalmente utilizada, mas, frequentemente, no documentada e pode ser menos
reprodutvel do que outras formas de teste.
Cobertura
Quando uma taxonomia utilizada, a cobertura determinada pelas falhas de dados e os tipos de defeitos
adequados. Sem uma taxonomia, a cobertura limitada pela experincia e pelo conhecimento do testado e
pelo tempo disponvel. Os frutos desta tcnica dependero de como o testador consegue objetivar as reas com
problemas.
Tipos de defeitos
Os defeitos comuns costumam ser os definidos na taxonomia especfica ou supostos pelo Test Analyst (TA)
que no foram descobertos durante os testes baseados em especificaes.
3.4.2 Teste baseado em checklist

Ao aplicar a tcnica de teste baseado em checklist, o Test Analyst (TA) experiente utiliza uma lista generalizada
de alto nvel de itens a serem anotados, verificados ou lembrados ou um conjunto de regras ou critrios de
acordo com o qual o produto precisa ser verificado. As checklists so elaboradas com base em um conjunto de
normas, experincia e outras consideraes. Uma checklist de normas de interface de usurio que serve de
base para testar um aplicativo um exemplo de teste baseado em checklist.
Aplicabilidade
O teste baseado em checklist utilizado com maior eficcia em projetos com uma equipe de teste experiente
que conhece o software testado ou a rea coberta pela checklist (por exemplo, para aplicar a checklist da
interface de usurio com sucesso, o Test Analyst (TA) pode conhecer o teste de interface de usurio, mas no
o software testado em especfico). Como as checklists so de alto nvel e tendem a no contar com etapas
detalhadas encontradas normalmente em casos de teste e procedimentos de teste, o conhecimento do testador
utilizado para preencher as lacunas. Ao remover as etapas detalhadas, as checklists so simples e podem ser
aplicadas a vrios releases parecidos. As checklists podem ser utilizadas em qualquer nvel de teste. As
checklists tambm so utilizadas em testes de regresso e testes bsicos.
A natureza de alto nvel das checklists pode afetar a reprodutibilidade dos resultados dos testes. possvel que
vrios testadores interpretem as checklists de maneira diferente e sigam abordagens diferentes para atender
aos itens da checklist. Isto pode provocar resultados diferentes, embora a mesma checklist seja utilizada. Isto
pode resultar em uma cobertura maior, mas, s vezes, a reprodutibilidade sacrificada. Alm disso, as
checklists podem resultar em um exagero de confiana a respeito do nvel de cobertura alcanado, j que o
teste depende do parecer do testador. As checklists podem ser obtidas de casos de teste ou listas detalhadas e
tendem a crescer com o tempo. A manuteno necessria para garantir que as checklists cubram os aspectos
importantes do software testado.
Cobertura
A cobertura to boa quanto a checklist, mas, por conta da natureza de alto nvel da checklist, os resultados
variaro com base no Test Analyst (TA), que executa a checklist.
Tipos de defeitos
Verso 2012br
Pgina 43 de 73

Os defeitos mais comuns encontrados nesta tcnica incluem falhas que decorrem da variao dos dados, da
sequncia das etapas ou do fluxo de trabalho geral durante o teste. A utilizao das checklists pode ajudar a
manter o teste renovado j que novas combinaes de dados e processos so permitidas durante o teste.
3.4.3 Teste exploratrio

O teste exploratrio caracterizado pelo testador que estuda o produto e os defeitos ao mesmo tempo,
planejando o teste a ser realizando, modelando e executando os testes e divulgando os resultados.
O testador ajusta dinamicamente as metas do teste durante a execuo e prepara apenas documentos simples.
[Whittaker09]
Aplicabilidade
Um bom teste exploratrio planejado, interativo e criativo. Exige pouca documentao sobre o sistema a ser
testado e, frequentemente, utilizado em situaes em que a documentao no est disponvel ou no
propcia para outras tcnicas de teste. O teste exploratrio utilizado frequentemente para aprimorar outros
testes e servir de base para o desenvolvimento de outros casos de teste.
Pode ser difcil gerenciar e agendar os testes exploratrios. A cobertura pode ser espordica e a
reprodutibilidade difcil. A utilizao de cartas para a designao de reas de cobertura em uma sesso de
teste e a definio de um cronograma para determinar o tempo de teste so os mtodos utilizados para gerenciar
o teste exploratrio. No final de uma sesso de teste ou um conjunto de testes, o Test Manager (TM) pode
realizar uma reunio para fazer um balano e coletar os resultados dos testes e determinar as cartas das
prximas sesses. As sesses de balano so difceis de escalar para equipes de teste ou projetos grandes.
Outra dificuldade nas sesses exploratrias consiste em rastre-las precisamente em um sistema de gesto de
testes. s vezes, isto feito com a criao de casos de teste que, na verdade, so sesses exploratrias. Isto
permite que o tempo alocado para o teste exploratrio e a cobertura planejada sejam rastreados com outros
testes.
Como a reprodutibilidade pode ser difcil com o teste exploratrio, isto tambm pode causar problemas quando
for necessrio se lembrar das etapas para reproduzir uma falha. Algumas organizaes usam a ferramenta de
captura e execuo de uma ferramenta de automao de testes para gravar as etapas realizadas de um testador
exploratrio. Isto cria um registro completo de todas as atividades durante a sesso exploratria (ou qualquer
sesso de teste baseado na experincia). Explorar os detalhes para detectar a causa real da falha pode ser
tedioso, mas, pelo menos h um registro de todas as etapas envolvidas.
Cobertura
As cartas podem ser criadas para a especificao de tarefas, objetivos e entregveis. Ento, as sesses
exploratrias so planejadas para atingir tais objetivos. Alm disso, a carta tambm pode identificar onde
concentrar o teste, o que est dentro e fora da abrangncia da sesso de teste e quais recursos devem ser
alocados para a concluso dos testes planejados. Uma sesso pode ser utilizada para se focar em tipos
especficos de defeitos e outras reas possivelmente problemticas que podem ser tratadas sem a formalidade
do teste com script.
Tipos de defeitos
Os defeitos comuns encontrados nos testes exploratrios so problemas baseados em cenrios que foram
ignorados durante os testes funcionais com script, problemas que recaem entre limites funcionais e problemas
Verso 2012br
Pgina 44 de 73

relacionados ao fluxo de trabalho. s vezes, problemas de desempenho e segurana tambm so descobertos
durante os testes exploratrios.
3.4.4 Aplicao da melhor tcnica

As tcnicas baseadas em defeitos e na experincia exigem a aplicao do conhecimento dos defeitos e outras
experincias de teste para objetivar o teste a fim de aumentar a deteco de defeitos. Vo de testes rpidos em
que o testador no possui atividades formalmente pr-planejadas para realizar a sesses pr-planejadas,
passando por sesses com script. Quase sempre so teis, mas tm um valor especfico nas seguintes
circunstncias:
Nenhuma especificao est disponvel;

H pouca documentao do sistema testado;
O tempo para modelar e criar testes detalhados insuficiente;
Os testadores tm experincia no domnio e / ou na tecnologia;
A diversidade do teste com script uma meta para a maximizao da cobertura de teste;
As falhas operacionais precisam ser analisadas.
As tcnicas baseadas em defeitos e na experincia tambm so teis quando utilizadas junto com tcnicas
baseadas em especificaes, j que preenchem as lacunas da cobertura do teste decorrentes de pontos fracos
sistemticos em tais tcnicas. maneira das tcnicas baseadas em especificaes, no h uma tcnica
perfeita para todas as situaes. importante que o Test Analyst (TA) entenda os prs e os contras de cada
tcnica e consiga escolher a melhor tcnica ou o melhor conjunto de tcnicas para determinada situao,
considerando o tipo do projeto, o cronograma, o acesso informao, a habilidade do testador e outros
fatores que podem influenciar a escolha.
Verso 2012br
Pgina 45 de 73

4. Teste de caractersticas de qualidade do software 120 minutos

Palavras-chave
teste de acessibilidade, teste de acurcia, atratividade, avaliao heurstica, teste de interoperabilidade,
assimilabilidade, operabilidade, teste de adequao, SUMI, entendibilidade, teste de usabilidade, WAMMI
Objetivos de aprendizagem do teste com caractersticas de qualidade do software

4.2
Caractersticas de qualidade para teste de domnio de negcios
TA-4.2.1 (K2) Explica-se com exemplos quais so as tcnicas de teste adequadas para testar as caractersticas
de acurcia, adequao, interoperabilidade e complacncia.
TA-4.2.2 (K2) Em termos de caractersticas de acurcia, adequao e interoperabilidade, definem-se os defeitos
comuns objetivados.
TA-4.2.3 (K2) Em termos de caractersticas de acurcia, adequao e interoperabilidade, define-se quando a
caracterstica deve ser testada no ciclo de vida.
TA-4.2.4 (K4) Em determinado contexto de projeto, descrevem-se as abordagens que seria adequado confirmar
e validam-se tanto a implementao dos requisitos de usabilidade quanto a materializao das expectativas do
usurio.
TA-4.2.5 (K2) Em termos de usabilidade, define-se quando a caracterstica deve ser testada visando a
acessibilidade para pessoas com necessidades especficas.
Verso 2012br
Pgina 46 de 73

4.1 Introduo
Embora o captulo anterior tenha descrito as tcnicas especficas disponveis para o testador, este captulo
considera a aplicao de tais tcnicas na avaliao das caractersticas principais utilizadas para descrever a
qualidade dos aplicativos ou sistemas do software.
Este syllabus discute as caractersticas de qualidade que podem ser avaliadas pelo Test Analyst (TA). Os
atributos que sero avaliados pelo Technical Test Analyst (TTA) so considerados no syllabus do Advanced
Technical Test Analyst (TTA). A descrio das caractersticas de qualidade do produto estipuladas na ISO 9126
serve de guia para a descrio das caractersticas. Outras normas, como a srie ISO 25000 [ISO25000] (que
suplantou a ISO 9126), tambm podem ser teis. As caractersticas de qualidade da ISO so divididas em
caractersticas de qualidade de produtos (atributos) e cada uma delas pode ter subcaractersticas (subatributos).
Aparecem na tabela abaixo, juntamente com uma indicao de qual caracterstica / subcaracterstica coberta
pelos syllabi do Test Analyst (TA) e do Technical Test Analyst (TTA).
Caracterstica
Subcaractersticas
Test Analyst
(TA)
Technical Test
Analyst (TTA)
Funcionalidade Acurcia, adequao, interoperabilidade, complacncia

X
Segurana
Confiabilidade
Usabilidade
Eficincia
Manutenibilidade
Portabilidade
X
Maturidade (robustez), tolerncia a falhas,
recuperabilidade, complacncia
Entendibilidade, assimilabilidade, operabilidade,
atratividade, complacncia
Desempenho (comportamento relacionado a tempo),

utilizao de recursos, complacncia
Analisabilidade, modificabilidade, estabilidade,
testabilidade, complacncia
Adaptabilidade, instalabilidade, coexistncia,
substitutibilidade, complacncia
O Test Analyst (TA) deve se concentrar nas caractersticas de funcionalidade e usabilidade na qualidade do
software. O teste de acessibilidade deve ser realizado pelo Test Analyst (TA). Embora no aparea como
subcaracterstica, a acessibilidade frequentemente considerada parte do teste de usabilidade. O teste com as
demais caractersticas de qualidade costuma ser considerado responsabilidade do Technical Test Analyst
(TTA). Embora tal alocao de trabalho possa variar em organizaes diferentes, seguida nestes syllabi do
ISTQB.
Verso 2012br
Pgina 47 de 73

A subcaracterstica da complacncia aparece em cada uma das caractersticas de qualidade. Em caso de certos
ambientes de segurana crtica ou regulados, cada caracterstica de qualidade pode ter que cumprir com normas
e regulamentos especficos (por exemplo, a complacncia da funcionalidade pode indicar que a funcionalidade
precisa cumprir com uma norma especfica, como a utilizao de um protocolo de comunicao em particular,
para conseguir enviar / receber dados de um chip). Como as normas podem variar bastante dependendo do
setor, no sero discutidas profundamente aqui. Se o Test Analyst (TA) estiver trabalhando em um ambiente
afetado pelos requisitos de complacncia, importante compreend-los e garantir que tanto o teste quanto a
documentao do teste atendam aos requisitos de complacncia.
Em relao a todas as caractersticas e subcaractersticas de qualidade discutidas nesta seo, os riscos comuns
devem ser reconhecidos para que uma estratgia de teste adequada possa ser formada e documentada. O teste
com caractersticas de qualidade exige foco especfico no tempo do ciclo de vida, na disponibilidade necessria
de ferramentas, software e documentos e na expertise tcnica. Sem o planejamento de uma estratgia para lidar
com cada caracterstica e suas necessidades de teste nicas, o testador pode no ter tempo suficiente para o
planejamento, o reforo e a execuo de testes no cronograma.
Alguns destes testes, por exemplo, o teste de usabilidade, podem exigir a alocao de recursos humanos
especiais, muito planejamento, laboratrios dedicados, ferramentas especficas, habilidades especializadas em
testes e, na maioria dos casos, bastante tempo. Em alguns casos, o teste de usabilidade pode ser realizado por
um grupo diferente de especialistas em usabilidade ou experincia do usurio.
Os testes com caractersticas e subcaractersticas de qualidade devem ser integrados ao cronograma geral de
teste e recursos suficientes devem ser alocados aos trabalhos. Cada uma das reas possui necessidades
especficas, objetiva problemas especficos e pode acontecer em momentos diferentes durante o ciclo de vida
de desenvolvimento de software, como se discute nas sees abaixo.
Embora o Test Analyst (TA) possa no ser responsvel pelas caractersticas de qualidade que exigem uma
abordagem mais tcnica, importante que o Test Analyst (TA) esteja ciente das outras caractersticas e entenda
a sobreposio das reas para o teste. Por exemplo, um produto que for reprovado no teste de desempenho
provavelmente tambm ser reprovado no teste de usabilidade se o usurio levar tempo demais para utiliz-lo
com eficcia. Igualmente, um produto com problemas de interoperabilidade em alguns componentes
provavelmente no est pronto para o teste de portabilidade, j que isto tender a obscurecer os problemas
mais bsicos quando o ambiente for alterado.
4.2 Caractersticas de qualidade para teste de domnio de negcios

O teste funcional o foco principal do Test Analyst (TA). O teste funcional se concentra no que o produto faz.
A base de teste dos testes funcionais geralmente consiste em um documento com requisitos ou especificaes,
na expertise referente ao domnio ou em uma necessidade implcita. Os testes funcionais variam de acordo
com o nvel do teste em que so realizados e tambm podem ser influenciados pelo ciclo de vida de
desenvolvimento de software. Por exemplo, um teste funcional realizado durante o teste de integrao testar
a funcionalidade de mdulos de interface que implementam uma nica funo definida. No nvel do teste de
sistema, os testes funcionais incluem o teste da funcionalidade do aplicativo como um todo. Em relao a
sistemas de sistemas, o teste funcional se concentrar principalmente no teste integral em sistemas integrados.
Em um ambiente gil, o teste funcional costuma ficar limitado funcionalidade disponibilizada na iterao ou
no sprint especfico, embora o teste de regresso com uma iterao possa cobrir todas as funcionalidades
lanadas.
Verso 2012br
Pgina 48 de 73

Uma ampla variedade de tcnicas de teste empregada durante os testes funcionais (vide o captulo 3). Os
testes funcionais podem ser realizados por um testador dedicado, um especialista em domnios ou um
desenvolvedor (normalmente no nvel de componentes).
Alm dos testes funcionais cobertos nesta seo, existem tambm duas caractersticas de qualidade que so
parte da rea de responsabilidade do Test Analyst (TA) e so consideradas reas de teste no funcionais (com
foco em como o produto realiza a funcionalidade). Estes dois atributos no funcionais so a usabilidade e a
acessibilidade.
As seguintes caractersticas de qualidade so consideradas nesta seo:
Subcaractersticas funcionais de qualidade
Acurcia;
Adequao;
Interoperabilidade.
Caractersticas no funcionais de qualidade
Usabilidade;
Acessibilidade.
4.2.1 Teste de acurcia

A acurcia funcional envolve testar a adeso do aplicativo aos requisitos especificados ou implcitos e tambm
pode incluir a acurcia computacional. O teste de acurcia emprega muitas das tcnicas de teste explicadas no
captulo 3 e frequentemente utiliza as especificaes ou um sistema legado como orculo de teste. O teste de
acurcia pode ser realizado em qualquer etapa do ciclo de vida e procura detectar o tratamento incorreto de
dados ou situaes.
4.2.2 Teste de adequao

O teste de adequao envolve a avaliao e a validao da aptido de um conjunto de funes para as tarefas
especificadas. O teste pode ser baseado em casos de uso. O teste de adequao costuma ser realizado durante
o teste de sistema, mas tambm pode ser realizado durante as etapas posteriores do teste de integrao. Os
defeitos descobertos neste teste so indcios de que o sistema no conseguir atender s necessidades do
usurio de uma maneira que seja considerada aceitvel.
4.2.3 Teste de interoperabilidade

O teste de interoperabilidade verifica at que ponto dois ou mais sistemas ou componentes podem trocar
informaes e, em seguida, utilizar as informaes que foram trocadas. O teste deve cobrir todos os ambientesalvo pretendidos (inclusive variaes no hardware, no software, no middleware, no sistema operacional etc.)
para garantir a troca adequada de dados. Na realidade, talvez isto apenas seja factvel para um nmero
relativamente pequeno de ambientes. Em tal caso, o teste de interoperabilidade pode ficar limitado a um grupo
representativo seleto de ambientes. A especificao de testes de interoperabilidade exige que as combinaes
dos ambientes-alvo sejam combinadas, configuradas e disponibilizadas equipe de teste. Ento, os ambientes
so testados com uma seleo de casos de teste funcionais que realizam os diversos pontos de troca de dados
presentes no ambiente.
Verso 2012br
Pgina 49 de 73

A interoperabilidade diz respeito a como diferentes sistemas de software interagem uns com os outros. O
software com boas caractersticas de interoperabilidade pode ser integrado a uma srie de outros sistemas sem
a necessidade de grandes alteraes. Uma srie de mudanas e o esforo necessrio para realizar tais alteraes
podem ser usados como medida de interoperabilidade.
O teste de interoperabilidade de software pode, por exemplo, se concentrar nas seguintes caractersticas de
modelagem:
Normas de comunicao do setor, como XML;

A capacidade de detectar automaticamente as necessidades de comunicao dos sistemas com os
quais interage e ajust-las adequadamente.
O teste de interoperabilidade pode ser particularmente significativo para organizaes que desenvolvem
software e ferramentas comerciais de prateleira (commercial off-the-shelf ou COTS, na sigla em ingls) e
sistemas de sistemas.
Este tipo de teste realizado durante o teste de componente, integrao e sistema com foco na interao do
sistema com o ambiente. No nvel da integrao de sistemas, este tipo de teste feito para determinar se o
sistema totalmente desenvolvido interage bem com os outros sistemas. Como os sistemas podem interoperar
em vrios nveis, o Test Analyst (TA) deve compreender tais interaes e conseguir criar as condies que
realizaro as diversas interaes. Por exemplo, se os dois sistemas trocarem dados, o Test Analyst (TA) deve
conseguir criar os dados e as transaes necessrios para realizar a troca de dados. Vale lembrar que talvez
todas as interaes no estejam claramente especificadas nos documentos de requisitos. Em vez disso, muitas
destas interaes sero definidas apenas nos documentos sobre a arquitetura e a modelagem do sistema. O Test
Analyst (TA) deve conseguir examinar tais documentos e estar preparado para isso a fim de determinar os
pontos de troca de informaes entre sistemas e entre o sistema e seu ambiente para garantir que todos sejam
testados. Tcnicas como as tabelas de deciso, os diagramas de transio de estado, os casos de uso e os testes
combinatrios valem para o teste de interoperabilidade. Entre os defeitos comuns encontrados esto a troca de
dados incorretos entre componentes que interagem entre si.
4.2.4 Teste de usabilidade

importante entender por que os usurios podem ter dificuldades na hora de utilizar o sistema. Para entender
isto, primeiro necessrio ter em mente que o termo usurio pode ser utilizado para indicar uma ampla
variedade de tipos diferentes de pessoas, de especialistas em TI e pessoas com deficincias a crianas.
Algumas instituies nacionais (por exemplo, o Real Instituto Nacional de Cegos da Gr-Bretanha) recomenda
que os sites sejam acessveis para usurios com deficincias, cegos, que possuem viso parcial, com
mobilidade reduzida, surdos e com deficincias cognitivas.
A verificao da usabilidade de aplicativos e sites por parte dos usurios supracitados tambm pode aprimorar
a usabilidade para todos os demais. A acessibilidade discutida abaixo.
O teste de usabilidade verifica a facilidade com a qual o usurio consegue usar ou aprender a usar o sistema
para atingir uma meta especfica em um contexto especfico. O teste de usabilidade procura medir o seguinte:
Eficcia: a capacidade que o software tem de permitir que o usurio atinja metas especficas com
exatido e integralidade em um contexto de uso especfico;
Eficincia: a capacidade que o produto tem de permitir que o usurio invista quantidades adequadas
de recursos em relao eficcia alcanada em um contexto de uso especfico;
Satisfao: a capacidade que o software tem de satisfazer o usurio em um contexto de uso especfico.
Verso 2012br
Pgina 50 de 73

Entre os atributos que podem ser medidos esto:
Entendibilidade: os atributos do software que afetam o esforo exigido pelo usurio para reconhecer
o conceito lgico e sua aplicabilidade;
Assimilabilidade: os atributos do software que afetam o esforo exigido pelo usurio para conhecer
o aplicativo;
Operabilidade: os atributos do software que afetam o esforo exigido pelo usurio para realizar
tarefas com eficcia e eficincia;
Atratividade: a capacidade que o software tem de ser apreciado pelo usurio.
O teste de usabilidade normalmente realizado em duas etapas:
Teste de usabilidade formativa: teste realizado iterativamente durante as etapas de modelagem e

prototipagem para ajudar a orientar (ou formar) a modelagem atravs da identificao de defeitos
de modelagem de usabilidade;
Teste de usabilidade cumulativo: teste realizado aps a implementao para medir a usabilidade e
identificar problemas com um componente ou sistema concludo.
Entre as habilidades do testador de usabilidade devem estar a expertise ou o conhecimento nas seguintes reas:
Sociologia;
Psicologia;
Conformidade com normas nacionais (inclusive normas de acessibilidade);
Ergonomia.
4.2.4.1 Realizao de testes de usabilidade

A validao da implementao real deve ser realizada sob condies o mais prximas possvel daquelas em
que o sistema ser utilizado. Isto pode implicar a montagem de um laboratrio de usabilidade com cmeras,
escritrios de mentira, mesas examinadoras, usurios etc., para que o pessoal de desenvolvimento consiga
observar o efeito do sistema real sobre pessoas de verdade. Frequentemente, um teste de usabilidade formal
exige alguma preparao dos usurios (podem ser usurios reais ou representantes de usurios), que consiste
em lhes dar roteiros ou instrues para que sigam. Outros testes livres permitem que o usurio explore o
software para que os observadores possam determinar se o usurio tem facilidade ou dificuldade na hora de
descobrir como realizar as tarefas.
Muitos testes de usabilidade podem ser executados pelo Test Analyst (TA) como parte de outros testes, por
exemplo, durante um teste de sistema funcional. Para uma abordagem coerente deteco e notificao de
defeitos de usabilidade em todas as etapas do ciclo de vida, as diretrizes de usabilidade podem ser teis. Sem
diretrizes de usabilidade, talvez seja difcil determinar o que uma usabilidade inaceitvel. Por exemplo, se o
usurio precisar de 10 cliques para acessar um aplicativo, isso admissvel? Sem diretrizes especficas, o Test
Analyst (TA) pode se encontrar na posio incmoda de defender relatrios de defeito que o desenvolvedor
deseja encerrar porque o software funciona como foi projetado. muito importante ter as especificaes de
usabilidade verificveis definidas nos requisitos e um conjunto de diretrizes de usabilidade aplicado a todos
os projetos parecidos. As diretrizes devem incluir itens como a acessibilidade das instrues, a clareza dos
prompts, o nmero de cliques para realizar uma atividade, a notificao de erros, os indicadores de
processamento (algum tipo de indcio para o usurio de que o sistema est realizando o processamento e no
consegue aceitar outras entradas no momento), diretrizes de layout da tela, o uso das cores e dos sons e outros
fatores que afetam a experincia do usurio.
Verso 2012br
Pgina 51 de 73

4.2.4.2 Especificaes do teste de usabilidade
Entre as tcnicas principais do teste de usabilidade esto:
Inspeo, avaliao ou reviso;

Interao dinmica com prottipos;
Verificao e validao da implementao real;
Realizao de pesquisas e questionrios.
Inspeo, avaliao ou reviso

A inspeo ou a reviso dos requisitos, das especificaes e das modelagens, do ponto de vista da usabilidade,
que aumentam o nvel de envolvimento do usurio podem ser rentveis se os problemas forem detectados
antecipadamente. A avaliao heurstica (a inspeo sistemtica da modelagem da usabilidade de uma
interface de usurio) pode ser utilizada para detectar problemas de usabilidade na modelagem para que possam
ser dirimidos em um processo de modelagem iterativa. Isto implica fazer um pequeno nmero de avaliadores
examinar a interface e julgar sua complacncia com os princpios aceitos de usabilidade (a heurstica). As
avaliaes so mais eficazes quando a interface de usurio mais visvel. Por exemplo, capturas de tela so
mais fceis de entender e interpretar do que um memorial descritivo da funcionalidade fornecido por uma tela
especfica. A visualizao importante para a devida avaliao de usabilidade da documentao.
Interao dinmica com prottipos
Quando os prottipos forem desenvolvidos, o Test Analyst (TA) deve trabalhar com os prottipos e ajudar os
desenvolvedores a aprimor-los mediante a incorporao do feedback dos usurios modelagem. Assim, os
prottipos podem ser refinados e o usurio consegue ver, de maneira mais realista, o look and feel do produto
acabado.
Verificao e validao da implementao real
Quando os requisitos especificarem as caractersticas de usabilidade do software (por exemplo, o nmero de
cliques para atingir uma meta especfica), devem ser criados casos de teste para verificar se a implementao
do software inclui tais caractersticas.
Para a validao da implementao real, os testes especificados para o teste de sistema funcional podem ser
desenvolvidos como cenrios de teste de usabilidade. Os cenrios de teso medem caractersticas especficas
de usabilidade, como a assimilabilidade ou a operabilidade, em vez de consequncias funcionais.
Os cenrios de teste de usabilidade podem ser desenvolvidos para testar a sintaxe e a semntica
especificamente. A sintaxe a estrutura ou a gramtica da interface (por exemplo, o que pode ser digitado em
um campo de entrada), enquanto a semntica descreve o significado e o propsito (por exemplo, mensagens e
sadas razoveis e significativas do sistema para o usurio) da interface.
Tcnicas caixa-preta (por exemplo, as descritas na seo 3.2), particularmente os casos de uso que podem ser
definidos em texto simples ou com Unified Modeling Language (UML, na sigla em ingls), s vezes so
empregadas nos testes de usabilidade.
Os cenrios de teste dos testes de usabilidade tambm precisam incluir as instrues de usurio, a alocao de
tempo para antes e depois das entrevistas de teste para dar instrues e receber feedback e um protocolo
acordado para a realizao das sesses. Este protocolo inclui uma descrio de como o teste ser realizado, as
oportunidades, os apontamentos, os registros das sesses e os mtodos de entrevista e pesquisa que sero
utilizados.
Verso 2012br
Pgina 52 de 73

Realizao de pesquisas e questionrios
Tcnicas de pesquisa e questionrio podem ser aplicados para coletar observaes e feedback relacionados ao
comportamento do usurio com o sistema. Pesquisas padronizadas publicamente disponveis, como o Software
Usability Measurement Inventory (SUMI) e o Website Analysis and MeasureMent Inventory (WAMMI),
permitem a criao de benchmarks contra um banco de dados de medies de usabilidade anteriores.
Alm disso, como o SUMI faz medies concretas da usabilidade, isto pode fornecer um conjunto de critrios de
concluso / aceitao.
4.2.5 Teste de acessibilidade

importante levar em considerao a acessibilidade ao software para as pessoas que possuem necessidades
especficas ou restries de uso. Isto inclui as pessoas com deficincia. O teste de acessibilidade deve
considerar as normas, como as Diretrizes de Acessibilidade ao Contedo na Web, e as leis pertinentes, como
as Leis sobre a Discriminao contra as Pessoas com Deficincia (Reino Unido e Austrlia) e a Seo 508
(Estados Unidos). A acessibilidade, maneira da usabilidade, deve ser levada em considerao durante as
fases de modelagem. Frequentemente, o teste ocorre durante os nveis de integrao e continua ao longo do
teste de sistema at os nveis de teste de aceitao. Normalmente, os defeitos so determinados quando o
software deixa de atender aos regulamentos designados ou s normas definidas para o software.
Verso 2012br
Pgina 53 de 73

5. Revises 165 minutos

Palavras-chave
nenhuma
Objetivos de aprendizagem das revises

5.1
Introduo
TA-5.1 (K2) Explica-se por que a preparao da reviso importante para o Test Analyst (TA).
5.2
Utilizao de checklists em revises
TA-5.2 (K4) Analisa-se um caso de uso ou uma interface de usurio e identificam-se problemas de acordo com as
informaes da checklist fornecidas no syllabus. Analisam-se especificaes de requisitos ou estrias de usurio e
identificam-se problemas de acordo com as informaes da checklist fornecidas no syllabus.
Verso 2012br
Pgina 54 de 73

5.1 Introduo
Um processo de reviso bem-sucedido exige planejamento, participao e acompanhamento. O Test Analyst
(TA) deve participar ativamente do processo de reviso e oferecer seus pontos de vista nicos. O Test Analyst
(TA) deve contar com treinamento formal em reviso para compreender melhor suas funes respectivas em
qualquer processo de reviso; Todos os participantes de revises devem estar comprometidos com os
benefcios de uma reviso bem feita. Quando bem feitas, as revises podem ser a maior e mais rentvel
contribuio para a qualidade geral proporcionada.
Independentemente do tipo de reviso realizada, o Test Analyst (TA) deve reservar tempo o suficiente para os
preparativos. Isto inclui tempo para revisar o produto de trabalho, verificar os documentos cruzados para
comprovar sua coerncia e determinar o que pode estar faltando no produto de trabalho. Sem tempo suficiente
para os preparativos, o Test Analyst (TA) pode ficar restrito apenas edio do que j aparece no documento
em vez de participar de uma reviso eficiente que maximiza o uso do tempo da equipe de reviso e proporciona
o melhor feedback possvel. Uma boa reviso inclui a compreenso do que est escrito, a determinao do que
est faltando e a comprovao de que o produto descrito mantm a coerncia com outros produtos que ou j
foram desenvolvidos ou esto em desenvolvimento. Por exemplo, ao revisar um plano de teste de integrao,
o Test Analyst (TA) tambm deve levar em considerao os itens que foram integrados. Quais so as condies
necessrias para que estejam prontos para a integrao? Existem dependncias que precisam ser
documentadas? Existem dados disponveis para testar os pontos da integrao? A reviso no se limita ao
produto de trabalho revisado. Tambm deve levar em considerao a interao daquele item com os outros no
sistema.
O autor de um produto revisado pode facilmente se sentir criticado. O Test Analyst (TA) deve fazer de tudo
para abordar quaisquer comentrios sobre a reviso partindo da premissa de colaborao com o autor para a
criao do melhor produto possvel. Ao usar esta abordagem, os comentrios sero feitos de maneira
construtiva e ficaro voltados para o produto de trabalho e no para o autor. Por exemplo, se uma declarao
for ambgua, melhor afirmar No sei o que devo testar para comprovar se este requisito foi implementado
corretamente. Pode me ajudar a entender isto? do que Este requisito ambguo e ningum conseguir
decifr-lo. Em uma reviso, o trabalho do Test Analyst (TA) consiste em garantir que as informaes
fornecidas no produto de trabalho sejam suficientes para fundamentar o teste. Se as informaes inexistirem,
no forem claras ou no fornecerem o nvel necessrio de detalhamento, ento, provavelmente, isto um
defeito que precisa ser corrigido pelo autor. Ao manter uma abordagem positiva em vez de uma abordagem
crtica, os comentrios sero mais bem recebidos e a reunio ser mais produtiva.
5.2 Utilizao de checklists em revises

As checklists so usadas durante as revises para lembrar os participantes de que devem verificar pontos
especficos durante a reviso. Alm disso, as checklists podem ajudar a despersonalizar a reviso, por exemplo:
a mesma checklist que usamos em todas as revises e no s em seu produto de trabalho. As checklists
podem ser genricas e so utilizadas em todas as revises ou podem se focar em caractersticas e reas de
qualidade ou tipos de documentos especficos. Por exemplo, uma checklist genrica pode verificar as
propriedades gerais dos documentos, como ter um identificador nico, sem referncias a definir, uma
formatao adequada e itens de conformidade parecidos. Uma checklist especfica referente a um documento
com requisitos pode conter verificaes do uso adequado dos termos dever e deve, da testabilidade de cada
requisito declarado e assim por diante. O formato dos requisitos tambm pode indicar o tipo de checklist a ser
Verso 2012br
Pgina 55 de 73

utilizado. Um documento de requisitos que assumir um formato de texto narrativo ter critrios de reviso
diferentes dos de um documento baseado em diagramas.
As checklists tambm podem estar orientadas para o conjunto de habilidades de um programador / arquiteto
ou testador. No caso do Test Analyst (TA), a checklist do conjunto de habilidades do testador seria a mais
adequada. As checklists podem incluir os itens abaixo.
As checklists utilizadas em requisitos, casos de uso e estrias de usurios geralmente tm um foco diferente
do das utilizadas em cdigos ou arquiteturas. As checklists orientadas para requisitos podem incluir os
seguintes itens:
A testabilidade de cada requisito;

Os critrios de aceitao de cada requisito;
A disponibilidade de uma estrutura de casos de uso, onde couber;
A identificao nica de cada requisito / caso de uso / estria de usurio;
O versionamento de cada requisito / caso de uso / estria de usurio;
A rastreabilidade de cada requisito a partir de requisitos de negcios / de marketing;
A rastreabilidade entre requisitos e casos de uso.
Isto deve servir apenas de exemplo. Vale lembrar que, se um requisito no for testvel, o que significa que foi
definido de maneira que o Test Analyst (TA) no consegue nem determinar como test-lo, h um defeito nele.
Por exemplo, um requisito que declarar O software deve ser muito fcil de usar no testvel. Como o Test
Analyst (TA) pode determinar se o software fcil de usar ou at mesmo muito fcil de usar? Se, pelo contrrio,
o requisito disser O software precisa cumprir com as normas de usabilidade declaradas no documento de
normas de usabilidade e se o documento de normas de usabilidade realmente existir, eis um requisito testvel.
Alm disso, trata-se de um requisito principal porque corresponde a todos os itens da interface. Neste caso,
este requisito pode facilmente gerar muitos casos de teste individuais em um aplicativo no trivial. A
rastreabilidade a partir deste requisito ou talvez a partir do documento de normas de usabilidade at os casos
de teste tambm crucial porque se a especificao de usabilidade mencionada mudar, todos os casos de teste
precisaro ser revisados e atualizados quando necessrio.
Um requisito tambm no testvel se o testador no conseguir determinar se o teste o aprovou ou o reprovou
ou se no conseguir elaborar um teste que consiga aprov-lo ou reprov-lo. Por exemplo, no possvel testar
um requisito que declare O sistema dever ficar disponvel o tempo todo, 24 horas por dia, sete dias por
semana, 365 (ou 366) dias por ano. Uma checklist simples para revises de casos de uso pode incluir as
seguintes perguntas:
O caminho (cenrio) principal foi claramente definido?

Todos os caminhos (cenrios) alternativos foram identificados, inclusive o tratamento de erros?
As mensagens da interface de usurio foram definidas?
Existe apenas um caminho principal (deve existir, seno existem vrios casos de uso)?
Todos os caminhos so testveis?
Uma checklist simples referente usabilidade da interface de usurio de um aplicativo pode incluir o seguinte:
Todos os campos e suas funes foram definidos?

Todas as mensagens de erro foram definidas?
Todos os prompts de usurio foram definidos e so coerentes?
A ordem de abas dos campos foi definida?
Existem alternativas no teclado para as aes do mouse?
Verso 2012br
Pgina 56 de 73

Existem combinaes de teclas de atalho definidas para o usurio (por exemplo, copiar e colar)?
Existem dependncias entre os campos (como certa data precisa ser posterior a outra data)?
H um layout de tela?
O layout da tela atende aos requisitos especificados?
H um indicador para o usurio que aparece quando o sistema est processando dados?
A tela atende ao requisito mnimo de um clique (se definido)?
A navegao flui logicamente para o usurio com base nas informaes de caso de uso?
A tela atende aos requisitos de assimilabilidade?
H um texto de ajuda disponvel para o usurio?
H um texto disponvel para o usurio quando o cursor do mouse colocado sobre um item?
O usurio considerar isto atrativo (avaliao subjetiva)?
O uso das cores combina com outros aplicativos e com as normas da organizao?
Os efeitos sonoros so utilizados adequadamente e so configurveis?
A tela atende aos requisitos de localizao?
O usurio consegue saber o que fazer (entendibilidade) (avaliao subjetiva)?
O usurio conseguir se lembrar do que fazer (entendibilidade) (avaliao subjetiva)?
Em um projeto gil, os requisitos costumam assumir a forma de estrias de usurio. Estas estrias representam
pequenas unidades de funcionalidade demonstrvel. Se, por um lado, um caso de uso uma transao de
usurio que se estende a vrias reas de funcionalidade, uma estria de usurio mais isolada e geralmente
entra em determinada abrangncia quando elaborada. Uma checklist referente a uma estria de usurio pode
incluir:
A estria adequada para a iterao / o sprint almejado?

Os critrios de aceitao so definidos e testveis?
A funcionalidade foi claramente definida?
Existem dependncias entre esta estria e as outras?
A estria foi priorizada?
A estria contm um item de funcionalidade?
Claro, se a estria definir uma nova interface, a utilizao de uma checklist genrica referente a estrias (como
a supracitada) e uma checklist detalhada referente a interfaces de usurio seria adequada.
Uma checklist pode ser ajustada com base no seguinte:
Organizao (por exemplo, pensar nas polticas, nas normas e nas convenes da empresa);
Projeto / trabalhos de desenvolvimento (por exemplo, foco, normas tcnicas, riscos);
Objeto revisado (por exemplo, revises de cdigos podem ser ajustadas a linguagens de programao
especficas).
Checklists boas encontraro problemas e ajudaro a iniciar discusses sobre outros itens que poderiam no ter
sido mencionados especificamente nelas. A utilizao de uma combinao de checklists uma tima maneira
de garantir que uma reviso realize o produto de trabalho da mais alta qualidade. A utilizao de checklists
padro, como as mencionadas no syllabus do nvel fundamental, e o desenvolvimento de checklists
organizacionalmente especficas, como as supracitadas, ajudaro o Test Analyst (TA) a ser eficaz nas revises.
Para obter mais informaes sobre revises e inspees, vide [Gilb93] e [Wiegers03].
Verso 2012br
Pgina 57 de 73

6. Gesto de defeitos 120 minutos

Palavras-chave
taxonomia de defeitos, conteno de fase, anlise de causa-raiz
Objetivos de aprendizagem da gesto de defeitos

6.2
Quando possvel detectar um defeito?
TA-6.2.1 (K2) Explica-se como a conteno de fase pode reduzir custos.
6.3
Campos dos relatrios de defeito
TA-6.3.1 (K2) Explicam-se as informaes que podem ser necessrias ao documentar um defeito no
funcional.
6.4
Classificao de defeitos
TA-6.4.1 (K4) Identificam-se, coletam-se e registram-se as informaes de classificao de determinado

defeito.
6.5
Anlise de causa-raiz
TA-6.5.1 (K2) Explica-se o propsito da anlise de causa-raiz.
Verso 2012br
Pgina 58 de 73

6.1 Introduo
O Test Analyst (TA) avalia o comportamento do sistema em termos de necessidades do negcio e do usurio,
por exemplo, o usurio saberia o que fazer quando se deparasse com esta mensagem ou este comportamento?
Com a comparao dos resultados reais com os esperados, o Test Analyst (TA) determina se o sistema est se
comportando corretamente. Uma anomalia (tambm chamada de incidente) uma ocorrncia inesperada que
exige uma maior investigao. Uma anomalia pode ser uma falha causada por um defeito. Uma anomalia pode
levar elaborao de um relatrio de defeito. Um efeito todo problema real que precise ser resolvido.
6.2 Quando possvel detectar um defeito?

Um defeito pode ser detectado atravs de testes estticos e os sintomas do defeito, a falha, podem ser
detectados atravs de testes dinmicos. Cada fase do ciclo de vida de desenvolvimento do software deve contar
com mtodos para a deteco e a eliminao de possveis falhas. Por exemplo, durante a fase de
desenvolvimento, as revises de cdigos e modelagens devem ser utilizadas para detectar defeitos. Durante o
teste dinmico, os casos de teste so utilizados para detectar falhas.
Quanto antes o defeito for detectado e corrigido, menores sero os custos de qualidade para o sistema como
um todo. Por exemplo, o teste esttico consegue encontrar defeitos antes que o teste dinmico seja possvel.
um dos motivos pelo qual o teste esttico uma abordagem rentvel para a produo de software de alta
qualidade.
O sistema de rastreamento de defeitos permite que o Test Analyst (TA) registre a fase do ciclo de vida na qual
o defeito foi introduzido e a fase em que foi detectado. Se as duas fases forem a mesma, a conteno de fase
perfeita foi alcanada. Isto significa que o defeito foi introduzido e detectado na mesma fase e no fugiu
para uma fase posterior. Um exemplo disto seria um requisito incorreto identificado durante a reviso de
requisitos e corrigido durante ela. No se trata apenas do uso eficiente da reviso de requisitos, mas tambm o
defeito impedido de provocar trabalho adicional, o que o encareceria para a organizao. Se um requisito
incorreto fugir da reviso de requisitos e for implementado depois pelo desenvolvedor, testado pelo Test
Analyst (TA) e detectado pelo usurio durante o teste de aceitao do usurio, todo o trabalho realizado em tal
requisito foi um desperdcio de tempo (sem falar que o usurio pode ter perdido a confiana no sistema).
A conteno de fase uma forma eficaz de reduzir os custos dos defeitos.
6.3 Campos dos relatrios de defeito

Os campos (parmetros) em um relatrio de defeito pretendem fornecer informaes suficientes para que o
relatrio de defeito sirva de base para a tomada de providncias. Um relatrio de defeito que provoca uma
ao :
Completo: todas as informaes necessrias aparecem no relatrio;

Conciso: no existem informaes irrelevantes no relatrio;
Exato: as informaes no relatrio so corretas e declaram claramente os resultados esperados e reais
e as etapas adequadas que devem ser reproduzidas;
Objetivo: o relatrio uma declarao de fatos escrita profissionalmente.
As informaes registradas em um relatrio de defeito devem ser dividas em campos de dados. Quanto mais
bem definidos forem os campos, mais fcil divulgar defeitos individuais e produzir relatrios de tendncias
Verso 2012br
Pgina 59 de 73

e outros resumos. Quando um nmero definido de opes estiver disponvel para um campo, ter listas
suspensas dos valores disponveis pode diminuir o tempo necessrio ao registrar um defeito. As listas
suspensas so apenas eficazes quando o nmero de opes limitado e o usurio no precisa repassar uma
longa lista para encontrar a opo correta. Tipos diferentes de relatrios de defeito exigem informaes
diferentes e a ferramenta de gesto de defeitos deve ser flexvel o bastante para gerar prompts para os campos
adequados dependendo do tipo de defeito.
Os dados devem ser registrados em campos diferentes, idealmente suportados pelas validaes de dados para
evitar falhas na entrada de dados e garantir uma divulgao eficaz.
Os relatrios de defeito tratam de falhas descobertas durante os testes funcionais e no funcionais. As
informaes em um relatrio de defeito sempre devem estar orientadas para a identificao clara do cenrio
em que o problema foi detectado, inclusive as etapas e os dados necessrios para a reproduo do cenrio, e
os resultados reais e esperados. Os relatrios de defeito no funcionais podem exigir mais detalhes do
ambiente, outros parmetros de desempenho (por exemplo, o tamanho da carga), a sequncia de etapas e os
resultados esperados. Ao documentar uma caracterstica de usabilidade, importante declarar o que o usurio
esperava que o software fizesse. Por exemplo, se a norma de usabilidade disser que uma operao deve ser
concluda em menos de quatro cliques, o relatrio de defeito deve mostrar quantos cliques foram necessrios
e comparar esse nmero com a norma declarada. Quando a norma no estiver disponvel e os requisitos no
cobrirem os aspectos de qualidade no funcionais do software, o testador pode utilizar o teste de pessoa
razovel para determinar se a usabilidade inaceitvel. Nesse caso, as expectativas de tal pessoa razovel
devem estar claramente contidas no relatrio de defeito. Como os requisitos no funcionais s vezes no
aparecem nos documentos de requisitos, a documentao de falhas no funcionais apresenta mais desafios
para o testador na documentao do comportamento esperado do que do comportamento real.
Embora, normalmente, a meta seja a redigir um relatrio de defeito para consertar o problema, as informaes
sobre os defeitos tambm devem ser fornecidas para reforar uma classificao precisa, uma anlise de risco
e uma melhoria de processo.
6.4 Classificao de defeitos

Existem vrios nveis de classificao que um relatrio de defeito pode receber ao longo de seu ciclo de vida.
A classificao adequada de defeitos parte integrante da notificao adequada de defeitos. As classificaes
so utilizadas para agrupar defeitos, avaliar a eficcia do teste, avaliar a eficcia do ciclo de vida de
desenvolvimento de terminar tendncias interessantes.
Entre as informaes sobre as classificaes comuns de defeitos recm-identificados esto:
A atividade do projeto que resultou na deteco do defeito (por exemplo, reviso, auditoria, inspeo,
codificao, teste);
A fase do projeto em que o defeito foi introduzido (se conhecido) (por exemplo, requisitos,
modelagem, modelagem detalhada, cdigo);
A fase do projeto em que o defeito foi detectado (por exemplo, requisitos, modelagem, modelagem
detalhada, cdigo, reviso de cdigo, teste de unidade, teste de integrao, teste de sistema, teste de
aceitao);
Suposta causa do defeito (por exemplo, requisitos, modelagem, interface, cdigo, dados);
Repetibilidade (por exemplo, uma vez, intermitente, reprodutvel);
Sintoma (por exemplo, pane, interrupo, erro na interface de usurio, erro no sistema, desempenho).
Verso 2012br
Pgina 60 de 73

Assim que o defeito for investigado, outras classificaes podem ser possveis:
Causa-raiz: o erro cometido que levou ao defeito, por exemplo, processo, erro de codificao, erro
de usurio, erro de teste, problema de configurao, problema de dados, software de terceiros,
problema de software externo, problema de documentao;
Fonte: o produto de trabalho no qual o erro foi cometido (por exemplo, requisitos, modelagem,
modelagem detalhada, arquitetura, modelagem de banco de dados, documentao do usurio,
documentao do teste);
Tipo (por exemplo, problema de lgica, problema computacional, problema de tempo, tratamento de
dados, aprimoramento).
Quando o defeito for consertado (ou tiver sido delegado ou tiver sido reprovado na confirmao), ainda mais
informaes de classificao podem estar disponveis, como:
Soluo (por exemplo, alterao no cdigo, alterao na documentao, delegao, inexistncia de

problema, duplicao);
Ao corretiva (por exemplo, reviso de requisitos, reviso do cdigo, teste de unidade,
documentao de configurao, preparao de dados, ausncia de alterao).
Alm das categorias de classificao, os defeitos tambm so frequentemente classificados com base na
gravidade e na prioridade. Alm disso, dependendo do projeto, talvez faa sentido classific-los com base no
impacto sobre a segurana da misso, no impacto sobre o cronograma do projeto, o projeto, nos custos do
projeto, no risco do projeto e no impacto sobre a qualidade do projeto. Estas classificaes podem ser levadas
em considerao em contratos que estipulem a rapidez de execuo de um reparo.
A rea final de classificao a resoluo final. Frequentemente, os defeitos so agrupados com base na
resoluo, por exemplo, reparado / verificado, fechado / sem problema, delegado, em aberto / no resolvido.
Esta classificao costuma ser utilizada ao longo de um projeto, j que os defeitos so rastreados ao longo do
ciclo de vida.
Os valores de classificao utilizados por uma organizao so frequentemente customizados. Os valores
supracitados so apenas exemplos de alguns dos valores comuns utilizados no setor. importante que os
valores da classificao sejam utilizados de maneira coerente para que sejam teis. Campos de classificao
em excesso deixaro a abertura e o processamento de defeitos um pouco lentos, ento importante cruzar o
valor dos dados coletados com o custo incremental de cada defeito processado. A capacidade de personalizar
os valores de classificao coletados por uma ferramenta frequentemente um fator importante na seleo de
ferramentas.
6.5 Anlise de causa-raiz

A finalidade da anlise de causa-raiz consiste em determinar o que provocou o defeito e fornecer dados para
reforar alteraes nos processos que removero as causas-raiz responsveis por boa parte dos defeitos. A
anlise de causa-raiz costuma ser realizada pela pessoa que investiga e ou corrige o problema ou determina
que o problema no deve ou no pode ser corrigido. Normalmente, o desenvolvedor. A definio de um valor
preliminar de causa-raiz normalmente realizada pelo Test Analyst (TA), que, com base em seus
conhecimentos, supor o que provavelmente ocasionou o problema. Ao confirmar o reparo, o Test Analyst
(TA) verificar a configurao de causa-raiz feita pelo desenvolvedor. Quando a causa-raiz for determinada,
tambm comum determinar ou confirmar a fase em que o defeito foi introduzido.
Verso 2012br
Pgina 61 de 73

Entre as causas-raiz comuns esto:
Requisito confuso;
Requisito ausente;
Requisito errado;
Implementao de modelagem incorreta;
Implementao de interface incorreta;
Erro de lgica de cdigo;
Erro de clculo;
Erro de hardware;
Erro de interface;
Dado invlido.
As informaes sobre a causa-raiz so agregadas para determinar problemas comuns que resultam na criao
de defeitos. Por exemplo, se um grande nmero de defeitos for causado por requisitos confusos, faz sentido se
empenhar mais para realizar avaliaes de requisitos eficazes. Igualmente, se a implementao de interfaces
for um problema em grupos de desenvolvimento, sesses conjuntas de modelagem podem ser necessrias.
A utilizao de causas-raiz para o aprimoramento de processos ajuda a organizao a monitorar as vantagens
de mudanas eficazes em processos e a quantificar os custos dos defeitos que podem ser atribudos a uma
causa-raiz especfica. Isto pode ajudar a financiar mudanas em processos que podem exigir a aquisio de
ferramentas e equipamentos adicionais e a alterao do cronograma. O syllabus Melhoramento do processo
de teste do nvel especialista do ISTQB [ISTQB_EL_ITP] examina a anlise de causa-raiz com maior
profundidade.
Verso 2012br
Pgina 62 de 73

7. Ferramentas de teste 45 minutos

Palavras-chave
teste orientado para palavras-chaves, ferramenta de preparao de dados de teste, ferramenta de modelagem
de teste, ferramenta de execuo de teste
Objetivos de aprendizagem das ferramentas de teste

7.2
Ferramentas e automao de testes
TA-7.2.1 (K2) Explicam-se as vantagens da utilizao de ferramentas de preparao de dados de teste, de

modelagem de teste e de execuo de teste.
TA-7.2.2 (K2) Explica-se a funo do Test Analyst (TA) na automao orientada para palavras-chave.
TA-7.2.3 (K2) Explicam-se as etapas para a identificao de uma falha de execuo em um teste automatizado.
Verso 2012br
Pgina 63 de 73

7.1 Introduo
As ferramentas de teste podem melhorar bastante a eficincia e a exatido dos trabalhos de teste, mas apenas
se as ferramentas adequadas forem devidamente implementadas. As ferramentas de teste tm que ser
gerenciadas como outro aspecto de uma organizao de teste bem administrada. A sofisticao e a
aplicabilidade das ferramentas de teste variam bastante e o mercado de ferramentas muda constantemente.
Normalmente, as ferramentas podem ser obtidas com fornecedores de ferramentas comerciais e diversos sites
de ferramentas de freeware ou shareware.
7.2 Ferramentas e automao de testes

Boa parte do trabalho do Test Analyst (TA) exige o uso eficaz de ferramentas. Saber quais ferramentas devem
ser utilizadas e quando elas devem ser utilizadas pode aumentar a eficincia do Test Analyst (TA) e ajudar a
estipular a melhor cobertura de teste no tempo alocado.
7.2.1 Ferramentas de modelagem de testes

As ferramentas de modelagem de testes so utilizadas para a criao de casos de teste e dados de teste que
sero aplicados no teste. As ferramentas podem funcionar a partir de formatos especficos de documentos de
requisitos, modelos (por exemplo, UML) ou entradas fornecidas pelo Test Analyst (TA). As ferramentas de
modelagem de testes so frequentemente projetadas e desenvolvidas para funcionar com formatos e produtos
especficos, como ferramentas especficas de gesto de requisitos.
As ferramentas de modelagem de testes podem fornecer informaes para que o Test Analyst (TA) as utilize
na hora de determinar os tipos de testes necessrios para a obteno do nvel desejado de cobertura de teste,
confiana no sistema ou mitigao de riscos de produto. Por exemplo, as ferramentas de classificao por
rvore geram (e exigem) o conjunto de combinaes necessrio para alcanar a cobertura total com base em
um critrio de cobertura escolhido. Ento, estas informaes podem ser utilizadas pelo Test Analyst (TA) para
determinar os casos de teste que precisam ser executados.
7.2.2 Ferramentas de preparao de dados de testes

As ferramentas de preparao de dados de testes dispem de vrios benefcios. Algumas ferramentas de
preparao de dados de testes conseguem analisar documentos como um documento de requisitos ou at
mesmo o cdigo-fonte para determinar os dados necessrios durante o teste para alcanar um nvel de
cobertura. Outras ferramentas de preparao de dados de teste podem obter um conjunto de dados de um
sistema de produo e depur-lo ou anonimiz-lo para remover quaisquer informaes pessoais ao mesmo
tempo em que mantm a integridade interna dos dados. Ento, os dados depurados podem ser utilizados para
a realizao de testes sem o risco de uma falha na segurana ou o uso indevido de informaes pessoais. Isto
particularmente importante quando houver necessidades de grandes volumes de dados realistas. Outras
ferramentas de gerao de dados podem ser utilizadas para gerarem dados de testes de certos conjuntos de
parmetros de entrada (isto , a utilizao em testes aleatrios). Algumas delas analisaro a estrutura do banco
de dados para determinas as entradas necessrias do Test Analyst (TA).
Verso 2012br
Pgina 64 de 73

Ferramentas de execuo de testes automatizados
As ferramentas de execuo de testes so mais utilizadas por Test Analyst (TA)s em todos os nveis de teste para a
realizao de testes e a verificao do resultado dos testes. A finalidade de usar uma ferramenta de execuo de
testes normalmente consiste em um ou mais dos seguintes:
Reduzir custos (em termos de esforo e / ou tempo);

Executar mais testes;
Executar o mesmo teste em muitos ambientes;
Tornar a execuo de testes mais repetvel.
Executar testes que seria impossvel executar manualmente (isto , testes de validao de muitos
dados).
Frequentemente, os objetivos se sobrepem aos objetivos principais de aumentar a cobertura ao mesmo tempo
em que os custos so reduzidos.
7.2.2.1 Aplicabilidade
O retorno do investimento das ferramentas de execuo de testes costuma ser mais alto quando os testes de
regresso so automatizados por conta do baixo nvel de manuteno esperada e a repetio da execuo dos
testes. A automao de testes bsicos tambm pode ser um uso eficaz da automao devido ao uso frequente
dos testes, necessidade de um resultado rpido e, embora o custo da manuteno possa ser mais alto,
capacidade de ter uma forma automatizada de avaliar um novo pacote em um ambiente de integrao contnua.
As ferramentas de execuo de testes so normalmente utilizadas durante os nveis de teste de sistema e de
integrao. Algumas ferramentas, especialmente as ferramentas de teste API, podem ser utilizadas no nvel do
teste de componente tambm. O aproveitamento das ferramentas quando elas forem relevantes contribuir
para a melhoria do retorno sobre o investimento.
7.2.2.2 Fundamentos das ferramentas de automao de testes

As ferramentas de execuo de testes funcionam com a execuo de um conjunto de instrues redigidas em
uma linguagem de programao, frequentemente chamada de linguagem script. As instrues para a
ferramenta so de um nvel muito detalhado que especifica entradas, ordem da entrada, valores especficos
utilizados nas entradas e sadas esperadas. Isto pode deixar scripts detalhados suscetveis a alteraes no
software em teste (SUT, na sigla em ingls), particularmente quando a ferramenta interage com a interface
grfica de usurio (GUI, na sigla em ingls).
A maioria das ferramentas de execuo de testes vem com um comparador, que permite a comparao de um
resultado real com um resultado esperado armazenado.
7.2.2.3 Implementao da automao de testes

A tendncia na automao de execuo de testes (em programao) a de ir de instrues detalhadas de baixo
nvel a linguagens de nvel mais alto com a utilizao de bibliotecas, macros e subprogramas. As tcnicas de
modelagem, como a captura orientada para palavras-chave e comandos, captam uma srie de instrues e
mencionam as que tm uma palavra-chave ou um comando especfico. Isto permite que o Test Analyst (TA)
escreva casos de teste em um idioma humano e desconsidere a linguagem de programao subjacente e as
funes de nvel menor. A utilizao desta tcnica de redao modular permite uma manutenibilidade mais
fcil durante mudanas na funcionalidade e na interface do software em teste. [Bath08] O uso de palavraschave em scripts automatizados discutido abaixo.
Verso 2012br
Pgina 65 de 73

Os modelos podem ser utilizados para guiarem a criao de palavras-chave ou comandos. Ao examinar os
modelos de processos de negcios, que frequentemente so includos nos documentos de requisitos, o Test
Analyst (TA) consegue determinar os principais processos de negcios que precisam ser testados. Ento, as
etapas dos processos podem ser determinadas, inclusive os pontos de deciso que podem ocorrer durante os
processos. Os pontos de deciso podem virar comandos que a automao de testes consegue obter e utilizar a
partir de planilhas com palavras-chave ou comandos. A modelagem de processos de negcios um mtodo de
documentao de processos de negcios e pode ser utilizada para identificar os principais processos e pontos
de deciso. A modelagem pode ser realizada manualmente ou com ferramentas que se fundamentaro em
entradas com base em regras de negcios e descries de processos.
7.2.2.4 Melhoria do sucesso dos trabalhos de automao

Ao determinar os testes que precisam ser automatizados, todo caso de teste apto ou sute de testes aptos deve
ser avaliado para ver se merece ser automatizado. Muitos projetos fracassados de automao se baseiam na
automao de casos de teste manuais prontos e no verificam se h alguma vantagem real na automao. Pode
ser ideal para certo conjunto de casos de teste (uma sute) para conter testes manuais, semiautomatizados e
totalmente automatizados.
Os seguintes aspectos devem ser levados em considerao ao implementar um projeto de automao de
execuo de testes:
Possveis vantagens:
O tempo de execuo de testes automatizados ficar mais previsvel;

O teste de regresso e a validao de defeitos com testes automatizados sero mais rpidos e mais
confiveis no final do projeto;
A situao e o crescimento tcnico do testador ou da equipe de teste precisam ser melhorados com a
utilizao de ferramentas automatizadas;
A automao pode ser particularmente til com ciclos de vida de desenvolvimento iterativos e
incrementais para a realizar de testes de regresso melhores para cada pacote ou iterao;
A cobertura de certos tipos de teste s pode ser possvel com ferramentas automatizadas (por exemplo,
validao de muitos dados);
A automao na execuo de testes pode ser mais rentvel do que o teste manual referente a testes de
entrada, converso e comparao de muitos dados ao proporcionar entradas e verificaes rpidas e
coerentes.
Possveis riscos:
Um teste manual incompleto, ineficaz ou incorreto pode ser automatizado no estado em que se
encontra (as is);
O testware pode ser difcil de manter, exigindo vrias mudanas quando o software em teste for
alterado;
O envolvimento direto do testador na execuo dos testes pode ser reduzido, o que leva a uma menor
deteco de defeitos;
A equipe de teste pode ter habilidades insuficientes para utilizar as ferramentas automatizadas de
maneira eficaz;
Testes irrelevantes que no contribuam com a cobertura geral do teste podem ser automatizados
porque existem e so estveis;
Os testes podem ficar improdutivos medida que o software se estabilizar (paradoxo do pesticida).
Verso 2012br
Pgina 66 de 73

Durante a implantao de uma ferramenta de automao de execuo de testes, nem sempre bom automatizar
os casos de teste manuais no estado em que se encontram. melhor redefinir os casos de teste para um melhor
uso da automao. Isto inclui a formao de casos de teste, a reutilizao de padres, a expanso das entradas
atravs do uso de variveis em vez de valores pr-programados e a utilizao de todas as vantagens da
ferramenta de teste. As ferramentas de execuo de testes costumam realizar vrios testes, agrupar testes,
repetir testes e mudar a ordem de execuo ao mesmo tempo em que fazem anlises e divulgam os resultados.
Em muitas ferramentas de automao de execuo de testes, as habilidades de programao so necessrias
para criar testes (scripts) e sutes de testes eficientes e eficazes. comum que seja bem difcil atualizar e
gerenciar grandes sutes de testes automatizados se no forem modeladas com cuidado. O treinamento
adequado em ferramentas de teste, programao e tcnicas de modelagem valioso para garantir o
aproveitamento de todas as vantagens das ferramentas.
Durante o planejamento do teste, importante reservar tempo para a execuo manual peridica de casos de
teste automatizados para aprender como o teste funciona, verificar o funcionamento correto e revisar a validade
dos dados de entrada e a cobertura.
7.2.2.5 Automao orientada para palavras-chave

As palavras-chave (s vezes denominadas comandos) so, em sua maioria, mas no exclusivamente, utilizadas
para representar interaes de negcios de alto nvel com um sistema (por exemplo, um pedido de
cancelamento). Cada palavra-chave normalmente utilizada para representar um nmero de interaes
detalhadas entre um ator e o sistema em teste. As sequncias de palavras-chave (inclusive os dados de teste
relevantes) so utilizadas para especificar casos de teste. [Buwalda01]
Na automao de testes, a palavra-chave implementada como um ou mais scripts de teste executveis. As
ferramentas leem casos de teste escritos como uma sequncia de palavras-chave que executa os scripts de teste
adequados, os quais implementam a funcionalidade da palavra-chave. Os scripts so implementados de
maneira altamente modular para possibilitar o fcil mapeamento de palavras-chave especficas. As habilidades
de programao so necessrias para implementar tais scripts modulares.
As principais vantagens da automao de testes orientados para palavras-chave so:
Palavras-chave que dizem respeito a um aplicativo ou a um domnio de negcios especfico podem

ser definidas por especialistas em domnios. Isto pode deixar a tarefa da especificao do caso de teste
mais eficiente;
Uma pessoa com expertise principal em domnios pode se beneficiar com a execuo automtica de
casos de teste (assim que as palavras-chave foram implementadas como scripts) sem ter que entender
o cdigo de automao subjacente;
mais fcil fazer a manuteno dos casos de teste escritos com palavras-chave porque menos
provvel que precisem de modificaes se os detalhes no software em teste mudarem;
As especificaes de casos de teste independem da implementao. As palavras-chave podem ser
implementadas com diversas linguagens script e ferramentas.
Os scripts de automao (o verdadeiro cdigo de automao) que utilizam as informaes da palavra-chave /

do comando costumam ser escritos por desenvolvedores ou Technical Test Analysts (TTA), enquanto o Test
Analyst (TA) normalmente cria dados de palavras-chave / comandos e faz a manuteno deles. Embora a
automao orientada para palavras-chave costume ser executada durante a fase de teste de sistema, o
desenvolvimento do cdigo pode comear ainda nas fases de integrao. Em um ambiente iterativo, o
desenvolvimento de automao de testes um processo contnuo.
Verso 2012br
Pgina 67 de 73

Assim que as palavras-chave e os dados de entrada forem criados, normalmente, o Test Analyst (TA) assume
a responsabilidade de executar os casos de teste orientados para palavras-chave e analisar quaisquer falhas que
possam ocorrer. Quando uma anomalia detectada, o Test Analyst (TA) deve investigar a causa do fracasso
para determinar se o problema est nas palavras-chave, nos dados de entrada, no prprio script de automao
ou no aplicativo testado. Normalmente, a primeira etapa na resoluo de problemas consiste em executar o
mesmo teste com os mesmos dados manualmente para ver se a falha est no prprio aplicativo. Se nenhuma
falha for indicada, o Test Analyst (TA) deve revisar a sequncia de testes que levou falha para determinar se
o problema ocorreu em uma etapa anterior (talvez atravs da produo de dados incorretos), mas s veio
tona em um momento posterior do processamento. Se o Test Analyst (TA) no conseguir determinar a causa
da falha, as informaes da resoluo de problemas devem ser proporcionadas ao Technical Test Analyst (TTA)
ou ao desenvolver para a realizao de outras anlises.
7.2.2.6 Causas de falhas nos trabalhos de automao

Frequentemente, os projetos de automao de execuo de testes no conseguem atingir suas metas. As falhas
podem acontecer por conta de uma flexibilidade insuficiente na utilizao da ferramenta de teste, de
habilidades insuficientes de programao na equipe de teste ou de uma expectativa nada realista de que os
problemas podem ser resolvidos com a automao de execuo de testes. Vale ressaltar que qualquer
automao de execuo de testes exige gesto, empenho, habilidade e ateno, assim como qualquer projeto
de desenvolvimento de software. Dedicou-se tempo criao de uma arquitetura sustentvel de acordo com
as prticas de modelagem adequadas, possibilitando o gerenciamento de configuraes, e de acordo com boas
prticas de codificao. Os scripts de testes automatizados precisam ser testados porque provavelmente
contm defeitos. Talvez o desempenho dos scripts precise ser ajustado. A usabilidade das ferramentas pode
ser levada em considerao, no s para o desenvolvedor, mas tambm para as pessoas que utilizaro a
ferramenta para a execuo de scripts. Talvez seja necessrio projetar uma interface entre a ferramenta e o
usurio que proporciona acesso aos casos de teste de uma maneira logicamente organizada para o testador,
mas que tambm propicie a acessibilidade de que a ferramenta precisa.
Verso 2012br
Pgina 68 de 73

8. Referncias
8.1 Normas
[ISO25000] ISO/IEC 25000:2005, Software Engineering Software Product Quality Requirements and
Evaluation (SQuaRE). Captulos 1 e 4.
[ISO9126] ISO/IEC 9126-1:2001, Software Engineering Software Product Quality. Captulos 1 e 4.
[RTCA DO-178B/ED-12B]: Software Considerations in Airborne Systems and Equipment Certification,
RTCA/EUROCAE ED12B.1992. Captulo 1.
8.2 Documentos do ISTQB
[ISTQB_AL_OVIEW] ISTQB Advanced Level Overview, verso 1.0

[ISTQB_ALTM_SYL] ISTQB Advanced Level Test Manager (TM) Syllabus, verso 1.0
[ISTQB_ALTTA_SYL] ISTQB Advanced Level Technical Test Analyst (TTA) Syllabus, verso 1.0
[ISTQB_FL_SYL] ISTQB Foundation Level Syllabus, verso 2011
[ISTQB_GLOSSARY] Standard Glossary of Terms Used in Software Testing, verso 2.2, 2012
8.3 Livros
[Bath08] BATH, Graham; MCKAY, Judy. The Software Test Engineer's Handbook Rocky Nook, 2008,
ISBN 978-1-933952-24-6.
[Beizer95] BEIZER, Boris. Black-Box Testing John Wiley & Sons, 1995, ISBN 0-471-12094-4.
[Black02] BLACK, Rex. Managing the Testing Process 2 edio, Nova Iorque: John Wiley & Sons,
2002, ISBN 0-471-22398-0.
[Black07] BLACK, Rex. Pragmatic Software Testing John Wiley and Sons, 2007, ISBN 978-0-47012790-2.
[Buwalda01] BUWALDA, Hans. Integrated Test Design and Automation Addison-Wesley Longman,
2001, ISBN 0-201-73725-6.
[Cohn04] COHN, Mike. User Stories Applied: For Agile Software Development Addison-Wesley
Professional, 2004, ISBN 0-321-20568-5.
[Copeland03] COPELAND, Lee. A Practitioner's Guide to Software Test Design Artech House, 2003,
ISBN 1-58053-791-X.
[Craig02] CRAIG, Rick David; JASKIEL, Stefan P. Systematic Software Testing Artech House, 2002,
ISBN 1-580-53508-9.
[Gerrard02] GERRARD, Paul; THOMPSON, Neil. Risk-Based e-Business Testing Artech House, 2002,
ISBN 1-580-53314-0.
[Gilb93] DOROTHY, Graham; GILB, Tom. Software Inspection Addison-Wesley, 1993, ISBN 0-20163181-4.
[Graham07] BLACK, Rex; EVANS, Isabel; GRAHAM, Dorothy; VEENENDAAL, Erik van.
Foundations of Software Testing Thomson Learning, 2007, ISBN 978-1-84480-355-2.
[Grochmann94] GROCHMANN, M. "Test Case Design Using Classification Trees," in: Conference
Proceedings of STAR 1994, 1994.
Verso 2012br
Pgina 69 de 73

[Koomen06] AALST, Leo van der; BROEKMAN, Bart; KOOMEN, Tim; VROON, Michiel. TMap
NEXT, For Result Driven Testing UTN Publishers, 2006, ISBN 90-72194-80-2.
[Myers79] MYERS, Glenford J. The Art of Software Testing John Wiley & Sons, 1979, ISBN 0-47146912-2.
[Splaine01] JASKIEL, Stefan P.; SPLAINE, Steven. The Web-Testing Handbook STQE Publishing,
2001, ISBN 0-970-43630-0.
[vanVeenendaal12] VEENENDAAL, Erik van. Practical Risk-Based Testing The PRISMA Approach
Holanda, UTN Publishers, 2012, ISBN 9789490986070.
[Wiegers03] WIEGERS, Karl. Software Requirements 2 Microsoft Press, 2003, ISBN 0-735-61879-8.
[Whittaker03] WHITTAKER, James. How to Break Software Addison-Wesley, 2003, ISBN 0-20179619-8.
[Whittaker09] WHITTAKER, James. Exploratory Software Testing Addison-Wesley, 2009, ISBN 0321-63641-4.
8.4 Outras referncias

As seguintes referncias contm informaes disponveis na Internet e em outros lugares. Embora estas
referncias tenham sido acessadas at o momento da publicao deste syllabus de nvel avanado, o ISTQB
no pode ser responsabilizada se as referncias no estiverem mais disponveis.
Captulo 3:
CZERWONKA, Jacek: www.pairwise.org;

Taxonomia de bugs: www.testingeducation.org/a/bsct2.pdf;
Taxonomia de amostras de bugs com base na obra de Boris Beizer: inet.uni2.dk/~vinter/bugtaxst.doc;
Um bom apanhado das diversas taxonomias: testingeducation.org/a/bugtax.pdf;
Heuristic Risk-Based Testing de James Bach;
Exploratory & Risk-Based Testing (2004): www.testingeducation.org;
Exploring Exploratory Testing, Cem Kaner e Andy Tikam, 2003;
PETTICHORD,
Bret.
An
Exploratory
Testing
Workshop
Report,
www.testingcraft.com/exploratorypettichord.
Captulo 4:
www.testingstandards.co.uk.
Verso 2012br
Pgina 70 de 73

9. ndice remissivo
0-switch, 35
defeito, 4, 5, 9, 12, 18, 20, 23, 27, 35, 37, 40, 42,
51, 55, 56, 58, 59, 60, 61
acessibilidade, 4, 46, 47, 49, 50, 51, 53, 68
deteco, 9, 19, 39, 45, 51, 59, 60, 66
acurcia, 4, 25, 27, 32, 37, 46, 49
gesto de risco, 12, 22
gil, 10, 15, 16, 28, 48, 57
grficos de causa e efeito, 28, 33, 34
anlise de risco, 22, 27, 42, 60

anlise de valores-limite, 28, 31, 32, 33, 38, 39
heurstica, 46, 52
incidente, 18, 59
arranjo ortogonal, 28, 36

atividades, 8, 9, 10, 11, 12, 13, 15, 18, 20, 26, 30,
37, 44, 45, 74
inspeo, 52, 60
interoperabilidade, 4, 46, 47, 48, 49, 50
atratividade, 46, 47
ISO 25000, 15, 47
automao orientada para palavras-chave, 63, 67
ISO 9126, 15, 47
avaliao, 3, 7, 9, 10, 16, 17, 20, 22, 25, 26, 27, 42,
46, 47, 49, 52, 57
iterativo incorporado, 11
baseado em defeitos, 28, 40
mtricas, 12, 20, 23, 40

modelagem de processos de negcios, 66
caractersticas de qualidade, 4, 15, 25, 30, 46, 47,

48, 49, 75
N-1 switches, 35
nvel de risco, 22, 26, 27
caso de teste de alto nvel, 8
operabilidade, 46, 47, 52
caso de teste de baixo nvel, 8
paradoxo do pesticida, 18, 66
caso de teste lgico, 8
pares, 36
casos de teste concretos, 14
partio de equivalncia, 28, 30, 31, 33, 36, 38, 39
casos de teste lgicos, 14
prottipos, 52
checklists em revises, 4, 54, 55
questionrios, 52, 53
checklists orientadas para requisitos, 56

cobertura, 11, 12, 13, 14, 15, 17, 18, 20, 23, 24, 27,
28, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42,
43, 44, 45, 64, 65, 66, 67
rastreamento de defeitos, 19, 23, 24, 59

resultado falso negativo, 18
resultado falso positivo, 18
comandos, 65, 67
reunies retrospectivas, 20
complacncia, 46, 47, 48, 52
reviso, 2, 6, 12, 52, 54, 55, 57, 59, 60, 61
conjunto de testes de regresso, 20
risco de produto, 13, 22, 26, 27
critrios de sada, 3, 8, 9, 10, 16, 17, 18, 19, 20
riscos de produto, 13, 23, 64
Verso 2012br
Pgina 71 de 73

subcaractersticas de qualidade, 48
SUMI, 41, 46
suposio de erros, 17, 28, 42, 43
pesquisas, 46
tabela de deciso, 28, 32, 33, 39
anlise de teste, 12
taxonomia de defeitos, 28, 40, 41, 58
base de teste, 14
tcnica baseada em defeitos, 28
caso de teste, 13
tcnicas baseadas na experincia, 17, 29, 42
carta de teste, 26
teste alternado, 28, 36
atividades de fechamento de teste, 18
teste baseado em checklist, 28, 43
condio de teste, 12
teste baseado em requisitos, 28
controle de teste, 8
teste combinatrio, 28, 35, 36
modelagem de teste, 8, 12
teste de acessibilidade, 53
ambiente de teste, 16
teste de acurcia, 49
estimativas de teste, 11
teste exploratrio, 9, 28, 44
execuo de teste, 8, 16
teste funcional, 11, 15, 48
implementao de teste, 8, 15
vantagens da automao, 67
registro de teste, 17
mitigao de risco, 20, 21, 24
monitoramento de teste, 20
teste baseado em risco, 20, 22
monitoramento e controle de teste, 11
estratgia de teste baseado em risco, 15
orculo de teste, 14
causa-raiz, 12, 54, 55
planejamento de teste, 8, 11
anlise de causa-raiz, 52, 55
planos de teste, 11
ciclo de vida de desenvolvimento de software
monitoramento e controle de andamento do teste,

21
mtodos geis, 10
estratgia de teste, 12, 13, 20
iterativo, 10
ciclo de vida de software, 9
tcnica baseada em especificaes, 26
tcnicas baseadas em especificaes, 27
sutes de teste, 15
tcnicas de teste, 26
teste de caractersticas de qualidade de software, 41
ferramenta de modelagem de teste, 29, 56, 57
DO-178B, 16
ferramenta de preparao de dados de teste, 56, 57
ED-12B, 16
ferramenta de execuo de teste, 56, 57
UML, 46
teste de transio de estados, 26, 30
rastreabilidade, 12
entendibilidade, 41
adequao, 41
teste de adequao, 44
Verso 2012br
teste sem script, 16

Pgina 72 de 73

no testvel, 50
usabilidade, 41
especificaes de teste de usabilidade, 46
teste de usabilidade, 44
teste de caso de uso, 26, 33
estrias de usurio, 14, 15, 30, 33, 50, 51
teste de estrias de usurio, 26, 33
validao, 46
WAMMI, 41, 46
Verso 2012br
Pgina 73 de 73

Syllabus CTAL TA 2012br PDF

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Syllabus CTAL TA 2012br PDF

Hochgeladen von

Copyright:

Verfügbare Formate

Certified Tester

Advanced Level Syllabus

Responsvel pela traduo: BSTQB/TAG01 Documentao

Brazilian Software Testing Qualifications Board

Nota de direitos autorais

Certified Tester Advanced Level

ISEB Practitioner Syllabus.

ISTQB Advanced Level Syllabus do Grupo de Software da Organizao

Verso de 2007 do Certified Tester Advanced Level Syllabus.

Incorporao das alteraes aceitas em 2009 e diviso de captulos por mdulos

Aceitao de alteraes no formato e correes que no afetam o significado

Diviso do syllabus, reviso dos objetivos de aprendizagem e alteraes no

Incorporao de todos os comentrios das comisses nacionais recebidos em

Incorporao de todos os comentrios das comisses nacionais recebidos em

Envio da verso beta Assembleia Geral.

Envio da verso revisada s comisses nacionais.

Incorporao de comentrios do EWG e glossrio.

Lanamento de rascunho incluso de edies finais das comisses nacionais.

Edies e correes finais para lanamento por parte da Assembleia Geral.

Advanced Level Syllabus - Test Analyst

Certified Tester Advanced Level

Introduo ao syllabus ............................................................................................. 7

Objeto do documento .......................................................................................................... 7

Objetivos de aprendizagem sujeitos avaliao ................................................................. 7

Processo de teste 300 minutos .............................................................................. 8

Teste no ciclo de vida de desenvolvimento de software ..................................................... 9

Planejamento, monitoramento e controle de testes ........................................................... 11

1.3.1 Planejamento de testes ...................................................................................................... 11

Anlise de testes ................................................................................................................ 12

Modelagem de testes ......................................................................................................... 13

1.5.1 Casos de teste concretos e lgicos .................................................................................... 14

Implementao de testes ................................................................................................... 16

Execuo de testes ............................................................................................................ 18

Avaliao de critrios de sada e divulgao .................................................................... 19

Atividades de fechamento de teste .................................................................................... 20

Gesto de testes: responsabilidades do Test Analyst (TA) 90 minutos ............. 22

Monitoramento e controle do andamento dos testes ......................................................... 23

Teste distribudo, terceirizado e internalizado .................................................................. 24

As tarefas do Test Analyst (TA) nos testes baseados em riscos ....................................... 25

2.4.1 Panorama .......................................................................................................................... 25

Tcnicas de teste 825 minutos ............................................................................ 28

Advanced Level Syllabus - Test Analyst

Certified Tester Advanced Level

Tcnicas baseadas em especificaes ............................................................................... 30

3.2.1 Partio de equivalncia ................................................................................................... 30

Tcnicas baseadas em defeitos .......................................................................................... 40

3.3.1 Uso das tcnicas baseadas em defeitos ............................................................................. 40

Tcnicas baseadas na experincia ..................................................................................... 42

3.4.1 Suposio de erros ............................................................................................................ 42

Teste de caractersticas de qualidade do software 120 minutos ......................... 46

Caractersticas de qualidade para teste de domnio de negcios....................................... 48

4.2.1 Teste de acurcia ............................................................................................................... 49

Revises 165 minutos......................................................................................... 54

Utilizao de checklists em revises ................................................................................. 55

Gesto de defeitos 120 minutos.......................................................................... 58

Quando possvel detectar um defeito? ........................................................................... 59

Advanced Level Syllabus - Test Analyst

Certified Tester Advanced Level

Campos dos relatrios de defeito ...................................................................................... 59

Classificao de defeitos ................................................................................................... 60

Anlise de causa-raiz ........................................................................................................ 61

Ferramentas de teste 45 minutos ........................................................................ 63

Ferramentas e automao de testes ................................................................................... 64