122900

Prévia do material em texto

Processo do teste de software e seus
princípios
Você vai compreender a importância dos testes de software, sua evolução histórica, os principais tipos e
técnicas, além de aprender a planejar, aplicar e diferenciar testes estruturais, funcionais, estáticos e
dinâmicos.
Prof. Carlos Alberto de Farias
1. Itens iniciais
Propósito
O conhecimento sobre testes de software é essencial para profissionais de TI garantirem a qualidade,
segurança e eficiência dos sistemas desenvolvidos. Compreender os tipos de teste e seu planejamento
impacta diretamente na entrega de soluções mais robustas e confiáveis ao mercado.
Objetivos
Justificar a importância da qualidade nos testes, identificando as características dos softwares e os
critérios de entrega para o cliente.
 
Avaliar os critérios de seleção e encerramento de testes, reconhecendo os processos e princípios do
teste de software para um planejamento eficaz.
 
Diferenciar os tipos de testes de software, reconhecendo o modelo V, as técnicas estáticas e
dinâmicas, e os testes estruturais e funcionais.
Introdução
Os testes de software desempenham um papel fundamental no desenvolvimento de sistemas de qualidade,
seguros e confiáveis. Para compreender sua real importância, é essencial olhar para sua trajetória histórica,
desde as décadas de 1950 e 1960, quando surgiram as primeiras linguagens de programação modernas —
algumas ainda utilizadas atualmente, como o Cobol. A partir desse contexto, é possível entender como os
testes se tornaram parte indispensável dos processos de controle de qualidade em projetos de software.
 
Ao longo deste conteúdo, você será convidado a refletir sobre questões fundamentais: o que significa testar?
O que, de fato, é um teste de software? Como é possível melhorar os testes realizados? E, ainda, quando
saber o momento certo de encerrar o processo de testes?
 
Além disso, será apresentada a estrutura do processo de teste de software, incluindo seus princípios, papéis e
responsabilidades. Você também irá explorar o planejamento de testes e compreender por que ele é tão
importante para o sucesso dos projetos de desenvolvimento.
 
Outro ponto relevante será o modelo V de desenvolvimento de software, que permite visualizar claramente a
relação paralela entre as etapas de desenvolvimento e as de verificação e validação. Esse modelo ajuda a
entender como os testes podem ser integrados desde as fases iniciais de um projeto.
 
Por fim, o conteúdo abordará a distinção entre testes estáticos e dinâmicos, apresentando técnicas
específicas para cada tipo, além de diferenciar testes estruturais dos funcionais. Essa base teórica e prática
fornecerá subsídios essenciais para que você atue com mais segurança e eficiência no planejamento e na
execução de testes em projetos reais.
• 
• 
• 
1. Qualidade de teste de software
Histórico
No início do desenvolvimento dos softwares, quando só existia a função de programador, que era exercida por
poucos, não havia atividades de testes no processo do seu desenvolvimento. Na verdade, antes dos anos
1970, não havia nem processo definido de desenvolvimento de software.
Comentário
O que ocorria nessa época? Tendo em vista que os erros ocorriam, após o software estar pronto, o
próprio programador percorria o código para solucionar possíveis erros; Os testes eram feitos pelo
próprio usuário. 
Já no final dos 1960 e início dos 1970, surgiu a "programação estruturada", que recomendava, basicamente,
evitar o uso de goto, ou seja, desvio incondicional. Há um consenso entre os programadores que o desvio
incondicional é um mau estilo de programação, que gera códigos com baixa qualidade.
 
Nessa época, surgiram, então, os primeiros conceitos de engenharia de software, adotados, principalmente,
como modelo nos cursos de Exatas nas universidades em todo o mundo. Assim, os primeiros procedimentos
de testes passaram a ser usados, porém de forma bastante tímida.
 
Em 1979, Genford J. Myers, autor do livro The Art of Software Testing, apresentou um trabalho pioneiro e
profundo sobre um processo de teste de software. Foi criador de termos muito usados como “caixa branca”,
“caixa preta" e "caso de teste".
 
Myers também ficou conhecido pela Regra de 10 de Myers, que mostra que “quanto mais tarde os defeitos
forem encontrados, tanto mais caro será corrigi-los”.
 
Entenda graficamente a regra de 10 de Myers:
Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
Regra de 10 de Myers.
Qualidade de software
Nos anos 1980, surgiu o conceito de qualidade de software, processo fortemente relacionado à conformidade
com requisitos e à satisfação do cliente, que envolve a delimitação do escopo de um sistema e a volatilidade
dos requisitos, lugar-comum no desenvolvimento de software.
 
Alguns fatores afetam o desenvolvimento do software e influenciam na avaliação do usuário, como:
 
Tamanho e complexidade do software.
 
Número de pessoas envolvidas no projeto.
 
Métodos, técnicas e ferramentas utilizadas.
 
Relação custo x benefício do sistema.
 
Custos referentes à correção e remoção de erros.
 
Os testes aconteciam desde a fase inicial do projeto de software até a fase de encerramento e entrega do
produto final.
 
Alguns padrões foram criados para a medição e avaliação do processo de desenvolvimento, e o modelo que
ganhou maior credibilidade e importância para as empresas desenvolvedoras foi o Capability Maturity Model
(CMM), apresentado pelo SEI.
 
Nos anos 1990, surgiram algumas ferramentas de teste que proporcionaram alta produtividade e qualidade no
processo.
• 
• 
• 
• 
• 
 
Assim, determinados tipos de testes, que antes não eram possíveis de serem executados, tornaram-se de fato
uma realidade, proporcionando alta produtividade e qualidade no processo de teste e, consequentemente, na
qualidade do software.
 
Assista o vídeo e entenda a importância da qualidade do software.
Capability Maturity Model (CMM)
Capability Maturity Model (ou Modelo de Maturidade em Capacitação) para Software é um conjunto de
processos desenvolvido pela SEI - Software Engineering Institute em 1986 para melhorar o
desenvolvimento de aplicações em organizações que trabalham com tecnologias de software. O
processo é divido em cinco níveis de desenvolvimento: inicial, repetível, definido, gerenciado com
métricas e otimizado. 
Conteúdo interativo
Acesse a versão digital para assistir ao vídeo.
Cenário atual do desenvolvimento de software
A era digital exigiu que os softwares fossem se adaptando à realidade. Hoje eles fazem parte do nosso
cotidiano, estando presentes, por exemplo, nos aplicativos das mais diversas áreas das atividades humanas,
como alimentação, transações bancárias, compra e aquisição de produtos, contratação de serviços etc.
 
A Globalização é o processo que proporciona a integração entre diversas sociedades, países e comunidades
em todo o mundo, aproximando pessoas, empresas e seus departamentos, clientes, fornecedores etc., seja no
âmbito político, cultural, financeiro ou comercial.
 
O destaque maior da Globalização está na integração de mercado existente entre os países.
 
Assim, a exigência pela qualidade, funcionalidade, portabilidade e tantas outras características fizeram com
que esses aplicativos atingissem um grau elevado de complexidade e integridade.
 
Por outro lado, provavelmente você já teve experiência com algum software ou aplicativo que não funcionasse
a contento.
 
O que pode acontecer se:
 
Bancos perderem milhões?
 
Clientes virem saldos de suas contas sumirem de repente?
• 
• 
 
Telefones pararem de funcionar?
 
Aviões tiverem suas rotas desviadas?
 
Vários trens do metrô forem colocados no mesmo trilho?
Atenção
Softwares que apresentam bugs podem acarretar diversos problemas, como supressão de negócio,
prejuízos financeiros, além de perda de tempo e, principalmente, queda na reputação das
empresas. Assim sendo, os processos de gerenciamento de testes ganham cada vez mais importância
no contextoresposta
A afirmação está errada. Segundo Myers, o custo de correção de defeitos tende a aumentar quanto mais
tarde o defeito é detectado.
Os defeitos encontrados durante a produção tendem a custar muito mais que os encontrados em modelos
de dados e em outros documentos do projeto do software.
Questão 3
No modelo V, que integra o ciclo de vida de desenvolvimento de software ao ciclo de teste, a validação refere-
se ao desenvolvimento, enquanto a verificação se refere ao teste. Identifique se essa afirmação está certa ou
errada.
Chave de resposta
A afirmação está errada. O conceito está invertido: o teste é parte tanto da verificação quanto da
validação.
Questão 4
_______________ geralmente são executados após a correção de algum defeito ou após a adição de uma nova
funcionalidade. Seu objetivo é garantir que nenhum defeito foi acrescentado ao sistema após sua modificação.
 
Assinale a alternativa que preenche a sentença corretamente:
A Testes de regressão.
B Testes de estresse.
C Testes fumaça.
D Testes alfa.
E Testes integração.
A alternativa A está correta.
Os objetivos desse teste são garantir que nenhum defeito foi acrescentado ao sistema após sua
modificação e também que as mudanças realizadas nessa nova versão não gerarão erros em componentes
prontos e testados.
O teste de regressão é uma técnica aplicável a cada alteração realizada no software. Consiste em aplicar,
antes e depois da alteração, todos os testes que já foram aplicados nas versões anteriores.
Por ter essa natureza de repetição, torna-se imprescindível que seja adotada uma ferramenta de
automação de testes. Esta técnica pode ser bem aplicada nas fases de testes de unidade, de integração e
de sistema.
4. Conclusão
Considerações finais
Neste conteúdo, estudamos a importância dos testes de software no desenvolvimento de sistemas confiáveis
e com alto padrão de qualidade. Iniciamos com uma contextualização histórica, abordando o surgimento das
linguagens de programação modernas nas décadas de 1950 e 1960, como o Cobol, e como esse marco
influenciou a consolidação dos testes como parte essencial do controle de qualidade em projetos de software.
 
Exploramos as definições fundamentais sobre o que é testar, o que são testes de software e como aprimorar
sua aplicação prática, além de refletir sobre o momento ideal para encerrar o processo de testes. Também
aprofundamos o entendimento sobre os princípios que norteiam o teste de software, seus papéis e
responsabilidades, bem como a importância do planejamento adequado para garantir a eficácia e a eficiência
dos testes.
 
Avançamos na compreensão do modelo V de desenvolvimento de software, que estabelece um paralelismo
entre as etapas de desenvolvimento e as atividades de verificação e validação. Esse modelo reforça a
integração dos testes desde o início dos projetos, promovendo maior alinhamento e qualidade no processo.
 
Por fim, abordamos os diferentes tipos de teste — estáticos e dinâmicos —, além das técnicas associadas a
cada um, diferenciando ainda os testes estruturais dos funcionais. Com isso, construímos uma base teórica e
prática sólida, essencial para a atuação segura e estratégica na área de testes, contribuindo diretamente para
a entrega de soluções tecnológicas mais robustas e eficazes.
Explore +
Leia os textos:
 
Engenharia de Software - Introdução à Inspeção de Software.
 
Capability Maturity Model for Software.
 
Entenda as diferenças entre testes de aplicações dinâmicos e estáticos no blog da Conviso App Sec.
 
Estudo da qualidade de software na Metodologia V-model e sua interação com metodologias ágeis
(SCRUM). 
 
Planejar o gerenciamento da qualidade – Escritório de projeto na página do Escritorio de Projetos
 
Qualidade de Software.
 
• 
• 
• 
• 
• 
• 
https://cdn-conteudo.ensineme.com.br/Artigo_Engenharia_de_Software_e0bc2cef01.pdf
https://cdn-conteudo.ensineme.com.br/Capability_Maturity_Model_48afddc04c.pdf
https://cdn-conteudo.ensineme.com.br/Capability_Maturity_Model_48afddc04c.pdf
https://cdn-conteudo.ensineme.com.br/Estudo_da_qualidade_de_software_na_Metodologia_V_2551223c09.pdf
https://cdn-conteudo.ensineme.com.br/Estudo_da_qualidade_de_software_na_Metodologia_V_2551223c09.pdf
https://cdn-conteudo.ensineme.com.br/qualidade_em_software_f906e420e2.pdf
Leia o livro Engenharia de Software, de Roger Pressman. Editora McGraw Hill (6ª edição). 
Você poderá aprofundar seus conhecimentos sobre o tema Qualidade de software, acessando os seguintes
websites:
 
Associação Latino Americana de Testes de Software (ALATS). 
 
BSTQB. 
 
Centro de Informática - UFPE. 
Referências
 
AGUIAR, E. P. Didática da história: uma ciência da aprendizagem histórica? XXIII Simpósio Nacional de
História. Florianópolis, 2015. Consultado na internet em: 10 mai. 2019.
 
BARTIÉ, Alexandre. Garantia de qualidade de software. 1. ed. Campus, 2002.
 
BEIZER, Boris. Black-Box Testing: techniques for functional testing of software and systems. New York:
Wiley, 1995.
 
CROSBY, Philip. Quality is free: the art of making quality certain. Nova York: McGraw-Hill, 1979.
 
DELAMARO, M.E.; MALDONADO, J.C.; JINO, M. Introdução ao teste de software. 1. ed. Rio de Janeiro:
Campus, 2007.
 
HETZEL, W. C. The Complete Guide to Software Testing, 1988.
 
HOWDEN, W. E. Theoretical and Empirical Studies of Program Testing, 1987.
 
MYERS, Glenford J. The Art of Software Testing. New York: Wiley, 1979.
 
PEZZÉ, Mauro; YOUNG, Michal. Teste e análise de software. 1. ed. Porto Alegre: Bookman, 2008.
 
PRESSMAN, R. S. Engenharia de Software. 6. ed. Makron Books, 1995.
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
 
PRESSMAN, R. S. Engenharia de software: uma abordagem profissional. 8. ed. Rio de Janeiro: Campus,
2016.
 
SOMMERVILLE, Ian. Engenharia de software. 9. ed. São Paulo: Pearson, 2011.
 
SPILLNER, Andreas. From V-model to W-model: establishing the whole test process conquest 2000. In:
Workshop on testing non-functional software requirements. Nuremberg, Germany, 2000.
• 
• 
• 
	Processo do teste de software e seus princípios
	1. Itens iniciais
	Propósito
	Objetivos
	Introdução
	1. Qualidade de teste de software
	Histórico
	Comentário
	Conteúdo interativo
	Qualidade de software
	Conteúdo interativo
	Cenário atual do desenvolvimento de software
	Atenção
	Qual a realidade dos softwares atuais?
	A necessidade de testes no desenvolvimento de softwares
	Conteúdo interativo
	Atenção
	Definição sobre qualidade de software
	Fatores externos
	Fatores internos
	Garantia de qualidade
	Conteúdo interativo
	Garantia de qualidade de software (SQA)
	Conteúdo interativo
	Qualidade do processo
	Verificando o aprendizado
	2. Principais Conceitos do processo de teste de software
	O que é testar?
	Conteúdo interativo
	Estratégia de teste
	Teste de baixo nível
	Teste de alto nível
	Processo de teste de software
	Conteúdo interativo
	Fases iniciais
	Fases internas do ciclo
	Como se dá a interação entre os ciclos de vida?
	Conteúdo interativo
	Teste de verificação
	Testes unitários
	Testes de integração
	Testes de sistema
	Teste de aceitação
	Conteúdo interativo
	Atenção
	Princípios de teste de software
	Princípios de teste de software
	1º Princípio: teste demonstra a presença de defeitos
	2º Princípio: teste exaustivo é impossível
	3º Princípio: teste antecipado
	4º Princípio: agrupamento de defeitos
	5º Princípio: paradoxo do pesticida
	6º Princípio: teste é dependente do contexto
	7º Princípio: a ilusão da ausência de defeitos
	Características das estratégias de teste
	Diretrizes que devem ser levadas em conta para o teste
	A importância dos testes
	Conteúdo interativo
	Conteúdo interativo
	Exemplo - Projetos de controle de voo
	Conteúdo interativo
	Quando terminar os testes?
	Conteúdo interativo
	Papéis e responsabilidades de teste de software
	Desenvolvedor
	Grupo independente de teste (independent group test – ITG)
	Verificando o aprendizado
	3. Ciclo de vida do processo de testes de software
	Modelo V
	Conteúdo interativoConteúdo interativo
	Verificação
	Validação
	Conteúdo interativo
	Vantagens
	Desvantagens
	Paralelismo entre as atividades de desenvolvimento e teste de software
	Exemplo
	Processo de teste
	Atenção
	Teste de migração de dados
	Teste de unidade
	Teste de validação
	Verificação e validação
	Verificação
	Validação
	Conteúdo interativo
	Conteúdo interativo
	Testes de verificação e validação
	Teste de verificação
	Teste de validação
	Conteúdo interativo
	Testes estáticos X testes dinâmicos
	Testes estáticos e dinâmicos
	Testes estáticos
	Testes dinâmicos
	Exemplo
	Técnicas de teste
	Reflexão
	Teste estrutural X testes funcionais
	Estrutural
	Teste estrutural (caixa branca)
	Teste de regressão
	Teste de carga
	Teste de estresse
	Teste de usabilidade
	Teste de segurança
	Conteúdo interativo
	Funcional
	Requisitos
	Regressão
	Tratamento de erros
	Manual
	Interfaces de integração
	Controle
	Paralelismo
	Fases de testes (validação)
	Testes de unidade
	Testes de integração
	Testes de sistema
	Testes de aceitação
	Verificando o aprendizado
	4. Conclusão
	Considerações finais
	Explore +
	Referênciasdo desenvolvimento do software, uma vez que vulnerabilidades ou falhas podem gerar
riscos e causar perdas, em muitos casos, irrecuperáveis. 
Apesar disso, algumas empresas ainda resistem em investir na área de segurança e testes, por considerar seu
custo alto e desnecessário.
 
Essas empresas precisaram quebrar paradigmas e considerar que a implantação de um processo que garanta
a qualidade do software é estratégico e vital para a continuidade dos negócios, em um mercado cada vez
mais exigente e competitivo.
 
Confira na tabela a seguir as principais demandas de software atuais e a evolução do processo de qualidade e
de teste, segundo Bartié (2002).
Características 1960 1980 2000
Tamanho do software Pequeno Médio Muito grande
Complexidade do software Baixa Média Alta
Tamanho da equipe de desenvolvimento Pequeno Médio Grande
Padrões de metodologia de desenvolvimento Interno Moderado Sofisticado
Padrões e metodologias de qualidade e testes Interno Emergente Sofisticado
Organização de qualidade e testes Bem poucas Algumas Muitas
Reconhecimento da importância da qualidade Pequeno Algum Significante
Tamanho da equipe de qualidade e testes Pequeno Pequeno Grande
Tabela. Evolução das empresas desenvolvedoras de softwares.
Carlos Alberto de Farias.
• 
• 
• 
Qual a realidade dos softwares atuais?
Você deve ter
percebido que
toda a
sociedade
tornou-se
dependente de
sistemas de
software, que
hoje são parte
integrante do
nosso dia a
dia.
 As empresas
desenvolvedoras
estão percebendo
que os processos
de
desenvolvimento
são estratégicos e
agregam valor aos
seus negócios,
valorizando seus
produtos e
serviços.
 Na realidade, a
indústria de
software não está
preparada para
atender às
exigências do
mercado em
constante
evolução porque
não investe em
seus processos
internos.
 Um estudo
feito
recentemente
nos EUA
mostra o
quanto a
indústria de
softwares
está
deficitária:
 30% dos
projetos são
cancelados.
 
70% dos
projetos falham
nas
funcionalidades.
 
Os custos
extrapolam em
180% a
previsão.
 
Os orçamentos
e prazos
extrapolam em
200% os
cronogramas
iniciais.
A necessidade de testes no desenvolvimento de softwares
Assista ao vídeo e saiba mais sobre os testes de desenvolvimento de software.
Conteúdo interativo
Acesse a versão digital para assistir ao vídeo.
A necessidade e a importância dos testes vão depender do tipo de uso que o software terá. São mais críticos
aqueles que podem causar danos à vida humana ou levar a grandes perdas financeiras.
 
Como vimos com Myers, quanto mais precoce a detecção de falhas ocorre, menores os gastos do projeto com
reparos e replanejamento.
 
Por esse motivo, a utilização de ferramentas de suporte a testes tem se tornado uma regra no
desenvolvimento de softwares.
Atenção
A qualidade de um produto ou artefato reúne um conjunto de características e propriedades que devem
ser satisfeitas segundo as exigências do usuário, de modo a atender a uma medida de conformidade
com as especificações, como defeito zero nos componentes e no produto final, obtendo benefício com o
alcance da qualidade. 
Definição sobre qualidade de software
• 
• 
• 
• 
Segundo Pressman (2016), em seu livro Engenharia de Software:
"Qualidade de software é a conformidade a requisitos funcionais e de desempenho que foram
explicitamente declarados, a padrões de desenvolvimento claramente documentados e a características
implícitas que são esperadas de todo software desenvolvido por profissionais."
Pressman, 2016.
Esse processo visa garantir a uniformidade dos processos e produtos, eliminando defeitos e melhorando o
desempenho de suas funcionalidades.
 
Para desenvolver softwares de qualidade, é necessário investir em processos de gestão de qualidade,
atuando em todas as fases do ciclo de vida.
 
Alguns fatores internos e externos podem afetar a qualidade do software. Vejamos alguns exemplos:
Fatores externos
São percebidos tanto pelas pessoas que
desenvolvem softwares quanto pelos usuários.
Fatores internos
São percebidos apenas pelas pessoas que
desenvolvem softwares.
São exemplos de:
 
Fatores externos: confiabilidade, eficiência e facilidade de uso.
 
Fatores internos: modularidade (conceito no qual o sistema ou software é divido em partes distintas) e 
legibilidade.
 
É importante notar que a garantia de qualidade de software (Software Quality Assurance) não é algo com que
começamos a nos preocupar depois que o código foi gerado, e sim “ao longo de todo o processo de
engenharia de software”.
Legibilidade
Facilidade de leitura em: simplicidade; ortogonalidade; instruções de controle e estruturas e tipos de
dados. 
Todos os métodos, ferramentas e procedimentos definidos pela Engenharia de Software buscam um
único objetivo: produzir softwares de alta qualidade.
• 
• 
Segundo Philip Crosby (Quality is Free): “O problema do gerenciamento da qualidade não é o que as pessoas
não sabem. O problema é o que as pessoas acham que sabem”.
Garantia de qualidade
Os testes também fazem parte dos procedimentos seguidos para garantir a qualidade do processo de
desenvolvimento de softwares, assegurada por certificações concedidas por organizações que avaliam o
processo, considerando modelos de qualidade, como o CMMI (Capability Maturity Model Integration) e a
ISO-12207.
 
 Assista o vídeo e entenda como a qualidade do software pode ser medida.
Conteúdo interativo
Acesse a versão digital para assistir ao vídeo.
Garantia de qualidade de software (SQA)
Um grande desafio para qualquer programa de qualidade, considerado crítico, é possibilitar que qualquer
pessoa faça revisões no trabalho de profissionais experientes.
 
Os gerentes sempre querem os melhores profissionais para projetar o produto, mas geralmente o SQA não
pode tê-los. É necessário concentrar esforços em métodos de SQA que permitam um desenvolvimento que
possa ser revisado também por pessoas que não são desenvolvedores. Nesse caso, qual o papel do SQA?
 
Monitorar os métodos e os padrões que os engenheiros de software usam e verificar se eles estão usando
apropriadamente seus conhecimentos.
 
É importante compreender que as pessoas podem ser experientes em SQA sem, no entanto, serem
experientes em projetos de software.
Software com qualidade → Investimentos em qualidade em todas as frases do
processo de desenvolvimento.
Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
Incidência de defeitos: 56% - requisitos; 27% - análise e modelagem; 10% - outros;
7% - implementação.
É impossível obter um software com qualidade com processos de desenvolvimento ineficientes.
Nos processos de gestão de qualidade, o software deverá atender a todas as exigências do cliente/ usuário.
 
Softwares mal testados causam prejuízos às empresas, como retrabalho, aumento de custo do projeto e
informações inconsistentes que podem acarretar decisões equivocadas, além da insatisfação dos usuários.
 
Temos a aplicação de qualidade em duas dimensões:
 
Qualidade do Processo.
 
Qualidade do Produto.
Qualidade do processo
A preocupação com a qualidade deve estar presente em todas as fases do ciclo de desenvolvimento, inclusive
no início e na fase de análise de requisitos do sistema.
 
Quanto mais cedo os problemas forem detectados e corrigidos, mais rápido será o desenvolvimento e com
menor custo.
Como medir?
• 
• 
Métricas de software são usadas para ajudar os desenvolvedores a criar softwares com qualidade
reconhecida.
 
Alguns garantem que o software é incomensurável, porém desconhecem que existem técnicas que colocam
as métricas e medições como práticas fundamentais para a determinação do grau de maturidade dos
processos de desenvolvimento, conforme definido nas plataformas CMMI e MPS-BR (melhoria do processo de
software brasileiro).
 
O software pode ser medido aplicando-se testes na documentação gerada em cada fase do ciclo de vida. São
chamados testes de verificação.
 
Além disso, existem outras técnicas de medição, como a Análise de Pontos deFunção - APF, usada para a
medição de projetos de software, seguindo alguns parâmetros de medida de tamanho, em pontos de função -
PF, considerando a funcionalidade implementada, sob o ponto de vista do usuário.
Verificando o aprendizado
Questão 1
O teste do software deve acontecer: (assinale a única opção correta).
A No início do processo de desenvolvimento.
B No final do processo de desenvolvimento.
C No meio do processo de desenvolvimento.
D No início e no final do processo de desenvolvimento.
E Em todo o processo de desenvolvimento.
A alternativa E está correta.
A garantia de qualidade de software (Software Quality Assurance) não é algo com que começamos a nos
preocupar depois que o código foi gerado, e sim, ao longo de todo o processo de engenharia de software.
Questão 2
Com relação ao tamanho e complexidade de software, assinale a opção correta, considerando tais
características nos anos 1960, 1980 e 2000.
A Em 1980, o tamanho era pequeno e a complexidade alta.
B Em 1960, o tamanho era mínimo e, em 1980, a complexidade era relativa.
C Em 1960, o tamanho era mínimo e, em 2000, a complexidade era média.
D Em 1980, a complexidade era média e, em 2000, a complexidade era alta.
E Em 1960, o tamanho era mínimo e, em 2000, o tamanho é o mesmo.
A alternativa D está correta.
No cenário atual do desenvolvimento de softwares, o conceito de teste ganha complexidade, pois o risco
de os softwares não funcionarem a contento cresce de forma exponencial.
Myers concluiu que zero-defeito é algo inatingível, ou seja, pela complexidade envolvida e pelo número
altíssimo de situações existentes, torna-se impossível imaginar um produto de software “livre de erros”.
Sempre existirão erros a serem descobertos.
Questão 3
O que estabelece a regra de 10 de Myers?
A Quanto mais tardiamente descobrimos os erros, mais caros eles ficam.
B Os testes tornam-se mais complexos, pois os riscos de os softwares não funcionarem a contento
cresce de forma exponencial.
C Não existe garantia de que a solução tecnológica contratada será entregue no prazo e nos custos
negociados.
D A partir de processos uniformes e consistentes, a tendência é que o produto final gerado, ou seja, o
software seja eficiente.
E Todas as decisões tomadas durante o processo de desenvolvimento do software podem comprometer
a sua qualidade final.
A alternativa D está correta.
Por volta de 1979, Myers produziu um dos primeiros trabalhos mais completos e profundos sobre um
processo de teste de software. Myers é o autor do livro The Art of Software Testing (Glenford J. Myers,
Corey Sandler, Tom Badgett), considerado por muitos a primeira obra de real valor sobre teste de software
e a criadora de termos muito usados como “caixa branca”, caixa preta" e "caso de teste".
Questão 4
Podemos conceituar qualidade de software como:
AUm processo sistemático que focaliza todas as etapas e artefatos gerados com o objetivo de garantir a
conformidade e uniformidade de processos e produtos, prevenindo e eliminado defeitos.
B Um processo que foca em todos os produtos de software gerados pela equipe de desenvolvimento.
C Um processo que demonstra que algo funciona corretamente.
D Um processo para provar que determinadas funções fazem o que devem fazer.
E Um processo para demonstrar que os defeitos não estão presentes.
A alternativa A está correta.
O conceito de teste ganha complexidade, pois os riscos de os softwares não funcionarem a contento
cresce de forma exponencial. Ainda assim, poucas empresas percebem que a implantação de um processo
de garantia de qualidade de software é uma questão de estratégia de sobrevivência em um mercado cada
vez mais exigente e competitivo.
Teste é o processo de demonstrar que os defeitos não estão presentes, que algo funciona corretamente e
que determinadas funções fazem o que devem fazer.
Seu objetivo real é mostrar que um software está de acordo com suas especificações e que ele atende às
expectativas do cliente.
Questão 5
Myers concluiu que “zero defeito” é algo inatingível, porém a qualidade de software trabalha com o conceito
de zero defeito. O que isto quer dizer?
Chave de resposta
Representa a não tolerância a erros. O objetivo da qualidade é definir um processo que contenha
mecanismos de inibição de defeitos, impedimento de que falhas sejam criadas e propagadas para as fases
seguintes.
2. Principais Conceitos do processo de teste de software
O que é testar?
O teste de software visa garantir a qualidade, minimizando as incertezas e sistematizando os critérios de
aceitação. Por meio dele, pode-se avaliar se o software está fazendo o que deveria fazer, de acordo com os
seus requisitos, e se não está fazendo o que não deveria fazer.
 
Ele ajuda a validar se:
 
As expectativas de todas as pessoas envolvidas estão sendo atendidas (e se estão alinhadas);
 
O software apresenta um bom funcionamento (parte disso está relacionada às expectativas implícitas –
aquilo que é inerente ao produto).
 
Algumas definições:
• 
• 
"Teste é uma parte inevitável de qualquer esforço necessário para desenvolver um sistema de software."
Howden, 1987.
"O teste de software é um conjunto de atividades que podem ser planejadas com antecedência e
executadas sistematicamente."
PRESSMAN, 1985.
"Qualquer atividade que, a partir da avaliação de um atributo ou capacidade de um programa ou sistema,
seja possível determinar se alcança os resultados desejados."
Hetzel, 1988.
"Processo de executar um programa ou sistema com a intenção de encontrar defeitos."
Myers, 1979.
Assista ao vídeo e aprenda sobre teste de software.
Conteúdo interativo
Acesse a versão digital para assistir ao vídeo.
O teste deve ser utilizado para confirmar a qualidade oriunda de aplicação de um processo de
Engenharia de Software. 
Estratégia de teste
Por que precisamos de uma estratégia de teste de software? O que ela deve incorporar? Essas perguntas são
facilmente respondidas assim:
 
A Engenharia de Software nos auxilia em muitas situações. Uma delas é a atividade de teste, que é um passo
do processo de que visa encontrar ou corrigir erros durante toda a construção do software.
 
Devemos incorporar dois tipos de testes:
Teste de baixo nível
Utilizado para verificar um pequeno fragmento
de código-fonte. Nesse caso, saberemos se ele
foi implementado corretamente.
Teste de alto nível
Tem a característica de validar as principais
funções do sistema com base nos requisitos
definidos pelo cliente.
Os testes podem ser usados para descobrir a presença de erros nos softwares, mas infelizmente
não mostram a sua ausência. 
Assim, conseguimos chegar à conclusão que “o teste de software é o processo de executar o software de
uma maneira controlada, com o objetivo de descobrir diferenças entre o comportamento previsto e o
comportamento observado”.
Processo de teste de software
Não podemos ter um teste de software sem uma metodologia que seja favorável a esse processo de
desenvolvimento, utilizando pessoal técnico qualificado, ambiente e, quando possível, todas as ferramentas
adequadas.
 
O documento básico para organizar a atividade de testar, aplicada no contexto da empresa, tem que ser uma
metodologia de teste.
 
Tanto o processo de desenvolvimento de software quanto o teste de software tem um ciclo de vida. Vejamos
a seguir um exemplo de ciclo de vida para teste de software e a especificação de cada um deles.
Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
Ciclo de vida para teste de software.
Fases iniciais
Planejamento: é a parte inicial. Sem planejamento, não se deve realizar o teste. Nesta fase, é feita a
elaboração e revisão da estratégia de teste e do plano de teste;
 
Preparação: paralelamente ao planejamento, precisamos fazer a preparação do ambiente de teste. Para tanto,
precisamos incluir equipamentos, rede, pessoal, software e ferramentas.
Fases internas do ciclo
Procedimentos iniciais: é nesta fase que efetivamente se faz a elaboração do documento. Nela,estabelece-se
um acordo entre as partes envolvidas no projeto de teste (as partes envolvidas são usuários e técnicos). Esse
acordo deve conter:
 
Objetivo do projeto de teste;
 
Pessoal a ser envolvido;
 
As responsabilidades de cada um;
 
O plano preliminar de trabalho;
 
A avaliação dos riscos;
 
Os níveis de serviços acordados.
 
Especificação: nessa fase, realizamos a elaboração e revisão dos seguintes itens: casos de teste, scripts (para
o caso de ferramentas de automação de testes), roteiros de teste e execução dos testes de verificação da
documentação do sistema (testes estáticos).
 
• 
• 
• 
• 
• 
• 
Execução: aqui executamos os testes planejados conforme os casos de teste; scripts; roteiros de teste com os
correspondentes registros dos resultados obtidos.
 
Entrega: chegamos à última fase do processo. É aqui que fazemos a entrega do sistema para o ambiente de
produção.
Testes estáticos
São testes realizados pela análise do código fonte. O tipo de análise é visual, podendo haver um
questionário para acompanhar os testes, inspecionando o código desenvolvido pela equipe de
programação.
Como se dá a interação entre os ciclos de vida?
No nosso exemplo, ficaria assim:
Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
Interação entre os ciclos de vida.
1. Teste das unidades individuais de programa.
2. Testes destinados a facilitar a integração de unidades.
3. Testes que usam o sistema concluído.
 
Vejamos algumas estratégias de teste.
Teste de verificação
Deve garantir a qualidade de todas as etapas do desenvolvimento de sistemas. Nesta etapa, são realizadas
inspeções (auditorias com foco nas atividades) e revisões (com foco nas documentações) sobre os produtos
gerados.
Testes unitários
Cada programa ou componente é testado isoladamente para testar sua resposta aos requisitos definidos.
Esses testes são realizados no estágio mais baixo da escala de testes e são aplicados nas menores 
componentes de códigos criados.
Componentes de códigos criados
Componentes são pedaços de código, módulos, aplicações distintas ou ainda clientes servidores.
Assim, é possível garantir que estes atendam às especificações, tanto de garantia quanto de funcionalidade.
 
Por terem que verificar o funcionamento de um pedaço do sistema ou software isoladamente, normalmente
são feitos pelos desenvolvedores.
Testes de integração
Os programas e componentes são integrados pouco a pouco para testar suas interfaces. São executados em
uma combinação de componentes para verificar se eles funcionam corretamente juntos, conforme foram
especificados, e também normalmente podem ser feitos pelos desenvolvedores.
Testes de sistema
Nesse momento, todos os programas e componentes estão totalmente integrados, formando um sistema.
Esses testes visam à execução do sistema como um todo ou um subsistema (parte de um sistema), dentro de
um ambiente operacional controlado, o mais próximo possível do ambiente de produção, para validar a
exatidão e perfeição na execução de suas funções.
 
Nesta fase, o teste deve simular a operação normal do sistema, pois serão testadas todas as suas funções da
forma mais próxima possível do que irá ocorrer no ambiente de produção. Esses testes são de
responsabilidade e feitos pela equipe de teste de software.
Teste de aceitação
O ambiente é o mesmo ou muito semelhante ao utilizado nos testes de sistema. São os testes finais de
execução do sistema, realizados pelos usuários.
 
Nesses testes é verificado se a solução atende aos objetivos do negócio e aos seus requisitos definidos
inicialmente, no que diz respeito à funcionalidade e dentro da característica de usabilidade, preocupando-se
também com a interação humano/ computador, antes da sua utilização no ambiente de produção.
 
Assista o vídeo e conheça as estratégias de testes de software.
Conteúdo interativo
Acesse a versão digital para assistir ao vídeo.
Quando a organização trata os testes como um processo bem estruturado e muitas vezes paralelo e integrado
ao processo de desenvolvimento, os custos de manutenção com certeza são reduzidos.
Atenção
É importante lembrar que, segundo Myers, o custo de correção de defeitos tende a aumentar quanto
mais tarde o defeito é detectado. Defeitos encontrados durante a produção tendem a custar muito mais
que defeitos encontrados em modelos de dados e em outros documentos do projeto do software. 
Quais os benefícios que cada um desses testes pode trazer?
Testes
unitários Podem remover entre 30% e 50% dos defeitos dos programas.
Testes de
sistemas
Podem remover entre 30% e 50% dos defeitos remanescentes, mas mesmo
assim, os sistemas podem ir para a produção ainda com aproximadamente
49% de defeitos.
Revisões de
códigos Podem reduzir entre 20% e 30% desses defeitos.
Tabela. Benefícios dos testes.
Carlos Alberto de Farias. 
Princípios de teste de software
Pensando no teste como parte fundamental do ciclo de vida de um software, vamos mostrar os sete princípios
fundamentais que envolvem o processo de teste que devem servir como um guia geral, tanto para testadores
quanto para desenvolvedores.
 
Veremos mais adiante que ambos participam efetivamente do processo de amadurecimento do sistema.
Princípios de teste de software
1º Princípio: teste demonstra a presença de defeitos
Os testes conseguem identificar a existência de falhas, mas não podem garantir a ausência delas.
Mesmo se nenhum erro for identificado em uma bateria de testes, não é possível afirmar que o software está
livre de falhas.
2º Princípio: teste exaustivo é impossível
Deve-se calcular o esforço dos testes baseando-se nos riscos e prioridades.
3º Princípio: teste antecipado
Ao desenvolver um software, as atividades de teste devem começar o mais cedo possível no ciclo de vida do
desenvolvimento do software. Assim diminuímos o custo das correções e possibilitamos que erros de design,
requisitos e arquitetura sejam encontrados no momento ideal.
 
Logo que os requisitos ou modelagem do sistema estiverem prontos, é possível começar o trabalho de
modelagem do plano de testes.
Quanto antes uma falha for identificada no ciclo de vida de um sistema, mais barata e mais simples
será a correção.
4º Princípio: agrupamento de defeitos
A maioria das falhas encontradas durante a execução dos testes está concentrada em um número pequeno de
módulos. Sempre existe uma área do software que é responsável pelo maior número de erros.
5º Princípio: paradoxo do pesticida
Um conjunto de testes, se executado várias vezes, pode não mais detectar novas falhas. Para contornar esse
problema, os casos de teste devem ser frequentemente revisados e atualizados.
 
Eles devem ser reformulados para abordar novas áreas do sistema e assim aumentar a chance de detectar
novas falhas.
Os testes precisam ser revisitados com frequência.
6º Princípio: teste é dependente do contexto
Diferentes tipos de aplicações exigem a aplicação de técnicas diferentes de teste.
 
Por exemplo: um sistema bancário deve ser testado de maneira diferente de uma rede social. Há questões de
segurança que devem ser mais precisamente abordadas no primeiro caso. 
 
Da mesma forma, testes web são elaborados com foco diferente dos testes de aplicações desktop.
7º Princípio: a ilusão da ausência de defeitos
Identificar e corrigir os problemas de um software não garante que ele está pronto.
 
Questões a serem respondidas:
 
Os testes foram elaborados para identificar todas as possíveis falhas?
 
O sistema atende às necessidades e expectativas dos usuários?
Ou seja, existem outros fatores que devem ser considerados para garantir a qualidade do sistema.
Não adianta o sistema ser correto funcionalmente, mas não atender à real necessidade do usuário.
Todos os princípios são importantes, porém entre os princípios listados, podemos citar que os números 3 e 7
representam os principais aspectos da atividade de teste.
A busca por antecipar cada vez mais as possíveis falhas da aplicação e assegurar que osistema entregue
atenda as reais necessidades do cliente, agregando valor ao seu negócio, é constante.
• 
• 
Características das estratégias de teste
Para executar um teste eficaz, devem-se proceder revisões técnicas eficazes. Isto é
necessário porque assim muitos erros são eliminados antes do começo do teste;
É importante que se usem diferentes técnicas de teste para diferentes abordagens e em
diferentes momentos;
O teste deve ser feito pelo desenvolvedor e por um grupo independente de teste (se for um
grande projeto);
Saiba que tanto o teste quanto a depuração são atividades diferentes, mas a depuração só
acontece em consequência da existência de um teste.
Com a atividade de teste, conseguimos executar um programa com a intenção principal de descobrir
um erro.
Para que um caso de teste seja considerado bom ou ótimo, ou seja, bem-sucedido, ele deve ter uma
grande probabilidade de revelar um erro ainda não descoberto.
Diretrizes que devem ser levadas em conta para o teste
Quando o teste deve ser interrompido? - Deve ser determinado no planejamento;
Atribuir a responsabilidade do teste a um testador? - Deve ser atribuído também no
planejamento;
Quais os resultados esperados para cada caso de teste? - Devem ser descritos
antecipadamente;
Quais os resultados esperados para cada caso de teste? - Devem ser descritos
antecipadamente;
Qual o resultado de cada teste por completo? - Cada um deles deve ser inspecionado depois
de testado;
Quais programadores devem ser alocados para o teste? - Sempre os mais criativos.
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
A importância dos testes
O processo de
desenvolvimento
de sistemas
(PDS) requer
uma série de
atividades em
que as
oportunidades
de inserção de
falhas são muito
grandes.
 Se os objetivos foram
especificados
erradamente, os erros
podem começar a
aparecer logo no
início do processo,
podendo também
aparecer erros em
fases de projeto e
desenvolvimento
posteriores.
 Como as informações
para o projeto são
determinadas pelo
usuário/cliente, e o
desenvolvimento é feito
por técnicos
especializados
(programadores,
analistas, gerentes etc.),
muitas vezes pode haver
falhas na comunicação.
 Assista
ao vídeo
e
conheça
os
papéis
no teste
de
software.
Conteúdo interativo
Acesse a versão digital para assistir ao vídeo.
Nesse momento, é importante que o desenvolvimento seja acompanhado de garantia de qualidade, em função
de não haver essa habilidade de realizar e de se comunicar com perfeição.
 
Vemos então que a atividade de teste de software passa a ser um elemento crítico da garantia de qualidade.
Esta passa a ser a última revisão de especificação, projeto e codificação.
Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
Relação entre o custo do software e as fases do desenvolvimento.
Exemplo - Projetos de controle de voo
Como vimos, é possível que os gastos fiquem entre 30% e 40% do esforço total do projeto no teste de
software.
 
Considere, por exemplo, os projetos de controle de voo, monitoramento de reatores nucleares etc. 
 
Esses projetos são considerados críticos para testes, pois sua falha pode resultar em significativos prejuízos
econômicos, humanos ou ambientais, e por isso podem custar de três a cinco vezes mais do que todos os
outros passos de engenharia de software combinados.
Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
Relação ente o tempo e o índice de falhas.
Devem-se utilizar as principais estratégias de teste de software, de forma a promover uma abordagem de
teste personalizada e de diferentes níveis, visando atingir todas as fases do ciclo de desenvolvimento do
software.
 
O uso de uma equipe independente no processo de teste de software cria um ambiente de teste e torna a
aplicação de teste unitário pelo desenvolvedor.
A aplicação de estratégias que integrem técnicas de projeto de casos de teste, numa série bem definida de
passos, produz um mapa que descreve os passos a serem dados como parte da atividade de teste.
 
Essa estratégia deve incorporar o planejamento de teste, o projeto de casos de testes, a execução e a
resultante coleta e avaliação.
 
Deve-se também responder às seguintes perguntas:
Como conduzir os testes de software?
 
Devemos estabelecer um plano formal para os testes?
 
Devemos testar o programa como um todo ou executar testes somente em uma parte dele
 
Devemos refazer os testes quando acrescentamos novos componentes ao sistema
 
Quando devemos envolver o cliente?
Quando terminar os testes?
• 
• 
• 
• 
• 
Em geral, os testes devem ser terminados quando a maioria das necessidades é atendida, permanecendo
poucos erros importantes. Pode-se alguma vez ter certeza de que não existem mais falhas?
Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
Relação entre o número de falhas encontradas e a possibilidade de existirem mais
falhas.
Quando o teste é terminado, como saber se ele foi suficiente?
 
Não há uma resposta única.
 
Algumas respostas pragmáticas:
 
Você jamais terá completado a atividade de teste;
 
A carga simplesmente transfere-se do projetista para o cliente;
 
O teste para quando não há mais erros “visíveis”;
 
O teste acaba quando o tempo acaba ou o dinheiro acaba:
 
Por restrição de tempo (nesse caso, deve-se negociar esse tempo);
 
Por restrição financeira (nesse caso, deve-se evitar).
 
A atividade de teste jamais termina. Ela passa do projetista para o usuário.
• 
• 
• 
• 
• 
 
Então, quando terminar o teste?
 
Basta pensar que:
 
O objetivo do teste é encontrar erros, e se eles não forem detectados, o teste não pode afirmar sua
ausência;
 
Testar tudo é impossível;
 
As técnicas de teste são complementares, devendo ser aplicadas em conjunto.
 
Para testar com eficiência, é preciso conhecer bem o software.
Papéis e responsabilidades de teste de software
Vamos ver dois grupos:
Desenvolvedor
É sempre responsável por testar unidades individuais (componentes). Em muitos casos, também
conduz testes de integração, um passo que leva à construção (e teste) da arquitetura completa do
software.
Grupo independente de teste (independent group test – ITG)
Normalmente, para que o processo de teste transcorra de forma íntegra, é comum a utilização de um
grupo independente de teste, já que as pessoas que criaram o software não devem ser as mesmas
que irão realizar os testes.
Seria um conflito de interesses, pois foram elas que o “criaram”. Eles se envolvem no projeto após a
arquitetura do software estar completada.
O engenheiro de software e o ITG trabalham juntos para garantir a execução de testes rigorosos. Existem
testes que somente serão conduzidos pelos desenvolvedores, como o teste de unidade, que iremos estudar
mais adiante.
 
O desenvolvedor deve estar disponível para corrigir eventuais erros descobertos.
• 
• 
• 
"O primeiro erro que o pessoal comete é pensar que a equipe de teste é responsável pela garantia de
qualidade."
Bryan Marich.
Existem várias responsabilidades e papéis dentro da equipe. Confira na tabela a seguir.
Gerente de
teste
Gerente de vários projetos de teste ou responsável pela área de teste da
empresa
Líder do
projeto de
testes
Responsável pela liderança de um projeto de teste, geralmente
relacionado a um sistema em desenvolvimento, seja um projeto novo ou
manutenção.
Arquiteto
Responsável pela montagem da infraestrutura de teste, monta o ambiente
de teste, escolhe as ferramentas e capacita a equipe para executar seu
trabalho nesse ambiente.
Analista do
teste
Responsável pela modelagem e elaboração dos casos de teste e pelos
scripts. Em alguns casos, estes podem ser elaborados pelos testadores.
Testador Responsável pela execução dos casos de teste e scripts.
Tabela. Papéis e responsabilidades da equipe.
Carlos Alberto de Farias. 
Verificando o aprendizado
Questão 1
Assinale a única alternativa correta.
 
O que é necessário para obter resultados positivos emum projeto de testes?
 
I. Que o projeto se inicie desde a especificação dos requisitos do sistema a ser implementado.
 
II. Que o projeto se inicie quando a programação estiver sendo desenvolvida.
 
III. Que o projeto se inicie quando a programação estiver sendo desenvolvida.
A Apenas o item I está correto.
B Apenas o item II está correto.
C Apenas o item III está correto.
D Apenas os itens I e II estão corretos.
E Apenas os itens II e III estão corretos.
A alternativa A está correta.
Para obter resultados positivos em um projeto de testes, é necessário que ele se inicie desde a
especificação dos requisitos do sistema a ser implementado, ou seja, tão logo comece o projeto de
desenvolvimento do software, inicia-se também em conjunto o projeto de testes de software.
Questão 2
Assinale a única alternativa correta.
 
O processo de testes de software representa uma estrutura das etapas, atividades, artefatos, papéis e
responsabilidades. Sendo assim, o que busca esse processo?
 
I. Padronizar os trabalhos para um melhor controle dos projetos de testes.
 
II. Minimizar os riscos causados por defeitos provenientes do processo de desenvolvimento, assim como a
redução de custos de correção de defeitos.
 
III. Redução de custos de correção de defeitos.
A Apenas os itens I e II estão corretos.
B Apenas os itens II e III estão corretos.
C Apenas o item II está correto.
D Apenas o item III está correto.
E Todos os itens estão corretos.
A alternativa E está correta.
O processo de testes de software representa uma estrutura das etapas, atividades, artefatos, papéis e
responsabilidades, buscando padronizar os trabalhos para um melhor controle dos projetos de testes.
O objetivo desse processo (com metodologia própria, ciclo de vida etc.) é minimizar os riscos causados por
defeitos provenientes do processo de desenvolvimento, assim como a redução de custos de correção de
defeitos, pois o custo do software (desenvolvimento + manutenção) tende a ser menor quando ele é bem
testado.
Questão 3
Como a equipe de teste deve ser formada?
A Apenas com os clientes e seus usuários.
B Apenas com uma equipe de testes independentes.
C Apenas com os desenvolvedores dos programas.
D Apenas com uma equipe de teste independente e os desenvolvedores.
E Apenas com os usuários e os desenvolvedores.
A alternativa D está correta.
Por conta da definição de teste, é importante ressaltar que a equipe deve ser “o mais independente
possível da equipe de desenvolvimento”, de forma a não estar envolvida emocionalmente nem
politicamente com o projeto, tendo um comportamento mais objetivo e direto.
Essa equipe terá mais facilidade em focar nos pontos que inicialmente o projeto deveria atender e por
motivos desconhecidos foram abandonados ou não atendidos corretamente.
Questão 4
Quando devemos terminar os testes?
 
I. Nunca; o projetista está sempre testando.
 
II. Quando o dinheiro ou o tempo acabar.
 
III. O teste termina quando não há mais erros.
 
Assinale a única alternativa correta:
A Apenas os itens I e II estão corretos.
B Apenas os itens II e III estão corretos.
C Apenas o item II está correto.
D Apenas o item III está correto.
E Todos os itens estão corretos.
A alternativa C está correta.
Você jamais terá completado a atividade de teste. A carga simplesmente transfere-se do projetista para o
cliente. O teste para quando não há mais erros “visíveis”, quando o tempo ou o dinheiro acaba:
Por restrição de tempo (neste caso, deve-se negociar esse tempo);
Por restrição financeira (nesse caso, deve-se evitar).
• 
• 
3. Ciclo de vida do processo de testes de software
Modelo V
Você se lembra do modelo cascata no processo de desenvolvimento de software? O modelo V é uma melhoria
do cascata do desenvolvimento de produto, pois esse modelo tinha um problema de reatividade.
 
Ele permite que, durante a integração de um sistema, os testes sejam feitos contra os próprios requisitos do
componente ou interface que está sendo testado, em contraste com modelos anteriores, nos quais o
componente era testado contra a especificação do componente/ interface.
 
Nesse modelo, cada etapa deve ser concluída antes que a próxima inicie, e o teste é planejado em paralelo
com a atividade correspondente no desenvolvimento, ou seja, o modelo considera o teste como uma atividade
paralela, e não como uma atividade isolada que ocorre no final do desenvolvimento.
Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
Como o modelo V se configura? Vejamos uma representação simples na imagem a seguir.
Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
Representação do modelo V.
Em muitos casos, as organizações criam seus próprios modelos usando isso como base. Contudo, o modelo
pode se tornar tão complexo quanto você quiser.
 
É importante ressaltar que devemos utilizar esse modelo para pequenos e médios projetos, com requisitos
bem definidos e profissionais experientes.
 
Os objetivos do modelo V são:
Minimizar os riscos do projeto;
 
Melhorar e garantir a qualidade do projeto;
 
Reduzir os custos totais ao longo do ciclo de vida do projeto;
 
Melhorar a comunicação entre as partes interessadas.
É um modelo mais robusto e completo do que o cascata, podendo produzir softwares de maior
qualidade do que com ele.
Esse modelo acrescenta duas partes importantes, que são:
Verificação
Que está relacionado com a questão:
O produto está sendo feito corretamente?
Validação
Está relacionado com a questão:
 
O produto está sendo feito, ou seja, o software
atende ao objetivo pretendido com precisão?
Assista ao vídeo e entenda sobre verificação e validação.
Conteúdo interativo
Acesse a versão digital para assistir ao vídeo.
No modelo V, podemos ver as mesmas fases do cascata, mas com uma melhor relação entre elas.
Vejamos as vantagens e desvantagens desse modelo.
• 
• 
• 
• 
Vantagens
• A relação entre os estágios de desenvolvimento e os diferentes tipos de testes facilita a localização
de falhas;
• É um modelo simples e fácil de aprender;
• Especifica os papéis dos diferentes tipos de testes para ser executada;
• Envolve o usuário no teste.
Desvantagens
• É difícil para o cliente expor explicitamente todos os requisitos;
• O cliente deve ter paciência, pois receberá o produto no fim do ciclo de vida;
• O teste pode ser caro e às vezes não ser suficientemente eficaz;
• O produto final pode não refletir todas as necessidades dos utilizadores.
Paralelismo entre as atividades de desenvolvimento e teste de software
Além do paralelismo entre as atividades, o teste
paralelo também serve para comparar os resultados
do teste do sistema atual com a versão anterior.
Essa comparação é importante para determinar se
os resultados do novo sistema são consistentes
com o processamento do antigo sistema ou da
antiga versão.
 Temos que
executar no teste
paralelo os
mesmos dados de
entrada utilizados
nas duas versões
da mesma
aplicação.
Exemplo
Se os requisitos não forem alterados na nova versão, os resultados com os dados de saída das duas
versões (atual e nova) devem ser iguais. 
Processo de teste
Com relação aos custos, ao tratar os testes como um processo organizado e muitas vezes paralelo e
integrado ao processo de desenvolvimento, os custos de manutenção ficarão bem reduzidos.
 
Segundo Myers, o custo de correção tende a aumentar quanto mais tarde o defeito for detectado.
"Defeitos encontrados durante a produção tendem a custar muito mais que aqueles encontrados em
modelos de dados e em outros documentos do projeto do software."
Atenção
Verificação da migração de dados Com relação aos dados, após o carregamento para o novo sistema, os
resultados são submetidos a uma etapa de verificação dos dados para determinar se estes foram
corretamente migrados, se ocorreu de forma completa. Durante essa verificação, pode ser necessário
um processo de execução em paralelo de ambos os sistemas para identificaráreas de disparidade e
evitar erros de perda de dados. 
Veja alguns processos de teste:
Teste de migração de dados
O paralelismo pode ser usado também pelas equipes de teste de aceitação e operacional, que irão
realizar o teste de concepção e execução em paralelo em duas plataformas completamente diferentes
e com objetivos e propósitos diferentes.
Já a equipe de teste de legado irá trabalhar com cada um dos outros grupos separadamente.
Equipe de teste operacional
É composta de usuários que irão utilizar o sistema. O grupo operacional realiza testes em paralelo
com a equipe de aceitação, mas com um objetivo completamente diferente.
Esse grupo trabalha na futura plataforma e no ambiente sob todos os aspectos que não sejam sob o
ponto de vista do negócio, ou seja, de conectividade e interoperabilidade.
Esse grupo também testa interfaces, desempenho, sistema de back-ups e demais elementos da nova
plataforma.
Simulação do novo sistema em substituição ao antigo
Nesta etapa do processo, deverá ser realizado um simulado do novo sistema em condições reais de
funcionamento em paralelo ao antigo sistema, para que o usuário gestor possa avaliar possíveis
necessidades de ajustes do fluxo operacional e computacional de forma a trazer benefícios com a
instalação do novo sistema.
Scripts estruturados ou scripts compartilhados
Esta técnica aciona mais de um comando, simulando a execução em paralelo de diversas ações.
Teste de unidade
O teste de unidade enfoca o esforço de verificação da menor unidade do projeto de software, que é o
módulo.
Usa-se como guia para a execução deste tipo de teste uma descrição detalhada do projeto.
Importantes caminhos de controle são testados para descobrir erros nas interfaces dos módulos.
O teste de unidade é do tipo caixa branca (veremos esse tipo de teste mais tarde). Pode ser
conduzido em paralelo para vários módulos.
Teste de validação
Os testes são baseados no comportamento do software por meio das mais diversas condições
baseadas e comparadas com as especificações levantadas pela área de negócio.
Durante o desenvolvimento do software, deverão ser aplicadas diferentes categorias de testes
empregando ferramentas, técnicas e abordagens diferentes.
As atividades de teste (conforme o modelo V, planejamento, modelagem, execução e conferência)
deverão ocorrer em paralelo às atividades de construção de componentes executáveis e respeitando
os estágios de desenvolvimento.
Verificação e validação
A atividade de teste de software é elemento de um tema mais amplo chamado verificação e validação.
Verificação
Refere-se ao conjunto de atividades que
garante que o software implemente
corretamente uma função específica.
Validação
Refere-se ao conjunto de atividades que
garante que o software que foi construído
segue as exigências do cliente.
A definição de verificação e validação abrange muitas das atividades às quais está diretamente ligada a
garantia da qualidade de software (SQA).
 
Vamos ver de outra forma o modelo V como um U.
Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
 Formato de "U".
Conteúdo interativo
Acesse a versão digital para ver mais detalhes da imagem
abaixo.
Representação do modelo U.
Os testes de verificação e validação são complementares, não devendo ser encarados como
atividades redundantes. Cada um possui natureza e objetivo distinto, fortalecendo desta forma o
processo de detecção de erros e aumentando a qualidade final do produto.
Testes de verificação e validação
Teste de verificação
• É a coleta de informações de negócios e o planejamento da arquitetura do software.
• A principal preocupação é o entendimento e a coerência entre o negócio a ser atendido e o software a ser
construído.
• Nesta fase não existem componentes tecnológicos, mas documentos que especificam o comportamento a
ser seguido pelo software a ser desenvolvido.
• É um processo de auditoria de atividades e avaliação de documentos gerados em todas as fases do
processo de desenvolvimento do software (PDS).
 
Esses testes não envolvem o processamento de softwares, pois eles ainda não nasceram.
 
Vejamos cada um dos processos de verificação:
 
Verificação dos negócios - seu objetivo é garantir que os diversos documentos produzidos tenham total
aderência às necessidades apontadas pelos clientes.
 
Verificação dos requisitos - seu objetivo é fazer a verificação das especificações do levantamento dos
requisitos:
 
 funcionais e 
Funcionais
Descrevem as funcionalidades do sistema. Estão diretamente ligados às especificações da tecnologia
envolvida, do perfil do usuário e do tipo do sistema. Ex.: O sistema deve permitir incluir e excluir
fornecedores. 
não funcionais do software a ser desenvolvido.
 
Verificação da implementação - seu objetivo é garantir a qualidade do código-fonte gerado pela equipe de
desenvolvimento.
 
Como se garante essa qualidade?
• Pela prática das regras da boa programação;
• Pelo processo formal de verificação do código produzido.
Não funcionais
Restrições sobre os serviços ou funções oferecidos pelo sistema. Ex.: A impressão do boleto deve ser
em no máximo 10 segundos. A consulta ao banco de dados financeiro não deve ultrapassar 3 segundos.
Teste de validação
É um processo formal de avaliação de produtos tecnológicos que podem ser aplicados em componentes
isolados, módulos existentes ou mesmo a totalidade do sistema.
 
Qual é o seu objetivo?
Avaliar a conformidade do software com os requisitos e especificações analisadas e revisadas nas etapas
iniciais do projeto.
 
Como ele se caracteriza?
Pela presença física do software e de seu processamento em um ambiente tecnicamente preparado.
 
Vejamos cada um dos processos de validação.
1. Validação de unidade - é a primeira etapa do processo de validação. Seu objetivo é testar os componentes
individuais de uma aplicação.
 
2. Validação da integração - é uma continuação natural dos testes unitários. Seu objetivo é validar a
compatibilidade entre componentes de um software.
• 
• 
 
3. Validação do sistema - seu objetivo é validar a solução como um todo. Quando este estágio é atingido, a
maior parte das falhas de funcionalidade deve ter sido detectada pelos testes unitários e pelos de
integrações.
 
4. Validação do aceite - é o último estágio do processo de validação, sendo o último processo formal de
detecção de erros no sistema, antes de sua disponibilização no ambiente de produção. Nessa etapa, o
software é disponibilizado para clientes e usuários com o objetivo que eles mesmos validarem todas as
funcionalidades requisitadas no início do projeto.
 
Exemplo de testes de validação:
 
Validação: testes que demonstram conformidade com os requisitos.
 
Plano de teste: descreve classes de testes + procedimento de teste + casos de teste.
 
Após a execução de cada caso de teste de validação ser conduzido:
1) Ou a característica testada está de acordo com a especificação – é aceita;
2) Ou descobre-se um desvio da especificação – lista de deficiências.
 
Objetivo: verificar o produto nas referências e padrões de usabilidade e de desempenho estabelecidos no
planejamento da qualidade.
 
O teste de validação verifica também a interação entre os componentes do produto, como por exemplo a
relação entre formulários e os bancos que recebem os dados coletados, o suporte e a ajuda oferecidos aos
usuários.
 
Assista ao vídeo e aprenda sobre classificação dos testes.
Conteúdo interativo
Acesse a versão digital para assistir ao vídeo.
Testes estáticos X testes dinâmicos
Falhas de software são uma constante para quem trabalha com desenvolvimento.
 
Falhas menores podem representar apenas pequenos problemas na execução de um sistema. Já em casos
mais graves, um bug ou vulnerabilidade pode levar à exposição de dados de usuários e informações privadas
de empresas.
 
• 
• 
Algumas divisões podem ser estabelecidas em relação ao teste de software. Uma delas corresponde à forma
de utilização do código obtido na etapafase eles devem ser realizados?
Por todos esses motivos, eles devem ser efetuados na fase de testes de aceitação.
Teste de segurança
O que devem ser validados nessa técnica? Precisamos validar os requisitos de segurança, visando
identificar as vulnerabilidades do sistema.
Seus objetivos são: prevenir ataques, detectar vulnerabilidades e preparar medidas de contingência
para casos de falhas.
É indicado durante as fases de testes de integração e de sistema.
Assista ao vídeo e aprenda sobre tipos de testes.
Conteúdo interativo
Acesse a versão digital para assistir ao vídeo.
Funcional
Testa os requisitos funcionais do software, as funções e os casos de uso. Responde a seguinte questão:
A aplicação faz o que deveria fazer?
Sendo um teste do tipo caixa preta, garante que os requisitos funcionem conforme o especificado.
 
Ele não se preocupa com a forma como foi implementado, ou seja, com o comportamento interno do sistema,
mas sim com a saída gerada após a entrada dos dados especificados.
 
Desta forma, indicamos essa técnica para detectar erros de interface, de comportamento e/ou de
desempenho.
 
Essa técnica também pode ser aplicada em todas as fases de testes (como vimos no modelo U: unidade,
integração, sistema e aceitação, que definiremos a seguir).
 
Uma dificuldade dessa técnica, por questões de tempo e recurso, é testar todas as entradas possíveis. São
inseridos alguns dados e espera-se na saída o resultado de como foram projetados os requisitos.
 
Essa técnica de teste é imprescindível durante o desenvolvimento de um sistema, porém, mostra-se
insuficiente para identificar certos riscos num projeto de software.
 
Os testes funcionais também são classificados conforme segue:
Requisitos
Serve para saber se o sistema é efetuado de acordo com suas especificações iniciais.
Regressão
Verifica se o sistema, ou alguma parte dele, foi afetado por alguma alteração efetuada nele.
Tratamento de erros
Utilizado para verificar se os possíveis erros que por ventura aconteçam têm tratamento antes de
acontecerem as derradeiras falhas.
Manual
Efetuado para verificar a interação entre homem e máquina.
Interfaces de integração
Utilizado para verificar se o sistema faz alguma troca de informações com algum outro sistema.
Controle
Muito utilizado para verificar se o sistema tem algum controle de dados, logs de auditoria e validações
e integridade.
Paralelismo
Importante para verificar se a versão atual e a antiga geram os mesmos resultados.
Fases de testes (validação)
É importante que o processo de teste esteja presente durante todo o desenvolvimento do software. Porém,
esses testes podem ser divididos em diferentes fases, as quais se diferenciam pela abstração e complexidade
dos testes produzidos e executados em cada uma delas.
 
Geralmente esse processo de teste é dividido em quatro fases, são elas:
Testes de unidade
Testa um componente isolado ou classe do sistema. Nesta fase, os esforços dos testes estão
concentrados nas menores unidades do software produzido.
O objetivo é detectar erros de lógica e/ou de implementação em pequenas partes do sistema,
independentemente do restante. Consequentemente, cada unidade do sistema é testada
isoladamente.
Isso contribui para assegurar a correção dos componentes individuais, “mas não garante que a
integração dessas partes funcione como o esperado”.
Exemplo: dividir (x int, y int ) = z int.
Caso tenhamos x=1 e y=0, z será um valor com erro e deverá retornar uma mensagem ao usuário,
avisando que a operação é inválida.
Caso a expressão seja um dado comum do sistema, para fazer essa validação a autorização deverá
ser do usuário, pois faz parte do conjunto de regras de negócio.
Testes de integração
Testa se um ou mais componentes combinados funcionam de maneira satisfatória. Pode-se dizer que
é composto por vários testes de unidade.
O ponto central dos testes está voltado para a detecção de falhas provenientes da integração interna
dos componentes do sistema. Para isso, os módulos são combinados e testados em conjunto.
Essa fase vem logo após os testes de unidade e antecede os testes de sistema, tendo como
resultado o sistema integrado e preparado para os testes.
Não faz parte do escopo dessa fase testar a interação do sistema produzido com outros sistemas,
que por ventura venham a se comunicar.
Testes de sistema
Objetivo dos testes de sistema:
Realizar a execução do sistema como um todo, dentro de um ambiente operacional controlado, para
validar a perfeição e requinte na execução de suas funções, acompanhando cenários sistêmicos
elaborados pelo profissional de requisitos do projeto. Devem retratar os requisitos funcionais e não
funcionais do sistema;
Este tipo de teste é realizado por uma equipe de teste independente, e o analista de teste elabora os
casos de testes, normalmente em conjunto com os desenvolvedores e atuando em um ambiente
controlado, no caso o ambiente de teste;
O comportamento de todo o sistema/ produto é definido pelo escopo de um projeto ou programa de
desenvolvimento;
O ambiente de teste deve corresponder o máximo possível ao objetivo final, ou ao ambiente de
produção.
Esta é a fase na qual o software já está completamente integrado. Assim sendo, os testes apontam
falhas em relação aos requisitos do sistema, no que diz respeito à comunicação com outros sistemas.
Os testes são realizados em condições bastante semelhantes (de ambiente, massa de dados etc.)
com as que o usuário utilizará em produção.
Os testes de sistema não se limitam aos requisitos funcionais, mas também objetivam testar os
requisitos não funcionais.
Testes de aceitação
Os testes de aceitação são, em geral, uma extensão dos testes de sistema. Nessa fase, o objetivo é
verificar se o software está pronto e pode ser usado pelo usuário final.
Para isso, verifica-se se o sistema realiza as funções para as quais foi criado, satisfazendo as
necessidades do cliente.
Os testes são planejados e projetados com o mesmo cuidado e nível de detalhe do teste do sistema.
Durante essa fase, os critérios de aceitação são conhecidos, o que permite a automação dos testes
de aceitação, além da monitoração e medição.
Verificando o aprendizado
Questão 1
Um processo de desenvolvimento de software em geral tem como entrada os requisitos do sistema e como
saída um produto fornecido. Analise as afirmativas sobre este tema:
 
I. O desenvolvimento de software envolve os estágios: análise e definição de requisitos, projeto do sistema,
codificação, testes e entrega do sistema. Assim, o ciclo de vida do software descreve a vida do produto de
software desde sua concepção até a implementação e entrega.
 
II. Um dos primeiros modelos propostos foi o cascata, no qual o desenvolvimento de um estágio deve terminar
antes do próximo começar. O modelo V é uma variação do cascata, que mostra como as atividades de teste
estão relacionadas com a análise e com o projeto.
 
III. O modelo cascata pode ser incrementado com atividades de prototipação, que é um modelo de processo
efetivo em que partes do sistema são construídas rapidamente com o objetivo de validar os requisitos. Caso
novas alternativas sejam discutidas, deve-se começar o ciclo em cascata novamente, abandonando-se o
protótipo.
 
Assinale a única alternativa correta:
A Apenas os itens I e II estão corretos.
B Apenas os itens II e III estão corretos.
C Apenas o item I está correto.
D Apenas o item II está correto.
E Apenas o item III está correto.
A alternativa D está correta.
Feedback:
A afirmativa II está correta ao descrever com precisão o modelo cascata e sua variação em V. Já os itens I e
III contêm imprecisões sobre o ciclo de vida do software e o uso do protótipo, que não precisa ser
descartado ao reiniciar o ciclo.
Questão 2
A utilização do modelo V minimiza os custos da qualidade do software; assim, segundo a regra de 10 de
Myers, os testes devem ser iniciados nas inspeções/ revisões de código até os testes de software. Identifique
se essa afirmação está certa ou errada.
Chave deConteúdo interativo
	Verificação
	Validação
	Conteúdo interativo
	Vantagens
	Desvantagens
	Paralelismo entre as atividades de desenvolvimento e teste de software
	Exemplo
	Processo de teste
	Atenção
	Teste de migração de dados
	Teste de unidade
	Teste de validação
	Verificação e validação
	Verificação
	Validação
	Conteúdo interativo
	Conteúdo interativo
	Testes de verificação e validação
	Teste de verificação
	Teste de validação
	Conteúdo interativo
	Testes estáticos X testes dinâmicos
	Testes estáticos e dinâmicos
	Testes estáticos
	Testes dinâmicos
	Exemplo
	Técnicas de teste
	Reflexão
	Teste estrutural X testes funcionais
	Estrutural
	Teste estrutural (caixa branca)
	Teste de regressão
	Teste de carga
	Teste de estresse
	Teste de usabilidade
	Teste de segurança
	Conteúdo interativo
	Funcional
	Requisitos
	Regressão
	Tratamento de erros
	Manual
	Interfaces de integração
	Controle
	Paralelismo
	Fases de testes (validação)
	Testes de unidade
	Testes de integração
	Testes de sistema
	Testes de aceitação
	Verificando o aprendizado
	4. Conclusão
	Considerações finais
	Explore +
	Referências