Teste de Software

Prévia do material em texto

SISTEMAS DE
 INFORMAÇÕES 
 GERENCIAIS
www.esab.edu.br 3
Sumário
1. Apresentação I.......................................................................08
2. Introdução – Organização do Conteúdo – Conceitos de Teste I 
– Testes Estáticos x Testes Dinâmicos – Testes Funcionais 
(Caixa-preta) x Estruturais (Caixa-branca) – Conceitos de 
Testes Níveis de Testes - As integrações podem ser do tipo 
Big-Bang ou incremental - II..................................................09
3. Técnicas de Testes - Custos de Testar; da Correção e o Retorno 
de Investimento em Testes - Custo da Correção - Retorno de 
Investimento - Custos das Falhas.........................................20
4. Erros em Escalas da GOL - Autodestruição do Foguete Ariane 
501 - Destruição da Sonda da NASA Mars Climate Orbiter - O 
Processo de Teste – O Modelo V – Planejamento dos Testes ..
...............................................................................................30
5. Análise dos Riscos – Término dos Testes – Ambiente de Testes 
– Massa de Dados – Ferramentas.............................................42
6. A Equipe e os Papéis nos Testes – Abordagens para Montar a 
Equipe - Papéis no Processo de Teste - Certificações para 
Profissionais de Testes - Técnicas Estáticas - Revisão e 
Inspeção................................................................................53
7. Resumo I................................................................................62
8. Apresentação II......................................................................63
9. Casos de Teste – Conteúdo do Caso de Teste – Características 
e Potenciais Problemas – Execução dos Testes – Testes 
Orientados a Dados (DDT – Data Driven Test) – Automatização 
dos Testes..............................................................................64
10. Gestão de Testes – Ferramenta TestLink – Gestão de Defeitos 
(Conceito de Erro, Defeito e Falha) – Gestão de Defeitos 
(Resolução do Defeito)...........................................................73
www.esab.edu.br 4
11. Gestão de Defeitos – Ferramenta Mantis – Gestão de Defeitos 
– Ferramenta Mantis (Continuação).......................................81
12. Cobertura de Código – Ferramenta EclEMMA – Testes de 
Unidade e Integração – Ferramenta Junit – Localização das 
Classes de Teste ................................................................89
13. Testes com Objetos Substitutos ou Falsificados (Mock Objects) 
– Ferramenta Mockito – Ferramenta Mockito – Ferramenta 
Mockito (Continuação) .............................. .........................101
14. Resumo II.............................................................................109
15. Apresentação III...................................................................110
16. Desenvolvimento Orientado a Testes (TDD - Test Driven 
Devlopment) - Exemplo de TDD na Prática........................111
17. SELENIUN - Ferramenta para Gravar/Executar Testes em 
Browsers I - Ferramenta para Gravar/Executar Testes em 
Browsers II - Ferramenta para Gravar/Executar Testes em 
Browsers III..........................................................................122
18. SELENIUN - Teste de Performance e Estresse - Ferramenta 
JMeter...................................................................................135
19. Integração Contínua - Controle de Versão de Código - Integração 
Contínua - Ferramenta Jenkins I..........................................145
20. Integração Contínua - Ferramenta Jenkins II .......................
.............................................................................................153
21. Resumo III............................................................................159
22. Glossário..............................................................................163
23. Bibliografia..........................................................................165
www.esab.edu.br 5
Palavras do Tutor
Sobre o autor
•	 Professor e Consultor de Tecnologia de Informação. 
•	 Doutorando (ITA) e Mestre (IPT) em Engenharia de 
Computação, Pós-Graduado em Análise de Sistemas 
(Mackenzie), Administração (Luzwell-SP), e Reengenharia 
(FGVSP). Graduado/Licenciado em Matemática. 
•	 Professor e Pesquisador da Universidade Anhembi Morumbi, 
UNIBAN, e ESAB (Ensino a Distância). Autor de livros em 
Conectividade Empresarial. Prêmio em ELearning no Ensino 
Superior (ABED/Blackboard).
•	 Consultor de T.I. em grandes empresas como Sebrae, 
Senac, Granero, Transvalor, etc. Viagens internacionais: 
EUA, França, Inglaterra, Itália, Portugal, Espanha, etc. 
Apresentação
O software passou a ser peça chave na competitividade de muitas 
empresas, fazendo com que suas falhas provocassem diversos 
tipos de prejuízos. Nesse cenário, para garantir a qualidade dos 
softwares, a área de teste vem ganhando cada vez mais importância 
e notoriedade. Para obter a atenção necessária, os testes devem 
ser tratados com uma abordagem mais sistemática, deixando de 
ser uma atividade dentro do processo de desenvolvimento, e 
passando a ter um processo próprio, com etapas, atividades, 
artefatos, técnicas, equipe, ambiente e ferramentas.
www.esab.edu.br 6
Objetivo
Apresentar de forma dinâmica os conceitos relacionados aos 
testes de software e a sua importância, em conjunto com 
demonstrações práticas. Proporcionar ao aluno o aprendizado 
necessário para colocar em prática os principais aspectos dos 
testes de software.
Para atingir esse objetivo, foram intercaladas unidades de 
conceituação e recomendações, com outras de demonstração de 
ferramentas gratuitas e ricas em funcionalidades, para apoiar 
diferentes atividades e etapas do processo de Teste do Software.
Ementa
Apresentação dos seguintes temas: Introdução, Organização do 
Conteúdo, Conceitos de Teste I, Testes Estáticos x Testes 
Dinâmicos, Testes Funcionais (Caixa-preta) x Estruturais (Caixa-
branca), Conceitos de Testes Níveis de Testes, As integrações 
podem ser do tipo Big-Bang ou incremental - II, Técnicas de Testes. 
Custos de Testar; da Correção e o Retorno de Investimento em 
Testes, Custo da Correção, Retorno de Investimento, Custos das 
Falhas - Erros em Escalas da GOL, Autodestruição do Foguete 
Ariane 501, Destruição da Sonda da NASA Mars Climate Orbiter, 
O Processo de Teste, O Modelo V, Planejamento dos Testes - 
Análise dos Riscos, Término dos Testes, Ambiente de Testes, 
Massa de Dados, Ferramentas - A Equipe e os Papéis nos Testes, 
Abordagens para Montar a Equipe, Papéis no Processo de Teste, 
Certificações para Profissionais de Testes, Técnicas Estáticas, 
Revisão e Inspeção, Casos de Teste, Conteúdo do Caso de Teste, 
www.esab.edu.br 7
Características e Potenciais Problemas, Execução dos Testes, 
Testes Orientados a Dados (DDT – Data Driven Test), Automatização 
dos Testes - Gestão de Testes, Ferramenta TestLink, Gestão de 
Defeitos (Conceito de Erro, Defeito e Falha), Gestão de Defeitos 
(Resolução do Defeito) - Gestão de Defeitos – Ferramenta Mantis, 
Gestão de Defeitos – Ferramenta Mantis (Continuação) - Cobertura 
de Código – Ferramenta EclEMMA, Testes de Unidade e Integração 
- Ferramenta Junit, Localização das Classes de Teste, Testes com 
Objetos Substitutos ou Falsificados (Mock Objects), Ferramenta 
Mockito, Ferramenta Mockito (Continuação) – Desenvolvimento 
Orientado a Testes (TDD - Test Driven Devlopment), Exemplo de 
TDD na Prática - Desenvolvimento Orientado a Testes (TDD - Test 
Driven Devlopment), Exemplo de TDD na Prática - SELENIUN - 
Ferramenta para Gravar/Executar Testes em Browsers I, 
Ferramenta para Gravar/Executar Testes em Browsers II, 
Ferramenta para Gravar/Executar Testes em Browsers III - Teste 
de Performance e Estresse - Ferramenta JMeter - Integração 
Contínua, Controle de Versão de Código,Integração Contínua, 
Ferramenta Jenkins I - Integração Contínua - Ferramenta Jenkins 
II - Integração Contínua, Ferramenta Jenkins I.
www.esab.edu.br 8
 
1: FUNDAMENTOS DE TESTE DE SOFTWARE
O teste de software é um processo usado para facilitar a 
identificação da exatidão, integridade, segurança e qualidade do 
software. Em outras palavras, um teste de software é um processo 
de auditoria ou comparação entre a saída real e a saída esperada. 
Com o desenvolvimento contínuo da tecnologia de teste de 
software, os métodos de teste são cada vez mais diversificados e 
mais direcionados. Este eixo temático fará uma descrição 
introdutória sobre teste de software, buscando sistematicamente 
introduzir o conceito de teste de software. Ainda, este eixo 
temático fará uma organização dos conteúdos de forma simples 
para uma melhor compreensão das características da disciplina 
de teste de software.
Objetivo
Fornecer conhecimentos básicos sobre o conceito de teste de 
software, através de uma introdução e organização dos conteúdos, 
a fim de permitir que os alunos adquiram habilidades básicas, para 
que mais tarde, à medida que o estudo se desenvolva, possam 
obter habilidades mais complexas. Desta forma, serão 
apresentados os seguintes tópicos: 
www.esab.edu.br 9
Introdução
Bem-vindo ao Módulo Teste de Software!
O avanço da tecnologia nas últimas décadas em áreas que vão 
dos hardwares até as linguagens de programação, proporcionou 
o surgimento de milhares de software. A utilização da Internet 
potencializou ainda mais esse fato, fazendo com que diversas 
aplicações computacionais fizessem parte do nosso dia a dia. 
Assim, o software passou a ser peça chave na competitividade de 
muitas empresas, fazendo com que suas falhas provocassem 
diversos tipos de prejuízos. Nesse cenário, para garantir a 
qualidade dos softwares, a área de teste foi ganhando cada vez 
mais importância.
Até a década de 1990, os testes eram realizados na maioria das 
vezes pelos próprios desenvolvedores, e eram tratados como 
uma atividade que tinha pouco tempo disponível, no cronograma 
do projeto de software, para ser realizada (BERNARDO, 2008). 
Desde então, diversos artigos, ferramentas e livros sobre testes 
foram lançados, mas, assim mesmo, é comum ver empresas que 
não dedicam a atenção necessária a essa área para garantia da 
qualidade.
Portanto, o objetivo deste Módulo 1 é apresentar os principais 
pontos envolvidos com o teste de software, com uma abordagem 
mais sistemática; deixando de ser uma atividade dentro do 
www.esab.edu.br 10
processo de desenvolvimento, e passando a ter um processo 
próprio, com etapas, atividades, artefatos, ambiente, técnicas, 
equipe e ferramentas.
Mesmo com todo avanço em relação aos testes, nos últimos anos; 
o teste de software não é uma ciência exata. No entanto, teste 
exaustivo é impossível, e para realizar os testes adequadamente 
é importante realizar uma avaliação de risco.
A análise de risco é uma parte importante dos testes de software, 
visto que vai determinar as áreas que precisam ser mais 
cuidadosamente testadas, e em qual momento pode-se considerar 
que os testes realizados foram suficientes para garantir uma 
confiança adequada para liberar o software para produção.
Para atingir o objetivo, este Módulo foi baseado em livros, artigos 
de especialistas, revistas especializadas e manuais de ferramentas. 
Para fornecer uma abordagem conceitual aliada à prática, 8 
ferramentas gratuitas, relacionadas com diferentes partes do 
teste de software, serão apresentadas.
O objetivo da apresentação dessas 8 ferramentas é propiciar ao 
aluno o conhecimento dos principais benefícios, facilidade de uso 
e o momento adequado para usar cada tipo de ferramenta. Assim, 
o Módulo não tem a pretensão de abranger todos os aspectos 
dessas ferramentas, até porque o manual delas é extenso, 
impossibilitando abordar em um módulo.
A Figura 1 apresenta algumas das bibliografias utilizadas como 
base para à elaboração deste Módulo 1.
www.esab.edu.br 11
Figura 1: Algumas referências que serviram como base para 
este Módulo
Fonte: Próprio autor
Um dos indicadores da importância e aumento de notoriedade dos 
testes de software é o surgimento de várias certificações. Dentre 
elas, é importante citar a Certificação Brasileira em Teste de 
Software (CBTS) e a Qualificação Internacional de Teste de 
Software (ISTQB - Internacional Software Testing Qualification), 
cujas referências também foram consultadas para a elaboração 
deste Módulo.
Os modelos de processo de melhoria de software, como CMMI 
(Capability Maturity Model Integration) e o MPS.BR (Melhoria de 
Processos do Software Brasileiro), exigem a implantação de 
testes de software. Por exemplo, para conquistar o nível 3 do 
CMMI é preciso adotar uma abordagem sistemática em relação 
aos testes, que se encontra nas áreas de Verificação e Validação 
deste modelo.
É importante notar que as metodologias ágeis como o XP (eXtreme 
Programming) contribuíram com os conceitos de Integração 
Contínua, Desenvolvimento Orientado a Testes (TDD) e 
ferramentas de testes unitários no modelo xUnit, que serão 
www.esab.edu.br 12
estudadas neste Módulo. Apesar de a origem ter sido em 
metodologias ágeis, qualquer metodologia de desenvolvimento 
pode se beneficiar dessas práticas (REIS, 2008).
Organização do Conteúdo
Nas próximas duas unidades deste Módulo, serão abordados 
conceitos utilizados nas demais unidades. Portanto, as Unidades 
1 e 2 apresentam conceitos como testes estáticos, dinâmicos, 
funcionais (caixa-preta), estruturais (caixa-branca), tipos e níveis 
de testes. As unidades seguintes apresentam conceitos 
relacionados com o custo do teste, custo da falha e da correção; 
o processo de teste; planejamento; ambiente; equipe; casos de 
teste; execução; gestão dos defeitos; revisão e inspeção; 
desenvolvimento orientado a testes (TDD) e integração contínua.
Serão apresentadas também 8 ferramentas gratuitas para: 
cobertura de código, teste unitário, objetos substitutos (mock 
objects), gestão de defeitos, gestão do processo de teste, teste de 
estresse e de performance, testes de aplicações web e integração 
contínua.
Conceitos de Testes I
Se os testes são tão importantes, por que normalmente não se 
testa adequadamente? Um dos principais fatores para responder 
essa pergunta é entender que a pressão por menores prazos e 
valores negociados para desenvolver um software, dificilmente 
contempla a realização de testes de forma adequada. Os testes 
precisam de um investimento inicial maior, mas como será visto, 
ao longo deste módulo, os prejuízos provocados pelas falhas 
costumam justificar o investimento em um processo de testes.
www.esab.edu.br 13
Os softwares são desenvolvidos por seres humanos, que por mais 
dotados de competências, não são perfeitos, sendo passíveis de 
cometer erros. A verdade é que infelizmente os erros estarão 
presentes no software, e se a equipe de desenvolvimento não os 
encontrar, o cliente vai encontrar, já que cada vez que ele interage 
com o software, ele está exercitando uma funcionalidade.
Delamaro, Maldonado e Jino (2007) citam no livro “Introdução ao 
Teste de Software” que o desenvolvimento de software está sujeito 
a diversos tipos de influências e problemas que acabam por gerar 
um software diferente do que o cliente esperava. Dentre os 
diversos fatores que podem causar esses problemas, eles 
identificam que a maioria é ocasionado por uma mesma origem, o 
erro humano.
Portanto, os testes devem ser realizados de uma maneira 
sistemática, para evitar o acontecimento de uma das Leis de 
Murphy: “Se alguma coisa pode dar errado, dará. E mais, dará 
errado da pior maneira, no pior momento e de modo que cause o 
maior dano possível.” (WIKIPÉDIA, 2018).
Exceto em casos triviais, a execução detestes exaustivos que 
testam todas as possibilidades de combinações, entradas, etc., 
não são viáveis. Pode-se citar como exemplo, uma demonstração 
simples apresentada por Falbo (2008, 71):
Suponha um programa que calcule o 
exponencial de números inteiros x e y (xy). 
Para testar todas as entradas possíveis todos 
os números inteiros de x e y combinados 
devem ser testados, gerando uma cardinalidade 
de 2n * 2n, sendo n o número de bits usados 
para representar um inteiro. Em uma arquitetura 
de 32 bits, a cardinalidade seria 264 (232*232). 
www.esab.edu.br 14
Se cada teste puder ser realizado em 1 
milissegundo, seria necessário 
aproximadamente 5,85 milhões de séculos 
para executar todos os testes. Adicionalmente 
mesmo que o teste exaustivo fosse executado, 
ele não garantiria que o software corresponde 
à sua especificação. Suponha que ao invés do 
xy o cliente tenha especificado a raiz de x por y 
(y√ x), e o desenvolvedor por equívoco 
implementou a função apresentada no 
exemplo; esse erro não seria identificado pelo 
teste exaustivo, e sim pela revisão dos 
requisitos ou teste de aceitação. 
Portanto, como afirmou Djkistra (1930-2202) “O teste não pode 
nunca demonstrar a ausência de defeitos, apenas sua presença”. 
(Wikiquote, 2018, n.p.).
Mesmo não sendo possível realizar testes exaustivos para provar 
que o software está livre de defeitos, a condução sistemática de 
testes em conjunto com as definições de critérios, riscos e 
prioridades contribuem para aumentar a qualidade e confiança no 
sistema.
Testes Estáticos x Testes Dinâmicos
As atividades relacionadas ao teste do software em si não envolvem 
somente a execução do programa, que é o teste dinâmico. 
Existem também os testes estáticos, que não precisam da 
execução de um software (ou nem mesmo a sua existência) para 
serem realizados. Os testes estáticos podem ser aplicados a 
diferentes artefatos como a revisão de documentos de requisitos, 
análise, do próprio código fonte etc.
www.esab.edu.br 15
Testes Funcionais (Caixa-preta) x Estruturais (Caixa-branca)
Os testes funcionais também são conhecidos como teste caixa-
preta, pelo fato de o testador não precisar conhecer os detalhes 
da codificação. Nesse tipo de teste o testador informa os dados de 
entrada e verifica se a saída/resultado está de acordo com o que 
era esperado. Portanto, esse tipo de teste não tem como objetivo 
saber como a funcionalidade foi implementada, mas, sim, quais 
são os resultados apresentados. Avaliando somente a entrada e a 
saída, o teste de caixa-preta visa identificar defeitos do tipo:
•	 Se o sistema aceita entradas incorretas;
•	 Se a saída produzida está correta;
•	 Se existem erros na interface;
•	 Se alguma funcionalidade está faltando;
•	 Dentre outros.
Já os testes estruturais, ou testes caixa-branca, levam em 
consideração a estrutura do código fonte para identificar a 
implementação e se os diferentes caminhos estão sendo cobertos 
por algum tipo de teste. Assim, os testes serão elaborados para: 
testar as decisões lógicas (verdadeiro/falso), testar os loops até o 
limite, as variáveis estáticas e dinâmicas, dentre outros.
O teste de caixa-branca não substitui o teste de caixa-preta, e 
vice-versa. Eles são utilizados em conjunto; cada um com um 
objetivo distinto.
www.esab.edu.br 16
Figura 2: Teste Caixa-preta e Teste Caixa-branca
Fonte: Costa (2013)
Conceitos de Testes II
Níveis de Testes
Os níveis de testes normalmente são classificados como: teste 
unitário, teste de integração, teste de sistema e teste de aceitação.
Os testes unitários são realizados nas menores unidades do 
software, que normalmente são os métodos ou funções. 
Usualmente são os próprios desenvolvedores que realizam os 
testes unitários do próprio código. O seu objetivo é buscar por 
erros de lógica e programação, nas unidades em separado, de 
forma a garantir que essas unidades funcionem corretamente e 
isoladamente. A justificativa clara para realizar os testes de unidade 
é se uma unidade não funcionar isoladamente, ao ser integrada 
com outras unidades, o erro será propagado e mais tempo será 
gasto para identificá-lo. Os testes unitários podem ser realizados 
após a implementação da unidade, ou até mesmo antes de seu 
código ser implementado, sendo essa última uma abordagem de 
metodologias ágeis (Mais detalhes, a respeito de desenvolvimento 
orientado a testes, serão abordados adiante).
www.esab.edu.br 17
Os testes de integração verificam se as partes que funcionavam 
isoladamente continuam a funcionar após serem combinadas. 
Portanto, são verificadas as integrações entre unidades, 
componentes, sistemas, camadas, etc.
As integrações podem ser do tipo Big-Bang ou incremental.
A integração Big-Bang consiste na realização do teste após 
todas as unidades, componentes, etc.; serem integrados, testando 
tudo de uma só vez. A integração incremental consiste em integrar 
e testar o programa gradativamente, começando com uma 
integração pequena e testando; constituindo uma nova integração 
somente quando os testes da integração menor forem bem-
sucedidos. A integração Big-Bang é mais arriscada, porque 
quanto maior for a abrangência da integração mais difícil será para 
identificar a parte que originou a falha. Sem contar que testar a 
integração, após tudo ter sido desenvolvido, faz com que os erros 
sejam encontrados tardiamente. Portanto, para evitar esses tipos 
de problemas, recomenda-se o uso da Abordagem Incremental.
Testes de sistema avaliam o comportamento do sistema como 
um todo. Além das funcionalidades, as características não 
funcionais como: performance, segurança, usabilidade, dentre 
outros, são avaliados. Esses quesitos podem ser avaliados 
também nos outros níveis de teste, e devem ser feitos por completo 
nos testes de sistema. Nesse nível, é importante que o ambiente 
de teste se pareça, ao máximo, com o ambiente de produção, de 
forma que os testes reproduzam o máximo possível o uso real.
Testes de aceitação são realizados pelos clientes e/ou usuários 
do sistema com o objetivo de verificar se o sistema está atendendo 
www.esab.edu.br 18
ao que era pretendido e foi especificado. Esse nível não tem como 
objetivo caçar defeitos e sim verificar se o sistema está «conforme». 
Engana-se quem pensa que esses testes devem ser realizados 
somente ao final do desenvolvimento. Eles devem ser realizados 
o quanto antes, para que os desvios possam ser corrigidos 
enquanto há tempo e não tenham sido propagados. Deixar os 
testes de aceitação somente para o final representa um risco 
altíssimo de reprovação do cliente, gerando diversos tipos de 
prejuízos que englobam o custo do retrabalho, perda do tempo 
certo para lançar o produto, dentre outros.
 
Fonte: DEVMEDA, 2013.
É válido lembrar que: 
Cada projeto apresenta características distintas, que 
dependem do tamanho do software, da tecnologia utilizada 
para o seu desenvolvimento e de muitos outros fatores. 
Assim, a escolha adequada dos tipos de testes que serão 
adotados torna-se primordial.
Saiba Mais
www.esab.edu.br 19
Reflexão
Em relação à performance de um site, a revista Exame PME, de junho 
de 2011, traz uma informação interessante. Na reportagem “Quem é 
mais rápido vende mais” são apresentados dados de uma pesquisa 
informando que:
•	 Cada 1 segundo que um site demora a mais para carregar; 
significa perda de 7% das vendas
•	 57% dos consumidores abandonam um site depois de esperar 3 
segundos para visualizar os dados
•	 80 % desses consumidores não voltam ao site por pelo menos 6 
meses
•	 Desde 2008, a Amazon estima ter aumentado suas receitas em 
1%, cada vez que suas páginas ficaram um décimo de segundo 
mais rápidas.
www.esab.edu.br 20
Técnicas de Testes
A seguir, serão apresentadas algumas técnicas de teste.
•	 Teste de regressão:consiste em testar novamente o 
software (ou partes dele), após o desenvolvimento de uma 
mudança. Assim, o objetivo é verificar se a introdução de 
uma mudança, como por exemplo, novo código ou até 
mesmo a correção de um defeito, não provocou um novo 
defeito em uma parte do software que funcionava 
corretamente, ou seja, verificar que não ocorreu nenhum 
efeito colateral. A reexecução dos testes muitas vezes 
não é realizada da forma adequada por ser encarada como 
uma tarefa cansativa e repetitiva, mas é preciso avaliar o 
risco de uma parte que funcionava apresentar defeitos. 
Como os testes de regressão são realizados muitas vezes, 
se tornam bons candidatos a serem automatizados.
•	 Teste de estresse: o objetivo do teste de estresse é avaliar 
como o sistema se comporta em condições extremas. 
Dessa forma, ele deve ser realizado para consumir os 
recursos disponíveis de forma anormal, testando: restrições 
de memória, espaço em disco, CPU, dentre outros. Para 
isso, testa-se com quantidade elevada de acessos 
simultâneos, volume de dados acima da média esperada, 
etc. Nessas condições o comportamento do sistema será 
avaliado. É importante que o ambiente de testes seja o 
mais parecido possível com o ambiente de produção.
www.esab.edu.br 21
•	 Teste de recuperação: verifica se o sistema será 
restabelecido à sua operação normal e de forma íntegra 
após ocorrer alguma falha, como por exemplo: queda da 
rede, falha de hardware, perda de acesso ao banco de 
dados, dentre outros. Para tanto, esses e outros tipos de 
falhas são provocadas pelo testador. O teste de recuperação 
avalia não só a recuperação automática do sistema, mas 
também os procedimentos manuais necessários. Dessa 
forma, os testes avaliam procedimentos com respectivos 
checklilsts e podem envolver inclusive a restauração de 
backup. Portanto, verifica-se, também, se o backup está 
sendo realizado e armazenado adequadamente. Outro 
ponto avaliado é a quantidade de tempo necessário para o 
software se restabelecer, depois da realização dos 
procedimentos.
•	 Teste de performance: o objetivo do teste de performance 
é avaliar se o sistema consegue obter um desempenho 
determinado em quesitos como, tempo de resposta, 
utilização do hardware, dentre outros. Não deve ser 
confundido com o teste de estresse, visto que, nesse caso, 
o objetivo é verificar se a performance está como esperada 
em condições normais, e não em condições extremas.
•	 Teste de segurança: os testes de segurança são executados 
para garantir que os mecanismos de segurança do software 
vão protegê-lo em relação à integridade, confidencialidade das 
informações e proteção do software. Esse tipo de teste pode 
necessitar de contratação de terceiros, visto que especialistas 
poderão utilizar técnicas e conhecimentos específicos para 
invadir o software, sendo que esses conhecimentos não 
costumam ser de conhecimento de analistas, desenvolveres 
e testadores em geral.
www.esab.edu.br 22
•	 Teste paralelo: a referência do CBTS chama de teste 
paralelo a execução da nova versão do software em conjunto 
com uma versão antiga, para comparar se os resultados 
apresentados são iguais.
Custos de Testar; da Correção e o Retorno de Investimento 
em Testes
O autor do livro The Art of Software Testing (A Arte de Testar 
Software), Glenford Myers (2011) estima que 50% do custo total 
do projeto são gastos com as atividades relacionadas ao teste de 
software. Embora outros autores apresentem estimativas 
diferentes é importante identificar onde esses custos estão 
alocados.
O teste de software consome recursos principalmente em:
•	 Profissionais: horas gastas pelos profissionais da equipe 
(desenvolvedores, analistas de teste, testadores, etc.) com 
atividades de testes, custos com treinamento da equipe, 
dentre outros.
•	 Equipamentos: máquinas necessárias para permitir a 
criação de um ambiente de teste adequado, que permita 
simular o ambiente de produção.
•	 Ferramentas: softwares necessários para gerenciar o 
processo de teste e os defeitos, preparar as bases de dados, 
realizar testes unitários, de integração, aceitação, regressão, 
e demais testes.
Portanto, para implantar um processo de teste de software será 
necessário investir um valor maior no início. Entretanto, o retorno 
www.esab.edu.br 23
desse investimento tende a ser muito maior do que se os testes 
não fossem realizados de forma planejada e organizada.
A Figura 3 demonstra, de forma simples, o aumento do investimento 
inicial com a implantação de um processo de testes bem como 
retorno de investimento proporcionado.
Figura 3: Economia proporcionada ao investir em testes de 
software
Fonte: Próprio autor
Como se pode perceber na Figura 3, a parte da esquerda representa 
um projeto que não possui um processo de teste formalizado. 
Mesmo não sendo formalizado, esse projeto consome recursos 
com testes; visto que alguns testes aleatórios são realizados pelos 
desenvolvedores e eventualmente por algum outro membro da 
equipe. Já no projeto da direita, que possui um processo de teste 
estabelecido, o custo com a realização dos testes aumenta em 
relação ao anterior (custo com pessoas, ferramentas, etc.) e o 
custo das falhas diminui, proporcionando uma economia ao longo 
do tempo. O Custo da Falha, representado de forma resumida na 
figura, engloba o custo do retrabalho, correção e prejuízos 
www.esab.edu.br 24
ocasionados pela falha; desde prejuízo de imagem da equipe 
desenvolvedora até prejuízos financeiros, como por exemplo, 
processos judiciais.
Custo da Correção
No processo de desenvolvimento de software com as etapas de: 
Especificação de Requisitos, Análise, Projeto, Implementação e 
Implantação; quanto mais tarde um defeito for encontrado, maior 
será o custo para corrigi-lo. E não é difícil visualizar o motivo desse 
aumento, visto que uma simples declaração errada, nos requisitos, 
pode gerar de duas a três decisões equivocadas na etapa de 
análise/projeto, podendo ocasionar uns vinte erros introduzidos 
no desenvolvimento (BLACK, 2005). É como se fosse uma bola 
de neve que aumenta na medida em que ela desce morro abaixo.
Essa percepção de que: quanto mais cedo o defeito for encontrado 
mais barato será a sua correção é antiga. Barry Boehm já abordava 
esse tópico em seu artigo de 1976 e Glenford Myers em seu livro 
The art of sotware testing (A arte de testar software) de 1979. A 
declaração de Myers ficou famosa, sendo conhecida como a 
Regra 10 de Myers, em que ele alega que o custo de corrigir um 
defeito aumenta 10x por cada etapa em que o projeto de software 
avança.
O custo de correção aumenta ainda mais se o erro for detectado 
externamente (pelo cliente), após a entrega do software, do que 
internamente pela equipe desenvolvedora/testadora. O especialista 
Rex Black (2010) estima que um defeito encontrado por um 
desenvolvedor, custa, em média, $10 para ser corrigido, enquanto 
que, se for identificado por um testador custará $100 e pelo cliente 
$1000. Para visualizar melhor esses custos, é importante pensar 
www.esab.edu.br 25
no processo. Quando o desenvolvedor identifica o defeito, ele vai 
e corrige. Caso esse mesmo defeito seja identificado por um 
testador, ele terá que reportar para que o desenvolvedor o 
identifique e conserte. Em seguida, uma nova versão deverá ser 
disponibilizada para o testador verificar se o erro foi, de fato, 
corrigido e se nenhum outro foi introduzido com a correção 
(realização do teste de regressão). Portanto, pode-se perceber 
como é mais caro quando o defeito é identificado pelo testador.
Quando o defeito é identificado pelo cliente, além dos passos 
descritos anteriormente, existe o aumento do custo com o suporte 
técnico que atenderá o cliente e de implantar a nova versão do 
software, sem contar os possíveis custos intangíveis com 
processosjudiciais e impactos, na reputação da empresa 
desenvolvedora (BLACK, 2010).
Adicionalmente, com o passar dos anos, os custos podem 
aumentar de maneira exorbitante, visto que pode ser difícil 
encontrar algum desenvolvedor que trabalhou no software 
(problema agravado se o software não tiver uma documentação 
adequada) e/ou então encontrar um profissional com experiência 
adequada em uma linguagem de programação/plataforma que se 
tornou obsoleta.
Então, se é fácil perceber pelos motivos citados que quanto mais 
cedo o defeito for identificado e corrigido, menor será o seu custo, 
por que muitos gestores ignoram a realização adequada de testes? 
A resposta é: eles não visualizam o teste como um investimento. 
Normalmente enxergam o teste como uma atividade custosa, que 
requer muito tempo e investimento e que não ajudará o software 
ficar pronto mais cedo, em um cenário que, na maioria das vezes, 
a pressão por prazo e as margens de lucro são bem pequenas. 
www.esab.edu.br 26
Portanto, para visualizar que o teste deve ser visto como um 
investimento; é importante observar a situação descrita a seguir.
Retorno de Investimento
Para entender melhor o retorno de investimento proporcionado 
pelos testes, deve-se tomar como base o seguinte estudo de caso 
hipotético, apresentado por Rex Black (2010).
Um software implantando em um cliente possui uma nova versão 
liberada a cada 3 meses. Em média, cada nova versão possui 
1000 novos defeitos. A equipe desenvolvedora desse software 
encontra em média 250 erros antes de liberar a versão, sendo que 
o restante (750) é encontrado pelo cliente. Tendo como base a 
estimativa anterior do próprio Rex Black (2010), que um erro 
encontrado por um desenvolvedor custa em média $10 e pelo 
cliente custa $ 1000, esse cenário, que não possui um processo 
formal de teste, gera um custo de $750.000 por versão, e uma 
insatisfação imensa no cliente. Para tentar melhorar essa situação, 
o gerente do projeto consegue investir $70.000 por versão em 
testes manuais para minimizar os impactos. Sendo assim, a equipe 
dedicada para testes identifica mais 350 defeitos que são corrigidos 
antes de lançar a versão. Partindo da estimativa que cada defeito 
encontrado por um testador custa em média $100, o retorno do 
investimento é 350%, conforme apresentado na Tabela 1 a seguir.
www.esab.edu.br 27
Tabela 1: Retorno de Investimento em Testes 
Fonte: Black (2010), adaptado.
Percebendo o retorno do investimento, o gerente do projeto 
consegue pleitear um investimento de mais $12.500, por versão, 
para investir em automatização dos testes, encontrando 150 
defeitos a mais. Dessa forma, o retorno de investimento obtido 
seria de 445%.
Apesar desse estudo de caso ser hipotético, o renomado 
especialista Rex Black (2010) afirma ter presenciado retorno de 
investimento, em testes, variando de 50% a 3200%. Entretanto, 
assim como qualquer outro investimento, somente disponibilizar a 
verba não é garantia de sucesso, visto que existem formas corretas 
e erradas de se investir. Se o dinheiro não for investido com a 
equipe, ferramentas e técnicas adequadas, o resultado pode ser 
negativo e frustrante.
www.esab.edu.br 28
Custos das Falhas
O National Institute of Standards and Technology (NIST), ou em 
português Instituto Nacional de Tecnologia e Padrões, é uma 
agência do Departamento de Comércio dos Estados Unidos. Em 
2002 o NIST elaborou um estudo para estimar o custo anual 
provocado por falhas de software. O estudo foi intitulado The 
Economic Impacts of Inadequate Infrastructure for Software 
Testing, ou em português, O Impacto Econômico da Infraestrutura 
Inadequada para Testes de Software. (TASSEY, 2002).
O impacto das falhas de software é alto devido ao fato de muitos 
empreendimentos, desde indústrias à medicina, dependerem de 
software. Segundo estimativas desse estudo, as falhas de 
software são predominantes e prejudiciais ao ponto de custar à 
economia americana $59,5 bilhões de dólares anualmente. Os 
autores estimaram também que pouco mais de um terço desse 
valor ($22,2 bilhões) poderiam ser eliminados com a implantação 
de processos de testes que permitissem identificar (e 
consequentemente corrigir) mais cedo e de maneira mais efetiva 
os defeitos de software.
Algumas falhas de software podem causar prejuízos imensos. 
Vamos ver agora alguns exemplos de falhas de software que 
viraram notícias.
 
www.esab.edu.br 29
Estudo Complementar
Rex Black é um dos especialistas mais 
reconhecidos em teste de software. Autor 
de livros relacionados aos testes, dentre 
eles o popular “Managing the Test Process” 
com mais de 25.000 cópias vendidas ao 
redor do mundo. Também é palestrante e 
autor de vários artigos (muitos deles podem 
ser encontrados em http://www.rbcs-us.
com/).
Durante 4 anos foi presidente do ISTQB e 
um dos autores do Syllabus da certificação 
desse instituto.
Conheça
Rex Black:
www.esab.edu.br 30
 
Erros em escalas da GOL
Veja a seguir parte da notícia publicada no portal Terra (CAMPOS, 
2010, n.p.) sobre o transtorno provocado por uma falha de software: 
“Gol diz à Anac que falha em software causou erro em escalas.”
Figura 3: Passageiros aguardam para fazer check-in no aeroporto 
de Guarulhos
Fonte: CAMPOS, 2010.
A Agência Nacional de Aviação Civil (Anac) 
informou nesta terça-feira que a companhia 
aérea Gol disse que um problema no software 
para planejamento de escala da tripulação 
gerou dados incorretos que resultaram no 
“planejamento inadequado da malha aérea e 
da jornada de trabalho dos tripulantes”. Hoje, a 
www.esab.edu.br 31
Gol foi convocada pela agência a apresentar 
um plano de ação para atender os passageiros 
de voos cancelados ou atrasados. A companhia 
operava cerca de 70% dos voos atrasados 
ontem em todo o País. De acordo com a Anac, 
a Gol afirmou que o problema no sistema 
aconteceu em julho, durante um upgrade no 
programa. “Por essa razão, foi adotada 
novamente a configuração de escala do mês 
anterior”, disse a agência, em nota: “O sistema 
era utilizado há três meses, segundo a 
companhia, e com o conhecimento da Anac. 
(CAMPOS, 2010, n.p.)
Autodestruição do Foguete Ariane 501
Em junho de 1996, aproximadamente 37 segundos após o seu 
lançamento o foguete Ariane 501 explodiu em voo.
O foguete possuía um sistema referencial inercial (SRI) para medir 
a trajetória. O SRI 2 era o principal, sendo que o SRI 1 funcionava 
como sistema redundante para assumir em caso de falhas no 
primeiro. Ao invés de enviar os dados corretos da altitude, o SRI 2 
enviou um código de erro decorrente de uma falha no software. Só 
que o SRI 1 não pode entrar em operação, visto que 72 
milissegundos antes apresentou o mesmo problema que o SRI 2.
A falha foi provocada pela conversão de um float de 64 bits para 
um número inteiro com sinal de 16 bits, referente à velocidade 
horizontal para a plataforma. Na tentativa da conversão, foi gerado 
um número maior do que o comportado nos 16 bits. O motivo 
www.esab.edu.br 32
dessa conversão estar vulnerável não foi identificada, uma vez 
que nenhum comentário no código fonte justificava esse fato, 
sendo que existiam outras conversões com a proteção adequada. 
O foguete e a carga destruída estavam avaliados em $ 500 milhões 
de dólares.
Destruição da sonda da NASA Mars Climate Orbiter
A NASA enviou uma sonda para Marte para poder estudar o clima 
deste planeta. A sonda Mars Climate Orbiter deveria entrar na 
órbita do planeta ao atingir uma altitude aproximada de 150 km. 
Porém, devido a um erro de conversão de medidas, a sonda 
entrou em uma altitude inferior, provocando a sua destruição. A 
conversão que não foi realizada era de medidas inglesas para o 
sistema métrico. O veículo espacial foi lançado no dia 11 de 
dezembro de 1998 e seu último sinalfoi recebido em 23 de 
setembro de 1999.
Os exemplos de incidentes apresentados nesta unidade 
apresentam alguns prejuízos financeiros, e de tempo, ocasionados 
por falhas de software. Existem outras falhas conhecidas que, 
infelizmente, além das perdas financeiras, provocaram a perda 
de vidas, como por exemplo, o caso do Therac-25; um acelerador 
médico utilizado para tratar tumores.
O Processo de Teste
É comum em projetos de software encontrar os testes sendo 
tratados como uma atividade dentro do processo de 
www.esab.edu.br 33
desenvolvimento. Nessa abordagem, muitas vezes os testes são 
iniciados após a etapa de desenvolvimento. A Figura 4, ilustra 
esse caso.
Figura 4: Abordagem de Testes como uma Atividade no Processo 
de Desenvolvimento
Fonte: Próprio autor.
Entretanto, para aumentar a qualidade do projeto, os testes 
precisam ter um processo próprio não sendo mais tratado apenas 
como uma atividade dentro do processo de desenvolvimento, 
conforme apresenta a Figura 5:
www.esab.edu.br 34
Figura 5: Abordagem de Testes com um Próprio
Fonte: Próprio autor.
Essa abordagem é importante para dar uma ênfase maior aos 
testes. Assim, o teste passa a ter as etapas estruturadas possuindo 
atividades, artefatos, métodos, papéis e responsabilidades. Esse 
processo deve ser iniciado em paralelo com o início do projeto de 
software e, normalmente, deve ser realizado dentro do prazo do 
processo de desenvolvimento, ou seja, de forma geral o cronograma 
do projeto não será aumentado para realização dos testes.
Mesmo sendo um processo e não mais uma atividade, o processo 
de teste e o de desenvolvimento estão interligados (conforme 
demonstrado a seguir no Modelo em V), mas possuem alguns 
indicadores distintos. Tome como exemplo o indicador Defeitos 
Encontrados: quanto maior o número de defeitos encontrados, 
www.esab.edu.br 35
mais bem-sucedidos consideram-se os testes, e menos o processo 
de desenvolvimento.
Um processo é constituído por um conjunto de tarefas e atividades, 
sendo que algumas podem ser sequenciais enquanto outras são 
realizadas em paralelo. De forma geral, as principais atividades do 
processo de teste são: planejamento, preparação, especificação, 
execução e entrega/avaliação (RIOS; MOREIRA, 2007).
O Modelo V
A representação gráfica que é mais utilizada para demonstrar a 
integração entre o desenvolvimento e os testes é o Modelo V. 
Existem algumas variações do Modelo V, mas, de forma geral, 
ele é representado conforme Figura 6:
Figura 6: Forma usual de representar o Modelo V (1)
Fonte: Próprio autor.
www.esab.edu.br 36
Outras formas de representação do modelo V, diferentes da figura 
anterior, existem. O próprio Syllabus (documentação) da 
certificação de testes ISTQB, cita o modelo V sem apresentar 
nenhuma figura e nem mesmo informar os nomes das quatro 
etapas de desenvolvimento.
Alguns autores criticam esse modelo, como por exemplo, James 
Christie. Christie alega que existem tantas variações do modelo 
em V que na prática podem significar qualquer coisa. As 
representações normalmente compartilham o formato de V com 
uma seta ligando os estágios equivalentes em cada lado. Mas 
qual é o significado dessas setas?
1. O teste das entregas de cada etapa do desenvolvimento?
2. O planejamento dos testes em paralelo a cada etapa do 
desenvolvimento?
Figura 7: Forma usual de representar o Modelo V (2)
Fonte: Próprio autor.
Seguem abaixo algumas críticas dos equívocos que podem ser 
ocasionados por conta da interpretação do modelo V baseados 
em Christie (2008), e aproveitando o gancho das críticas, algumas 
www.esab.edu.br 37
recomendações de boas práticas de testes (que na verdade 
independem do modelo adotado).
1. Desencoraja a participação do usuário avaliando as 
funcionalidades e interface antes da etapa de Teste de 
Aceitação, que de acordo com a representação ocorre 
mais tardiamente no projeto.
a. Recomendação: Idealmente, a prototipação e testes 
cedo devem ser incluídos para identificar problemas 
quando são mais baratos de resolver. Não é raro 
encontrar projetos que são submetidos para o cliente 
aprovar somente ao final e o cliente não aprova o que 
foi entregue, gerando um imenso prejuízo (para ambas 
as partes) e insatisfação. Portanto o planejamento do 
projeto deve contemplar os testes de aceitação em 
todas as etapas, submetendo, sempre que possível, 
às telas (mesmo que protótipos) e funcionalidades 
para aprovação do cliente.
2. Caso ocorra o atraso no tempo do desenvolvimento, sobrará 
pouco tempo para realização dos testes, visto que a 
interpretação pode deixar a entender que os testes são 
realizados após o desenvolvimento.
a. Recomendação: É importante que os testes ocorram 
em paralelo durante todo o processo
3. Começar as respectivas revisões e testes, em paralelo com 
as etapas de desenvolvimento, não deve significar revisão 
e aceite ao final de cada etapa.
www.esab.edu.br 38
a. Recomendação: Revisões e testes devem ser 
realizados enquanto os documentos/diagramas são 
elaborados. Testadores devem se envolver na revisão 
de documentos o mais cedo possível ao longo do ciclo 
de desenvolvimento.
Independente da representação gráfica utilizada é importante 
visualizar que o processo de desenvolvimento e o de testes andam 
juntos para proporcionar um aumento na qualidade do projeto do 
software.
Planejamento dos Testes
Para elaborar um planejamento de testes, é importante identificar 
as seguintes questões, conforme aponta McGregor e Sykes 
(2001):
•	 Quem deve realizar os testes?
•	 Quais partes deverão ser testadas e receber mais 
atenção?
•	 Em qual momento os testes serão realizados?
•	 Como os testes serão realizados?
•	 Quanto de teste é adequado?
O planejamento dos testes visa minimizar os riscos e evitar 
desperdícios de tempo e dinheiro. Se os testes forem realizados 
ao acaso, o esforço gasto tende a ser um prejuízo e não proporcionar 
um retorno do investimento, visto que muitos defeitos não serão 
identificados antes do software ir para produção.
www.esab.edu.br 39
E como em qualquer planejamento. O planejamento de testes 
após ter sido realizado no início deve ser revisado e atualizado até 
o término do projeto, para não ficar engessado e desatualizado, 
permitindo corrigir o rumo na ocorrência de imprevistos. Se o 
planejamento do desenvolvimento mudar, o planejamento de 
testes tem que ser reavaliado.
Esse planejamento é feito em um documento de Plano de Testes 
que essencialmente deve conter: o escopo, o processo de teste 
definido, os profissionais, ferramentas, ambiente/hardware, 
estimativas financeiras, cronograma e riscos. Esses são itens 
importantes, mas a composição do documento varia de empresa 
para empresa, sendo um fator limitante os recursos disponíveis 
principalmente de tempo e dinheiro. Um exemplo de modelo de 
plano de testes é o padrão IEE 829.
Os autores do livro, em referência para a certificação brasileira 
CBTS, citam que o Plano de Testes deveria seguir o modelo de 
Plano de Projeto do PMBOK, que é o conjunto de práticas para 
gestão de projetos, publicado pelo PMI (a principal associação 
mundial de gerenciamento de projetos). Eles identificaram que é 
possível fazer uma relação entre os dois modelos.
De forma geral, um bom Plano de Testes abordará questões como: 
o que será testado, as funcionalidades que serão testadas e as 
que não serão testadas em conjunto com o motivo, o processo 
com as principais técnicas e ferramentas que serão utilizadas, os 
critérios para considerar os testes concluídos, os artefatos que 
serão produzidos pelo processo de testes (casos de testes, 
relatórios, etc.), indicadores de qualidade (elaborados em conjunto 
com o cliente), a necessidade de aquisição de suprimentos como 
hardware e software, necessidadede treinamento da equipe, as 
www.esab.edu.br 40
responsabilidades, riscos do projeto de teste (ex: risco de 
determinado profissional ficar ausente, ou de ter que utilizar uma 
ferramenta nova que ninguém tem experiência), risco do negócio 
e das funcionalidades do software, custo e cronograma previstos. 
Abordando esses itens, o planejamento visa proporcionar ações 
preventivas ao invés de reativas, de forma que os riscos sejam 
minimizados e as medidas (como por exemplo, compra de 
hardware/software) sejam realizadas no momento certo para 
evitar atrasos.
 
 
 
Estudo Complementar
Como os testes são realizados na empresa que 
você trabalha? Existe algum tipo de abordagem 
sistemática (casos de teste, apoio por ferramentas, 
automatização de testes, definição de papéis e 
processos, etc.)? Quais?
www.esab.edu.br 41
Reflexão
Com uma breve pesquisa na Internet é possível 
achar várias outras falhas de software que 
ficaram famosas.
É possível inclusive assistir o vídeo de destruição do 
foguete Ariane 5. Um dos endereços disponíveis é: http://
www.youtube. com/watch?v =gp_D8r-2hwk
www.esab.edu.br 42
Análise dos Riscos
O planejamento está fortemente relacionado com a avaliação 
dos riscos que é fundamental para definir o que será testado e 
em qual momento os testes podem ser considerados 
terminados. Esse ponto é bem importante porque não tem como 
realizar testes exaustivos para garantir que o sistema está livre de 
defeitos então é preciso garantir que as partes mais críticas do 
sistema foram testadas.
São avaliados os riscos, ou seja, potenciais situações que, se 
acontecerem, podem gerar diversos tipos de prejuízos e perdas 
para a organização. Dessa forma, as ameaças e vulnerabilidades 
são analisadas para identificar potenciais formas de controle que 
podem prevenir, ou minimizar os prejuízos.
A análise do risco avalia a probabilidade de ocorrência com 
gravidade do impacto do dano causado. Essa análise deve ser 
feita ao longo de todo o projeto, uma vez que a gravidade e o 
impacto podem mudar com o decorrer do tempo. Por exemplo, no 
início do projeto a probabilidade de invasão ao software quando 
estiver pronto pode ser alto, mas no decorrer do desenvolvimento 
o surgimento de um componente de segurança que pode ser 
acoplado ao software diminui os riscos. A avaliação deve contemplar 
tanto os riscos referentes ao projeto e processo de teste em si, 
quanto os riscos inerentes ao negócio, como por exemplo, as 
funcionalidades que contemplam áreas mais críticas.
www.esab.edu.br 43
Quanto ao projeto de teste os riscos já começam no orçamento e 
no cronograma. Se a verba e/ou o tempo disponível para os testes 
forem poucos, os testes serão realizados inadequadamente, 
aumentando muito a probabilidade dos defeitos serem encontrados 
no software já implantado, potencializando, assim, os prejuízos. 
Muitas vezes, a empresa que está orçando o desenvolvimento do 
software não contempla na proposta comercial o custo e tempo 
para os testes, percebendo que tomou prejuízo somente no 
momento dos testes de aceitação quando o cliente não aprova o 
que lhe foi apresentado. Portanto, no fechamento do contrato é 
fundamental negociar prazos e custos adequados que contemplem 
a realização dos testes. Outros riscos envolvem a qualificação da 
equipe, utilização de uma ferramenta nova para realização dos 
testes, ambiente de teste pouco parecido com o ambiente de 
produção, inadequação de metodologias, processo e controle dos 
artefatos de teste.
A realização dos testes custa dinheiro e o investimento necessário 
aumenta na medida em que a cobertura dos testes aumenta. A 
análise de riscos bem realizada proporciona uma destinação 
coerente dos esforços, priorizando as partes que apresentam 
maior probabilidade de ocorrência x impacto de perda (risco) de 
forma que o teste tenha o maior nível possível de confiabilidade 
no tempo disponível (RIOS;MOREIRA, 2007).
Portanto, é necessário realizar uma análise de custo x benefício 
para avaliar até que ponto vale a pena investir em testes, 
respondendo perguntas como: O custo da ocorrência do defeito 
é muito maior do que o custo da sua prevenção? 
Uma forma de se estabelecer a prioridade é definir quantitativamente 
a probabilidade e severidade (impacto) da ocorrência. A Tabela 2 
www.esab.edu.br 44
apresenta um exemplo simples de análise quantitativa de risco 
utilizando escalas como 1, 5, 10, 15; sendo que quanto maior o 
número maior a prioridade.
Tabela 2: – Exemplo simples de cálculo de prioridade de 
funcionalidade a ser testada 
Algumas das formas de determinar o risco são: intuição baseada 
na experiência de profissionais, consenso da equipe e estimativas. 
Essa última se baseia em dados para o cálculo, como por exemplo: 
Quanto custa cada hora que essa máquina fica parada sem 
produzir? Quanto se perderá, por minuto, se o site ficar fora 
do ar?.
Adicionalmente, pode-se utilizar também o Princípio de Pareto 
adaptado, em que 20% do software são responsáveis por 80% 
das funcionalidades mais utilizadas. Para determinar quais são 
essas funcionalidades mais utilizadas, se o software já estiver em 
produção (vale lembrar que as manutenções também devem ser 
testadas), pode-se monitorar as estatísticas de uso, e caso o 
software não esteja implantado, perguntar aos usuários. Porém, é 
importante perceber que o Princípio de Pareto, por si só, pode não 
ser suficiente, visto que uma funcionalidade pode ser muito 
www.esab.edu.br 45
importante e raramente utilizada, mas se falhar pode causar um 
grande prejuízo. Portanto, deve-se avaliar quando essa informação 
será útil, atrelada a outras estimativas.
Término dos Testes
Um ponto muito importante relacionado ao projeto de testes é o 
momento de identificar o seu fim, para não acontecem: testes de 
menos, com uma interrupção, muito antes de atingir a cobertura 
adequada (essa situação é mais comum, principalmente por causa 
das pressões por prazos, ou inadequação em definir a cobertura 
apropriada); ou testes de mais, implicando em custos, acima do 
necessário, com o excesso de testes, pois o custo adicional, com 
os testes, não compensa o custo que seria provocado pela falha.
Figura 7 – Custo do teste comparado com número de defeitos que 
faltam ser corrigidos
Fonte: Rios e Moreira, 2007
Portanto, é importante identificar o ponto de equilíbrio. Esse ponto 
de equilíbrio está relacionando com aspectos de criticidade: quanto 
mais crítico o negócio, mais testes devem ser realizados. Por 
exemplo, os testes de um software para controle de rota de 
espaçonaves, é muito mais crítico do que um software para gestão 
financeira pessoal, de forma que o primeiro requer muito mais 
www.esab.edu.br 46
testes, visto que, o prejuízo ocasionado por uma possível falha 
pode ser muito alto.
Mas, como se pode identificar esse ponto de interrupção? Rios e 
Moreira, (2007) apontam algumas sugestões que podem ser 
utilizadas em conjunto para definir o momento de término:
•	 Quando intervalo de ocorrência e identificação de defeitos 
aumenta muito – de horas para dias;
•	 Quando a nova realização de um ciclo de teste acha 
menos do que um número determinado de bugs;
•	 Quando atinge determinado valor de cobertura sem 
descobrir novos defeitos;
•	 De acordo com o número de defeitos encontrados e 
ainda não corrigidos, considerando a respectiva 
severidade (ex: existem defeitos, de alto ou médio 
risco, que ainda não foram corrigidos?).
Ambiente de Testes
É preciso planejar também o ambiente em que os testes devem 
ser realizados. Engana-se quem pensa que o ambiente se refere 
apenas ao hardware necessário; ele engloba toda a estrutura 
envolvida com a execução dos testes, como por exemplo: sistemas 
operacionais, browsers compatíveis, a massa de dados a ser 
utilizada, eassim por diante.
As características do ambiente vão depender de alguns fatores. 
Quanto mais crítico o software, mais o ambiente de teste deve 
ser parecido com o ambiente de produção. E em alguns casos, o 
ambiente de produção pode ser o mais variado possível. Por 
exemplo, um grande site de vendas precisa rodar perfeitamente 
www.esab.edu.br 47
em diferentes browsers (e em diferentes versões do mesmo) 
combinados com diferentes sistemas operacionais. Se uma 
atualização do site não rodar em um determinado browser padrão, 
o prejuízo pode ser grande; visto que seus clientes em um segundo 
podem acessar o site do concorrente. Assim, a preparação do 
ambiente deve levar em consideração as características de cada 
projeto. Um software com arquitetura cliente-servidor deve permitir 
a realização adequada de testes em ambientes que simulem bem 
a parte do cliente e, também, em ambientes que simulem a parte 
do servidor.
Um software que precise ser testado com diferentes sistemas 
operacionais e configurações; pode utilizar as máquinas virtuais 
(ou Virtual Machines). Um mesmo computador pode ser utilizado 
com diferentes máquinas virtuais. Cada máquina virtual pode 
receber um sistema operacional diferente, reduzindo os custos. 
Assim, um único computador com um Windows 7 (ou qualquer 
outro sistema operacional) instalado, pode ter uma máquina virtual 
com o Linux Ubuntu 10.10, outra com o Windows XP, outra com 
Mac O.S, etc. A referência do CBTS lembra um ponto importante; 
normalmente esses ambientes não são recomendados para teste 
de performance, uma vez que a máquina virtual pode não ter a 
quantidade suficiente de recursos alocados (ex: memória e 
processamento) por estar sendo compartilhada com o sistema 
operacional do computador.
Existem casos em que determinadas condições são proibitivas 
para a reprodução do ambiente no local do desenvolvimento. 
Pode-se citar como exemplo fictício, mas provável, uma indústria 
que contrata uma empresa para desenvolver um software. Essa 
indústria pode ter uma estrutura de hardware muito cara que pode 
custar muito mais do que o software que está sendo desenvolvido. 
Nesse caso, a empresa desenvolvedora tem que realizar alguns 
www.esab.edu.br 48
tipos de testes no ambiente de testes da indústria, enviando alguns 
participantes de sua equipe para lá. É importante perceber, que 
essa situação deve ser prevista no planejamento dos testes.
Massa de Dados
A necessidade dos dados que serão utilizados nos testes varia de 
acordo com a necessidade de cada tipo de teste. Os testes de 
unidades e integração normalmente não precisam de muitos 
dados, enquanto os testes de performance precisam, e para os 
testes de homologação e aceitação é interessante que tenha uma 
quantidade representativa.
Em alguns casos, ter dados reais de uma base já em produção é 
relevante. Mas nem sempre é possível obtê-los seja porque não 
existe uma base de dados de produção (sistema novo) ou porque 
a política de privacidade da empresa contratante não permite que 
esses dados sejam acessados por terceiros. Caso seja possível 
obter os dados reais é importante ter cuidado para camuflar dados 
confidenciais, substituindo-os ou convertendo-os no momento da 
importação. Também é preciso, avaliar se é necessário utilizar 
todos os dados, ou se apenas uma parte deles seria mais 
adequada, filtrando o que for relevante para reduzir a base. Em 
alguns casos, como nos testes de performance e estresse, os 
dados geralmente não precisam ser reais, ou seja, em muitos 
casos podem ser gerados aleatoriamente.
Outro ponto importante a se observar, na realização de testes com 
dados reais, é em relação ao disparo de e-mails. Se a aplicação 
possui funcionalidades que disparam e-mails, na base de teste é 
fundamental adotar uma política que trate os mesmos, adotando 
medidas como substituir os e-mails originais por e-mails de teste, 
www.esab.edu.br 49
por exemplo. Essa política visa evitar problemas maiores com as 
pessoas cadastradas no sistema. Além de ser incômodo para 
pessoa receber e-mails desse tipo, uma informação falsa pode ser 
enviada causando confusão e problema. Por exemplo, se estiver 
sendo realizado um teste em um sistema bancário e um cliente 
que possua uma fortuna recebe um e-mail disparado pelo ambiente 
de testes informando que sua conta foi zerada, certamente seria 
gerado um transtorno. Outro ponto que deve ser observado, é que 
a aplicação no ambiente de testes deve estar apontando para um 
banco de dados de testes, pois em alguns casos, por descuido, 
eles podem estar apontando para o banco de produção, 
ocasionando a perda de dados importantes.
Quando não for possível, ou não for necessário obter dados reais, 
de acordo com o objetivo e necessidade de volume dos testes, os 
mesmos podem ser gerados manualmente ou então 
automaticamente; sendo gerado de forma aleatória por alguma 
ferramenta.
Como diferentes tipos de testes demandam de diferentes tipos de 
dados, várias bases com propósitos distintos são criadas. Após 
essa criação, é interessante fazer o backup dessas bases, 
armazenando-os de forma adequada e categorizada, para futura 
reutilização em testes de regressão ou outros. Por exemplo, 
suponha um sistema que gerencia planos de saúde que de acordo 
com a idade do cliente cadastrado o valor e os benefícios mudam. 
Os casos de testes vão ser elaborados para exercitar essa situação 
de forma que um determinado cliente seja envelhecido nos testes, 
passando por diferentes idades. Assim, um teste pode começar 
com João da Silva com 5 anos de idade e no final dos testes, ele 
estar com 75 anos. Após a realização de alterações no sistema os 
testes de regressão vão precisar que João da Silva tenha 5 anos 
www.esab.edu.br 50
novamente, bastando para isso restaurar a base previamente 
criada com essas condições.
Ferramentas
Faz parte de preparação, e utilização do ambiente, o uso de 
ferramentas. As ferramentas visam apoiar diversos aspectos 
relacionados aos testes, desde a gestão do processo de teste em 
si até a sua execução dos mesmos. Portanto, existem ferramentas 
para gerenciar os testes, controle de defeitos, cobertura de código 
e ainda, realizar testes de estresse, facilitar os testes unitários, 
comparar os resultados dos testes, dentre outros. Existem 
ferramentas que atuam sobre uma atividade específica enquanto 
outras contemplam mais do que uma.
Apenas a aquisição da ferramenta não é condição suficiente para 
obter o sucesso na atividade que ela suporta. Portanto, existem os 
benefícios que podem ser conquistados e, também, existem os 
riscos que são apresentados abaixo, baseados na referência da 
certificação do ISTQB:
Alguns possíveis benefícios:
•	 Redução de trabalhos repetitivos (ex: execução de testes 
de regressão);
•	 Avaliação dos objetivos (ex: número de defeitos, cobertura 
de código);
•	 Maior consistência e possibilidade de repetições (ex: 
testes realizados por uma ferramenta);
•	 Facilidade de acessar as informações sobre os testes 
(ex: estatísticas e gráficos referentes ao progresso do 
www.esab.edu.br 51
teste, como número de defeitos graves que faltam ser 
corrigidos).
Alguns riscos potenciais:
•	 Criar expectativas falsas sobre a ferramenta, como por 
exemplo, funcionalidades oferecidas e facilidade de uso;
•	 Subestimar o tempo necessário para iniciar o uso da 
ferramenta, assim como, custo e esforço necessário 
para conseguir utilizar a mesma;
•	 Subestimar o esforço necessário para manter atualizados 
os artefatos gerados pelas ferramentas;
•	 Tentar utilizar a ferramenta para tudo, mesmo quando a 
realização manual seria mais adequada.
Ao longo deste Módulo, serão apresentadas algumas ferramentas 
gratuitas que, se forem bem empregadas, podem auxiliar bastante 
nos testes. Essas ferramentas servem para demonstrarconceitos 
para você saber escolher qual tipo de ferramenta será adequada 
ao seu projeto. Entretanto, o Módulo não tem a pretensão de 
abranger todos os aspectos dessas ferramentas, até mesmo 
porque o manual delas é extenso. Assim, problemas com instalação 
e utilização das ferramentas não devem ser retiradas na sala 
de aula, e sim nos manuais encontrados em fóruns de discussão 
da internet, dentre outros meios adequadamente disponíveis na 
web para essa finalidade. Algumas ferramentas demonstradas 
são específicas para linguagem de programação Java. Uma vez 
entendido os benefícios oferecidos por determinado tipo de 
ferramenta, independente da linguagem de programação, basta 
pesquisar na internet por uma ferramenta similar para a sua 
linguagem de programação preferida.
www.esab.edu.br 52
 
Saiba Mais
Existem ferramentas que facilitam a geração, 
extração e manipulação de dados, como por exemplo 
a ferramenta gratuita Kettle da suite Pentaho, 
disponível em http://kettle.pentaho.com/.
Para crirar as Virtuais Machines, uma opção gratuita 
é o Virtual Box - http://www.virtualbox.org/.
www.esab.edu.br 53
A Equipe e os Papéis nos Testes
Conforme visto anteriormente, as atividades relacionadas com os 
testes devem ser iniciadas junto com projeto de software. Dessa 
forma, a equipe de testes inicia sua participação no início do 
projeto para detectar defeitos o mais cedo possível, visando evitar 
a propagação dos mesmos e tentar corrigi-los enquanto os custos 
são menores. A equipe de testes utilizará os artefatos gerados 
pela equipe de desenvolvimento para testá-los ou planejar testes 
de outros artefatos.
Para montar a equipe de testes, existem algumas abordagens 
que vão desde utilizar os próprios desenvolvedores até terceirizar 
os testes para equipe externa. A estratégia utilizada depende 
muito das condições do projeto, como custo, prazo, dentre outros. 
O ideal é uma equipe de testes dedicada (seja ela interna ou 
terceirizada), mas muitas vezes esse objetivo é difícil de alcançar 
por restrições financeiras. Mas é importante ter em mente que: 
dificilmente se obtém resultados satisfatórios quando o 
desenvolvedor testa o próprio código. Alguns motivos são:
•	 O testador precisa trabalhar de maneira isenta e 
independente e os seres humanos tendem (mesmo que 
de forma inconsciente) a encobrir os seus próprios 
enganos.
•	 É difícil ter motivação psicológica para elaborar casos de 
testes que mostram que seu código possui defeitos.
•	 Ao desenvolver, utilizou-se uma lógica de raciocínio que 
www.esab.edu.br 54
precisa ser modificada, para tentar identificar os possíveis 
defeitos.
•	 O desenvolvedor possui uma lista de atividades para 
desenvolver e normalmente fica ansioso. Quando termina 
uma atividade, tem a intenção de logo começar outra e 
não parar e ficar testando o que já fez.
Essas dificuldades não são exclusivas de desenvolvedores de 
software, por isso, estão presentes em qualquer tipo de construção 
intelectual. Você já tentou revisar um texto depois que escreveu? 
E revisar novamente após outra pessoa ter feito uma revisão 
seguida de correções? Muitas pessoas consideram essa atividade 
torturante.
Abordagens Para Montar a Equipe
A seguir, algumas vantagens e desvantagens de montar a equipe 
de testes com os desenvolvedores e outra com profissionais 
designados somente para essa função, com base na referência 
da certificação CBTS (RIOS; MOREIRA, 2007).
1 Alocar equipe de desenvolvimento para realizar os testes 
- Nesse caso, um desenvolvedor (ou analista) deve testar a 
funcionalidade do outro, de forma que o responsável nunca 
deve testar o que ele mesmo produziu (com exceção dos 
testes unitários e alguns tipos de integração). Para isso, é 
importante que os desenvolvedores passem por treinamentos 
que permitam desempenhar melhor a função de testador, 
adquirindo conhecimentos com técnicas, documentos e 
ferramentas de testes. Apesar dessa abordagem envolver 
menores investimentos iniciais e permitir alcançar resultados 
positivos, o gerenciamento passa ser mais trabalhoso, uma 
www.esab.edu.br 55
vez que é necessário organizar o tempo e sincronizar 
cronogramas de forma a não atrapalhar o trabalho do outro 
desenvolvedor (seja por interrupção ou espera da realização 
dos testes para poder prosseguir). Além da dificuldade de 
sincronizar cronogramas, outros riscos envolvidos são: os 
desenvolvedores terão uma tendência a realizar os testes de 
maneira mais informal. Assim, dificilmente manterão os 
documentos de testes atualizados, portanto, não terão 
conhecimento a respeito do negócio.
2 Alocar equipe independente para realizar os testes - A 
equipe independente pode ser da própria empresa 
desenvolvedora ou então uma equipe externa, terceirizada. 
Essa abordagem tem um custo inicial maior, visto que mais 
pessoas estarão envolvidas e alocadas no projeto. Porém, 
tende a proporcionar um retorno financeiro maior ao longo do 
tempo, principalmente se for contabilizado o custo de corrigir 
os defeitos encontrados no software em produção. A qualidade 
final é maior devido à: dedicação de tempo maior, conhecimento 
mais especializado nas técnicas, ferramentas e metodologias 
de teste. Para funcionar bem, é preciso gerenciar alguns 
pontos, como por exemplo: a equipe de desenvolvimento 
pode achar que a responsabilidade sobre a qualidade é 
somente da equipe de testes, diminuindo o seu padrão de 
qualidade e existe uma tendência de desentendimento entre 
as duas equipes, que pode ser ocasionado principalmente se 
os testadores reportarem os erros com linguagem inapropriada 
(ex: deboche, agressividade, etc.).
Beizer já dizia, em 1990: responsabilidade, e teste com (tradução 
livre).
“Testadores, quebrem o software como é de sua força, mas não 
sinta prazer com a dor do programador” (BEIZER, 1990, n.p.)
www.esab.edu.br 56
Papéis no Processo de Teste
A equipe de desenvolvimento é responsável por realizar os testes 
unitários e de integração. Em relação à equipe de testes, 
normalmente os papéis existentes são:
•	 Gerente de Teste: esse papel é semelhante ao gerente 
de projetos, e normalmente encontrado apenas em 
equipes maiores.
•	 Líder do Projeto de Teste: lidera um projeto de teste 
específico.
•	 Arquiteto de Teste: tem como responsabilidade 
preparar o ambiente de testes e escolher as 
ferramentas que serão utilizadas.
•	 Analista de Teste: elabora os casos de teste.
•	 Testador: executa os casos de teste.
Pode ser que profissionais acumulem alguns papéis (tanto de 
teste como de desenvolvimento), de acordo com a necessidade e 
porte da equipe e projeto. Em relação à automatização dos testes 
e aos testes de performance, essa atribuição, dependendo da 
equipe, fica sob responsabilidade do testador ou do analista de 
teste.
Certificações para Profissionais de Testes
Existem no mercado várias certificações para os profissionais 
de testes. Abaixo são relacionadas três delas (2 delas já citadas 
neste módulo) que são bem aceitas no Brasil, juntamente com 
algumas informações adicionais. Vale ressaltar que essas 
www.esab.edu.br 57
informações servem apenas para dar uma pequena noção, visto 
que os valores, tempo, número de questões podem mudar.
•	 CBTS - Certificação Brasileira de Teste de Software.
•	 ALATS (Associação Latino-Americana de Teste de 
Software).
Material de apoio para a certificação: Livro Base de 
Conhecimento em Teste de Software, 2ª edição.
Valor: R$ 300 reais.
Número de Questões: 100 questões.
Percentual de Acerto para aprovação: 75%
Duração: 3 horas.
Formato: Múltipla escolha.
Site: http://www.alats.org.br.
•	 CTFL Foundation - Certified Tester, Foundation Level.
•	 ISTQB (International Software Testing Qualifications 
Board).
Material de apoio para a certificação: “Foundation Level 
Syllabus” e “Glossaryof Terms” (ambos possuem 
tradução para português).
Valor: R$ 350 reais.
Número de Questões: 40 questões.
Percentual de Acerto para aprovação: 60%
Duração: 1 hora.
Formato: Múltipla escolha.
Site: http://www.bstqb.org.br/
•	 CSTE - Certified Software Tester.
•	 QAI - Quality Assurance Institute.
Material de apoio para a certificação: Common Body of 
Knowledge(CBOK).
Valor: U$ 350 dólares.
www.esab.edu.br 58
Número de Questões: 100 múltipla-escolha e 20 
dissertativas curtas
Percentual de Acerto para aprovação: 75%
Duração: 4 horas e meia.
Formato: Múltipla escolha e dissertativa.
Site: http://www.softwarecertifications.org/qai_cste.htm
Técnicas Estáticas - Revisão e Inspeção
As técnicas de Teste Dinâmico necessitam da execução do 
código fonte para serem realizadas. Portanto pode-se citar 
como exemplo, a execução dos testes unitários e dos testes 
de performance como técnicas de Teste Dinâmico.
Já as técnicas de Teste Estático não estão relacionadas à 
execução do código fonte, que pode muitas vezes nem existir 
ainda. São exemplos de testes estáticos, as revisões de 
artefatos como especificação de requisitos, diagrama de 
classes, inspeção do código fonte, dentre outros. Portanto, 
muitas das técnicas de Teste Estático são realizadas 
manualmente, como a leitura de documentos para identificar 
inconsistências.
Como estudado anteriormente, quanto mais cedo um defeito 
for identificado, menor é o custo da sua correção. Para evitar 
que defeitos introduzidos nos artefatos, como especificação 
de requisitos, diagramas de classe, etc., se propaguem para 
os demais artefatos, é importante realizar a revisão desses 
documentos.
Para facilitar a leitura, os defeitos dos artefatos citados nesta 
Unidade, são mais abrangentes do que o conceito de defeito 
www.esab.edu.br 59
que será estudado, abstraindo o conceito para qualquer tipo 
de problema. Ao revisar os requisitos e diagramas os tipos de 
problema procurados são (KALINOWSKI, 2008, n.p.):
Omissão: falta de informações relevantes a 
respeito do sistema, como por exemplo, parte 
importante não definida, ausência de classes, 
diagramas, etc. - Ambiguidade: a descrição do 
texto ou diagramas permite que a mesma 
informação seja interpretada de diferentes 
formas - Inconsistência: informações no mesmo 
artefato ou em artefatos distintos são conflitantes 
entre si - Fato Incorreto: a informação textual ou 
diagramática não condiz com a verdade- 
Informação Estranha: informações que não são 
necessárias ou não são utilizadas - Outros: os 
demais tipos de defeito, como posicionamento 
errado de informações em determinada seção.
A realização da revisão deve iniciar o quanto antes e não somente 
ao término de uma fase. As revisões podem seguir processos 
informais ou formais. Segundo o Syllabus do ISTQB (2011), a 
revisão formal normalmente contempla as etapas de planejamento, 
kick-off, preparação individual, reunião de revisão, correção e 
acompanhamento. No planejamento são definidas as técnicas a 
serem empregadas e os revisores, dentre outros. A fase de kick-
off contempla a distribuição dos documentos, e explicação para 
os participantes sobre os objetivos, documentos e processos. A 
preparação individual consiste na revisão individual antes da 
reunião, de forma que cada revisor identifique os problemas, 
comentários e sugestões. Na reunião de revisão, os participantes 
discutem as anotações realizadas previamente e decidem com a 
ajuda do moderador os defeitos (e os pontos que não são defeitos) 
e possíveis encaminhamentos. O retrabalho (correção) é a etapa 
de correção dos defeitos, normalmente pelo autor do artefato. O 
www.esab.edu.br 60
acompanhamento consiste em verificar se os defeitos foram 
devidamente corrigidos e a necessidade de uma nova revisão.
As abordagens para leitura normalmente são: ad hoc, baseadas 
em checklists e técnicas de leitura de software. A leitura ad hoc 
não possui um método definido, sendo sua eficácia dependente 
da habilidade do revisor. A leitura baseada em checklist (ou lista 
de verificação) não apresenta uma metodologia sistemática, mas 
sim um conjunto de características de defeitos conhecidos 
previamente, que devem ser verificados (FALBO, 2017). Já a 
técnica de leitura de software visa adotar uma postura mais 
sistemática na realização da revisão. Pode-se citar como exemplo, 
a Técnica de Leitura Orientada a Objetos (OORT - Object-Oriented 
Reading Techniques). A OORT estabelece procedimentos para 
revisão de documentos e diagramas do projeto orientados a objeto 
(MAFRA; TRAVASSOS; 2005). Duas dimensões são analisadas, 
a leitura horizontal (verificação de consistência de artefatos de 
uma mesma fase) e leitura vertical (verificação de artefatos 
produzidos em fases diferentes) (FALBO, 2017). Assim, são 
apresentadas técnicas que verificam, por exemplo, a consistência 
dos casos de uso com o diagrama de classes.
Na inspeção do código fonte, algumas atividades podem ser 
apoiadas por ferramentas. Por exemplo, a ferramenta Checkstyle 
(http://checkstyle.sourceforge.net/) verifica se o código fonte dos 
desenvolvedores segue um padrão como nomenclatura de 
métodos, código duplicado, etc. Já a ferramenta gratuita FindBugs 
(2018), para Java, analisa estaticamente o código fonte e aponta 
possíveis defeitos, baseados em padrões conhecidos. Dentre as 
inúmeras análises realizadas, aponta variáveis que não são 
inicializadas, possíveis ocorrências de exceções de null pointer, 
indicação de problemas de performance com código desnecessário, 
tratamento incorreto de exceções, etc.
www.esab.edu.br 61
 
 
 
Estudo Complementar
Uma alternativa de terceirização da equipe 
de testes que vem ganhando popularidade, 
principalmente no exterior é o CrowdTest 
(algo como: teste da multidão).
Atividade
Após o estudo referente ao Eixo Temático 1, 
você será capaz de entrar na sua sala de aula 
virtual e acessar a Lista 1 de atividades 
objetivas. Boas atividades!
www.esab.edu.br 62
O objetivo do estudo sobre Fundamentos de Teste de Software foi 
o de expor os Fundamentos de Teste de Software para o aluno, 
além de conceituar os níveis de testes, as técnicas utilizadas, bem 
como se dá o processo de teste e suas falhas. Portanto, ao 
discorrer sobre as cinco primeiras unidades desse eixo temático 
1, buscou-se de forma sucinta alcançar os seguintes entendimentos 
sobre cada unidade e sua importância para a Engenharia de 
Software: Unidade 1 - Introdução, Organização do Conteúdo, 
Conceitos de Teste I, Testes Estáticos x Testes Dinâmicos, Testes 
Funcionais (Caixa-preta) x Estruturais (Caixa-branca), Conceitos 
de Testes Níveis de Testes, As integrações podem ser do tipo Big-
Bang ou incremental – II. Unidade 2 - Técnicas de Testes. Custos 
de Testar; da Correção e o Retorno de Investimento em Testes, 
Custo da Correção, Retorno de Investimento, Custos das Falhas. 
Unidade 3 - Erros em Escalas da GOL, Autodestruição do Foguete 
Ariane 501, Destruição da Sonda da NASA Mars Climate Orbiter, 
O Processo de Teste, O Modelo V, Planejamento dos Testes. 
Unidade 4 - Análise dos Riscos, Término dos Testes, Ambiente de 
Testes, Massa de Dados, Ferramentas. Unidade 5 - A Equipe e os 
Papéis nos Testes, Abordagens para Montar a Equipe, Papéis no 
Processo de Teste, Certificações para Profissionais de Testes, 
Técnicas Estáticas, Revisão e Inspeção.
www.esab.edu.br 63
 
2: TESTES AUTOMÁTICOS
Os Testes automáticos de software é de suma importância quan-
to a garantia, agilidade e qualidade durante o projeto de desenvol-
vimento. Além disso, o testes automáticos apresentam longo ciclo 
de vida no mercado, por isso, cada vez mais vêm se desenvolven-
do nas indústrias e no mercado.
Para que a sustentabilidade de sua operação tenha êxito, não 
deve existir o risco de mau funcionamento ou falhas durante