11 1 --teste_de_software_motivação_e_conceitos_basicos

Centro de Tecnologia da Informação Renato Archer – CTI/MCT
Centro de Tecnologia da Informação Renato Archer, CTI
Ministério da Ciência e Tecnologia, MCT
Teste de Software: Motivação
e Conceitos Básicos
Autores:
Adalberto Nobiato Crespo: Adalberto.crespo@cti.gov.br
Mario Jino: Jino@dca.fee.unicamp.br
Miguel Argollo: Miguel.argollo@cti.gov.br
Paulo Bueno: Paulo.bueno@cti.gov.br
Celso Penteado de Barros: Celso.barros@cti.gov
Outubro/2009
Teste de Software: Motivação e Conceitos Básicos Página 1

Teste de Software: Motivação e Conceitos Básicos
Apresentação
Este documento apresenta uma introdução ao teste de software, um conjunto de atividades
de extrema importância para a obtenção de produtos de software de qualidade. Como um
texto inicial, buscou-se apresentar os conceitos fundamentais de teste de uma forma simples
e breve. São descritos, dentre outros conceitos de teste: o objetivo; os procedimentos; o
processo; os tipos; os níveis e as técnicas aplicadas à atividade de teste.
O objetivo é apontar práticas aceitas como eficazes por profissionais da área e
também padrões recentes de teste de software, definidos por órgãos como ISO/IEC e IEEE.
É importante notar que a adoção de qualquer tecnologia de teste por parte das organizações
ou profissionais envolvidos com o SPB deve ser calcada em uma análise cuidadosa das
reais necessidades de teste, tendo em vista o objetivo da organização ou do profissional e a
natureza do software produzido.
Diferentes usuários podem se interessar prioritariamente por partes distintas deste
documento. Embora a leitura integral seja recomendada, podem-se identificar duas áreas de
interesse: aspectos mais técnicos do teste e aspectos mais voltados à política e ao
gerenciamento do teste.
As Seções 1, 2, 3 e 11 abordam a motivação, alguns conceitos que são essenciais para
todos os leitores assim como as conclusões. As Seções 4, 5, 6 e 7 discutem conceitos como
níveis, ciclos, tipos, técnicas, critérios e ferramentas de teste; conteúdo importante para os
desenvolvedores de software e os responsáveis pelo teste (gerentes, projetistas e executores
de teste). As Seções 8, 9, 10 apresentam os conceitos de processo, documentação, análise
de riscos, e considerações políticas e estratégicas do teste, temas relacionados à gerência
estratégica de TI, importantes para os responsáveis pela área de qualidade e de processos da
organização.
Guias e tutoriais de teste estão sendo desenvolvidos para complementar este
documento.

Conteúdo
1 Introdução: software público, qualidade e teste ............................................................. 4
2 Teste de software: objetivo, custos e benefícios ............................................................. 5
3 O sucesso no teste: provocar falhas que mostrem defeitos ............................................ 8
4 Níveis e ciclos do teste: quando testar .......................................................................... 11
5 Tipos de teste: o que testar ........................................................................................... 13
6 Técnicas e critérios de teste: como testar ..................................................................... 15
6.1 Critérios da técnica funcional ................................................................................... 17
6.2 Critérios da técnica estrutural .................................................................................. 21
7 Ferramentas de apoio ao teste ...................................................................................... 24
8 Processo e documentação do teste: como organizar o trabalho .................................. 26
9 Análise de riscos: priorizar aspectos para o teste .......................................................... 28
10 Política e processo de teste: o papel do teste na estratégia da organização ................ 29
11 Conclusão: transformando conceitos de teste em melhores produtos de software .... 31

1 Introdução: software público, qualidade e teste
O amadurecimento da indústria de software no Brasil traz consigo um aumento da
competitividade entre as empresas brasileiras desenvolvedoras e também destas com
empresas de outros países. Neste contexto, a promoção da qualidade de produtos de
software é um fator crítico de sucesso. Também de suma importância é o aprimoramento
dos processos de engenharia e de gestão no desenvolvimento de software, visando permitir
projetos bem sucedidos, com menores custos e respeitando os limites de prazo.
O Software Público Brasileiro (SPB) adota um modelo de desenvolvimento de
software caracterizado pelo compartilhamento de produtos de software, assim como dos
artefatos e serviços a eles relacionados. A existência de um alto nível de qualidade do
software, artefatos e serviços compartilhados seguramente tem uma influência positiva para
o sucesso deste modelo. Deste modo, a adoção de práticas visando avaliar e aprimorar a
qualidade deve ser estimulada no contexto do SPB.
O desenvolvimento de software não é uma tarefa fácil e, por ser fortemente baseada
no trabalho humano, é altamente sujeita a erros. Portanto, por mais que se adotem
processos de software bem estabelecidos, e que estes sejam executados por pessoas
capacitadas, usando técnicas e ferramentas adequadas, erros durante o desenvolvimento
acontecem e resultam em deficiências no software. A atividade de teste visa identificar
estas deficiências, permitindo assim o aprimoramento dos produtos de software.
O restante do documento está organizado do seguinte modo. A Seção 2 aborda a
necessidade do teste e os impactos negativos de um teste inadequado; a Seção 3 define
alguns conceitos fundamentais; a Seção 4 mostra como o esforço de teste pode ser realizado
em etapas e ciclos; a Seção 5 apresenta alguns tipos de teste existentes; a Seção 6 descreve
as principais técnicas e critérios para seleção e avaliação de testes; a Seção 7 cita alguns
tipos de ferramentas que podem apoiar esta atividade, enquanto a Seção 8 descreve as
atividades principais e as informações envolvidas em um processo de teste; a Seção 9
sumariza como a análise de riscos pode ser considerada no teste; a Seção 10 aborda como
situar estrategicamente o teste em relação aos objetivos da organização. Finalmente, tem-se
a conclusão na Seção 11.

2 Teste de software: objetivo, custos e benefícios
Existem diversas definições de teste de software; por exemplo:
• “Teste é uma atividade direcionada para avaliar um atributo ou capacidade de um
programa ou sistema e determinar se ele satisfaz os resultados requeridos”1;
• “Teste é o processo de executar um programa com a intenção de encontrar
defeitos”2;
• “Teste é o processo pelo qual se explora e se entende o estado dos benefícios e
riscos associados com a versão de um sistema de software”3.
Todas essas definições são válidas e destacam algum aspecto importante da atividade
de teste. De maneira simplificada podemos entender o teste de software como: “a execução
do software de uma forma controlada com o objetivo de avaliar se o software se comporta
ou não conforme especificado”.
Trata-se, portanto, de uma atividade fundamental para avaliar se o software produzido
atende aos requisitos levantados com os usuários. No entanto, teste não exclui a realização
de outras atividades como as inspeções efetuadas nos artefatos produzidos ao longo do
processo de software.
Uma questão essencial é: “por que existe a necessidade de se testar software?” Uma
resposta (provocativa) a esta pergunta tem a forma de outra questão: “você se sentiria
confortável em ser o passageiro de um vôo em uma aeronave que nunca decolou antes?”
O processo de projeto e construção de aeronaves envolve uma série de atividades de
teste da aeronave como um todo e de seus componentes principais (asas, turbinas, sistemas
eletrônicos, sistemas mecânicos). Essas atividades visam a confirmar as teorias
consideradas no projeto, obter dados empíricos e avaliar os aspectos não embasados por
teorias, avaliar a conformidade com padrões de segurança e de desempenho de vôo, além
de vários outros pontos. Os testes são aplicados em componentes, em subsistemas, e na
aeronave inteira, incluindo o teste em condições reais de vôo. Esta questão é obviamente
1 Hetzel, B. 1988, “The Complete Guide to Software Testing (2nd Ed.)”. QED Information Sciences, Inc.
2 Myers, G.J., 1979, “The Art of Software Testing”, Addison-Wesley, New York.
3 Cem Kaner, James Bach e Bret Pettichord, “Lessons Learned in Software Testing: A Context-Driven
Approach”, Willey Computer Publishing, 2002.

um exagero proposital; uma aeronave não testada nunca seria liberada para um vôo
comercial.
Analogamente, um software não deve ser liberado para uso sem que atividades
adequadas de teste tenham sido realizadas. Por meio do teste diversas deficiências
existentes no software, relacionadas a problemas de funcionalidade, desempenho,
segurança, instalação e utilização podem ser encontradas e removidas, antes que o software
“entre em vôo”, isto é, seja implantado para o uso dos clientes.
Enfim, testa-se software porque o desenvolvimento de sistemas envolve uma série de
atividades em que as possibilidades de ocorrência de erros humanos são inúmeras. Erros
podem ocorrer logo no início do processo de criação do software, quando objetivos
definidos podem estar incorretos ou incompletos. Além disso, erros podem ocorrer nas
demais fases do desenvolvimento, como projeto, codificação e integração do software.
Essencialmente erros ocorrem pela dificuldade dos seres humanos de executar tarefas e se
comunicar com perfeição. Esses são os mesmos motivos que justificam o teste rigoroso em
aeronaves.
O teste de software não é uma atividade tecnicamente fácil nem barata. A atividade
de teste representa um percentual significativo do custo total de desenvolvimento do
software. Estudos mostram que, dependendo do tipo do software e do processo de
desenvolvimento, o custo do teste tipicamente fica entre 50% e 80% do custo total 4.
No entanto, é fato reconhecido que a ausência de uma atividade de teste bem
realizada acarreta um custo total significativamente maior.
O retrabalho devido à manutenção corretiva de problemas de especificação, projeto e
programação é uma realidade amplamente conhecida. Estatísticas apresentadas mostram
ainda que cada R$ 1,00 investido em prevenção de defeitos diminui de R$ 3,00 a R$ 10,00
os custos de manutenção corretiva. E cada R$ 1,00 investido em remoção de defeitos
diminui de R$ 2,00 a R$ 5,00 os custos de manutenção corretiva.
Um estudo do NIST (Instituto Nacional de Padrões e Tecnologia, órgão do
Departamento de Comércio dos Estados Unidos) aponta impactos negativos de
4 Boehm, B. W. 1981, “Software Engineering Economics.” 1st. Prentice Hall PTR

inadequações nas atividades de teste5. Dentre os problemas acarretados pelo teste
inadequado podem-se destacar:
• Crescimento do número de falhas em uso devido à má qualidade do software,
acarretando perdas na reputação da organização e no potencial de negócios futuros;
• Aumento no custo de desenvolvimento de software, visto que o custo da correção de
problemas no software cresce ao longo dos estágios do desenvolvimento, tendo seu
maior valor quando é necessário corrigir problemas em um software já implantado
no cliente;
• Atraso para disponibilizar o produto ao mercado devido à ausência de processos e
técnicas de teste padronizadas e a conseqüente necessidade de criar às pressas uma
infra-estrutura de teste.
Esta lista de problemas é mais extensa, e apresenta problemas potencialmente
dramáticos, no caso de software com altos requisitos de confiabilidade, tais como: software
de controle de reatores nucleares; software aeroespacial e software de monitoramento de
leitos em UTIs. O teste inadequado de softwares que manipulam informações de alto valor,
como dados estratégicos de empresas e informações bancárias, também pode acarretar
grandes danos financeiros e de imagem às organizações.
No contexto do SPB as deficiências no teste de um produto de software podem
acarretar uma perda de reputação deste software entre os seus possíveis usuários, limitando
consequentemente os potenciais benefícios trazidos pelo software.
Raymond define o “modelo bazar” de desenvolvimento no qual o código fonte do
software é disponibilizado publicamente na internet e desenvolvido de forma colaborativa e
compartilhada por milhares de desenvolvedores espalhados pelo mundo; é o modelo
utilizado para o desenvolvimento do Kernel do sistema operacional Linux 6. Segundo
Raymond, ao se usar este modelo de desenvolvimento “quanto mais largamente o código
fonte estiver disponível para o teste, exame e experimentação, mais rapidamente os “bugs”
5 The National Institute of Standards and Technology (NIST) Strategic Planning and Economic Analysis
Group, “The Economic Impacts of Inadequate Infrastructure for Software Testing,” Maio, 2002
6 Eric S. Raymond, “The Cathedral & the Bazaar, Musings on Linux and Open Source by an Accidental
Revolutionary,” Fevereiro, 2001, O´Reilly & Associates, Inc.

serão descobertos”, chamada por ele de “Lei Linus” – referindo-se a Linus Torvalds,
idealizador do Linux – “given enough eyeballs, all bugs are shallow” 7. Na medida em que
o SPB caracteriza-se pelo compartilhamento de código fonte e de outros artefatos de
software, é razoável esperar que as práticas de teste possam ser conduzidas de forma
eficiente, aproveitando a característica colaborativa do ambiente e o espírito engajado e
investigativo de muitos membros de comunidades. A utilização de boas práticas de teste
neste contexto tem o potencial de aumentar a qualidade dos produtos de software e os
benefícios do SPB à sociedade.
3 O sucesso no teste: provocar falhas que mostrem defeitos
O teste de software pode também ser definido como “a execução de
um software com o objetivo de encontrar defeitos”. Neste caso, fica
explícita a idéia de que o teste deve exercitar o software de uma
maneira tal que este falhe, permitindo assim a posterior identificação
e remoção da causa desta falha.
Deve-se ter em mente que um defeito (fault ou defect em inglês) é uma anomalia no
software que pode causar uma falha (exemplos: um comando imperfeito, incompleto,
ausente ou extra no software). Uma falha (failure) é a ocorrência de uma discrepância entre
o resultado observado da execução do software e o resultado prescrito pelos requisitos. Um
erro (error) é um estado incorreto, intermediário ou final, de execução do software que
pode produzir um resultado incorreto, ou seja, pode levar a uma falha do software. Um
defeito no software é introduzido devido a algum engano (mistake) cometido em algum
momento no desenvolvimento do software e não descoberto em atividades de inspeção.
Por exemplo: o foguete Ariane V explodiu em 1996, cerca de 40 segundos após ter
decolado 8. O foguete saiu de sua rota programada e se desintegrou devido a forças
aerodinâmicas. Em uma análise posterior do incidente, verificou-se que o software de
controle do vôo indicou uma direção errada ao foguete (esta foi a falha) devido a uma
7 “se os olhos forem suficientes, todos os bugs serão vistos” em uma tradução livre. Ou: “... dados grupos
grandes o suficiente de testadores-beta e de desenvolvedores, quase todos os problemas serão identificados
rapidamente e o conserto será óbvio para alguém...”.
8 ARIANE 5 Flight 501 Failure Report by the Inquiry Board, Julho, 1996.

Centro de Tecnologia da Informação Renato Archer
conversão incorreta de uma variável
defeito).
Esta conversão produziu um
erro de overflow, isto é, um valor
errôneo de uma variável (este foi o
erro), que ocasionou a resposta
incorreta do software. O engano foi,
provavelmente, cometido por um
programador, que inseriu no
software um comando de atribuição
indevido.
Portanto, para um defei
(este foi o
de uma forma tal que o defeito seja “sensibilizado”
falha. Isto ocorre
quando o comando defeituoso é executado e cria um
as variáveis internas, por exemplo)
ainda que este
erro seja propagado, ao longo da execução, do ponto onde foi criado
defeituoso) para alguma saída do software, ocasionando uma resposta final incorreta
(valores incorretos para alguma saída produzida, por exemplo).
A Figura 1 ilustra a cadeia de eventos que se inicia com um engano e que pode
resultar em uma falha do software.
Figura 1: C
Em uma visão simplificada, a realização do teste
a. Selecionar valores para as
teste (chamados de Dad
partir do conjunto de todos os possíveis valores que podem ser usados para executar
o software, chamado de
– CTI/MCT
ftware: tipo real de 64 bits em um inteiro de 16 bits
efeito ser descoberto é necessário que o software seja executado
e provoque uma falha
estado de erro (valores incorretos para
ternas, exemplo). Para que a falha aconteça, é necessário
(logo após o comando
Cadeia de Eventos Para a Falha do Software
envolve:
Variáveis de Entrada a serem submetidos ao software em
ados de Entrada ou de Dados de Teste); esta seleção é feita a
Domínio de Entrada do software.
Página 9

b. Executar o software com os dados de teste
, as
variáveis de entrada e acionar alguma função no software
c. Avaliar se a saída produzida corresponde à
do software, isto é, se o comportamento e os valores produzidos como resultado da
execução foram os corretos
Um par dados de entrada
de Teste. Uma coleção de vários
Teste.
Para a realização do teste, presume
hamado Caso
onjunto de Casos de
permita avaliar se certo resultado
acordo com a especificação (ou
Esta avaliação é feita por meio de um
papel de oráculo e realiza a comparação “esperado versus obtido”
software falhou ou não.
A Figura 2 apresenta uma visão simplificada do teste:
de entrada e a avaliação da saída produzida pelo programa
esperados.
Uma limitação inerente à atividade de teste é
identificando se o
software está correto. O teste pode revelar a
ausência desses defeitos. Portanto, por mais rigoroso que seja o teste, não é possível
assegurar que não permaneceram no software defeitos “escondidos”
– CTI/MCT
ftware: teste, ou seja, informar os valores para
software; e
saída esperada segundo a especificação
, corretos.
e resultados esperados associados é chamado de um
casos de teste é referida como um Conjunto
presume-se a existência de algum meio ou dispositivo que
- ou comportamento - produzido pelo software está de
seja, se é o resultado esperado de um software correto).
oráculo. Normalmente o executor do teste assume o
obtido”, identifica
a execução do programa com dados
em relação aos resultados
Figura 2: Visão Simplificada do Teste
sua impossibilidade de provar que um
. presença de defeitos no software, mas não a
escondidos”, não encontrados
Página 10

durante o teste. No entanto, o teste pode dar subsídios para que se avalie o quão confiável
(ou não) é o software.
4 Níveis e ciclos do teste: quando testar
O teste de software é normalmente realizado em uma série de fases, ou níveis:
• Teste de Unidade;
• Teste de Integração;
• Teste de Sistema; e
• Teste de Aceitação.
Após o desenvolvimento de cada unidade do software (procedimento, função, método
ou classe) é realizado o teste de unidade (ou teste unitário), que visa a identificar defeitos
introduzidos nos algoritmos e estruturas de dados dessas unidades. Em geral, o teste de
unidade é feito pelo próprio desenvolvedor da unidade. As unidades são então
incrementalmente integradas e testadas (teste de integração). Esta etapa é realizada pelos
desenvolvedores ou por elementos de uma equipe de teste e visa a identificar defeitos de
interface entre as unidades. Depois de integrado, o software é testado “como um todo”: o
teste de sistema é o nível de teste cujos requisitos são derivados da especificação de
requisitos funcionais e não funcionais, e é aplicado para verificar se o software e o
hardware executam corretamente ou não quando integrados ao ambiente de operação. O
teste de aceitação é então conduzido para estabelecer se o sistema satisfaz ou não os
critérios de aceitação definidos com o cliente.
Deve-se notar que em cada um desses níveis (unidade, integração, sistema e
aceitação) diversos ciclos de teste podem ocorrer. Em cada ciclo de teste um procedimento
de teste é realizado, por meio do qual um ou mais casos de teste são executados. Falhas
provocadas por casos de teste devem ser registradas para posterior depuração do software
(localização e remoção dos defeitos) pela equipe de desenvolvimento. No próximo ciclo,
casos de teste devem ser re-executados para avaliar se os defeitos que ocasionaram as
falhas foram realmente removidos e se as alterações no software não introduziram
inadvertidamente outros defeitos. Pode ocorrer também a necessidade de se retornar a um
nível de teste anterior. Por exemplo: durante o teste de integração podem ser identificados

problemas que requeiram muitas alterações em
pode ser adequado, além de re
novamente o teste de unidade
as algum módulo do software. Neste caso,
O teste de um software já testado previamente
Teste de Regressão. Este teste busca verificar se as modificações efetuadas não
introduziram novos defeitos ou ativaram defeitos em partes inalteradas do código; visa
também avaliar se o software ainda satisfaz os seus r
tipicamente realizado na fase de manutenção, após a realização de mudanças no software
ou no seu ambiente. Conforme descrito no parágrafo anterior, este teste também pode
ocorrer ao longo do desenvolvimento do software.
A Figura 3 ilustra um processo
sequencialmente: teste de unidade
níveis são mostrados os ciclos
execução de casos de teste. A figura mostra
de teste.
– CTI/MCT
ftware: re-executar casos de teste de integração, também realizar
do módulo alterado.
e que sofreu mudanças é chamado de
. requisitos. O teste de regressão é
em que os níveis de teste são executados
quencialmente: unidade, de integração, de sistema e de aceitação.
que envolvem alterações do software (ou depuração
ão também o fluxo de retorno a níveis anteriores
Figura 3: Níveis e Ciclos de Teste
Página 12
equisitos. Em todos os
depuração) e a re-também

É importante destacar que não é obrigatório que todos os níveis de teste ocorram para
que se tenha um teste adequado. A necessidade ou não de realizar cada um desses níveis
deve ser decidida a partir da análise da situação específica, conforme descrito nas seções
sobre processos de teste (Seções 8 e 10).
5 Tipos de teste: o que testar
Diversos atributos de qualidade do software podem ser avaliados por meio de testes.
Características de qualidade de software definidas em padrões como a ISO/IEC 9126 9
podem servir como base para a definição de aspectos do software a serem avaliados por
meio da realização de testes. Portanto, existem diversos tipos de teste; cada tipo visa à
avaliação de um aspecto distinto do software e pode ser aplicado em um ou mais níveis de
teste (unidade, integração, etc.).
O teste de funcionalidade busca avaliar se o software apresenta um conjunto de funções
que satisfaça ou não às necessidades levantadas (associadas aos requisitos definidos).
O teste de desempenho visa a avaliar se o
software executa as funções previstas satisfazendo ou
não os requisitos de desempenho definidos (e.g.,
velocidade de processamento, tempo de resposta, uso
de memória).
O teste de interoperabilidade avalia a capacidade do
software em interagir com um ou mais componentes ou
sistemas.
O teste de segurança (security) visa a avaliar a habilidade
do software de impedir o acesso não autorizado – acidental ou
deliberado – ao software ou a dados.
O teste de sanidade (smoke test) envolve a execução de um subconjunto dos testes
projetados que cobrem algumas funcionalidades principais; pode ser realizado
9 ISO/IEC 9126-1:2001 Software engineering -- Product Quality -- Part 1: Quality model

periodicamente, ou como uma atividade inicial para avaliar se o software está pronto para
um esforço maior de teste.
O teste de estresse simula condições atípicas de utilização do software, provocando
aumentos e reduções sucessivas de transações que superem os volumes máximos previstos
para a capacidade de processamento dos componentes ou do sistema.
O teste de usabilidade visa a determinar quão
facilmente o produto de software é compreendido,
apreendido e usado, e quão agradável ele é ao usuário.
O teste de portabilidade busca avaliar o nível de
facilidade de transferência de um ambiente de hardware e
software para outro ambiente.
O teste de carga consiste em medir o comportamento
de um componente ou sistema submetido a cargas de
processamento crescentes para determinar qual nível de
carga o sistema pode tratar; por exemplo, número de
usuários ou número de transações.
O teste de instalação busca avaliar se o software é instalado e desinstalado com sucesso
ou não em determinado ambiente operacional.
O teste de recuperação determina a capacidade ou incapacidade de um produto de
software de restabelecer condições normais de operação e de recuperar dados afetados, em
caso de falha.
A determinação de quais tipos de teste devem ser utilizados e em qual (quais) nível
(níveis) eles devem ser aplicados, ocorre durante a fase de planejamento do teste. Esta
definição é feita considerando-se as informações disponíveis sobre a natureza do software
em teste e dos requisitos específicos dos módulos que compõem o software.
Na maior parte das situações é adequado focar atenção no teste de funcionalidade para
avaliar os se os requisitos funcionais do software são satisfeitos ou não. Este teste deve ser
complementado por outros tipos de teste (carga, desempenho, etc) para avaliar se os
requisitos não funcionais do software são satisfeitos ou não.

6 Técnicas e critérios de teste: como testar
Esta seção apresenta algumas Técnicas e Critérios de Teste úteis para a seleção de bons
casos de teste. É importante ressalvar que existem outras técnicas não relatadas aqui;
procurou-se destacar as técnicas mais usadas na prática ou mais consolidadas na literatura.
Como este documento apresenta apenas uma visão inicial sobre técnicas e critérios, é
recomendada a consulta a tutoriais específicos e de literatura especializada para maiores
informações.
Uma tarefa fundamental na atividade de teste é a seleção dos casos de teste a serem
utilizados. Esta seleção é necessária porque o Teste Exaustivo, feito com todas as possíveis
combinações de valores de entrada, é quase sempre inviável. Por exemplo, considere um
software que tenha como entrada 15 variáveis, sendo que cada uma delas pode assumir 7
valores diferentes. Considere ainda que a execução de cada caso de teste demore 1/100 de
segundo (0,01 segundo). Para realizar o teste exaustivo deste software seriam necessários
715/100 segundos, o que equivale a 1.505 anos e alguns meses de processamento.
Tendo em vista o objetivo principal do teste de revelar defeitos e a restrição de que os
cronogramas e orçamentos sejam cumpridos, é aconselhável a utilização de Técnicas de
Teste. Estas técnicas estabelecem procedimentos para selecionar - ou criar - os casos de
teste que resultem em um conjunto de teste eficaz e de tamanho moderado. As técnicas de
teste determinam a natureza da informação a ser utilizada para se fazer a seleção ou a
avaliação de conjuntos de teste. Na técnica de Teste Funcional os casos de teste são
selecionados por meio da análise da especificação do software, ou utilizando modelos
criados na fase de análise e projeto do software. Na técnica de Teste Estrutural os casos de
teste são selecionados por meio da análise da estrutura interna do software. Na técnica de
teste Baseada em Defeitos, casos de teste são selecionados a partir de classes de defeitos
que podem ser introduzidos ao longo do desenvolvimento do software. A Figura 4 ilustra
as técnicas funcional e estrutural de teste.

As diversas técnicas de teste não são excludentes;
técnicas é recomendada, pois os defeitos revelados pela aplicação de
ser diferentes.
A utilização de uma técnica de teste ocorre por meio da aplicação
de Teste. Um critério de teste determina um conjunto de
que devem ser exercitados pela realização do teste.
comandos - ou todos os nós
requeridos os comandos do código do software
deve ser executado (ou exercitado), pelo menos uma vez, por algum dado de teste.
A Cobertura do Teste,
Critério
equeridos do software
todos os
. software
o
percentual de elementos requeridos exercitados por um conjunto de casos
executados. Por exemplo, o percentual de comandos executados durante o teste seria uma
medida de cobertura considerando
medida de cobertura quantifica, sob certa perspectiva, a qualidade do teste realizado.
razoável supor, neste exemplo, que um conjunto de teste que executa 90% dos comandos de
um software é melhor do que outro conjunto de teste
de teste
É
10 O teste caixa preta inclui outras técnicas além da técnica funcional, única que está sendo considerada neste
documento.
– CTI/MCT
ftware: Figura 4: Técnicas de Teste 10
as na verdade, a utilização de várias
ada, cada uma delas podem
de algum
Elementos Requeridos
Por exemplo, o critério
- da técnica estrutural de teste define como elementos
o software. Neste caso, cada comando do so
este, com respeito a um critério de teste específico, mede
. considerando-se o critério de teste do exemplo anterior. Deste modo, a
que executa apenas 50% dos
Página 16

comandos. Se um conjunto de casos de teste exercita todos os elementos requeridos pelo
critério, diz-se que tal conjunto satisfaz o critério.
Em geral, os critérios de teste podem ser utilizados para: criar um conjunto de casos
de teste; avaliar um conjunto de casos de teste já criado; ou ainda, servir como uma
condição para a finalização do teste.
A seguir é feita uma breve descrição de alguns critérios de teste da técnica funcional e
da técnica estrutural, as mais usadas na prática.
6.1 Critérios da técnica funcional
Os critérios da técnica de teste funcional caracterizam-se por utilizar informações
originadas da especificação do software como base para a seleção de casos de teste.
Artefatos criados na fase de análise de requisitos e de projeto do software, tais como o
documento de requisitos do software ou modelos como diagramas UML, são utilizados
para criar os casos de teste.
A idéia essencial da técnica funcional é selecionar dados de teste representativos o
suficiente para avaliar se as funcionalidades definidas na especificação do software foram
implementadas corretamente ou não. Para tanto, operações associadas às funcionalidades
são identificadas e dados de teste que as exercitem são definidos e executados.
O critério Particionamento de Equivalência divide o domínio de entrada do software
em classes de equivalência e requer que pelo menos um dado de teste de cada classe seja
selecionado e executado. Essas classes são definidas pressupondo que todo dado de entrada
pertencente a uma classe é tratado do mesmo modo, de acordo com a especificação do
software. Portanto, cada dado de teste selecionado representa os demais dados de testes da
sua classe de equivalência.
Por exemplo, se a especificação define que um software recebe como entrada uma
variável idade, tipo inteiro, que pode variar de 0 a 120 anos (incluindo os extremos),
poderiam ser identificadas as seguintes classes de equivalência:
• Classe 1: idade menor que zero – referida como classe de valores inválidos;
• Classe 2: idade entre 0 e 120 – classe de valores válidos; e,
• Classe 3: idade maior que 120 – outra classe de valores inválidos.

Ao se executar o software com dados de teste que pertençam às Classes 1 e 3 espera-se que
os valores fornecidos sejam identificados como não aceitáveis e sejam emitidas mensagens
apropriadas. Ao se executar o software com um dado de teste que pertença à Classe 2 o
valor fornecido deve ser aceito e uma saída apropriada deve ser produzida.
A Figura 5 ilustra as classes de equivalência do exemplo e os dados de teste selecionados
para exercitar cada classe.
Classe 2
(valores válidos)
(valores inválidos)
Classe 1
-39 0 45 120 135
Figura 5: Classes de Equivalência e Dados de Teste
Classe 3
Dependendo da especificação, se existirem diferentes tipos de tratamento dentro de
alguma dessas classes, ela deve ser subdividida. Por exemplo, a Classe 2 pode ser
subdividida em sub-classes: 2.1 – idade entre 0 e 17; 2.2 – idade entre 18 e 20; e 2.3 – idade
entre 21 e 120. Esta divisão faz sentido e deve ser feita se a especificação do software
definir tratamentos distintos para estas diferentes faixas de valores. Neste caso a Classe 2
não é homogênea e, portanto, a execução de apenas um caso de tese da classe seria
insuficiente.
Deve-se notar que o modo como as classes de equivalência são definidas influencia
fortemente a eficácia do critério. Esta definição deve ser feita de forma cuidadosa,
analisando-se a natureza de cada variável de entrada do programa e a especificação do
software em teste.
O critério Análise de Valores Limite complementa o critério Particionamento de
Equivalência. Freqüentemente as situações de transição de comportamento do software de
uma classe para outra classe, as situações limite, são implementadas de forma incorreta.
Estas situações costumam ser inerentemente complexas e acabam induzindo a erros de
análise, projeto ou codificação.
Para descobrir defeitos associados a estas situações é recomendada a seleção de dados
de teste situados nos limites das classes. No exemplo anterior (variável idade, tipo inteiro,

que pode variar de 0 a 120 anos, incluindo os extremos) os valores limite seriam: 1, 0 e -1,
referentes ao limite entre as Classes 1 e 2; e 119, 120, 121, referentes ao limite entre as
Classes 2 e 3, conforme ilustrado na Figura 6. Notar que são selecionados valores
exatamente no limite, valores imediatamente inferiores e imediatamente superiores ao
limite. A definição dos valores limite também deve ser feita cuidadosamente, analisando-se
a natureza de cada variável de entrada do programa e a especificação do software em teste.
Classe 2
(valores válidos)
-1 0 1 119 120 121
Figura 6: Valores Limite e Dados de Teste
Classe 3
Classe 1
Teste baseado em modelos
Alguns critérios caracterizam-se por utilizar modelos do software (representações
intermediárias do software) como base para a seleção de dados de teste. Esses critérios são
freqüentemente chamados de Teste Baseado em Modelos (Model Based Testing). Modelos
como Máquinas de Estados Finitas (FSM), ou modelos definidos em linguagens como
UML (Unified Modelling Language) ou SDL (Specification and Description Language)
podem ser utilizados para este propósito.
O Teste Baseado em Casos de Uso utiliza os modelos de Casos de Uso (representação
definida na UML), criados na fase de análise de requisitos e de projeto do software, para a
seleção de casos de teste. Casos de Uso são muito usados para especificar o comportamento
esperado do sistema do ponto de vista dos atores que interagem com o sistema. Como são
elaborados normalmente em etapas iniciais do processo de desenvolvimento, esses modelos
são úteis para o projeto antecipado de casos de teste, principalmente os que serão aplicados
nos testes de sistema e de aceitação do software.
A aplicação do critério de teste é feita nos seguintes passos:

a. Descrever os fluxos de eventos para o caso de uso. Devem ser descritos tanto o
fluxo de eventos básico como os fluxos alternativos e de exceção.
b. Definir o conjunto de cenários que serão usados nos testes. Cada cenário pode ser
formado a partir dos fluxos de eventos identificados bem como das combinações
desses fluxos.
c. Definir casos de teste para cada um dos cenários, ou seja, para cada cenário definir
valores de entrada, ações no software que provoquem a execução do cenário e as
saídas esperadas.
d. Executar o software com os dados de teste, avaliar se os resultados produzidos
correspondem aos esperados, registrar os resultados e os incidentes observados.
Notar que os passos a, b e c podem ser realizados logo que a especificação dos casos
de uso esteja pronta e revisada; não é necessário esperar a conclusão da implementação dos
casos de uso para realizá-los. O passo d pode ser realizado em momentos distintos,
dependendo do nível do teste realizado: quando os módulos que implementam as funções
especificadas nos casos de uso estiverem disponíveis (no caso do teste de “partes” do
sistema); quando o sistema como um todo estiver integrado e disponível (no caso do teste
de sistema); ou ainda, quando o sistema for utilizado no processo de aceitação pelo cliente
(no caso do teste de aceitação).
Naturalmente, outros modelos (da UML ou de outras linguagens) podem ser
utilizados de forma semelhante para a seleção de casos de teste. Por exemplo, Diagramas
de Estados (com os Statecharts) podem servir como base para a seleção de casos de teste
que exercitem transições de estado que podem ocorrer em um objeto. Critérios de teste
baseados em modelos de estados são úteis para aplicações nas quais muitas transições
complexas de estado dos objetos são possíveis, tais como sistemas de controle de processos
e sistemas de telefonia.
Diagramas de Colaboração, que descrevem a interação entre objetos para especificar
um comportamento, também podem ser utilizados para seleção de casos de teste. Critérios
de teste baseados em Diagramas de Colaboração permitem avaliar interações específicas
entre objetos, formadas por seqüências de comunicações. Os casos de teste visam a

exercitar e avaliar se as trocas de mensagens, que caracterizam a colaboração de um
conjunto de objetos, permitem atingir os propósitos definidos na especificação do sistema.
6.2 Critérios da técnica estrutural
Na técnica de Teste Estrutural os dados de teste são selecionados por meio da análise da
estrutura interna do software. Portanto, o código fonte do software deve estar disponível,
pois ele é utilizado para a seleção dos dados de teste. A motivação para o uso desses
critérios muitas vezes é feita com questionamentos do tipo: “você confiaria em um software
se fosse informado que algumas instruções deste software nunca foram executadas antes?”
Esta pergunta enfatiza que defeitos em trechos não exercitados do código fonte do software
certamente não serão descobertos.
Na Técnica Estrutural uma unidade de software (função, procedimento ou método) é
considerada como o conjunto de seus componentes estruturais. Estes componentes
estruturais podem ser comandos de desvio (como os comandos: if-then; switch; while e
repeat) ou outros comandos (instruções como: x = y + 2; read(a,b); x = func(a,b) ). O
software pode ser representado por um Grafo de Fluxo de Controle (GFC) composto de nós
– correspondem a blocos de comandos que são sempre executados conjuntamente -, e
ramos, que correspondem a possíveis desvios no fluxo de execução. O GFC possui um
único nó de entrada, um único nó de saída, e define um conjunto de caminhos que podem
ser executados do nó de entrada ao nó de saída, passando por certos comandos e desvios ao
longo da execução. Quando se executa o software com um dado de teste, algum caminho
específico será executado no programa (isto só não ocorre caso o software entre em um
laço infinito).
A Figura 7 mostra um código fonte em C (identifier.c) e o respectivo GFC 11. Notar
que o código fonte apresenta no lado esquerdo como comentários o número do nó do GFC
ao qual o comando pertence. É possível identificar conjuntos de comandos executados
sempre conjuntamente, por exemplo, os comandos precedidos por /* 01 */ que pertencem
ao nó 1 do GFC. Pode-se também observar o efeito de comandos de desvio no fluxo de
11 Código fonte e GFC presentes em: Barbosa E., Maldonado, J., Vincenzi, A., Delamaro, M., Souza, S., Jino,
M. “Introdução ao Teste de Software”, XIV Simpósio Brasileiro de Engenharia de Software”, 2000.

controle, por exemplo, o comando while presente no nó 4 do grafo, ou o comando if-then-else
iniciado no nó 8.
/* 01 */ {
/* 01 */ char achar;
/* 01 */ int length, valid_id;
/* 01 */ length = 0;
/* 01 */ printf (“Digite um possível identificadorn”);
/* 01 */ printf (“seguido por <ENTER>: “);
/* 01 */ achar = fgetc (stdin);
/* 01 */ valid_id = valid_starter (achar);
/* 01 */ if (valid_id)
/* 02 */ length = 1;
/* 04 */ while (achar != ‘n’)
/* 05 */ {
/* 05 */ if (!(valid_follower (achar)))
/* 06 */ valid_id = 0;
/* 07 */ length++;
/* 07 */ }
/* 08 */ if (valid_id && (length >= 1) && (length < 6) )
/* 09 */ printf (“Validon”);
/* 10 */ else
/* 10 */ printf (“Invalidon”);
/* 11 */ }
Figura 7: Código Fonte e Respectivo Grafo de Fluxo de Controle
Critérios de teste estrutural estabelecem componentes internos do software como
elementos requeridos. O critério de teste Todos os Comandos (ou Todos os Nós) requer que
cada comando do software seja exercitado pelo menos uma vez durante o teste. A
determinação de dados de teste que exercitem um comando específico requer a análise do
código fonte do software e a escolha de valores para as variáveis de entrada que provoquem
a execução do comando.
Por exemplo, a Figura 8 mostra um trecho de programa no qual há um comando de
decisão if-then-else e o respectivo GFC. Para que os comandos representados por B sejam
executados é necessária a seleção de valores de entrada tais que a condição lógica do
comando if seja satisfeita; por exemplo, valores de entrada que façam com que x tenha
valor 100 e y tenha valor 30 imediatamente antes do comando if (notar que x e y podem ser
variáveis de entrada, mas também podem ser computadas internamente, a partir de outras
variáveis). Outros dados de teste serão necessários para exercitar os comandos

representados por C; por exemplo, dados que resultem nos valores x = 20 e y = 15 antes do
comando if.
A …;
A if (x > y * 2)
B { … }
C else
C { … }
D …;
A
B C
D
Figura 8: Comando if-then-else e Respectivo Grafo de Fluxo de Controle
A …;
A If (x > y * 2)
B { … }
C …;
A
B
C
Figura 9: Comando if-then e Respectivo Grafo de Fluxo de Controle
O critério Todos os Ramos requer que cada possível transferência de controle seja
exercitada pelo menos uma vez. A Figura 9 mostra um trecho de programa com um
comando condicional if-then. Os dados de teste que satisfazem a condição do if, exercitam
os comandos representados em B e também os em C. Este critério, no entanto (ao contrário
do anterior), requer a execução de dados de teste adicionais, que provoquem a transferência
de controle (ou ramo) do comando if diretamente para os comandos em C (sem passar por
B).
O critério Todos os Caminhos requer que cada diferente caminho no GFC seja
executado pelo menos uma vez. Este critério é geralmente considerado excessivamente
exigente visto que, em programas reais, a sua aplicação tende a gerar conjuntos muito
grandes de elementos requeridos. Considere a Figura 10 que mostra um trecho de código
com dois comandos if-then-else em sequência e o respectivo GFC; note que o segundo
comando if pertence ao nó D no grafo. A execução de apenas dois casos de teste é
suficiente para exercitar todos os nós e também todos os arcos do GFC; por exemplo,
utilizando um caso de teste que exercite a seqüência ABDEG e outro que exercite a

seqüência ACDFG. No entanto, para satisfazer o critério todos os caminhos são necessários
quatro casos de teste, cada um exercitando um caminho do GFC: ABDEG, ABDFG,
ACDEG e ACDFG.
A …;
A if (x > y * 2)
B { … }
C else
C { … }
D if (z > w)
E { … }
F else
F { … }
G …;
A
B C
D
E F
G
Figura 10: Comandos if-then em Sequência e Respectivo Grafo de Fluxo de Controle
Existem outros critérios estruturais que não serão abordados neste documento. Mais
informações sobre os critérios apresentados e sobre como utilizá-los encontram-se em
tutoriais específicos e em literatura especializada.
7 Ferramentas de apoio ao teste
As empresas de software são cada vez mais pressionadas a produzir produtos de qualidade
em curto espaço de tempo. Esta situação coloca uma forte pressão em suas equipes de teste,
que são levadas a tentar aumentar a cobertura dos testes realizados sem comprometer os
prazos de entrega do projeto.
O emprego de ferramentas de apoio pode reduzir o esforço e aprimorar a qualidade
do teste. Estas ferramentas não são suficientes para automatizar completamente o teste, mas
podem auxiliar o testador na realização de diversas atividades.
São exemplos de atividades de teste para as quais se encontram ferramentas de apoio:
• Definição dos elementos requeridos para o teste: para as diversas técnicas são
determinados elementos requeridos que podem servir de base para a criação de
casos de teste;

• Avaliação de cobertura atingida no teste e a identificação de elementos requeridos
não exercitados: para as diversas técnicas são avaliados o nível de cobertura
atingido (percentual de elementos requeridos exercitados) e os elementos requeridos
ainda não exercitados. As ferramentas permitem quantificar a qualidade do teste;
• Captura de eventos e de respostas do
software: gravação e reprodução de
informações do teste, tais como: dados de
entrada, eventos de entrada, interfaces e
informações mostradas;
• Execução do teste: execução do software
com um conjunto de casos de teste e a
avaliação do resultado produzido.
Ferramentas podem ser aplicadas tanto para
o teste de unidade como para o teste de
sistema;
• Armazenamento e gerenciamento de informações de teste: manutenção de
informações de teste – planos, projetos, scritps e casos de teste. Ferramentas
permitem também o rastreamento de informações associando casos de teste aos
requisitos do software a serem validados;
• Armazenamento e gerenciamento de incidentes: registro de informações sobre
incidentes ocorridos e acompanhamento da resolução;
• Definição e gerenciamento do processo de teste: definição de aspectos do processo
de teste como recursos, medidas, atividades e tarefas, e também o gerenciamento da
execução do processo de teste.
A adoção de um processo de teste para a organização (veja próximas seções) pode
incluir a avaliação de quais tipos de ferramentas são adequadas aos objetivos estabelecidos
para o teste.

8 Processo e documentação do teste: como organizar o trabalho
A adoção de um processo bem estabelecido para realizar as diversas atividades da
engenharia de software contribui positivamente para que se alcance o objetivo pretendido.
Um processo é um conjunto de passos parcialmente ordenados, constituídos por atividades,
métodos, práticas e transformações, usado para atingir uma meta. A atividade de teste de
software também deve ser conduzida por meio de um processo bem estabelecido. Um
processo de teste de software é um conjunto de passos parcialmente ordenados constituídos
por atividades, métodos e práticas, usadas para testar um produto de software.
Um exemplo de modelo de processo de teste é o ArtProTest (“Artifact Oriented
Process Model for Testing”) 12,13. Este modelo é baseado em artefatos de teste determinados
na Norma IEEE Std 829-1998 14 e é formado por subprocessos, definidos e ordenados de
forma a permitir que o teste seja eficiente e eficaz.
No subprocesso Planejar é criado o Plano de Teste de Software, que contém, dentre
outras informações: extensão e abordagem do teste; recursos necessários, equipe e
treinamento, cronograma de atividades; ambiente operacional; itens a serem testados, o
nível e abordagem de teste para cada item, atividades, tarefas e respectivos responsáveis,
além de riscos e planos de contingência no teste.
O subprocesso Projetar envolve: refinar a abordagem de teste, definir e especificar os
casos de teste; estabelecer o ambiente e procedimentos de teste.
O subprocesso Executar envolve: executar, registrar, suspender, retomar, parar,
encerrar e tratar as contingências no teste.
O subprocesso Registrar visa relatar a execução dos testes e os incidentes observados
(defeito no software ou anomalia de funcionamento do ambiente). Também são
sumarizados os resultados do teste e as avaliações baseadas nesses resultados.
12 Crespo, A. N.; Silva, O. J. ; Borges, C. A.; Salviano, C. F.; Argollo Junior, M. T. E.; Jino, M. “Uma
Metodologia para Teste de Software no Contexto da Melhoria de Processo”. III Simpósio Brasileiro de
Qualidade de Software, 2004. v. 3. p. 271-285.
13 Bueno, P.M.S., Crespo A.N., Jino, M., “Analysis of an Artifact Oriented Test Process Model and of Testing
Aspects of CMMI”. In: 7th International Conference on Product Focused Software Process Improvement,
Amsterdam., Lecturer Notes in Computer Science. Berlin: Springer-Verlag, 2006. v. 4034. p. 263-277.
14 IEEE Std 829 (1998), “IEEE Standard for Software Test Documentation”, IEEE, New York.

É importante destacar que existem diversas atividades associadas a cada subprocesso
descrito anteriormente, que criam ou utilizam os artefatos que documentam o teste (plano
de teste, projetos de teste, etc). A definição de como esta informação de teste deve ser
estruturada em artefatos (isto é, a definição de “templates” de teste) é uma etapa importante
da implantação de um processo de teste em uma organização.
O processo de teste deve ser alinhado com o processo de desenvolvimento como um
todo. Uma alternativa é organizar os subprocessos de teste considerando as principais fases
do processo de desenvolvimento e associando a cada fase o nível de teste de software
correspondente – unidades, integração, sistema e aceitação (Modelo V). As atividades de
teste podem ser iniciadas junto com as atividades de desenvolvimento, logo que as
informações necessárias estejam disponíveis. Neste caso, o planejamento do teste deve ser
realizado junto com o planejamento do desenvolvimento, enquanto que o projeto do teste
de aceitação pode ser iniciado logo que os requisitos do software tenham sido definidos. A
execução de atividades de teste o mais cedo possível diminui as chances de que esta
atividade seja feita de forma apressada no final do projeto, devido à necessidade de entregar
o produto ao cliente.
Alguns modelos de processo de desenvolvimento de software, como o Espiral ou o
RUP, definem iterações (ou ciclos) para o desenvolvimento do software. Ao invés da
realização seqüencial das atividades de desenvolvimento do software, como no tradicional
modelo “cascata” 15, são definidas iterações para o desenvolvimento e incrementos (ou
releases) são associados a cada iteração. Cada incremento envolve a realização das
atividades para: definição de requisitos, projeto, implementação, integração e testes. Nestes
casos, as atividades de teste devem ser associadas às atividades de desenvolvimento em
cada iteração, de modo que haja o adequado replanejamento, projeto, execução e registro
dos testes. Recomenda-se realizar um planejamento global do teste junto com o
planejamento do desenvolvimento. O teste final do sistema e o teste de aceitação são
executados após o término da última iteração do processo de desenvolvimento.
15 Tipicamente, as atividades realizadas no modelo cascata são: análise de requisitos; projeto do software;
implementação e teste de unidades; integração e teste de integração; teste de sistema; implantação e teste de
aceitação.

Alguns modelos mais recentes enfatizam o projeto de testes e sua execução como um
elemento central do desenvolvimento do software. A abordagem Desenvolvimento Baseado
em Testes (ou TDD, sigla em inglês) é frequentemente adotada em métodos ágeis, como a
Programação Extrema (XP). No TDD os casos de teste são criados pelos desenvolvedores
antes mesmo que o código fonte seja criado.
9 Análise de riscos: priorizar aspectos para o teste
Em muitos casos o software em teste possui algumas partes (ou funcionalidades) nas quais
a ocorrência de uma falha pode acarretar graves conseqüências a seus usuários, podendo
impactar negativamente seus negócios e eventualmente até mesmo colocar a integridade de
vidas humanas em risco. Por outro lado, o mesmo software pode possuir partes nas quais a
ocorrência de falhas, embora não desejável, não seja crítica em termos dos negócios de seus
usuários, impactando-os somente de forma marginal.
Neste contexto, uma preocupação fundamental do
teste é avaliar as funcionalidades do software que sejam
mais importantes para o negócio de seus futuros
usuários e propor e desenvolver atividades de teste que
abordem com o devido cuidado essas áreas. Pensar nos
testes com a perspectiva dos riscos que as falhas
possam provocar é um aspecto importante para o
sucesso do teste.
A análise de riscos deve ocorrer no planejamento do teste e deve dar subsídios para a
definição de tipos e técnicas de teste a serem utilizadas em cada parte do software, assim
como o quão rigoroso deve ser o teste daquela parte do software. Em última análise, a
consideração dos riscos envolvidos permite alocar os recursos de teste de uma maneira
prudente, dosando o rigor e o esforço do teste de cada parte do software ao nível requerido
de confiabilidade.

10 Política e processo de teste: o papel do teste na estratégia da
organização
A definição de uma Política de Teste é fundamental para qualquer organização que
pretende definir ou aprimorar as suas atividades de teste. Trata-se, portanto, de um primeiro
passo importante que servirá de base para definição do processo de teste da organização.
A política de teste define, de maneira geral, os objetivos e a visão estratégica em
relação ao teste. Portanto, deve estar alinhada com a política de qualidade e com os
objetivos de negócios da organização. Ao se estabelecer uma visão comum sobre o teste
para todos os envolvidos com esta atividade, obtém-se um alinhamento das iniciativas para
a utilização ou melhoria do processo de teste, tanto no desenvolvimento como na
manutenção de software. Recomenda-se, portanto, que a política de teste seja documentada,
divulgada e tenha um responsável definido.
A definição de indicadores associados aos objetivos do teste permite a avaliação e a
melhoria contínua do processo de teste na organização. Tipicamente uma política de teste
aborda: objetivos e importância do teste; níveis de qualidade a serem atingidos; nível de
independência da equipe de teste; principais responsabilidades; definição em alto nível do
processo de teste; e separação entre teste e depuração.
A partir do momento em que se estabelece “o quê” as atividades de teste devem
atingir na organização – a Política de Teste – pode-se trabalhar para definir “como” os
objetivos serão atingidos. A definição do “como” dá-se pelo estabelecimento de um
processo de teste. Modelos de processos genéricos de teste e modelos de maturidade de
teste podem servir como inspiração nesta tarefa.
Um modelo de processo genérico de teste, como é o descrito na Seção 8, pode ser
adaptado às necessidades específicas de cada organização. Tal tipo de modelo define um
conteúdo amplo em teste (formado por atividades, métodos, artefatos, etc.) que serve como
base para o estabelecimento de processos customizados, fundamentados nas necessidades
de teste específicas de cada organização. O termo Estratégia de Teste também é utilizado
na literatura com significado semelhante, ou seja, atividades, métodos, artefatos de teste
adotados por uma organização.

Modelos de maturidade de testes, tais como o Test Process Improvement (TPI) 16 ou
o Test Maturity Model Integration (TMMi) 17, também podem ser utilizados para definir
um processo de teste bem como para guiar a sua avaliação e melhoria. O TMMi é
complementar ao modelo CMMI e aborda aspectos importantes para os gerentes e analistas
de testes e demais profissionais de qualidade de software. Assim como o modelo em
estágios do CMMI, o TMMi usa o conceito de níveis de maturidade para a avaliação e
melhoria do processo de teste.
A adoção de um processo de teste, feita por meio da customização de um modelo de
processo genérico de teste, é referida como uma implantação ou configuração de um
processo de teste na organização. Os modelos de processos genéricos de teste ou os
modelos de maturidade do teste podem ser utilizados também para aprimorar, de forma
controlada e gradual, um processo de teste já existente na organização.
A implantação de um processo de teste deve ser feita de forma cuidadosa, por meio
da análise das reais necessidades de teste e das possibilidades da organização. Fatores como
tipo de software desenvolvido, requisitos de confiabilidade e segurança, bem como a
disponibilidade de recursos humanos e financeiros da organização, devem ser levados em
conta nesta implantação. Em geral, requisitos rigorosos de confiabilidade e segurança do
software determinam a definição de processos de teste mais completos, contemplando
vários níveis, tipos e técnicas de teste. Por outro lado, em muitos casos um processo “leve”
– com poucos níveis e utilizando técnicas simples e documentando apenas o essencial –
pode ser o suficiente.
Processos de teste mais completos demandam um maior esforço por parte da
organização, mas tendem a propiciar melhores produtos de software, além de evidências
mais claras da qualidade do teste.
16 Koomen, T. and Pol M., (1999), “Test Process Improvement: A practical step-by step guide to structured
testing”. ACM Press, London, England.
17 TMMi Foundation, “Test Maturity Model Integration (TMMi®) Version 2.0”, 2009.

11 Conclusão: transformando conceitos de teste em melhores produtos
de software
Este documento apresentou um corpo de conhecimentos fundamentais em Teste de
Software. O conteúdo foi abordado mais em extensão do que em profundidade, isto é,
espera-se que o leitor tenha adquirido um conhecimento amplo dos vários aspectos das
atividades de teste; entretanto, é necessário o aprofundamento nos assuntos específicos
conforme o interesse e os objetivos específicos.
Os guias e os tutoriais de teste (em elaboração) irão prover o aprofundamento em
alguns aspectos tratados de forma rápida neste documento. A literatura específica de teste
também pode ser útil para este intento.
Espera-se que com a aplicação do conteúdo apresentado, os diversos atores
envolvidos com as questões de qualidade e teste das mais diversas organizações possam
definir ou aprimorar as suas práticas de teste. Em especial, espera-se que todos os
participantes que compõem o ecossistema do SPB possam se beneficiar da aplicação deste
conteúdo e também possam contribuir para o aprimoramento do conhecimento público de
teste de software do SPB.

11 1 --teste_de_software_motivação_e_conceitos_basicos

Mais conteúdo relacionado

Mais procurados

Destaque

Semelhante a 11 1 --teste_de_software_motivação_e_conceitos_basicos

11 1 --teste_de_software_motivação_e_conceitos_basicos