1.

Fundamentos do Teste (K2)

1.1 Porque � necess�rio testar?

1.1.1 Contexto dos sistemas de software
- Software faz parte do nosso dia-a-dia desde o banco at� os carros.
- Se n funcionar direito pode levar a muitos problemas (financeiro, tempo,
reputa��o, etc).
1.1.2 Causas dos defeitos de software
- Um humano est� sujeito a cometer um ERRO (engano).
- Um engano (ERRO) produz um DEFEITO (bug, falha) no c�digo ou num doc.
- Se um DEFEITO FOR EXECUTADO teremos uma FALHA.
- DEFEITOS no soft resultam em FALHAS, mas nem todos DEFEITOS causam FALHAS.
- Causas do defeito: prazos, press�o, complexidade no c�digo, complexidade na
infra, mudan�a na tecnologia e/ou mtas intera��es na tecnologia.
- FALHAS tb podem ocorrer por condi��es do ambiente como: radia��o, magnetismo,
campos eletr�nicos, polui��o, etc.
1.1.3 Fun��o do teste no desenvolvimento, manuten��o e opera��o de software
- Testes RIGOROSOS reduzem os riscos e contriu p qualidade.
- Testes tb pode ser necess�rio p atender requisitos contratuais ou legais ou
determinados padr�es de mercado.
1.1.4 Teste e qualidade
- Com a ajuda do teste � poss�vel MEDIR a QUALIDADE do software em termos de
DEFEITOS encontrados, por CARACTER�STICAS e
requisitos FUNCIONAIS OU N�O FUNCIONAIS do software (confiabilidade,
usabilidade, efici�ncia, manutenibilidade e portabilidade).
- Se os testes mostrarem poucos ou nenhum DEFEITO = confian�a na qualidade do
software.
- Se um teste PROJETADO ADEQUADAMENTE e EXECU��O sem defeitos = redu��o no n�vel
de RISCOS em um sistema.
- Por outro lado, se testes ENCONTRAM DEFEITOS = QUALIDADE AUMENTA qdo s�o
corrigidos.
- Projetos anteriores devem prover LI��ES APRENDIDAS.
- Entendendo CAUSA RAIZ dos DEFEITOS encontrados em OUTROS PROJETOS = processos
podem ser APRIMORADOS p PREVENIR REINCID�NCIA de ERROS.
- Testes devem ser integrados COMO UMA DAS atividades de GARANTIA DA QUALIDADE
(ex.: juntamente aos padr�es de desenvolvimento, treinamento
e an�lise de defeitos).
Quanto teste � suficiente?
- P saber QTO teste � sufiencie leva-se em considera��o: N�VEL DO RISCO (incluindo
risco t�cnico, do neg�cio e do projeto), al�m de RESTRI��ES
DO PROJ COMO TEMPO E OR�AMENTO.
- O teste DEVE prover informa��es suficientes aos interessados (stakeholders) para
TOMADA DE DECIS�O sobre a distribui��o do software ou sistema,
para as pr�ximas fases do desenvolvimento ou implanta��o nos clientes. Obs:
N�O LIBERA o soft, apenas prove infos p TOMADA DE DECIS�O.

1.2 O que � teste?

- Vis�o COMUM do PROCESSO DE TESTE = consiste apenas da fase de execu��o, como
executar o programa.
- Esta � uma PARTE do teste, mas n�o s�o TODAS ATIVIDADES do teste.
- Existem atividades de teste ANTES e DEPOIS da fase de EXECU��O.
- Ex: planejamento e controle, escolha das condi��es de teste, modelagem dos casos
de teste, checagem dos resultados, avalia��o do crit�rio de
conclus�o, gera��o de relat�rios sobre o processo de teste e sobre sistema
alvo e encerramento ou conclus�o (ex.: ap�s a finaliza��o
de uma fase de teste).
Teste tamb�m inclui revis�o de documentos (incluindo o c�digo fonte) e
an�lise est�tica.
- Testes DIN�MICOS e EST�TICOS podem ser usados p objetivos SIMILARES e provem
infos p mehorar o sistema testado e o PROCESSO DE TESTE.
- Teste podem ter objetivos diferentes:
* ENCONTRAR defeitos.
* Ganhar confian�a sobre o n�vel de QUALIDADE.
* Prover informa��es para TOMADA de decis�o.
* PREVENIR defeitos.
- Projetar testes ANTECIPADAMENTE no ciclo de vida pode ajudar a PREVENIR defeitos
q poderiam ser introduzidos no code.
- REVIS�O DE DOCUMENTOS (ex: requisitos) tb ajuda a PREVENIR DEFEITOS q possam
aparecer no code.
- No processo de teste, diferentes pontos de vista levam a diferentes objetivos.
- Ex: teste no desenvolvimento (teste de componente, integra��o e de sistema) =
principal objetivo pode ser causar o maior nro de falhas poss�veis,
assim defeitos podem ser identificados e resolvidos.
- J� no TESTE DE ACEITE o objetivo pode ser CONFIRMAR se o sistema est� FUNCIONANDO
conforme esperado (ou seja, prover confiabilidade d q esteja
de acordo com o requisito).
- Em outros casos o obj principal � avaliar a QUALIDADE DO SOFTWARE (n p encontrar
defeitos), p prover infos sobre os RISCOS da implanta��o do sistema
em um determinado momento aos gestores.
- TESTE DE MANUTEN��O podem ser usados p verificar se n foram INSERIDOS ERROS
durante o desenvolvimento de mudan�as.
- Durante os TESTES OPERACIONAIS, o principal obj pode ser AVALIAR caracter�sticas
como CONFIABILIDADE e DISPONIBILIDADE.
- DEPURA��O <> TESTE
- TESTES podem demonstrar falhas q s�o causadas por DEFEITOS.
- DEPURA��O de c�digo � a atividade de desenv q identifica a causa de um defeito,
repara o c�digo e checa se os defeitos foram corrigidos corretamente.
Depois � feito um TESTE DE CONFIRMA��O por um TESTADOR p certificar se a
falha foi eliminada.
- Testadores TESTAM, desenvolvedores DEPURAM.

1.3 Os sete Princ�pios do Teste

- Alguns princ�pios foram sugeridos ao longo dos �ltimos 40 anos, oferecendo um
guia geral para o processo de teste como um todo.

Princ�pio 1 � Teste demonstra a presen�a de defeitos:

Teste pode mostrar a presen�a de defeitos, mas n pode PROVAR q eles
existem.
Mesmo q n se encontre defeitos, teste n prova q ele esteja PERFEITO.
Princ�pio 2 � Teste exaustivo � imposs�vel
Testar TUDO, todas combina��es de entrada e pr�-condi��es, N�O �
vi�vel, exceto casos TRIVIAIS.
Em vez disso, RISCOS E PRIORIDADES s�o levados em considera��o para dar
FOCO aos esfor�os de teste.
Princ�pio 3 � Teste antecipado
Atividade de teste DEVE COME�AR O MAIS BREVE poss�vel no ciclo de
desenv do soft ou sistema e focado em objetivos definidos.
Princ�pio 4 � Agrupamento de defeitos
Um grupo PEQUENO de m�dulos CONT�M A MAIORIA DOS DEFEITOS descobertos
durante o teste antes da entrega ou exibe a MAIORIA
DAS FALHAS OPERACIONAIS.
Princ�pio 5 � Paradoxo do Pesticida
Pode ocorrer de um mesmo conj de testes q s�o repetidos v�rias vezes
N�O encontrarem novos defeitos ap�s um momento.
Por isso, casos de testes precisam ser frequentemente REVISADOS E
ATUALIZADOS.
Assim, um conj de testes NOVO e DIFERENTE precisa ser escrito p
execitar diferentes partes do soft.
 Princ�pio 6 � Teste depende do contexto
Testes s�o realizados de forma diferente conforme o contexto.
Por exemplo, softwares de SEGURAN�A CR�TICA s�o testados DIFERENTEMENTE
de um software de COM�RCIO ELETR�NICO.
Princ�pio 7 � A ilus�o da aus�ncia de erros
Encontrar e consertar defeitos N AJUDA se o sistema constru�do N ATENDE
�s EXPECTATIVAS e necessidades dos usu�rios.

1.4 Fundamentos do processo de teste

- Parte mais VIS�VEL do teste: EXECU��O.
- A parte mais vis�vel do teste � a execu��o. Mas para se obter efic�cia e
efici�ncia, os PLANOS DE TESTE precisam conter:
-> Tempo a ser gasto no planejamento dos testes
-> Modelagem dos casos de testes
-> Prepara��o da execu��o
-> Avalia��o de resultados.
- O PROCESSO DE TESTE b�sico consiste das seguintes atividades: (Apesar da
sequencia, podem se SOBREPOR ou ocorrer de forma CONCORRENTE)
Planejamento e controle
An�lise e modelagem
Implementa��o e execu��o
Avalia��o dos crit�rios de sa�da e relat�rios
Atividades de ENCERRAMENTO de teste

1.4.1 Planejamento e controle do teste

- Planejamento de Teste: consiste em definir os OBJETIVOS e ESPECIFICAR AS
ATIVIDADES de forma a alcan��-los.
- Controle do Teste: CONSTANTE atividade q consiste em COMPARAR o PROGRESSO ATUAL
contra o que foi PLANEJADO, REPORTANDO o STATUS e os DESVIOS do plano.
Ele envolve ainda a TOMADA DE A��ES necess�rias para ALCAN�AR a miss�o e
objetivos do projeto.
Teste deve ser MONITORADO durante TODO o projeto.
- O PLANEJAMENTO leva em considera��o o retorno de infos das atividades de
MONITORA��O E CONTROLE.

1.4.2 An�lise e modelagem do Teste (Obs: depois j� vamos partir p implementar e

execu��o, essa atividade � mto importante)
- AN�LISE e MODELAGEM s�o atividades onde OBJETIVOS GERAIS do teste S�O
TRANSFORMADOS em CONDI��ES e MODELOS de teste TANG�VEIS.
- Principais atividade da AN�LISE e MODELAGEM:
- Revisar a base de testes (como requisitos, n�vel de integridade do software
(n�vel de risco), arquitetura, modelagem, interfaces).
- Avaliar a TESTABILIDADE dos REQUISITOS e do sistema.
- IDENTIFICAR e PRIORIZAR REQUISITOS de teste e DADOS de testes baseado na
AN�LISE dos ITENS DE TESTE, ESPECIFICA��O, COMPORTAMENTO e ESTRUTURA.
- PROJETAR e PRIORIZAR os casos de testes de ALTO N�VEL.
- IDENTIFICAR as necessidades de DADOS p teste suportando condi��es e casos
de teste.
- PLANEJAR a PREPARA��O DO AMBIENTE de teste e IDENTIFICAR A INFRA e
FERRAMENTAS necess�rias.
- Criar uma RASTREABILIDADE BIDIRECIONAL entre REQUISITOS e CASOS DE TESTE.

1.4.3 Implementa��o e execu��o de teste

- Atividade em q PROCEDIMENTOS ou SCRIPTS de teste s�o ESPECIFICADOS pela
combina��o dos casos de teste em uma ordem particular, incluindo todas as
outras infos necess�rias p EXECU��O do teste, al�m do ambiente ser PREPARADO
e os testes EXECUTADOS.
- Atividades principais:
- FINALIZAR, IMPLEMENTAR e PRIORIZAR os CASOS DE TESTE (incluindo a
identifica��o dos DADOS necess�rios p teste).
- DESENVOLVER e PRIORIZAR os PROCEDIMENTOS de teste, CRIAR DADOS de teste e,
opcionalmente, PREPARAR O AMBIENTE p teste e os SCRIPTS de
testes AUTOMATIZADOS.
- CRIAR su�tes de teste A PARTIR dos casos de teste (tem casos de uso e casos
de teste) p executa��o de teste eficiente.
- VERIFICAR se o ambiente est� preparado corretamente.
- VERIFICAR e ATUALIZAR a RASTREABILIDADE BIDIRECIONAL entre a BASE de teste
e os CASOS DE TESTE.
- EXECUTAR os casos de teste MANUALMENTE OU utilizando FERRAMENTAS de acordo
com a sequencia planejada.
- REGISTRAR os RESULTADOS da EXECU��O do teste e anotar as CARACTER�STICAS e
VERS�ES do soft EM TESTE, FERRAMENTA DE TESTE e TESTWARE.
- COMPARAR os resultados OBTIDOS com resultados ESPERADOS.
- REPORTAR discrep�ncias (defeitos no code com algum dado, na documenta��o ou
uma execu��o inadequada) COMO INCIDENTE e analis�-lo p
estabelecer suas causas.
- REPETIR os testes como resultado de a��es tomadas p cada discrep�ncia. (ex:
re-execu��o de um teste q falhou qdo j� corrigido - teste de
CONFIRMA��O - e tb p �rea q j� tinham sido testadas p certificar q
corre��es n afetaram outras partes - teste de REGRESS�O).

1.4.4 Avalia��o do crit�rio de sa�da e relat�rio

- Atividade onde a EXECU��O do teste � AVALIADA mediante os OBJETIVOS definidos.
- Atividades principais:
- CHECAR os registros de teste (LOGS) mediante o CRIT�RIO DE ENCERRAMENTO
definido l� no PLANEJAMENTO.
- AVALIAR se s�o necess�rios testes ADICIONAIS ou se o crit�rio de sa�da
especificado deve ser alterado.
- ELABORAR um relat�rio de teste RESUMIDO p os interessados.

1.4.5 Atividades de encerramento de teste

- COLETA os dados de TODAS ATIVIDADES p CONSOLIDAR EXPERI�NCIA, TESTWARE, FATOS e
NROS.
- Ex: qdo um soft � LAN�ADO, um proj de teste COMPLETADO ou CANCELADO, um MARCO do
proj alcan�ado, ou IMPLANTA��O de uma demanda de manuten��o completada.
- Atividades principais:
- CHECAR quais entreg�veis planejados foram REALMENTE ENTREGUES.
- FECHAR relat�rios de incidentes, ou levantar os registro de mudan�a q
PERMANECEM ABERTOS.
- DOCUMENTAR o ACEITE do sistema.
- FINALIZAR e ARQUIVAR o TESTWARE, AMBIENTE de teste e INFRA de teste p
reuso.
- ENTREGAR o TESTWARE p a manuten��o da organiza��o.
- ANALISAR LI��ES APRENDIDAS p determinar mudan�as necess�rias p futuros
releases e projetos.
- Utilizar as infos COLETADAS p MELHORAR a MATURIDADE de teste.

1.5 A psicologia do teste

- A forma de pensar qdo se est� testando e revisando � diferente de qdo se est�
analisando e desenvolvendo.
- DESENVOLVEDORES estao aptos a testarem seus pr�prios c�digos, mas a separa��o de
resp p um TESTADOR � feita p ajudar o esfor�o e prover
benef�cios como VIS�O INDEPENDENTE, PROFISSIONAL e TREINADA de recursos de
teste.
- TESTE INDEPENDENTE pode ser considerado em qlqr n�vel de teste.
- Esse grau de independ�ncia (evitando INFLU�NCIA DO AUTOR) mtas vezes representa
uma forma eficiente de encontrar DEFEITOS e FALHAS.
- N�vel de INDEPEND�NCIA N�O � apenas SUBSTITUIR desenvolvedor por testador.
- N�veis de Independecia podem ser definidos como:
Teste elaborado por quem ESCREVEU o soft q ser� testado = BAIXO N�VEL DE
INDEPEND�NCIA
Teste elaborado por OUTRA(S) PESSOA(S) = por ex, EQUIPE DE DESENV
Teste elaborado por pessoa(s) de um GRUPO ORGANIZACIONAL DIFERENTE = por ex,
EQUIPE INDEPENDENTE DE TESTE
Teste elaborado por pessoa(s) de DIFERENTES ORGANIZA��O ou EMPRESAS =
TERCEIRIZADA ou CERTIFICADA POR �RG�O EXTERNO
- � importante ter OBJETIVOS CLAROS do teste: ex encontrar defeitos ou confirmar q
o soft funciona.
- IDENTIFICAR falhas pode ser considerado uma CR�TICA contra o produto ou autor,
TESTE aqui � visto como atividade DESTRUTIVA, apesar de
ser CONSTRUTIVA p o gerenciamento do risco do produto.
- PROCURAR por falhas REQUER curiosidade, pessimismo profissional, olha cr�tico,
aten��o ao detalhe, comunica��o eficiente com prof do desenv e
experi�ncia p encontrar erros.
- ERROS, DEFEITOS ou FALHAS comunicados de forma construtiva podem evitar
constragimentos entre eq de teste, analista e desenv.
- DEFEITOS encontrados e resolvidos durante o teste trar� ganho de TEMPO e
DINHEIRO, al�m de REDUZIR OS RISCOS.
- Testadores s�o m� visto especialmente qdo forem vistos somente como mensageiros
de m�s not�cias ao informar defeitos.
- Existem formas de melhorar essa comunica��o e relacionamento entre testadores e
os demais:
-Come�ar com esp�rito de colabora��o, ao inv�s de disputa (conflitos), onde
todos tem o mesmo objetivo p alcan�ar a melhor
qualidade do sistema;
-Comunicar os erros encontrados de forma NEUTRA, dar FOCO no fato sem
criticar a pessoa q criou, por ex, escrevendo OBJETIVAMENTE o
RELAT�RIO DE INCIDENTES;
-Tentar COMPREENDER COMO a pessoa se SENTE ao receber a not�cia e INTERPRETAR
A SUA REA��O.
-CONFIRMAR q a outra pessoa COMPREENDER o q vc relatou e vice-versa.

1.6 C�digo de �tica

- Envolvimento em teste permite q as pessoas conhe�am infos CONFIDENCIAIS e
PRIVILEGIADAS.
- Reconhecendo o c�digo de �tica para engenheiros da ACM e IEEE, o ISTQB�
estabelece o seguinte c�digo de �tica:
- P�BLICO: Testadores certificados devem atuar CONSISTEMENTEMENTE COM
INTERESSE P�BLICO.
- CLIENTE E EMPREGADOR: Testadores certificados devem agir da melhor forma p
os interesses de seus CLIENTE E EMPREGADORES,
CONSISTENTE com o INTERESSE P�BLICO.
- PRODUTO: Testadores certificados DEVEM GARANTIR q os entreg�veis q eles
fornecem (produtos e sistemas q eles testam) correspondem
aos mais ALTOS PADR�ES PROFISSIONAIS poss�veis.
- JULGAMENTO: Testadores certificados DEVEM manter INTEGRIDADE e
INDEPEND�NCIA em seu julgamento profissional.
- GERENCIAMENTO: Gerentes e l�deres de teste certificados DEVEM se submeter e
PROMOVER uma abordagem �tica ao geren do teste de soft.
- PROFISS�O: Testadores certificados DEVEM promover INTEGRIDADE e REPUTA��O
da profiss�o, consistentemente com o interesse p�blico.
- COLEGAS: Testadores certificados DEVEM ser AGRAD�VEIS e INCENTIVADORES com
seus colegas, e PROMOVEREM a COOPERA��O com os
desenvolvedores de soft.
- INDIV�DUO: Testadores certificados DEVEM PRATICAR um APRENDIZADO vital�cio
em considera��o � pr�tica de sua profiss�o e DEVEM PROMOVER
uma abordagem �TICA nessa pr�tica.
2. Teste Durante o Ciclo de Vida do Software
2.1 Modelos de Desenvolvimento de Software
- N�o existe teste ISOLADO.
- A ATIVIDADE DE TESTE est� INTIMAMENTE RELACIONADA com as atividades de
DESENVOLVIMENTO DE SOFTWARE.
- MODELOS de ciclo de vida de desenv DIFERENTES necessitam de ABORDAGENS DIFERENTES
p testar.

2.1.1 Modelo V
- Apesar de varia��es do Modelo V, um TIPO COMUM deste modelo usa QUATRO N�VEIS de
teste CORRESPONDENTES a QUATRO N�VEIS DE DESENVOLVIMENTO.
- Assim, p quatro est�gios de desenv tem-se um n�vel de teste para aquele est�gio
de desenv.
- QUATRO n�veis usados no syllabus:
-Teste de COMPONENTE (unidade)
-Teste de INTEGRA��O
-Teste de SISTEMA
-Teste de ACEITE
- DEPENDENDO DO PROJETO ou do PRODUTO o Modelo V pode ter mais, menos ou
diferentes n�veis de desenv e teste.
- Os PRODUTOS DE TRAB DE SOFT como CEN�RIO DE NEG�CIOS ou CASOS DE USO,
ESPECIFICA��O DE REQUISITOS, documentos de MODELAGEM e C�DIGO produzidos
durante o desenvolvimento muitas vezes s�o a BASE DO TESTE em UM OU MAIS
N�VEL de teste.
- VERIFICA��O e VALIDA��O (e MODELAGEM ANTECIPADA de teste) podem ser executadas
durante a ELABORA��O destes produtos de trab.

2.1.2 Modelos iterativos de desenvolvimento

- � o processo q estabelece requisitos, modelagem, contru��o e teste, realizada
como uma s�rie de desenvs menores.
- Ex: Prototipagem, Desenv R�pido de Aplica��o (RAD), RUP e modelos �geis de
desenv.
- O PRODUTO resultante de UMA ITERA��O PODE SER TESTADO em v�rios n�veis como
parte do seu desenv.
- O INCREMENTO q � adicionado a outros incrementos j� desenvolvidos, forma um
sistema parcial em crescimento q TB DEVE SER TESTADO.
- TESTE DE REGRESS�O tem sua import�ncia aumentada a CADA ITERA��O.
- VERIFICA��O e VALIDA��O podem ser efetuadas a CADA INCREMENTO.

2.1.3 Teste dentro de um modelo de ciclo de vida

- Abaixo as caracter�sticas p um BOM TESTE p QUALQUER MODELO de ciclo de vida:
-Para TODAS atividades do desenv H� UMA ATIVIDADE de teste correspondente.
-Cada N�VEL DE TESTE tem um OBJETIVO espec�fico DAQUELE N�VEL.
-AN�LISE e MODELAGEM do teste p um DADO N�VEL de teste DEVEM COME�AR DURANTE
a atividade de DESENV CORRESPONDENTE.
-Testadores devem se envolver na REVIS�O de documentos o MAIS CEDO poss�vel
utilizando as primeiras vers�es dispon�veis ao longo
do ciclo de desenv.
- N�VEIS DE TESTE podem ser COMBINADOS ou REORGANIZADOS dependendo da natureza do
proj ou arquitetura do sistema.
- Ex: p INTEGRA��O de um pacote (COTS) o cliente pode fazer o TESTE DE INTEGRA��O
(integra��o da infra ou outros sistema, implanta��o do sistema)
e TESTE DE ACEITE (funcional, n funcional, teste de user e operacional).

2.2 N�VEIS de Teste

- Para CADA N�VEL de teste aspectos podem ser identificados: objetivos GEN�RICOS,
PRODUTOS DE TRABALHO utilizados p DERIVAR casos de teste,
 objeto do teste (o q est� sendo testado), defeitos e falhas t�picas a se
encontrar, testes e ferramentas e suporte e abordagens e
responsabilidades espec�ficas.

2.2.1 Teste de Componente

- PROCURA DEFEITOS e verifica o FUNCIONAMENTO DO SOFT (ex: m�dulos, programas,
objetos, classes, etc).
- PODE ser feito ISOLADO DO RESTO do sistema, dependendo do contexto do ciclo de
desenv e do sistema.
- Pode-se usar CONTROLADORES (drivers) e SIMULADORES (stubs).
- Teste de Componente pode incluir TESTE DE FUNCIONALIDADE e CARACTER�STICAS
ESPEC�FICAS N�O FUNCIONAIS como comportamento dos recursos (ex falta
de mem�ria) e testes de robustez, AL�M DE TESTE ESTRUTURAL (cobertura de
c�digo).
- Teste Estrutural (White Box) X Teste Funcional (Black Box): ESTRUTURAL garantem
que os softwares e os programas sejam estruturalmente s�lidos
e que funcionem no contexto t�cnico onde ser�o instalados, FUNCIONAL garantem
o atendimento aos requisitos, ou seja, que os requisitos est�o
corretamente codificados. SER�O VISTOS NO PR�X CAP�TULO (TIPOS de teste).
- CASOS DE TESTE s�o derivados dos produtos de trabalho como, por exemplo,
ESPECIFICA��O de componente, MODELAGEM do software ou MODELO DE DADOS.
- Tipicamente, TESTE DE COMPONENTE ocorre com ACESSO AO C�DIGO q est� sendo
testado e no ambiente de desenv, assim como um FRAMEWORK DE TESTE
DE UNIDADE ou FERRAMENTA DE DEPURA��O "debugging".
- Na pr�tica, ENVOLVE O PROGRAMADOR do c�digo.
- Defeitos s�o corrigidos assim q s�o ENCONTRADOS sem registrar FORMALMENTE os
incidentes.
- Sua abordagem consiste em PREPARAR e AUTOMATIZAR os casos de teste ANTES de
codificar.
- Isto � chamado de TESTE ANTECIPADO ou DESENV DIRIDIGO A TESTE (TDD). � uma
abordagem iterativa e baseada em ciclos de elabora��o de casos de testes.
- � medida q s�o CONSTRU�DAS e INTEGRADAS pequenas partes do c�digo, s�o
executados testes de componente at� q eles passem.

2.2.2 Teste de Integra��o

- Caracterizado por TESTAR AS INTERFACES ENTRE os COMPONENTES, INTERA��ES de
diferentes partes de um sistema, como o sistema operacional,
arquivos, hardware ou INTERFACES entre os sistemas.
- PODE HAVER MAIS Q UM N�VEL de teste de integra��o, q pode ser utilizado em
objetos de teste de tamanho variado, por ex:
-TESTE DE INTEGRA��O DE COMPONENTES testa intera��es entre componentes de
soft e � realizado AP�S o TESTE DE COMPONENTE.
-TESTE DE INTEGRA��O DE SISTEMAS testa intera��o entre DIFERENTES SISTEMAS e
pode ser realizado AP�S o TESTE DE SISTEMA.
Aqui o desenv pode controlar APENAS UM LADO DA INTERFACE, de forma q
mudan�as podem causar instabilidades.
- QTO MAIOR o escopo da INTEGRA��O, MAIOR a DIFICULDADE DE ISOLAR as falhas p
componentes ou sistemas espec�ficos, fato q pode representar
um AUMENTO no risco.
- ESTRAT�GIAS DE INTEGRA��O podem ser baseadas na ARQUITETURA do sistema (top-down
e bottom-up), fun��es, sequencias de processamento de
transa��es, entre outros aspectos do sistema ou componente.
- Visando REDUZIR O RISCO de encontrar defeitos TARDIAMENTE, a integra��o deve,
preferencialmente, ser INCREMENTAL e N�O "big bang" (tudo de uma vez).
- Teste de caracter�sticas N�O FUNCIONAIS espec�ficas (por exemplo, performance)
PODE ser inclu�do nos testes de integra��o.
- A CADA EST�GIO da integra��o, os TESTADORES CONCENTRAM somente na integra��o
propriamente. Ex: m�dulo A est� sendo INTEGRADO com m�dulo B o FOCO
� na COMUNICA��O entre os m�dulos, n suas funcionalidades. Podem ser usados
TESTES FUNCIONAIS qto ESTRUTURAIS.
- O IDEAL � q os TESTADORES DEVEM COMPREENDER a ARQUITETURA e INFLUENCIAR no
PLANEJAMENTO da integra��o.
- Se o TESTE DE INTEGRA��O for PLANEJADO ANTES q os COMPONENTES OU SISTEMAS
estejam PRONTOS, eles podem ser preparados visando um teste MAIS
EFICIENTE.

2.2.3 Teste de Sistema

- Se refere ao COMPORTAMENTO de TODO SISTEMA/PRODUTO definido pelo escopo de um
proj ou programa de desenv.
- No teste de sistema, o AMBIENTE DE TESTE deve corresponder o m�ximo poss�vel ao
AMBIENTE DE PRODU��O.
- Isso MINIMIZA q os RISCOS DE FALHAS espec�ficas de AMBIENTE n�o sejam
encontradas durante o teste.
- TESTES DE SISTEMA podem ser baseados em ESPECIFICA��ES DE RISCO OU REQUISITOS,
PROCESSOS de neg�cio, CASOS DE USO, dentre outras
descri��es de ALTO N�VEL do comportamento, INTERA��ES e RECURSOS do sistema.
- TESTE DE SISTEMA deve tratar REQUISITOS FUNCIONAIS e N�O FUNCIONAIS do sistema.
- Requisitos podem estar como um TEXTO ou DIAGRAMAS.
- Testadores tb devem lidar com REQUISITOS INCOMPLETOS ou N�O DOCUMENTADOS.
- Teste de sistema EM REQUISITOS FUNCIONAIS deve INICIALMENTE utilizar a t�cnica
baseada em especifica��o mais apropriada (caixa-preta) de
acordo com a caracter�stica do sistema a ser testado.
- Por exemplo, uma TABELA DE DECIS�O pode ser criada por COMBINA��ES de efeitos
descritos em regras de neg�cio. A seguir, t�cnica baseada na
estrutura (caixa-branca) pode ser utilizada para avaliar a efic�cia do teste
com respeito ao elemento ESTRUTURAL, assim como estrutura do
menu ou p�gina web.
- Uma equipe de teste INDEPENDENTE � frequentemente respons�vel pelo teste de
sistema.

2.2.4 Teste de Aceite

- RESPONSABILIDADE do CLIENTE OU USU�RIO do sistema.
- Stakeholders tb podem ser envolvidos.
- OBJETIVO DO TESTE DE ACEITE = estabelecer a CONFIAN�A no sistema ou uma
caracter�sticas n espec�fica do sistema.
- PROCURAR DEFEITOS N�O � o PRINCIPAL foco.
- PODE avaliar a DISPONIBILIDADE do sistema PARA ENTRAR EM PRODU��O, apesar de N�O
ser o �LTIMO n�vel de teste.
- Ex: TESTE DE INTEGRA��O em larga escala pode vir AP�S TESTE DE ACEITE de um
sistema.
- Pode ser realizado em mais de um �nico n�vel de teste, ex: Um pacote (COTS) de
sosft ter um TESTE DE ACEITE qdo INSTALADO ou INTEGRADO, um
teste de aceite DE USABILIDADE de um componente pode ser feito durante o
TESTE DE COMPONENTE, TESTE DE ACEITE de uma NOVA FUNCIONALIDADE
pode vir ANTES do TESTE DE SISTEMA.
- As FORMAS de TESTE DE ACEITE incluem tipicamente os seguintes:
->Teste de Aceite de Usu�rio: Normalmente verifica se o sistema est�
APROPRIADO para o uso POR UM USER com perfil de NEG�CIO.
->Teste Operacional de Aceite: O aceite do sistema PELO ADMINISTRADOR dos
sistemas inclui:
-Teste de Backup/Restore.
-Recupera��o de Desastre.
-Gerenciamento de Usu�rio.
-Tarefas de manuten��o.
-Checagens peri�dicas de vulnerabilidades de seguran�a.
->Teste de aceite de contrato e regulamento: verifica-se crit�rios de aceite
INCLUSO EM CONTRATO na produ��o do soft encomendado.
Esse CRIT�RIO deve ser definido qdo o contrato � ASSINADO.
 TESTE DE ACEITE DE REGULAMENTO � qdo se verifica a necessidade de
ADES�O A ALGUM REGULAMENTO de acordo com outras normas como
seguran�a, governamental, legisla��o.
->Alfa e Beta Teste (ou teste no campo): Desenvolvedores de softwares
comerciais ou pacotes, muitas vezes precisam obter um feedback de
clientes em potencial existente no mercado antes que o software
seja colocado � venda comercialmente.
ALTA TESTE: feito no "SITE" DA ORGANIZA��O em q o produto FOI
DESENVOLVIDO.
BETA TESTE: tb chamado TESTE NO CAMPO, � feito PELAS PESSOAS EM SUAS
PR�PRIAS LOCALIDADES.
AMBOS s�o feitos pelos CLIENTES EM POTENCIAL e N�O pelos
desenvolvedores do produto.
- Organiza��es podem utilizar outros termos como Teste de Aceite de F�brica e
Teste de Aceite no �site�, para sistemas que s�o testados antes e
ap�s terem sido movidos ao �site� do cliente.

2.3 TIPOS de Teste: o alvo do teste

- Cada tipo de teste tem FOCO em um objetivo PARTICULAR, que pode ser o teste de
uma FUNCIONALIDADE, uma caracter�stica da qualidade N�O FUNCIONAL,
tal como a confiabilidade ou usabilidade, a ESTRUTURA ou arquitetura do
software ou sistema; ou MUDAN�AS relacionadas, ex.: confirmar
que os DEFEITOS foram SOLUCIONADOS (teste de CONFIRMA��O) e procurar por
MUDAN�AS INESPERADAS (teste de REGRESS�O).
- P teste estrutural ou funcional pode-se usar MODELOS DO SOFTWARE. Ex: p teste
funcional um DIAGRAMA DE FLUXO DE PROCESSO, DIAGRAMA DE TRANSI��O
DE ESTADOS ou ESPECIFICA��O do programa, e p TESTE ESTRUTURAL um DIAGRAMA DE
CONTROLE DE FLUXO ou MODELO DE ESTRUTURA do menu.
2.3.1 Teste de Fun��o (Teste funcional) (K2)
- As FUN��ES que um sistema, subsistema ou componente devem realizar podem ser
descritas nos seguintes produtos de trabalho: ESPECIFICA��O de
requisitos; CASOS DE USO, ESPECIFICA��O FUNCIONAL, ou PODEM N�O estar
documentados.
- As fun��es representam "O QUE" o sistema FAZ.
- Testes funcionais s�o baseados em fun��es (descritas nos documentos ou
compreendidas pelos testadores), e devem ser realizados em TODOS os
N�VEIS DE TESTE (ex.: teste DE COMPONENTE deve ser baseado na ESPECIFICA��O
do componente).
- T�cnicas baseadas em ESPECIFICA��O podem ser utilizadas para DERIVAR as
CONDI��ES de teste e CASOS DE TESTE a partir da FUNCIONALIDADE
do software ou sistema.
- TESTE FUNCIONAL considera o comportamento EXTERNO do software (teste caixa-
PRETA).
- Um tipo de teste funcional, o teste de seguran�a, investiga as fun��es (ex.: um
"firewall") relacionados � detec��o de amea�a de v�rus ou
de a��es mal intencionadas. Nesse caso testa-se esse firewall e verifica seu
comportamento EXTERNO qto as detec��es.

2.3.2 Teste de CARACTER�STICAS do produto de software (testes n�o funcionais)

- Testes n�o funcionais incluem, mas n�o se limita a: teste de performance; teste
de carga; teste de estresse; teste de usabilidade; teste de
interoperabilidade; teste de manutenibilidade; teste de confiabilidade e
teste de portabilidade.
- � o teste de "COMO" o sistema trabalha.
- Testes n�o funcionais podem ser realizados em TODOS OS N�VEIS de teste.
- O termo teste N�O funcional descreve que o teste � executado para MEDIR as
caracter�sticas que PODEM SER QUANTIFIC�VEIS em uma escala vari�vel,
como o tempo de resposta em um teste de performance.
- A NORMA �Engenharia de Software � Qualidade de Produto de Software� (ISO 9126)
define o q se pode medir nos testes n�o funcionais.

2.3.3 Teste de ESTRUTURA/arquitetura do software (teste estrutural)

- Teste estrutural (caixa-branca) pode ser feito em TODOS OS N�VEIS de testes.
- Recomenda-se utilizar as t�cnicas ESTRUTURAIS AP�S as t�cnicas BASEADAS EM
ESPECIFICA��ES, j� que ela auxilia a medi��o da efici�ncia do
teste atrav�s da AVALIA��O DA COBERTURA de um tipo de estrutura.
- COBERTURA � a EXTENS�O que uma estrutura FOI EXERCITADA por um CONJUNTO DE
TESTES, expresso como uma porcentagem de itens cobertos.
- Se a cobertura n�o atinge 100%, ent�o MAIS TESTES devem ser constru�dos a fim de
testar aqueles itens que N�O FORAM CONTEMPLADOS para,
desta forma, aumentar a cobertura.
- Em TODOS OS N�VEIS de teste, mas especialmente no teste de COMPONENTE e teste de
INTEGRA��O de componentes, FERRAMENTAS podem ser usadas para
MEDIR a cobertura do c�digo dos elementos assim como as declara��es ou
decis�es.
- Teste estrutural deve ser baseado na arquitetura do sistema, como uma hierarquia
de chamadas.
- Teste de estrutura TAMB�M pode ser aplicado no sistema, integra��o de sistema ou
n�vel de teste de aceite (por exemplo, para modelos de neg�cios
ou estrutura de menu).

2.3.4 Teste relacionado a mudan�as (teste de confirma��o e regress�o)

- Quando um DEFEITO � DETECTADO E RESOLVIDO, o software pode ser RETESTADO para
CONFIRMAR que o defeito original foi realmente removido.
Isto � chamado de TESTE DE CONFIRMA��O.
- Aten��o! Depurar (resolver defeitos) � uma atividade do desenvolvimento, e n�o
uma atividade do teste.
- Teste de REGRESS�O � o teste REPETIDO de um programa que j� foi testado, AP�S
sua modifica��o, para DESCOBRIR a exist�ncia de algum defeito
introduzido ou n�o coberto originalmente COMO RESULTADO DA MUDAN�A.
Estes defeitos podem estar no software ou em um componente, relacionado ou
n�o ao software.
� realizado quando o software, ou seu ambiente � modificado.
A quantidade de teste de regress�o � baseada no risco de n�o se encontrar
defeitos no software que estava funcionando previamente.
- Os testes DEVEM SER REPETIT�VEIS se forem utilizados nos teste de confirma��o e
para suportar o teste de regress�o.
- Teste de REGRESS�O pode ser realizado em TODOS OS N�VEIS de teste, e SE APLICAM
aos testes funcionais, n�o funcionais e estruturais.
- Testes de regress�o s�o executados muitas vezes e geralmente desenvolve-se
vagarosamente, o que faz com que seja um forte candidato � automa��o.

2.4 Teste de Manuten��o

- Sistemas podem ficar ativos por anos ou d�cadas.
- Durante este tempo o sistema e seu ambiente podem ser corrigidos, modificados ou
completados.
- TESTE DE MANUTEN��O � realizado no MESMO sistema operacional e � INICIADO por
MODIFICA��ES, MIGRA��ES ou RETIRADA de software ou sistema.
- Alguns EXEMPLOS de MODIFICA��ES incluem melhorias planejadas (ex.: baseadas em
�releases�), mudan�as corretivas e emergenciais, al�m de
mudan�as de ambiente, como atualiza��o em sistema operacional ou banco de
dados, e corre��es (�patches�) para expor e encontrar
vulnerabilidades do sistema operacional.
- Teste de manuten��o POR MIGRA��O (ex.: de uma plataforma a outra) pode incluir
testes operacionais do NOVO ambiente TANTO QTO a mudan�a
de software.
- Teste de manuten��o PARA RETIRADA de um sistema pode incluir o teste de migra��o
de dados, ou arquivamento se longos per�odos de RETEN��O
 de dados forem necess�rios.
- Al�m de testar o que FOI ALTERADO, o teste de manuten��o inclui teste de
REGRESS�O massivo para as PARTES do sistema que N�O FORAM TESTADAS.
- O ESCOPO do teste de manuten��o est� relacionado ao RISCO DA MUDAN�A, o TAMANHO
do sistema EXISTENTE e o tamanho da MUDAN�A.
- DEPENDENDO da mudan�a, o teste de manuten��o pode ser feito EM TODOS ou ALGUNS
N�VEIS, e em TODOS ou ALGUNS TIPOS de testes.
- AN�LISE DE IMPACTO = determina como um sistema pode ser afetado por mudan�as.
- AN�LISE DE IMPACTO pode ser usado p ajudar a decidir qtos TESTES DE REGRESS�O
ser�o realizados.
- Teste de manuten��o pode se tornar uma tarefa COMPLICADA se as ESPECIFICA��ES
estiverem DESATUALIZADAS ou INCOMPLETAS.

3. T�cnicas Est�ticas
3.1 Revis�o e o Processo de Teste
- Ao contr�rio dos testes din�micos, as t�cnicas de teste est�tico N�O pressup�em
a EXECU��O DO SOFTWARE que est� sendo testado.
- Elas s�o MANUAIS (revis�o) OU AUTOMATIZADAS (an�lise est�tica).
- Revis�o � uma maneira de testar o produto de software (incluindo o c�digo) e
pode ser realizada BEM ANTES da EXECU��O do teste din�mico.
- Defeitos detectados durante as REVIS�ES o mais cedo poss�vel no ciclo de vida do
software s�o muitas vezes MAIS BARATO do que aqueles
detectados e removidos DURANTE os testes (ex.: defeitos encontrados nos
requisitos).
- Uma revis�o pode ser feita inteiramente como uma atividade MANUAL, MAS H� tamb�m
FERRAMENTAS de suporte.
- A PRINCIPAL atividade MANUAL � EXAMINAR o produto de trabalho e FAZER OS
COMENT�RIOS sobre ele.
- QLQR software PODE SER REVISADO, INCLUINDO a especifica��o de requisitos,
diagramas, c�digo, plano de teste, especifica��o de teste,
casos de teste, script de teste, manual do usu�rio ou p�ginas web.
- As REVI�ES incluem detec��o e corre��o ANTECIPADA dos defeitos, redu��o de
custo, tempo de teste, etc.
- A revis�o pode encontrar omiss�es, por exemplo, nos requisitos, que n�o s�o
normalmente encontrados no teste din�mico.
- Revis�es, an�lises est�ticas e testes din�micos t�m os mesmos objetivos �
IDENTIFICAR DEFEITOS.
- Eles s�o COMPLEMENTARES: as DIFERENTES T�CNICAS podem encontrar DIFERENTES TIPOS
DE DEFEITOS eficazmente e eficientemente.
Em contraste com o teste DIN�MICO, revis�es encontram DEFEITOS ao inv�s de
FALHAS.
- Os defeitos mais facilmente encontrados durante REVIS�ES do que em testes
DIN�MICOS s�o: desvios de padr�es, defeitos de requisitos,
defeitos de modelagem, manutenibilidade insuficientemente e especifica��o
incorreta de interfaces.

3.2 Processo de Revis�o

- As revis�es variam de muito INFORMAIS para MUITO FORMAIS (ex.: bem estruturadas
e reguladas).
- A FORMALIDADE do processo de revis�o � RELACIONADA a fatores como a MATURIDADE
do processo de desenvolvimento, requisitos LEGAIS e
REGULADORES ou a necessidade de acompanhamento de AUDITORIA.
- O MODO como uma REVIS�O � CONDUZIDA depende do seu OBJETIVO (ex.: encontrar
defeitos, obter compreens�o, discuss�o ou decis�es por um consenso).

3.2.1 Fases de uma revis�o formal

- Uma revis�o formal normalmente possui as seguintes fases principais:
->Planejamento:
Definir os CRIT�RIOS de revis�o.
 Selecionar a EQUIPE.
Alocar as FUN��ES.
Definir os CRIT�RIOS de ENTRADA e de SA�DA para os DIVERSOS TIPOS de
revis�o formal (ex.: inspe��o).
SELECIONAR quais as PARTES DOS DOCUMENTOS ser� visto.
CHECAR os crit�rios de ENTRADA (para diversos tipos de revis�o formal).
->Kick-off:
DISTRIBUIR os documentos.
EXPLICAR os objetivos, processos e documentos para os participantes.
->Prepara��o individual:
AN�LISE da DOCUMENTA��O para a reuni�o de revis�o.
ANOTAR os defeitos em potenciais, quest�es e coment�rios.
->Reuni�o de revis�o:
DISCUSS�O OU REGISTRO, com resultados documentados ou anota��es (para
os tipos de revis�es mais formais).
ANOTAR os DEFEITOS, fazer recomenda��es para o tratamento de defeitos
ou tomar decis�es sobre os defeitos.
Examinar, avaliar e registrar QUAEST�ES durante as reuni�es de
acompanhamento.
->Retrabalho:
RESOLVER defeitos encontrados, tipicamente feitos pelo autor.
REGISTRAR os STATUS ATUAIS dos defeitos (para revis�es formais).
->Acompanhamento:
CHECAR se os defeitos foram encaminhados.
OBTER M�TRICAS.
CHECAR os CRIT�RIOS DE SA�DA (para tipos de revis�es formais).

3.2.2 Pap�is e responsabilidades

- Uma t�pica revis�o formal inclui as fun��es abaixo:
->Gerente: TOMA DECIS�O durante a realiza��o da revis�o, ALOCA TEMPO nos
cronogramas de projeto e determina se o objetivo da
revis�o foi atingido.
->Moderador: a pessoa que LIDERA a revis�o do documento ou conjunto de
documentos, INCLUINDO o PLANEJAMENTO da revis�o, e o
ACOMPANHAMENTO ap�s a reuni�o.
Se necess�rio, o moderador MEDIAR� ENTRE os v�rios PONTOS DE VISTA e �
muitas vezes quem responder� pelo sucesso da revis�o.
->Autor: � a pessoa que ESCREVEU ou que possui a responsabilidade pelos
DOCUMENTOS que SER�O REVISADOS.
->Revisores: indiv�duos COM CONHECIMENTO T�CNICO ou de neg�cio (tamb�m
chamados inspetores), que, ap�s a prepara��o necess�ria, IDENTIFICAM
e DESCREVEM os DEFEITOS ENCONTRADOS no produto em revis�o.
Revisores PODEM ser escolhidos para representar DIFERENTES FUN��ES e
perspectivas no processo de revis�o, e � parte
integrante de qualquer reuni�o de revis�o.
->Redator: DOCUMENTA todo o conte�do da reuni�o, problemas e itens em aberto
que foram identificados durante a reuni�o.
- Olhando os documentos de diferentes perspectivas e usando �check-lists�,
tornamos a revis�o MAIS EFICAZ e eficiente.
- Por exemplo, um �check-list� baseado em PERSPECTIVAS tais como a do usu�rio,
desenvolvedor, testador, operador, ou um �check-list� t�pico
de problemas de requisitos pode ajudar a DESCOBRIR problemas N�O DETECTADOS
anteriormente.

3.2.3 Tipos de revis�o

- Um �nico documento pode ser objeto para MAIS DE UMA revis�o.
- Se MAIS DE UM TIPO de revis�o for usado, a ORDEM pode variar.
- Ex: REVIS�O INFORMAL antes de uma REVIS�O T�CNICA, ou INSPE��O executada em uma
ESPECIFICA��O DE REQUISITOS antes de um ACOMPANHAMENTO COM CLIENTE.
 - As principais caracter�sticas, op��es e prop�sitos dos tipos de revis�o
comumente s�o:
->Revis�o informal:
N�o existe processo FORMAL.
Pode haver programa��o em PARES ou um l�der t�cnico revisando a
modelagem e o c�digo.
A DOCUMENTA��O � OPCIONALMENTE.
A import�ncia pode variar dependendo do revisor.
Principal prop�sito: uma forma de obter ALGUM BENEF�CIO a um BAIXO
CUSTO.
->Acompanhamento:
Reuni�o CONDUZIDA pelo AUTOR.
Cen�rios, grupos de discuss�o, exerc�cios pr�ticos.
Sess�es SEM RESTRI��O de TEMPO.
Opcionalmente h� uma reuni�o PREPARAT�RIA dos revisores.
Opcionalmente, relat�rios de revis�o e lista de defeitos encontrados
s�o preparados.
OPCIONALMENTE h� um REDATOR.
Na pr�tica PODE VARIAR de INFORMAR para MTO FORMAL.
Principal prop�sito: aprendizagem, obten��o de entendimento e encontrar
defeitos.
->Revis�es t�cnicas:
Documentado, processo de detec��o de defeito definido que inclui
colegas especialistas ou t�cnicos com a participa��o
opcional da ger�ncia.
Pode ser feito por um colega SEM a participa��o da ger�ncia.
Idealmente s�o CONDUZIDAS por um MODERADOR TREINADO (que n�o seja o
autor).
Reuni�o preparat�ria dos revisores.
Opcionalmente usa check-lists.
Elabora��o de um relat�rio de revis�o, que inclui a lista de defeitos
encontrados, se o produto de software corresponde �s
suas exig�ncias e, quando apropriado, recomenda��es relacionadas
com as descobertas.
Na pr�tica, pode variar de informal para muito formal.
Principais prop�sitos: discuss�o, tomada de decis�es, avaliar
alternativas, encontrar defeitos, resolver problemas t�cnicos e
checar a conformidade da padroniza��o das especifica��es.
->Inspe��o :
CONDUZIDA pelo MODERADOR (que n�o seja o autor).
Geralmente � uma an�lise por pares.
Pap�is DEFINIDOS.
Utiliza��o de M�TRICAS.
Processo formal baseado em regras e utiliza��o de check-list.
Entrada especificada e crit�rios de sa�da para a aceita��o do produto
de software.
Reuni�o de prepara��o.
Relat�rio de inspe��o, lista de defeitos encontrados;
Processo de acompanhamento FORMAL.
Opcionalmente, ter aperfei�oamento do processo e um leitor.
Principal prop�sito: encontrar defeitos.
- Acompanhamento, revis�es t�cnicas e inspe��es podem ser executados dentro de um
GRUPO DE PESSOAS no MESMO N�VEL organizacional.
Este tipo de revis�o � chamado de �revis�o por pares�.

3.2.4 Fatores de sucesso para as revis�es

- Os fatores de SUCESSO para as REVIS�ES incluem:
Cada revis�o tem um OBJETIVO claramente DEFINIDO.
A PESSOA ADEQUADA para os objetivos da revis�o deve ser envolvida.
 Testadores s�o valorizados como revisores que contribuem para a revis�o e
aprendizado sobre o produto o que lhes permite preparar
os testes facilmente.
Defeitos encontrados s�o encorajados e expressados OBJETIVAMENTE.
Deve-se lidar com os problemas pessoais e aspectos psicol�gicos (ex.: fazer
com que a reuni�o seja uma experi�ncia positiva para o autor).
A an�lise � conduzida em uma atmosfera de confian�a, o resultado N�O ser�
utilizado para a avalia��o dos participantes.
T�cnicas de revis�o s�o aplicadas de forma a combinar com o tipo e n�vel do
software e revisores.
Caso necess�rio, check-lists ou pap�is s�o utilizados para aumentar a
efici�ncia na identifica��o de defeitos.
TREINAMENTO � um item importante para as t�cnicas de revis�o, especialmente
para as t�cnicas formais, assim como as inspe��es.
Gerenciamento � importante para um bom processo de revis�o (ex.: incorporando
o tempo adequado para as atividades de revis�o nos
cronogramas de projetos).
H� uma �nfase em aprender e aprimorar o processo.

3.3 An�lise Est�tica por Ferramentas

- Objetivo: encontrar defeitos no C�DIGO fonte do software E na MODELAGEM.
- Realizada SEM a EXECU��O do software examinado pela ferramenta. DIFERENTE do
teste DIN�MICO q EXECUTA o software.
- Como as REVIS�ES, a an�lise est�tica encontra DEFEITOS ao inv�s de falhas.
- Ferramentas de an�lise est�tica analisam o C�DIGO do programa (ex.: fluxo de
controle e fluxo de dados), gerando, como sa�da,
arquivos do tipo HTML e XML, por exemplo.
- Benef�cio: detec��o de defeitos ANTES da execu��o do teste, conhecimento
ANTECIPADO sobre aspectos SUSPEITOS no c�digo ou PROGRAMA atrav�s de
M�TRICAS, identifica DEFEITOS dificilmente encontrados por testes DIN�MICOS,
detec��o de DEPEND�NCIAS E INCONSIST�NCIAS em modelos de
software (como links perdidos), aprimoramente da MANUTENIBILIDADE do c�digo e
constru��o, PREVEN��O de defeitos (se as li��es forem aprendidas
pelo desenvolvimento).
- Defeitos mais comuns descobertos: REFER�NCIA a uma v�riavel com VALOR
INDEFINIDO, INCONSIST�NCIAS entre as interfaces dos m�dulos e componentes,
vari�veis NUNCA usadas ou IMPROPRIAMENTE DECLARADAS, c�digo MORTO, falta de
l�gica ou l�gica errada (loops infinitos), constru��es
EXCESSIVAMENTE COMPLICADAS, VIOLA��O de PADR�ES de programa��o,
VULNERABILIDADE na seguran�a, VIOLA��O de sintaxe e de modelos.
- Ferramentas de an�lise est�ticas s�o tipicamente usadas por DESENVOLVEDORES
(checando regras pr�-definidas ou padr�es de programa��o) ANTES e
DURANTE o teste de componente e de integra��o e por PROJETISTAS durante a
MODELAGEM de software.
- Ferramenta de an�lise est�tica pode produzir um grande n�mero de mensagens de
ADVERT�NCIAS que precisam ser gerenciadas para permitir o uso
mais efetivo da ferramenta.
- Compiladores podem oferecer algum suporte para a an�lise est�tica, incluindo o
c�lculo de m�tricas.

4. T�cnica de Modelagem de Teste

4.1 Identificando as condi��es de testes e projetando os casos de testes

- O PROCESSO pode ser realizado de DIFERENTES maneiras: desde INFORMALMENTE (sem
mtos dados ou documenta��o) at� um processo MTO FORMAL.
- O N�VEL de FORMALIDADE depende do contexto do teste, o q inclui a ORGANIZA��O,
MATURIDADE do processo de teste e desenv, RESTRI��ES DE TEMPO e
as PESSOAS envolvidas.
- Durante a AN�LISE DE TESTE, a DOCUMENTA��O base de teste � analisada de maneira a
DETERMINAR O QUE TESTAR (ex: identificar as condi��es de teste).
- A CONDI��O DO TESTE � definida como um ITEM ou EVENTO q pode ser VERIFICADO por
UM ou MAIS casos de teste (ex: uma fun��o, transa��o, caracter�stica
de qualidade ou elemento estrutural).
- ESTABELECER a RASTREABILIDADE das CONDI��ES de teste de volta AT� as
ESPECIFICA��ES E REQUISITOS permitem ANALISAR O IMPACTO qdo os REQUISITOS
MUDAM e, a COBERTURA DE REQUISITOS a ser DETERMINADA por um conj de TESTES.
- Durante a MODELAGEM DO TESTE, o DETALHAMENTO da ABORDAGEM de teste ser�
implementado - entre outras considera��es - COM BASE NOS RISCOS IDENTIFICADOS.
- Durante a MODELAGEM DE TESTE, os CASOS DE TESTE e os DADOS DE TESTE s�o
ESPECIFICADOS E CRIADOS.
- CASO DE TESTE = conj de VALORES DE ENTRADA, PR�-CONDI��ES de execu��o, resultados
ESPERADOS e P�S-CONDI��ES de execu��o, desenvolvidos p cobrir
certas condi��es de teste.
- RESULTADOS ESPERADOS inclui as SA�DAS, MUDAN�AS DE DADOS e STATUS, e qlqr outra
consequencia do teste.
- Durante a IMPLEMENTA��O DO TESTE os CASOS DE TESTE s�o desenvolvidos,
implementados, priorizadas e organizadas na especifica��o de procedimento
de teste (IEEE STD 829-1998). Normalmente os CASOS DE TESTE e PROCEDIMENTOS
DE TESTE s�o juntados em um �nico doc.

Tabela 1. Plano de teste do sistema SAD

Plano de Teste
--------------
Nome do Projeto:
Sistema de Apoio a Tomada de Decis�o
Pessoas Envolvidas / Responsabilidade:
Usu�rio2 � Cria��o de casos de testes e execu��o dos testes
Usu�rio1� Cria��o de casos de testes e execu��o dos testes
Funcionalidades ou M�dulos:
Cadastro de cliente, classifica��o dos dados e relat�rios
Equipamentos / Softwares:
O sistema deve funcionar em um servidor Web com acesso via browser em
desktop e dispositivos m�veis.
Cronograma:
Data de In�cio e Fim do Projeto: 01/08/2009 � 01/10/2010
Data de In�cio e Fim do Teste: 01/02/2010 a 01/10/2010
Local dos Testes:
N�o possui local espec�fico p os teste. Ser�o executados nos micros das
pessoas envolvidas.
Observa��es:
O relat�rio de incidente ser� enviado para todos os desenvolvedores por
e-mail assim que alguma altera��o tenha sido feita.
Ser�o criados os casos de testes, os relat�rios de incidentes e o
relat�rio resumo de teste

Tabela 2. Casos de testes do sistema SAD

Casos de testes
---------------
Nome Projeto: Sistema de Apoio a Tomada de Decis�o

ID M�dulo Descri��o Roteiro Resultado esperado

Resultado do

desenvolvedor Resultado do teste

-- ------ --------- ------- ------------
------ -------------- -------------------
 1 Altera��o Alterar dados 1) Escolher a op��o Exibir na
lista de usu�rios Usu�rio2 � Usu�rio1 �
Usu�rio cadastrais Listar Usu�rio cadastrados
15/02/2010. 25/02/2010. Mostra
dos usu�rio 2) Clicar em alterar
Executado com um erro ao alterar
na lista
sucesso usu�rio

2 Altera��o Verifica��o 1) Escolher a op��o Mostrar a mensagem

�Campo Usu�rio2 � Usu�rio1 �
Usu�rio valida��o dos Inserir Usu�rio. para os
campos nome, senha 15/02/2010. 25/02/2010.
campos 2) Deixar os campos e e-mail.
Executado com Executado com
nome, e-mail e senha
sucesso sucesso
em branco

3 ...

Tabela 3. Relat�rio de incidente de teste do sistema SAD

Relat�rio de Incidente
----------------------
Nome Projeto: Sistema de Apoio a Tomada de Decis�o

ID Status Respons�vel Prioridade de

Descri��o do erro Data e Nome de quem
pela corre��o corre��o
corrigiu
-- ------ ------------- -------------
----------------- --------------------
1 Pronto para testar Usu�rio2 Alta Mostra um
erro ao alterar usu�rio 01/03/2010 �Usu�rio2
novamente

3 Pronto para testar Usu�rio2 Alta O campo

senha aceita menos de 6 14/03/2010-Usu�rio2
novamente caracteres

5 Pronto para testar Usu�rio1 Baixa No cabe�alho

o nome do relat�rio 10/03/2010 - Usu�rio1
novamente est� errado

6 Aberto Usu�rio2 Alta Erro ao

classificar os dados

- O PROCEDIMENTO de teste especifica a SEQUENCIA de A��ES para a uma EXECU��O de

teste.
- Se os testes s�o executados por uma ferramenta, a sequ�ncia de a��es �
especificada por um script automatizado.

4.2 CATEGORIAS das t�cnicas de modelagem de teste

- O PROP�SITO da t�cnica de MODELAGEM de teste � IDENTIFICAR as CONDI��ES e os
CASOS DE TESTES.
- Classificar testes como caixa-preta ou caixa-branca � uma diferencia��o cl�ssica.
- T�cnicas caixa-PRETA, (tamb�m chamadas de t�cnicas BASEADAS EM ESPECIFICA��O) s�o
uma forma de DERIVAR E SELECIONAR as CONDI��ES e CASOS DE TESTE
baseados na an�lise DA DOCUMENTA��O.
 Inclui: testes funcionais, n funcionais, p um COMPONENTE ou SISTEMA SEM levar
em considera��o a sua ESTRUTURA INTERNA.
- T�cnicas de caixa-BRANCA (tamb�m chamadas de t�cnicas ESTRUTURAIS ou BASEADAS EM
ESTRUTURA) s�o baseadas na estrutura INTERNA de um COMPONENTE
ou SISTEMA.
- Algumas T�CNICAS se encaixam claramente EM UMA �NICA categoria; outras t�m
elementos de MAIS DE UMA categoria.
- Este syllabus considera T�CNICAS baseadas em ESPECIFICA��O ou t�cnicas baseadas
em EXPERI�NCIA COMO T�CNICAS caixa-PRETA e T�CNICAS baseadas
em ESTRUTURA como t�cnicas caixa-BRANCA.
- CARACTER�STICAS comuns das t�cnicas baseadas EM ESPECIFICA��O:
-Modelos, formais ou informais, s�o utilizados PARA ESPECIFICA��O de um
problema a ser resolvido, o software ou seu componente.
-Os CASOS DE TESTES podem ser DERIVADOS sistematicamente DESTES MODELOS.
- CARACTER�STICAS comuns das t�cnicas baseadas em ESTRUTURA:
-Informa��es sobre COMO o software � CONSTRU�DO � utilizada para DERIVAR os
CASOS DE TESTES. Por exemplo, C�DIGO e informa��es
detalhadas de modelagem.
-A extens�o da COBERTURA do software pode ser MEDIDA PELOS casos de testes.
Al�m disto, os casos de testes podem ser derivados
sistematicamente para aumentar a cobertura.
- CARACTER�STICAS comuns de t�cnicas baseada em EXPERI�NCIA:
-CONHECIMENTO e EXPERI�NCIA DE PESSOAS s�o utilizados para DERIVAR os casos
de testes.
-CONHECIMENTO de TESTADORES, DESENVOLVEDORES, USERS, outros interessados
(stakeholders) respons�veis pelo software, seu uso e ambiente.
-CONHECIMENTO sobre DEFEITOS PROV�VEIS e sua distribui��o.

4.3 T�cnicas baseadas em ESPECIFICA��O ou Caixa-PRETA

4.3.1 Parti��o de Equival�ncia
- As ENTRADAS do software ou sistema s�o divididas em GRUPOS que tenham um
COMPORTAMENTO SIMILAR, podendo ser tratados da mesma forma.
- Parti��es (ou classes) de equival�ncia podem ser encontradas em dados V�LIDOS e
INV�LIDOS (por exemplo, valores que deveriam ser rejeitados).
- Parti��es podem tamb�m ser identificadas para valores de sa�das, valores
internos e valores relacionados a tempo, (antes e ap�s um evento) e
para par�metros de interface (durante teste de integra��o).
- Testes podem ser elaborados para cobrir as parti��es. Parti��o de Equival�ncia �
aplic�vel a TODOS os n�veis de testes.

4.3.2 An�lise do Valor Limite

- O COMPORTAMENTO nos LIMITES de uma parti��o de equival�ncia � onde existe MAIOR
PROBABILIDADE de estar INCORRETO.
- LIMITES s�o �reas onde testes est�o mais propensos a indicar defeitos.
- Os valores limites de uma parti��o s�o seu M�XIMO e seu M�NIMO.
- Um valor limite para uma parti��o V�LIDA � um valor LIMITE V�LIDO. O limite de
parti��o INV�LIDA � um valor LIMITE INV�LIDO.
- Testes podem ser projetados para COBRIR tanto valores INV�LIDOS como V�LIDOS.
- Quando os casos de testes s�o projetados, um valor em cada limite � escolhido.
- An�lise do valor limite pode ser aplicada em TODOS OS N�VEIS de teste.
- F�cil de aplicar, alta capacidade de encontrar defeitos e especifica��es
detalhadas podem ser �teis em sua elabora��o.
- Esta t�cnica � muitas vezes considerada uma EXTENS�O da PARTI��O DE EQUIVALENCIA
e pode ser aplicada para entradas manuais como, por exemplo,
em escalas de tempo ou tabela de limites.

4.3.3 Tabela de Decis�o

- Boa alternativa para CAPTURAR requisitos de sistemas que CONT�M condi��es
L�GICAS e para DOCUMENTAR o comportamento interno do sistema.
 - Elas podem ser utilizadas para REGISTRAR REGRAS de neg�cio COMPLEXAS a serem
implementadas.
- A ESPECIFICA��O � ANALISADA e as CONDI�OES E A��ES do sistema s�o IDENTIFICADAS.
- As CONDI��ES de entrada e A��ES s�o declaradas de uma FORMA que possam ser
ENTENDIDAS, como verdadeiras ou falsas (Booleano).
- A TABELA DE DECIS�O cont�m as condi��es que disparam as a��es, muitas vezes
combina��es verdadeiras e falsas para todas as condi��es de
entrada, e a��es resultantes para cada combina��o de condi��es.
- Cada COLUNA da tabela corresponde a uma REGRA DE NEG�CIO que define uma �nica
COMBINA��O de CONDI��ES que RESULTA na execu��o de A��ES associadas
com aquela regra.
- A cobertura padr�o comumente usada em uma tabela de decis�o � ter no M�NIMO UM
TESTE POR COLUNA cobrindo TODAS as COMBINA��ES DE CONDI��ES apresentadas.
- O grande ganho na utiliza��o da tabela de decis�o � que ela cria COMBINA��ES de
condi��es que geralmente N�O FORAM EXERCITADAS durante os testes.
- Pode ser aplicada a todas as situa��es quando a execu��o do software depende de
muitas decis�es l�gicas.

4.3.4 Teste de transi��o de estados

- Um sistema pode exibir RESPOSTAS DIFERENTES dependendo da sua CONDI��O ATUAL OU
de ESTADO ANTERIOR.
- Neste caso, o COMPORTAMENTO do sistema pode ser representado como um diagrama de
TRANSI��O DE ESTADOS.
- Permite ao testador visualizar o software em termos de estados, transi��es entre
estados, as entradas ou eventos que disparam as mudan�as de estado
(transi��o) e as a��es que podem resultar daquelas transi��es.
- Uma tabela de estado exibe a RELA��O entre ESTADOS E ENTRADAS, e pode destacar
poss�veis TRANSI��ES inv�lidas.
- Os testes podem ser constru�dos para cobrir uma sequ�ncia t�pica de status,
cobrir TODOS OS ESTADOS, exercitar TODAS AS TRANSI��ES, exercitar
uma sequ�ncia espec�fica de transi��es ou testar transi��es INV�LIDAS.
- Teste de transi��o de status � muito utilizada em softwares industriais
embarcados e automa��es t�cnicas em geral.
- No entanto, a t�cnica � tamb�m adequada para modelar um objeto de neg�cio tendo
estado espec�fico ou para testar fluxos de telas de di�logos
(exemplo: aplica��o de internet e cen�rios de neg�cios).

4.3.5 Teste de Caso de Uso

- Testes podem ser ESPECIFICADOS a partir de CASOS DE USO ou CEN�RIOS DE NEG�CIOS.
- Um caso de uso descreve intera��es entre os atores (usu�rios e o sistema) que
produz um resultado relevante para um usu�rio do sistema.
- Cada caso de uso tem pr�-condi��es, que precisam ser garantidas para que o caso
de uso funcione com sucesso.
- Cada caso de uso � finalizado com uma p�s-condi��o que representa os resultados
observados e o estado final do sistema ap�s o t�rmino do caso de uso.
- Um caso de uso normalmente tem um cen�rio mais comum (mais prov�vel), e algumas
vezes ramifica��es.
- Caso de uso descreve o fluxo de processo de um sistema baseado nas suas
possibilidades de utiliza��o.
- CASOS DE TESTES DERIVADOS de CASOS DE USO s�o muito �teis na DESCOBERTA DE
DEFEITOS no fluxo do processo durante a utiliza��o do sistema no mundo real.
- Casos de uso muitas vezes s�o tratados como cen�rios, e �teis para construir
TESTES DE ACEITE com a participa��o do usu�rio final.
- Eles podem ajudar a descobrir defeitos de integra��o causados pela intera��o e
interfer�ncia de diferentes componentes, que testes individuais
de componentes podem n�o ter detectado.

4.4 T�cnicas baseadas em estrutura ou Caixa-Branca

- Teste de estrutura ou caixa-branca � baseado na ESTRUTURA do software ou sistema,
como veremos nos exemplos que seguem abaixo:
-N�vel de COMPONENTE: a estrutura � o PR�PRIO C�DIGO, ex.: comandos, decis�es
e desvios.
-N�vel de INTEGRA��O: a estrutura pode ser uma �RVORE DE CHAMADAS (um
diagrama em que um m�dulo chama outros m�dulos).
-N�vel de SISTEMA: A estrutura pode ser uma estrutura de menu, PROCESSOS DE
NEG�CIO ou estruturas das p�ginas Web.
- Nesta se��o h� basicamente DUAS t�cnicas de cobertura de c�digo baseados em
comandos e decis�es ser�o discutidas.

4.4.1 Teste e Cobertura de Senten�a

- No teste de COMPONENTE, cobertura de SENTEN�A � avaliada pela porcentagem de
SENTEN�AS execut�veis que foram EXERCITADAS por um conjunto de
casos de testes.
- No teste de senten�as derivam-se casos de teste para EXECUTAR SENTEN�AS
espec�ficas, normalmente para se aumentar a cobertura.

4.4.2 Teste e Cobertura de Decis�o

- Cobertura de decis�o, tamb�m chamada de teste de ramifica��o, � avaliada pela
porcentagem dos resultados da DECIS�O (por exemplo, as op��es
de �Verdadeiro� ou �Falso� de uma express�o condicional - IF) que foram
EXERCITADOS em um conjunto de casos de teste.
- No teste de decis�o derivam-se os CASOS DE TESTE para EXECUTAR DECIS�ES
espec�ficas, normalmente para se aumentar a cobertura.
- A cobertura de decis�o � MAIS EFICI�NTE Q a cobertura de SENTEN�AS: 100% da
cobertura de DECIS�O GARANTE 100% da cobertura de SENTEN�A,
mas N�O vice-versa.
- Ex:
Dado o seguinte c�digo:
Switch PC on
Start �outlook�

IF outlook appears THEN

Send an email
Close Outlook
ENDIF
Resp: b) 1 teste de cobertura de senten�a (comando), 2 para a cobertura de
desvio;

4.4.3 Outras t�cnicas baseadas na estrutura

- Existem formas mais detalhadas de cobertura estrutural AL�M da cobertura de
decis�o, por exemplo, COBERTURA DE CONDI��ES e COBERTURA DE
M�LTIPLAS CONDI��ES.
- O conceito de cobertura tamb�m pode ser aplicado a outros N�VEIS de teste (teste
de integra��o) no qual, as porcentagens de m�dulos, componentes
ou classes s�o exercitadas por um conjunto de casos de teste.
Por exemplo, poderia express�-las como cobertura de m�dulos, componentes ou
classes.
- Normalmente � utilizada uma ferramenta para dar o suporte de teste de estrutura
do c�digo.

4.5 T�cnicas baseadas na experi�ncia

- Os testes baseados na experi�ncia s�o testes DERIVADOS da INTUI��O e CONHECIMENTO
dos testadores atrav�s de SUA EXPERI�NCIA em aplica��es
e tecnologia similares.
- QDO USADO para AUMENTAR a t�cnica sistem�tica (caixa branca e preta com suas
t�cnias), testes intuitivos podem ser �teis para identificar
testes espec�ficos que n�o s�o facilmente identificados pelas t�cnicas
formais, especialmente quando aplicado ap�s ter estabelecido o
 processo mais formal.
- No entanto esta t�cnica pode produzir amplas variedades e graus de efici�ncia,
dependendo da experi�ncia do testador.
- Possivelmente a t�cnica mais amplamente aplicada � a de supor (adivinhar) onde
est�o os erros.
- Listas de defeitos e falhas podem ser constru�das com base na experi�ncia, dados
de defeitos/falhas dispon�veis e do conhecimento comum de como
o software falha.
- � uma abordagem muito usual, em locais onde a especifica��o � rara ou inadequada
e existe grande press�o por conta de prazo, ou para
aprimorar/complementar um teste mais formal.
- Pode servir como uma checagem do processo de teste, assegurando que os defeitos
mais importantes sejam encontrados.

4.6 Escolhendo as t�cnicas de teste

- A escolha de qual T�CNICA utilizar depender� de uma s�rie de fatores, incluindo o
tipo de sistema, padr�es, clientes, requisitos contratuais,
n�vel do risco, tipos de riscos, objetivos do teste, documenta��o dispon�vel,
conhecimento dos testadores, tempo, dinheiro, ciclo
de desenvolvimento, modelo de caso de uso e uma experi�ncia pr�via do tipo de
defeitos encontrados.
- Algumas T�CNICAS s�o mais facilmente aplicadas em CERTAS SITUA��ES e N�VEIS DE
TESTE, j� OUTRAS s�o aplic�veis a TODOS OS N�VEIS.
- Ao criar CASOS DE TESTE, os testadores geralmente usam uma COMBINA��O DE T�CNICAS
de teste, incluindo regras de processo e t�cnicas de data-driven
para garantir uma cobertura adequada do objeto em teste.

5. Gerenciamento de Teste

5.1 Organiza��o do Teste

5.1.1 A organiza��o e o teste independente
- A EFIC�CIA na procura por defeitos por testes e revis�o pode ser APERFEI�OADA
utilizando-se TESTADORES INDEPENDENTES.
- As OP��ES para independ�ncias s�o:
->NENHUM testador independente. Os DESENVOLVEDORES TESTAM seu pr�prio c�digo.
->Testadores INDEPENDENTES provenientes da equipe de desenvolvimento.
->EQUIPE de teste INDEPENDENTE ou grupo dentro da organiza��o, reportando a
um gerente de projeto ou diretor executivo.
->Testadores INDEPENDENTES DA ORGANIZA��O do neg�cio, dos usu�rios e da �rea
de TI.
->ESPECIALISTAS em teste independente para um OBJETIVO ESPEC�FICO DE TESTE,
como testes de usabilidade, seguran�a ou certifica��o
(quem certifica se o software est� em conformidade com as normas e
padr�es).
->EQUIPE de teste TERCEIRIZADA ou independente da organiza��o.
- Para projetos LONGOS, COMPLEXOS e CR�TICOS, normalmente � melhor ter V�RIOS
N�VEIS de teste, COM ALGUM ou TODOS os n�veis efetuados por
EQUIPES INPENDENTES de teste.
- A equipe de desenvolvimento PODE PARTICIPAR do teste, especialmente para os
TESTES DE BAIXO N�VEL, mas sua falta de objetividade muitas vezes
limita a efetividade do teste.
- A EQUIPE INPENDENTE de teste deve ter a autoridade para REQUISITAR e DEFINIR OS
PROCESSOS de teste e SUAS REGRAS, mas os testadores teriam
que exercer estas fun��es somente sob um claro gerenciamento.
- BENEF�CIOS da INDEPEND�NCIA da equipe de testes s�o:
->Testadores independentes conseguem ENXERGAR outros defeitos e s�o
IMPARCIAIS.
->Um testador independente � capaz de verificar concep��es pessoais criadas
durante a especifica��o e implementa��o de um sistema.
- DESVANTAGENS incluem:
->ISOLAMENTO da equipe de desenvolvimento (se for tratado com independ�ncia
total).
->Equipe pode se tornar um GARGALO, considerando-se o �ltimo ponto de
controle.
->Os desenvolvedores podem PERDER o senso da RESPONSABILIDADE pela qualidade.
(Ex: n vou testar nem o b�sico pq algu�m vai fazer)
- A atividade do teste DEVE ser realizada por pessoas com uma fun��o ESPEC�FICA de
teste, OU pode ser feita por algu�m em outra fun��o, assim
como gerente de projeto, gerente de qualidade, desenvolvedores, especialistas
no neg�cio, suporte de infraestrutura ou opera��es em TI.

5.1.2 Tarefas do l�der de teste e dos testadores

- DUAS fun��es: L�DER de teste e TESTADOR.
- Algumas vezes o l�der de teste � chamado de GERENTE ou COORDENADOR de teste.
- A FUN��O do L�DER PODE ser efetuada por um GERENTE: de projeto, de
desenvolvimento, da qualidade ou at� mesmo por um gerente de um grupo de teste.
- Em projetos LONGOS podem existir DUAS posi��es: L�DER do Teste e GERENTE de
Teste.
- Normalmente, o L�DER � respons�vel pelo PLANEJAMENTO, MONITORA��O e CONTROLE das
atividades de testes e tarefas como as definidas na se��o 1.4.
- As TAREFAS t�picas de um L�DER s�o:
->COORDENAR a estrat�gia de teste e PLANEJAR com o GERENTE DE PROJETOS e
outros envolvidos.
->Escrever ou revisar uma ESTRAT�GIA de teste para o projeto e uma pol�tica
de teste para a empresa.
->CONTRIBUIR com PERSPECTIVA DO TESTE para outras atividades, como o
planejamento de integra��o.
->PLANEJAR os testes considerando o contexto e compreendendo os RISCOS,
incluindo a escolha da abordagem do teste, ESTIMATIVA de tempo,
ESFOR�O, CUSTO, AQUISI��O de recursos, defini��o de N�VEIS e ciclos de
testes, defini��o de OBJETIVOS e planejamento da GEST�O DE INCIDENTE.
->INICIAR a ESPECIFICA��O, PREPARA��O, IMPLEMENTA��O e EXECU��O dos testes e
MONITORAR o controle da execu��o.
->ADAPTAR o planejamento BASEADO NOS RESULTADOS e progresso do teste (algumas
vezes documentado em relat�rio de andamento) e TOMAR A��ES
necess�rias para resolver problemas.
->PREPARAR o gerenciamento de CONFIGURA��O do testware para facilitar a
rastreabilidade.
->Introduzir m�tricas para MEDIR O PROGRESSO do teste e AVALIAR A QUALIDADE
do teste e do produto.
->Decidir o que pode ser AUTOMATIZADO, em que grau e como.
->ESCOLHER ferramenta de apoio e organizar treinamento para seus usu�rios
(testadores).
->DECIDIR sobre a IMPLEMENTA��O do AMBIENTE de teste.
->Montar um RELAT�RIO com base nas informa��es obtidas durante o teste.
- As TAREFAS t�picas de um TESTADOR podem incluir:
->REVISAR e CONTRIBUIR no PLANEJAMENTO dos testes.
->Analisar, revisar e avaliar os REQUISITOS de usu�rios, ESPECIFICA��ES e
MODELOS para testabilidade.
->Criar ESPECIFICA��O DE TESTE.
->CONFIGURAR o AMBIENTE de teste (muitas vezes com a coordena��o do
administrador de sistemas e redes).
->PREPARAR e ADQUIRIR DADOS para os testes.
->IMPLEMENTAR os TESTE em TODOS OS N�VEIS, execu��o, registro, avalia��o dos
resultados e documentar os desvios dos resultados esperados.
->Utilizar FERRAMENTA de ADMINISTRA��O, GEST�O e MONITORA��O de teste se
necess�rio.
 ->AUTOMATIZAR TESTES (esta tarefa pode ser efetuada pelo desenvolvedor ou por
um especialista em automa��o).
->MEDIR a PERFORMANCE dos componentes e sistemas (se aplic�vel).
->REVER os testes desenvolvidos por outras pessoas.
- As pessoas que trabalham na an�lise, constru��o, tipos espec�ficos de teste ou
automa��o PODEM SE ESPECIALIZAR nestas fun��es.
- Dependendo do N�VEL do teste E DO RISCO relacionado ao produto e o projeto,
PESSOAS DIFERENTES podem ocupar a fun��o do testador, mantendo
algum grau de independ�ncia.
- Tipicamente, testadores em N�VEL DE COMPONENTE e INTEGRA��O s�o DESENVOLVEDORES,
TESTADORES em n�vel de ACEITE, podem ser os especialistas
no neg�cio ou usu�rio final e testadores para o N�VEL DE TESTE OPERACIONAL
podem ser os PR�PRIOS operadores.

5.2 Organiza��o do Teste

5.2.1 Planejamento de Teste
- Esta se��o trata dos OBJETIVOS DO PLANEJAMENTO do teste dentro do
desenvolvimento e implementa��o dos projetos.
- O PLANEJAMENTO pode ser DOCUMENTADO em um PLANO DE TESTE (visto acima) mestre ou
de projeto separado em v�rios planos de testes para diferentes
n�veis, assim como teste de aceite ou teste de sistemas.
- O PLANEJAMENTO � INFLUENCIADO pela POL�TICA DE TESTE da organiza��o, o ESCOPO,
OBJETIVO, RISCOS, OBT�CULOS, CR�TICAS e DISPONIBILIDADE de RECURSOS.
- Quanto MAIOR for o projeto e o progresso do planejamento dos testes, mais
informa��es estar�o dispon�veis e mais detalhes podem ser inclu�dos no plano.
- PLANEJAMENTO do teste � uma atividade CONT�NUA realizada durante TODO o processo
do CICLO DE VIDA do software.
- O RETORNO (feedback) da atividade do teste � utilizado para identificar riscos
de mudan�as, para que AJUSTES no planejamento sejam efetuados.

5.2.2 ATIVIDADES no Planejamento de testes

- As ATIVIDADES no PLANEJAMENTO do teste podem incluir:
->DETERMINA��O do ESCOPO e RISCO, IDENTIFICANDO os OBJETIVOS do teste.
->Defini��o COMPLETA da abordagem do teste (estrat�gia de teste), incluindo a
DEFINI��O DO N�VEL de testes, dos CRIT�RIOS de entrada e sa�da.
->INTEGRA��O e COORDENA��O da atividade de teste no ciclo de vida do software
(aquisi��o, fornecimento, desenvolvimento, opera��o e manuten��o).
->Tomar a decis�o sobre O QUE TESTAR, quais as fun��es executar�o as
atividades de teste, QUANDO e COMO as atividades podem ser realizadas,
como o resultados dos testes ser�o avaliados e QUANDO PARAR o teste
(crit�rio de sa�da).
->PROGRAMAR as atividades de AN�LISE e PLANEJAMENTO dos testes
->PROGRAMAR a IMPLEMENTA��O, EXECU��O e VALIDADE dos testes.
->Designar RECURSOS para as diferentes tarefas definidas.
->Definir o N�VEL DE DETALHE, ESTRUTURA e MODELOS para a DOCUMENTA��O dos
testes.
->Escolher M�TRICAS para MONITORAR, CONTROLAR a prepara��o e execu��o do
teste, RESOLVER DEFEITOS e APONTAR os riscos.
->Configurar o N�VEL de detalhe para os PROCEDIMENTOS de teste de forma a
prover informa��es suficientes para que o suporte possa
REPRODUZIR O INCIDENTE.

5.2.3 Crit�rio de Entrada

- CRIT�RIOS DE ENTRADA definem QDO COME�AR um teste, no in�cio de um n�vel de
teste ou QDO UM CONJ de testes est� PRONTO para execu��o.
- Os CRIT�RIOS DE ENTRADA podem ser constitu�dos de:
->DISPONIBILIDADE do AMBIENTE de teste.
->PREPARA��O da FERRAMENTA e do AMBIENTE de teste.
->DISPONIBILIDADE de C�DIGO a ser testado.
 ->DISPONIBILIDADE dos DADOS de teste.

5.2.4 Crit�rio de Sa�da

- CRIT�RIOS DE SA�DA definem QDO PARAR de testar, no FINAL de um N�VEL de teste ou
quando um conjunto de testes realizados ATINGIU um objetivo
espec�fico.
- Os CRIT�RIOS de ENCERRAMENTO podem ser constitu�dos de:
->M�TRICAS como a COBERTURA de c�digo, RISCOS ou FUNCIONALIDADE.
->Estimativa da densidade de defeitos ou seguran�a nas medi��es.
->Custos.
->Riscos residuais, como defeitos n�o solucionados ou falta de cobertura de
teste em algumas �reas.
->Cronograma, baseado na data de entrega do produto.

5.2.5 Estimativa do teste

- Duas abordagens para ESTIMATIVA do esfor�o do teste s�o cobertas no syllabus:
->Estimativa do ESFOR�O do teste BASEADO em m�tricas de PROJETOS ANTERIORES
ou SIMILARES, ou baseado em valores t�picos.
->Estimativas das TAREFAS pelo pr�prio EXECUTOR ou por especialistas.
- Uma vez que a ESTIMATIVA do esfor�o do teste � EFETUADA, RECURSOS podem ser
ALOCADOS e um CRONOGRAMA pode ser ELABORADO.
- O ESFOR�O do teste pode depender de in�meros FATORES que incluem:
->CARACTER�STICAS DO PRODUTO: a QUALIDADE da ESPECIFICA��O ou outra
informa��o usada por projetos de teste, o TAMANHO do produto,
a COMPLEXIDADE do problema, os REQUISITOS para SEGURAN�A e os
requisitos para DOCUMENTA��O.
->CARACTER�STICAS DO PROCESSO DE DESENVOLVIMENTO: A ESTABILIDADE da
organiza��o, FERRAMENTAS usadas, PROCESSOS de teste, EXPERI�NCOA
das pessoas envolvidas e press�o no PRAZO.
->AS SA�DAS DO TESTE: o NRO DE DEFEITOS e a QTDE de RETRABALHO necess�ria.

5.2.6 A Estrat�gia do Teste, Abordagem de teste

- A ABORDAGEM de teste � a IMPLEMENTA��O DA ESTRAT�GIA DE TESTE para um projeto
espec�fico.
- A ABORDAGEM de teste (impl. da estrat.) � DEFINIDA e REFINADA nos PLANOS DE
TESTE e na MODELAGEM de teste.
- Geralmente, ela INCLUI as decis�es tomadas com base na META do projeto (teste) e
AVALIA��O de RISCO.
- � o PONTO DE PARTIDA para o PLANEJAMENTO do processo de teste, para selecionar
as T�CNICAS DE MODELAGEM de teste e TIPOS DE TESTE a ser aplicado,
e para a defini��o dos CRIT�RIOS de entrada e sa�da.
- A ABORDAGEM ESCOLHIDA depende do CONTEXTO e pode considerar os RISCOS, PERIGOS
de seguran�a, RECURSOS dispon�veis e habilidades, TECNOLOGIA, NATUREZA
do sistema, OBJETIVOS do teste, e REGULAMENTA��ES.
- Abordagens t�picas incluem:
->ANAL�TICA: nas quais os TESTE S�O DIRECIONADOS nas �REAS DO SOFTWARE ou
sistema onde APRESENTEM MAIORES RISCOS.
->BASEADA EM MODELOS: nas quais os TESTES S�O BASEADOS em dados INFORMAIS
ESTAT�STICOS sobre taxa de erros (tais como erros operacionais
e de seguran�a).
->ABORDAGEM MET�DICA: como a baseada em falhas (incluindo dedu��o de erros e
inje��o de falhas), BASEADAS em CHECK-LIST, e baseadas em
CARACTER�STICA de QUALIDADE.
->COMPAT�VEL COM PROCESSOS OU PADR�ES: como algumas especificadas por PADR�ES
DA IND�STRIA ou as v�rias metodologias �geis.
->DIN�MICA E HEUR�STICA: tais como os testes EXPLORAT�RIOS onde a ATIVIDADE
DE TESTAR � mais REATIVA do que pr�-planejada e onde a
EXECU��O E AVALIA��O s�o tarefas CONCORRENTES.
->BASEADA EM CONSELHOS: como os testes em que a cobertura � dirigida por
CONSELHOS DE ESPECIALISTAS em tecnologia ou neg�cio FORA do
time de teste.
->REGRESS�O: como aqueles em que h� o REUSO do material de teste, AUTOMA��O
EXTENSIVA dos testes funcionais de regress�o, e um
conjunto de testes padr�o.
- DIFERENTES ABORDAGENS para MONTAR uma ESTRAT�GIA podem ser utilizadas como, por
exemplo, ABORDAGEM baseada em RISCO.

5.3 Controle e Monitora��o do Progresso do Teste

5.3.1 MONITORA��O do PROGRESSO do Teste
- Prop�sito: permitir uma VISIBILIDADE sobre as ATIVIDADES do teste.
- As INFORMA��ES a serem MONITORADAS podem ser coletadas MANUALMENTE ou
AUTOMATICAMENTE e serem utilizadas para MEDIR os crit�rios de sa�da (qdo parar
o teste), como cobertura.
- M�tricas podem ser usadas para avaliar o PROGRESSO em rela��o ao OR�AMENTO e
CRONOGRAMAS planejados.
- As M�TRICAS mais COMUNS incluem:
->Porcentagem de trabalho na prepara��o do caso de teste (ou porcentagem de
casos de testes devidamente planejados).
->Porcentagem de trabalho na prepara��o do ambiente.
->EXECU��O dos casos de testes (n�meros de casos de teste EXECUTADOS ou n�o,
testes com resultados positivos e negativos).
->Informa��es dos defeitos (densidade do defeito, defeitos encontrados e
resolvidos, taxas de falha e resultado de retestes).
->COBERTURA de requisitos, riscos ou c�digo.
->Confian�a SUBJETIVA do testador sob o produto (posso afirmar q o produto
est� num n�vel aceit�vel?)
->Datas dos pontos de controle.
->Custo do teste, incluindo o custo comparado ao benef�cio de encontrar o
pr�ximo erro ou de executar o pr�ximo teste.

5.3.2 Relat�rio do teste

- O RELAT�RIO do teste � CONSTITU�DO de informa��es RESUMIDAS sobre o ESFOR�O do
teste, incluindo:
->O que ACONTECEU durante a o per�odo do teste, e qual o melhor momento de
parar.
->INFOS e M�TRICAS para dar suporte na tomada de decis�o e recomenda��es
sobre futuras a��es, tais como avalia��o dos defeitos
persistentes, vantagem econ�mica da continua��o dos testes e dos riscos
consider�veis apontados al�m do n�vel de confian�a no
software testado.
- As m�tricas podem ser COLETADAS durante ou ao final do teste:
->A adequa��o dos objetivos do teste com o n�vel do teste.
->A adequa��o da abordagem/estrat�gia do teste.
->A efic�cia dos testes em respeito a seus objetivos

5.3.3 Controle do Teste

- O CONTROLE do teste descreve qualquer ORIENTA��O ou A��O CORRETIVA tomada COMO
RESULTADO de INFORMA��ES e M�TRICAS COLETADAS e relatadas.
- As A��ES podem abranger QLQR ATIVIDADE DE TESTE e pode afetar qualquer outro
software de atividade do ciclo de vida ou tarefa.
- Exemplos de CONTROLE de teste:
->TOMAR DECIS�ES baseadas em informa��es adquiridas na monitora��o dos
testes.
->PRIORIZAR novamente os testes quando RISCOS s�o IDENTIFICADOS.
->MUDAR o CRONOGRAMA de acordo com disponibilidade do ambiente de teste.
->DEFINIR um crit�rio de entrada para se iniciar o reteste de bugs resolvidos
pelo desenvolvedor antes de aceit�-lo em uma build.
5.4 Gerenciamento de Configura��o
- PROP�SITO: estabelecer e manter a INTEGRIDADE dos produtos (componentes, dados e
documenta��o) do software ou sistema durante TODO o projeto
ou ciclo de vida do produto.
- Para o teste, o GERENCIAMENTO DE CONFIGURA��O pode GARANTIR que:
->TODOS os itens do software S�O IDENTIFICADOS, CONTROLADAS as mudan�as, seus
RELACIONAMENTOS, facilitando MANUTEN��O e a RASTREABILIDADE
durante todo o processo de teste.
->TODOS os DOCUMENTOS e ITENS do software s�o REFERENCIADOS sem ambiguidade
na documenta��o do teste.
- Para o testador, o gerenciamento de configura��o ajuda na identifica��o �nica (e
a reprodu��o) do item testado, documentos de testes, aos testes
e aos scripts de execu��o de testes.
- Durante o PLANEJAMENTO do teste A FERRAMENTA e PROCESSOS de GERENCIAMENTO DE
CONFIGURA��O DEVEM ser escolhidos, documentados e implementados.

5.5 Riscos e Teste

- RISCO pode ser definido como uma CHANCE de um EVENTO INDESEJ�VEL ACONTECER,
causando um problema em potencial.
- O N�VEL do risco pode ser DETERMINADO pela POSSIBILIDADE do EVENTO ACONTECER e os
DANOS que podem causar caso aconte�a.

5.5.1 Riscos no Projeto

- Riscos NO PROJETO s�o os aqueles que COMPROMETEM a capacidade do PROJETO N�O
atender seus OBJETIVOS.
- FATORES ORGANIZACIONAIS:
->Falta de CONHECIMENTO da equipe.
->Reciclagem e TREINAMENTO pessoal.
->Fatores POL�TICOS como:
->PROBLEMAS com testadores COMUNICANDO suas necessidades com os
resultados dos testes.
->DIFICULDADE para PASSAR INFOS (defeitos) encontradas nos testes e
revis�es, n�o permitindo o aprimoramento
do desenvolvimento e, da pr�tica do teste.
->ATITUDES IMPR�PRIAS em rela��o �s expectativas do teste (ex.: a n�o
valoriza��o dos defeitos encontrados durante os testes).
- FATORES T�CNICOS:
->PROBLEMA na DEFINI��O correta do REQUISITO.
->At� que ponto os REQUISITOS podem ser SATISFEITOS dadas RESTRI��ES
diversas.
->A QUALIDADE da MODELAGEM, do C�DIGO e do TESTE.
- PROBLEMAS DO FORNECEDOR:
->FALHAS de terceiros
->Problemas CONTRATUAIS
- Quando analisando, gerenciando e mitigando os riscos, o gerente de teste �
conduzido por um princ�pio de gerenciamento de projeto bem estabelecido.

5.5.2 Riscos do Produto

- �reas de POTENCIAIS DE FALHAS, (futuros eventos ou riscos indesej�veis) no
software ou sistema s�o conhecidas como RISCOS para a QUALIDADE
do produto final. Incluindo:
->Software INST�VEL (com alta probabilidade de erros).
->O dano POTENCIAL que um SOFT OU HARD pode causar a uma pessoa ou companhia.
->Software com CARACTER�STICAS POBRES (funcionalidade, seguran�a, confian�a,
usabilidade e performance).
->Software com INTEGRIDADE de dados e QUALIDADE POBRES (pend�ncias na
migra��o de dados, problemas de convers�o de dados, problemas
de transporte de dados, viola��o de padr�es de dados).
->Software que N�O cumpre com seus OBJETIVOS.
 - Risco � usado para se decidir quando come�ar e onde dever� se TESTAR com MAIS
FREQU�NCIA;
- O teste � utilizado para REDUZIR o risco da ocorr�ncia de um efeito indesejado,
ou para reduzir seu impacto.
- Risco do PRODUTO � um tipo especial de risco porque COMPROMETE o SUCESSO DE UM
PROJETO.
- A atividade de CONTROLE DE RISCOS fornece informa��es sobre RISCOS RESIDUAIS,
por medir a efici�ncia da retirada de defeitos cr�ticos e
dos planos de conting�ncia.
- Um TESTE baseado NOS RISCOS pode fornecer oportunidades PROATIVAS para REDUZIR
os n�veis do risco do produto quando � abordado no est�gio
INICIAL do projeto.
- Envolve a IDENTIFICA��O do RISCO e seu uso para ORIENTAR o PLANEJAMENTO,
ESPECIFICA��O, PREPARA��O e EXECU��O do teste.
- Os RISCOS IDENTIFICADOS podem ser utilizados para:
->Determinar a T�CNICA de teste a ser empregada.
->Determinar o N�VEL de DETALHAMENTO do teste.
->PRIORIZAR o teste na tentativa de buscar erros CR�TICOS o mais cedo
poss�vel.
->Determinar se ALGUMA ATIVIDADE (que n�o seja o teste) poderia ser efetuada
para REDUZIR o risco (ex.: prover treinamento).
- Teste BASEADO no RISCO AUXILIA os stakeholders a DETERMINAR os RISCOS e N�VEIS
de testes, com base no conhecimento coletivo e na vis�o do projeto.
- Para assegurar que a chance de um produto FALHAR seja MINIMIZADA, o
gerenciamento de riscos dever� prover disciplina para:
->Avaliar (e reavaliar PERIODICAMENTE) o que poder� dar errado (riscos).
->Determinar QUAIS riscos s�o IMPORTANTES para negoci�-los.
->Implementar A��ES para NEGOCIAR aqueles riscos.
- Al�m disto, o teste pode demonstrar a identifica��o de NOVOS riscos, que riscos
deveriam ser reduzidos e diminuir as incertezas sobre os riscos.

5.6 Gerenciamento de Incidente

- Levando em considera��o que um dos objetivos do teste � ENCONTRAR DEFEITOS, as
DISCREP�NCIAS entre o resultado atual e o esperado precisam
ser REGISTRADAS COMO INCIDENTES.
- Um incidente precisa ser investigado e pode se tornar um defeito.
- A��ES apropriadas para dispor incidentes e defeitos devem SER DISPON�VEIS.
- INCIDENTE e DEFEITO deve ser RASTRE�VEL DESDE a descoberta, classifica��o at� �
corre��o e confirma��o da resolu��o.
- Para GERENCIAR os incidentes, a empresa deve ESTABELECER processos e regras para
CLASSIFIC�-LOS.
- Incidentes podem ser DESCOBERTOS DURANTE o DESENVOLVIMENTO, o TESTE e a
UTILIZA��O do software.
- Eles podem se REVELAR por problemas no C�DIGO, por FUN��ES do sistema,
DOCUMENTA��O de desenvolvimento, documenta��o de teste, manual de
instala��o ou manual do usu�rio.
- O RELAT�RIO de Incidentes tem os seguintes objetivos:
->PROVER aos desenvolvedores e outros envolvidos um RETORNO sobre o problema
PARA PERMITIR a identifica��o, isolamento e corre��o se necess�rio.
->PROVER aos l�deres de teste um meio para se RASTREAR a qualidade do sistema
em teste e o PROGRESSO do teste.
->PROVER IDEIAS para APRIMORAR o processo de testes.
- Os DETALHES de um RELAT�RIO de incidente podem incluir:
->Data da emiss�o, autor, status e organiza��o.
->Resultados ESPERADOS e resultados ATUAIS.
->IDENTIFICA��O do ITEM de teste (item de configura��o) e AMBIENTE.
->Processo do ciclo de vida do sistema ou software em que o incidente foi
descoberto.
->DESCRI��O do incidente para permitir a REPRODU��O e resolu��o, incluindo
logs, database dumbs, ou screenshots.
->Escopo e grau de impacto para os stakeholder.
->Severidade do IMPACTO no sistema.
->Urg�ncia / Prioridade na corre��o.
->Estado (status) do incidente (aberto, rejeitado, duplicado, aguardando
resolu��o, aguardando reteste ou fechado).
->CONCLUS�O, RECOMENDA��ES e APROVA��ES.
->Coment�rios gerais, tais como outras �reas que podem ser afetadas por uma
mudan�a resultante de um incidente.
->HIST�RICO de mudan�as, como a sequ�ncia de A��ES TOMADAS pela equipe
envolvida no projeto com respeito ao isolamento do
incidente, reparo e confirma��o da resolu��o.
->Refer�ncias, incluindo a identifica��o da especifica��o do caso de teste
que revelou o problema.

6. Ferramentas de Suporte a Teste

6.1 Tipos de Ferramentas de Teste

6.1.1 Ferramentas de suporte a teste
- Ferramentas de teste podem ser usadas para UMA OU MAIS atividades DE SUPORTE a
TESTE. Estas incluem:
1) Ferramentas que s�o DIRETAMENTE UTILIZADAS no teste, como ferramentas de
execu��o de teste, ferramentas de gera��o de dados de
teste e ferramentas de compara��o de resultados.
2) Ferramentas que AUXILIAM NA GEST�O do processo de teste, como aquelas
utilizadas para gerenciar testes, resultados de teste, dados,
requisitos, incidentes, defeitos, etc., e para relat�rios e monitora��o
da execu��o de teste.
3) Ferramentas que s�o usadas em RECONHECIMENTO, ou, em termos mais simples,
EXPLORA��O (exemplo: ferramentas que monitoram atividades
de arquivos para uma aplica��o).
4) Quaisquer ferramentas que AUXILIAM no teste (uma planilha Excel tamb�m �
uma ferramenta de teste, neste contexto.).
- Ferramentas DE SUPORTE ao teste podem ter um ou mais dos seguintes OBJETIVOS,
dependendo do contexto:
->AUMENTAR a EFICI�NCIA das atividades de teste, atrav�s da AUTOMA��O de
TAREFAS REPETITIVAS ou dar SUPORTE a ATIVIDADES de
teste manuais, como PLANEJAMENTO, modelagem, relat�rio e monitora��o.
->Automatizar atividades que requerem RECURSOS SIGNIFICATIVOS quando
executadas manualmente (exemplo: teste est�tico).
->Automatizar atividades que N�O podem ser executadas MANUALMENTE (ex.: teste
de performance em larga escala de aplica��es cliente-servidor).
->Aumentar a CONFIABILIDADE do teste (exemplo: pela automa��o de compara��es
em larga escala ou simula��o de comportamento).
- O termo �FRAMEWORKS de teste� tamb�m � frequentemente utilizado na ind�stria, em
pelo menos tr�s sentidos:
->BIBLIOTECAS de teste reutiliz�veis e extensivas que podem ser UTILIZADAS
para CONSTRUIR FERRAMENTAS de teste (chamadas de
prepara��o de teste tamb�m).
->Um TIPO DE DESIGN de automa��o de teste (ex.: data-driven, context-driven)
->O processo de execu��o de teste como um todo.
- Para o syllabus, o termo �frameworks de teste� � utilizado em seus dois
primeiros significados.

6.1.2 Classifica��o das Ferramentas de Teste

- H� v�rias ferramentas que suportam diferentes ASPECTOS do TESTE.
- Ferramentas podem ser classificadas baseadas em v�rios crit�rios como objetivo,
comercial/livre/c�digo aberto/shareware, tecnologia
utilizada e da� por diante.
 - Ferramentas s�o classificadas neste syllabus de acordo com as ATIVIDADES DE
TESTE que elas SUPORTAM.
- Algumas suportam APENAS UMA atividade; outras podem suportar MAIS Q UMA, mas
est�o classificadas sob a ATIVIDADE de que ela est� mais associada.
- Ferramentas de UM �NICO fornecedor, especialmente aquelas que foram planejadas
para atuarem em conjunto, podem ser AGRUPADAS em um �NICO PACOTE.
- Alguns tipos de ferramentas de teste s�o INTRUSIVOS, ou seja, eles pr�prios
podem afetar o resultado do teste.
- Ex: o resultado de uma aferi��o de tempo pode ser diferente dependendo de como �
a medi��o em diferentes ferramentas de performance, ou ent�o
pode-se ter uma MEDIDA DIFERENTE na cobertura do c�digo dependendo da
ferramenta que se utiliza.
- A consequ�ncia de uma ferramenta intrusiva � conhecida como efeito de
monitora��o.
- Algumas ferramentas oferecem suporte mais apropriado para desenvolvedores
(durante teste de componente e integra��o dos componentes).

6.1.3 Ferramentas para gerenciamento do teste

- As ferramentas de GERENCIA aplicam-se a TODAS as atividades do teste sobre o
ciclo de vida do software.
- Ferramenta de GERENCIAMENTO DE TESTE:
Estas ferramentas fornecem interfaces para a execu��o de teste, RASTREAMENTO
de defeitos e GEST�O de requisitos juntamente com suporte
para an�lise quantitativa e relat�rio dos objetos de teste.
Elas tamb�m suportam o RASTREAMENTO dos OBJETOS de teste �s especifica��es de
requisitos e podem ter uma capacidade de controle de
vers�o independente ou uma interface a um controle de vers�o externo.
- Ferramentas de GERENCIAMENTO DE REQUISITOS:
Estas ferramentas ARMAZENAM termos de requisitos, armazenam os ATRIBUTOS para
os requisitos (incluindo prioridade), fornecem identificadores
�nicos e d�o suporte ao RASTREAMENTO DOS REQUISITOS aos TESTES
INDIVIDUAIS.
Estas ferramentas podem tamb�m ajudar a identificar requisitos inconsistentes
ou ausentes.
- Ferramentas de GERENCIAMENTO DE INCIDENTES (Ferramenta de Rastreamento de
Defeitos):
Estas ferramentas armazenam e gerenciam relat�rios de INCIDENTES (ex.:
defeitos, falhas, problemas e anomalias) e ajudam no gerenciamento
do ciclo de vida de incidentes, opcionalmente com suporte para an�lise
estat�stica.
- Ferramentas de GERENCIAMENTO DE CONFIGURA��O:
Embora n�o s�o estritamente ferramentas de teste, mas s�o necess�rias para
manter o CONTROLE DA VERS�O de diferentes builds de softwares e
testes, especialmente quando � configurada mais que um ambiente de
hardware/software em termos de vers�es de sistemas operacionais,
compiladores, browsers, etc.

6.1.4 Ferramentas de suporte para teste est�tico

- Ferramentas para testes EST�TICO (n precisa estar em execu��o o soft) fornecem
uma alternativa de baixo custo para encontrar mais defeitos em
um est�gio INICIAL dentro do processo de desenvolvimento.
- Ferramentas para suporte ao PROCESSO DE REVIS�O:
Essas ferramentas auxiliam com o processo de revis�o, check-lists, diretrizes
de revis�o e s�o utilizadas para armazenar e comunicar
COMENT�RIOS DE REVIS�O e fornecer relat�rios de defeitos e esfor�o
associado.
Podem ser �teis tamb�m no fornecimento de ajuda para revis�es online para
times grandes ou que est�o DISTANTES geograficamente.
- Ferramentas de An�lise Est�tica:
 Ferramentas de an�lise est�tica ajudam os desenvolvedores, testadores e os
envolvidos com a qualidade a encontrar defeitos antes dos
testes din�micos, atrav�s da aplica��o de padr�es de codifica��o
(incluindo c�digo seguro), al�m de an�lise de estrutura e depend�ncias.
Podem ser �teis tamb�m no planejamento ou an�lise de risco devido ao
fornecimento de m�tricas para o c�digo (ex.: complexidade).
- Ferramentas de Modelagem:
Ferramentas de modelagem VALIDAM O MODELO do software (ex.: modelo f�sico de
dados, para um banco de dados relacional), enumerando
inconsist�ncia e encontrando defeitos.
Essas ferramentas podem geralmente ajudar na gera��o de alguns casos de
testes baseados no modelo.

6.1.5 Ferramenta de suporte para especifica��o de teste

- Ferramenta de Modelagem de Teste:
Ferramentas de modelagem de teste geram entradas de teste ou testes A PARTIR
dos REQUISITOS, de uma interface gr�fica do usu�rio, dos
diagramas de modelagem (estado, dados ou objetos) ou do c�digo.
- Ferramentas para prepara��o de dados de teste:
Estas ferramentas MANIPULAM a BASE DE DADOS, arquivos ou transmiss�o de dados
para ajudar na prepara��o dos dados de teste a serem
utilizados durante a execu��o de testes, al�m de garantir a seguran�a
atrav�s do anonimato dos dados.

6.1.6 Ferramenta de suporte para execu��o e registro

- Ferramentas de execu��o do teste:
Ferramentas de EXECU��O do teste permitem que o teste seja EXECUTADO
AUTOMATICAMENTE, ou SEMI-automaticamente, usando dados de entradas
e resultados esperados atrav�s do uso de uma linguagem de script, e
GERALMENTE FORNECEM um REGISTRO de teste para cada teste executado.
Tamb�m podem ser usadas para registrar testes, e geralmente suportam
linguagens de script ou parametriza��o de dados baseados em telas e
outras customiza��es do teste.
- Ambiente preparado/Ferramentas framework de teste de unidade:
O Ambiente preparado e frameworks facilitam o TESTE DE COMPONENTE ou parte de
um sistema por SIMULAR o ambiente em que o objeto de
teste ser� executado, atrav�s do fornecimento de simuladores, como
stubs ou drivers.
- Comparadores de teste:
Comparadores de teste determinam as DIFEREN�AS entre os arquivos, banco de
dados ou resultados dos testes.
As ferramentas de execu��o normalmente incluem compara��es din�micas, mas
compara��o ap�s a execu��o pode ser feita por uma ferramenta
especificamente de compara��o.
Um comparador de teste pode ser usado como or�culo de teste, especialmente se
for automatizado.
- Ferramentas de medi��o de cobertura:
Ferramenta de MEDI��O de COBERTURA pode ser intrusiva ou n�o intrusiva, e
medem a porcentagem de ESTRUTURAS de c�digo que S�O EXERCITADOS
(comandos, decis�es, ramos, m�dulos e chamada de fun��es) por um dado
conjunto de testes.
- Ferramentas de Seguran�a:
Ferramentas de seguran�a s�o utilizadas para AVALIAR as caracter�sticas de
seguran�a do software.
Isso inclui a avalia��o da habilidade do software em proteger
confidencialidade, integridade, autentica��o, autoriza��o, disponibilidade
e n�o rep�dio de dados.
Ferramentas de seguran�a s�o principalmente focadas em uma plataforma
espec�fica de tecnologia e seu objetivo.
 6.1.7 Ferramenta de performance e monitora��o
- Ferramenta de An�lise din�mica:
ESTAS ferramentas encontram DEFEITOS que s� s�o evidenciados quando o
software est� EM EXECU��O, assim como depend�ncia de tempo ou
vazamento de mem�ria.
S�o NORMALMENTE utilizados em testes de COMPONENTES, testes de INTEGRA��O dos
componentes e teste de MIDDLEWARE.
- Ferramentas de Teste de Performance/Teste de Carga/Teste de Estresse:
Ferramenta de teste de PERFORMANCE monitoram e relatam como um sistema se
comporta sob uma variedade de condi��es simuladas, em termos
de n�mero de usu�rios concorrentes, seu padr�o ramp-up, frequ�ncia e
porcentagem relativa de transa��es.
A simula��o de CARGA � conseguida atrav�s da cria��o de usu�rios virtuais que
executam um CONJUNTO selecionado de TRANSA��ES,
espalhados atrav�s de v�rias m�quinas de testes normalmente chamadas de
geradores de carga.
- Ferramentas de monitora��o:
Ferramentas de monitora��o continuamente analisam, verificam e reportam a
respeito do uso de recursos espec�ficos do sistema, e fornecem
avisos de poss�veis problemas do servi�o.

6.1.8 Ferramenta de suporte para �reas de aplica��es ESPEC�FICAS

- Avalia��o de QUALIDADE de dados:
Dados est�o no centro de alguns projetos, como aqueles de convers�o/migra��o
de dados e aplica��es como data warehouse e seus atributos
podem variar em termos de criticidade e volume.
Em tais contextos, ferramentas precisam ser empregadas para avalia��o da
qualidade dos dados para revisar e verificar a convers�o de dados
e regras de migra��o, para garantir que os dados processos est�o
corretos, completos e aderentes com padr�es pr�-definidos
espec�ficos ao contexto.
- Outras ferramentas de teste existem para teste de USABILIDADE.

6.2 Uso Efetivo das Ferramentas: Riscos e Benef�cios em potenciais

6.2.1 Potenciais benef�cios e riscos de ferramentas de suporte ao teste

- A simples compra da ferramenta n�o significa o sucesso da mesma.
- Cada tipo de ferramenta pode requerer um esfor�o para atingir os benef�cios
reais e cont�nuos.
- H� oportunidades d benef�cios potenciais com o uso de ferramentas de teste, mas
tamb�m existem RISCOS.
- BENEF�CIOS potenciais do uso das ferramentas incluem:
->REDUZIR trabalhos REPETITIVOS (executar os testes de regress�o, entrar os
mesmos dados do teste e checar a padroniza��o do c�digo).
->Maior CONSIST�NCIA e POSSIBILIDADE de REPETI��ES (ex.: testes executados
por uma ferramenta e testes derivados de requisitos).
->Avalia��o dos objetivos (ex.: medidas est�ticas, cobertura e comportamento
do sistema)
->Facilidade do acesso a informa��es sobre o teste (ex.: estat�sticas e
gr�ficos referente ao progresso de teste, taxas de incidente e performance).
- RISCOS no uso das ferramentas s�o:
->EXPECTATIVAS FALSAS referentes � ferramenta (incluindo funcionalidades e
facilidade de uso).
->SUBESTIMA��O do tempo, custo e esfor�o necess�rio para a INTRODU��O INICIAL
da ferramenta (incluindo treinamento e expertise externo).
->Subestima��o do esfor�o e tempo necess�rios para obter benef�cios
significantes e cont�nuos do uso da ferramenta (incluindo
a necessidade para mudan�as no processo de teste e melhoria cont�nua na
forma como a ferramenta � utilizada).
->Subestima��o do esfor�o para MANTER os artefatos de teste gerados pela
ferramenta.
->CONFIAN�A EXCESSIVA na ferramenta (quando o emprego de teste manual e
modelagem de teste s�o mais recomendados).
->NEGLIG�NCIA no CONTROLE de vers�o de ativos de teste dentro da ferramenta.
->Neglig�ncia na manuten��o dos relacionamentos e quest�es de
interoperabilidade entre ferramentas cr�ticas, como ferramentas de
gest�o de requisitos, controle de vers�o, gerenciamento de incidente,
rastreamento de defeitos e ferramentas de m�ltiplos fornecedores.
->Risco do fornecedor da ferramenta abandonar o neg�cio, aposentar a
ferramenta, ou vender a ferramenta para outro fornecedor.
->Baixa capacidade do fornecedor para suporte, upgrades e corre��es de
defeitos.
->RISCO de SUSPENS�O de projetos de c�digo ABERTO e ferramentas LIVRES.
->Imprevistos, como a falta de habilidade para dar SUPORTE a uma nova
plataforma.

6.2.2 Considera��es especiais para alguns tipos de ferramentas

- Ferramentas de EXECU��O de testes:
Ferramentas de execu��o de testes EXECUTAM os SCRIPTS desenvolvidos para
IMPLEMENTAR testes que foram armazenados eletronicamente.
Este tipo de ferramenta muitas vezes requer um ESFOR�O SIGNIFICATIVO para
OBTER os BENEF�CIOS.
CAPTURAR testes pela GRAVA��O de a��es manuais do usu�rio pode parecer
atrativo, mas esta abordagem N�O tem uma ESCALABILIDADE.
Um script de CAPTURA � uma representa��o linear com DADOS e A��ES
espec�ficas como parte de cada script.
Este tipo de script pode se tornar inst�vel a eventos inesperados.
Uma abordagem ORIENTADA a DADOS separa os dados de entrada dos testes,
normalmente em diversas PLANILHAS contendo VARIA��ES destes DADOS,
utilizando scripts mais gen�ricos que possam LER ESTAS PLANILHAS
na execu��o de um mesmo teste fazendo com que os dados utilizados
sejam diferentes.
Os testadores que n�o tem familiaridade com a linguagem dos scripts
podem entrar com os dados para estes scripts pr�-definidos.
Em uma abordagem ORIENTADA a PALAVRAS-CHAVE, as planilhas cont�m palavras-
chaves que descrevem A��ES a serem tomadas e os DADOS do teste.
Testadores (mesmo que n�o tenham familiaridade com a linguagem de
scripts) podem ent�o definir os testes utilizando estas palavras-chaves,
que poder� ser montada para o aplicativo que ser� testado.
Um t�cnico ESPECIALISTA na linguagem do script ser� necess�rio para TODOS os
casos (ainda que como testador ou como especialista em automa��o).
Para QUALQUER t�cnica de script utilizada, os RESULTADOS de cada teste
precisam ser armazenados para futuras compara��es.
- Ferramentas de AN�LISES est�ticas:
Ferramentas de an�lises EST�TICAS aplicadas ao C�DIGO fonte podem for�ar a
PADRONIZA��O do c�digo.
No entanto se aplicada a um c�digo existente (sistemas LEGADO) pode gerar
GRANDE quantidade de mensagens.
Mensagens de aten��o N�O param o processo de compila��o, mas devem ser
tratados para que a manuten��o do c�digo seja mais f�cil no futuro.
Uma implementa��o gradual com filtros iniciais para excluir algumas mensagens
poder� ser uma boa e eficiente alternativa.
- Ferramentas de GERENCIAMENTO de teste:
Ferramentas de GERENCIAMENTO de teste precisam fazer a INTERFACE COM OUTRAS
ferramentas ou planilhas para produzir as informa��es no
melhor formato poss�vel de modo a atender as necessidades da empresa.
O relat�rio precisa ser bem desenhado e monitorado para que traga o benef�cio
esperado.

6.3 Implementando uma Ferramenta na Organiza��o

- Os princ�pios para INTRODUZIR uma ferramenta em uma organiza��o s�o:
->Avalia��o da MATURIDADE da organiza��o, pontos fracos e pontos fortes na
identifica��o de oportunidades para um aperfei�oamento do
processo de teste COM USO de uma FERRAMENTA.
->AVALIA��O frente a REQUISITOS claros e os crit�rios objetivos.
->Uma prova de conceito (POC), utilizando a ferramenta durante a fase de
avalia��o para estabelecer se ela funciona adequadamente
com o software sendo testado e dentro da infraestrutura atual ou para
identificar mudan�as necess�rias � infraestrutura para
efetivamente utilizar a ferramenta.
->Avalia��o do FORNECEDOR (incluindo treinamento, suporte e aspectos
comerciais) ou fornecedores de suporte ao servi�o em caso de
ferramentas n�o comerciais.
->Identifica��o dos requisitos INTERNOS para acompanhamento (mentoring e
coaching) no uso da ferramenta.
->Avalia��o das NECESSIDADES de TREINAMENTO, considerando as habilidades de
automa��o de teste da equipe.
->Estimativa de uma raz�o custo-benef�cio baseado em um business case
concreto.
- Introduzir a ferramenta seleciona em uma organiza��o se inicia com um PROJETO
PILORO, que tem os seguintes OBJETIVOS:
->Aprender MAIS DETALHES sobre a ferramenta.
->Ver como a ferramenta poder� se ADEQUAR aos processos e pr�ticas e como
necessitariam mudar.
->Decidir as formas e padr�es de uso, gerenciamento, arquivamento e
manuten��o da ferramenta e artefatos de testes (ex.: decidir
a conven��o dos nomes de arquivos, cria��o de bibliotecas e decidir a
modularidade dos grupos de teste).
->ESTIMAR se os benef�cios ser�o atingidos a um custo razo�vel.
- Os fatores de SUCESSO para a IMPLANTA��O de uma ferramenta em uma organiza��o
incluem:
->IMPLEMENTAR a ferramenta ao restante da organiza��o incrementalmente.
->Adaptar e aprimorar o processo para combinar com o uso da ferramenta.
->Providenciar TREINAMENTOS para novos usu�rios.
->Definir DIRETRIZES de utiliza��o.
->IMPLEMENTAR um modo de APRENDER LI��ES com o uso da ferramenta.
->Fornecer SUPORTE ao TIME de teste para uma determinada ferramenta.
->Monitorar o USO e os BENEF�CIOS da ferramenta.