Introdução aos Testes de Software

Prévia do material em texto

Testes de Software
1
Testes de Software
Prof. José Macedo dos Santos
Testes de Software
2
Apresentação 3
Fundamentos de Teste de Software 4
A Busca pela Qualidade 4
Defeitos, Falhas e Erros 4
Fundamentos de Teste de Software 6
Estratégias de Teste 7
Técnicas de Teste 10
Caixa Branca ou Caixa de Vidro 10
Caixa Preta 10
Regressão 11
Outros Tipos de Testes 12
Exercícios do Capítulo 1 14
Automação de Testes 15
Importância dos Testes de Software 15
Ciclo de Vida de Testes de Software 17
Procedimentos Iniciais 18
Planejamento 18
Preparação 18
Especificação 18
Execução 18
Entrega 19
Testes Automatizados 19
Testes manuais ou não automatizados 20
Implementação dos Testes 22
Ambiente de Testes Automatizados 25
Quando executar os testes automatizados 25
Documentação de Teste de software 26
Exercícios do Capítulo 2 28
Testes em Modelagem Ágil 29
Modelos Ágeis e Testes de Software 29
Teste de software no Scrum 30
O analista de testes no Scrum 31
Tipos de Testes Usados na Modelagem Ágil 33
Ferramentas de Testes em Métodos Ágeis 34
TDD – Test-Driven Development 36
 Exercícios do Capítulo 3 39
Organizações Envolvidas com Testes de Software no Brasil 40
BSTQB 40
ALATS 41
Normas e Padrões em Testes e Qualidade de Software 42
Exercícios do Capítulo 4 46
Considerações Finais 47
Referências 47
Respostas Comentadas dos Exercícios 49
Capítulo 1 49
Capítulo 2 49
Capítulo 3 50
Sumário
Testes de Software
3
Capítulo 4 51
Outros Tipos de Testes de Software - Glossário 51
Testes de Software
4
Apresentação
Desde o início do que conhecemos como a Era da In-
formação, os profissionais envolvidos com tecnologia 
enfrentam sérios desafios. Um destes desafios está rela-
cionado com a qualidade dos aplicativos desenvolvidos. 
A grande maioria dos produtos eletrônicos que adquiri-
mos hoje possui softwares embarcados que garantem o 
funcionamento adequado do produto dentro dos padrões 
exigidos. Agora imagine se um fabricante desses produtos 
detecta uma grave falha e faz um recall (chamada para re-
paração de erros), como estamos acostumados a ver nas 
montadoras de veículos? Que situação complicada, não? 
Não é difícil imaginarmos uma falha de software e uma 
eventual manutenção para regularizar o acerto em um 
ambiente corporativo no qual há uma equipe dedicada ao 
desenvolvimento. Mas quando contratamos uma equipe 
externa ou quando temos estes softwares instalados em 
ambientes remotos, a situação torna-se muito mais com-
plexa.
Esta situação atípica apresenta uma necessidade cada 
vez maior de qualidade de desenvolvimento. Consideran-
do que é quase impossível se desenvolver um software 
perfeito, surge a única alternativa para enfrentar estes 
desafios: os testes de software. Os testes têm como ob-
jetivo eliminar as possíveis falhas de programação e atuar 
no software de forma a deixá-lo adequado ao negócio que 
vai atender.
Há uma grande necessidade hoje de se discutir os di-
versos aspectos que envolvem esta atividade. Comitês 
já foram criados para padronizar as técnicas adequadas 
visando identificar as principais causas de defeitos, erros 
e falhas no desenvolvimento de softwares. Atualmente 
a globalização e o uso cada vez maior de equipamentos 
que necessitam de softwares embarcados, obrigam seus 
desenvolvedores a investir em qualidade. E testar, certa-
mente, é a melhor ferramenta para garanti-la.
Testar um software pode ser definido de forma sim-
ples como a execução de um software em um ambiente 
controlado e acompanhar seu desempenho para saber se 
está dentro do esperado ou especificado.
Pensar em teste de software nos remete, normalmen-
te, para a avaliação das linhas de código para encontrar 
falhas. Mas não se engane, testar um software tem um 
objetivo muito mais amplo. O software precisa gerar o re-
sultado esperado, então testá-lo envolve analisar tudo o 
que ele fornece de resposta e sua devida veracidade. Tes-
tar um software envolve planejar e controlar a aplicação, 
além de validar seus resultados. O principal objetivo sem-
pre será a busca de qualidade. E entender estes conceitos 
pode significar a quebra de alguns paradigmas.
Caro aluno, proponho que para percorrer o caminho 
proposto por esta disciplina você esteja aberto a mudan-
ças, entendendo a necessidade do planejamento, ge-
renciamento e análise do resultado para finalmente nos 
aproximarmos do sucesso de um desenvolvimento que 
contribuirá para o sucesso do negócio. 
José Macedo dos Santos
Testes de Software
5
Fundamentos de Teste de 
Software
A Busca pela Qualidade 
Caro aluno, meditemos um pouco na nossa constan-
te busca pela perfeição. Estamos acostumados a valorizar 
nossos bens que possuem qualidade e desprezar aqueles 
que por algum motivo não apresentam a qualidade dese-
jada. Um carro que quase nunca quebra, por exemplo, é 
extremamente valorizado, enquanto outro que sempre dá 
alguma manutenção é descartado o mais breve possível. 
Se nós estamos acostumados a agir desta forma com 
nossos bens, porque seria diferente no ambiente corpora-
tivo? O mesmo conceito que adotamos com nossos bens 
pessoais, adotamos para os bens que administramos na 
corporação. Portanto sempre iremos valorizar aquele 
hardware ou software que quase nunca dá problema em 
detrimento daquele que sempre dá alguma manutenção.
É lógico então concluir que o sucesso do negócio pode 
estar ligado à qualidade que os softwares corporativos de-
monstram ter, enquanto que o contrário também é lógico, 
seu negócio pode correr grandes riscos se os softwares 
não possuem a qualidade desejada.
Enfrentamos então o desafio de desenvolver softwa-
res que possuem a qualidade esperada e necessária para 
colaborar com o sucesso do negócio. Afinal, quando se 
contrata o serviço de desenvolvimento, espera-se sempre 
o melhor. 
Mas, mesmo parecendo tão lógica esta questão, por 
que enfrentamos tantos problemas com a qualidade dos 
softwares desenvolvidos? Muitos poderiam ser os moti-
vos para acirrarmos uma discussão a respeito, mas nos 
propomos aqui, não a discutirmos as causas da baixa qua-
lidade de desenvolvimento, mas técnicas que podem aju-
dar a buscar a qualidade dos softwares.
Você já ouviu alguma vez a frase: “Ando devagar por-
que tenho pressa”? Não raro, a pressa é a principal ini-
miga da qualidade. Mas também é ilusório dizer que um 
prazo dilatado é sinônimo de qualidade para um desen-
volvimento. Na verdade, prazo dilatado quase nunca é 
uma opção para a maioria dos desenvolvimentos. Então 
somos obrigados a concluir o fato que se impõe no mun-
do globalizado: qualidade e velocidade sempre.
A aplicação de técnicas de testes de softwares pode 
conter a ajuda necessária para aproximar os produtos da 
necessidade imposta pelo mercado. 
Proponho então que consideremos com atenção os 
conceitos, quebrando paradigmas e nos ajustando a téc-
nicas necessárias para melhorarmos a qualidade no de-
senvolvimento de softwares.
Defeitos, Falhas e Erros
Para começarmos, precisamos entender a diferença 
entre defeito, falha e erro (veja figura 1). 
• Defeito: Ocorre quando há uma instrução ou co-
mando incorreto. Um veículo, por exemplo, apre-
senta defeito quando não obedece ao comando do 
motorista.
Testes de Software
6
• Falha: É um comportamento inconsistente. Em um veículo, por exemplo, quando ocorre uma falha, ele conti-
nua funcionando de forma precária, mas não para.
• Erro: É um desvio da especificação. Em um veículo, por exemplo, é quando ocorre uma montagem indevida de 
algum componente.
Por que é importante termos bem definidas estas dife-
renças? Considere a seguinte frase: “A melhor maneira de 
tentar construir a confiança é tentar destruí-la”.Parece um paradoxo, concorda?
Pois saiba que não apenas parece, é um paradoxo.
Na tentativa de destruir a confiança por encontrar de-
feitos, falhas ou erros, na verdade estamos construindo 
uma confiança cada vez mais sólida no produto desenvol-
vido. 
Pense, por exemplo, nos exaustivos testes automo-
bilísticos, quando as montadoras literalmente destroem 
seus veículos para provar a qualidade de seus bens pro-
duzidos (veja figura 2). Não concorda que estão provando 
com isso a segurança que você espera em um momento 
crítico, como um acidente numa estrada em alta veloci-
dade?
Figura 1 – Defeito, Falha e Erro
Os projetos podem ter uma grande complexidade, en-
tão entendemos claramente que será impossível que eles 
não possuam alguns defeitos, principalmente porque em 
um grande projeto temos várias cabeças pensantes, com 
Figura 2 - Test Crash
Fonte: http://just4x4sales.com.au/images/crash%20test.jpg
Testes de Software
7
formação e lógica diferentes, trabalhando juntos para 
atingir os objetivos.
Vários poderiam ser os motivos para alegar a impossi-
bilidade de um software sem qualquer tipo de erro, falha 
ou defeito, mas não queremos contribuir nem para a bus-
ca da perfeição, que não existe, e nem para o relaxamento 
relacionado à inexistência de perfeição.
Hoje não podemos falar de qualidade de software sem 
falar de desenvolvimento ágil, que tem sido considerado 
um conceito avançado de desenvolvimento e busca na eli-
minação de erros, falhas e defeitos.
Caro aluno, para melhor compreensão e acompanha-
mento, as definições que abordaremos seguem a termi-
nologia padrão para Engenharia de Software do Institute 
of Electrical and Electronics Engineers (IEEE ,1990).
Qualidade, Confiabilidade, Usabilidade, Eficiência, Ma-
nutenibilidade e Portabilidade são atributos buscados in-
cansavelmente no desenvolvimento de software e o que 
nos propomos a fazer na consideração deste assunto é 
como o testador pode contribuir para esta busca quase 
que inalcançável. 
O processo de testes é efetivo quando encontra defei-
tos e é eficiente quando encontra os defeitos com a me-
nor quantidade de recursos possível.
Fundamentos de Teste de Software
De acordo com Pressman (2010), um software é testa-
do para descobrir erros que foram introduzidos inadver-
tidamente no momento em que o software foi projetado 
e construído. 
Teste é um conjunto de atividades que podem 
ser planejadas antecipadamente e conduzidas 
sistematicamente. Um gabarito de testes de 
software, que é um conjunto de passos no qual 
podem-se incluir técnicas de projetos de casos 
de teste e métodos de teste específicos, deve 
ser definido para o processo de software sendo 
utilizado no projeto. Fonte: [PRESSMAN, 2010]
O autor lista um conjunto de perguntas e respostas 
que apresentam os principais fundamentos que embasam 
os testes de software, quais sejam: 
• Quem faz? O gerente do projeto, os engenheiros 
de software e especialistas em testes devem desen-
volver uma estratégia de testes, de forma a que o 
projeto tenha um plano formal de testes.
• Porque é importante? O teste é a atividade que 
requer maior esforço de projeto dentro do ciclo de 
desenvolvimento de software. Se for conduzido ao 
acaso pode implicar em desperdício de tempo e 
esforço, além de abrir espaço para a infiltração de 
erros. Assim, é muito importante que se estabeleça 
uma estratégia sistemática para o teste de softwa-
re.
• Quais são os passos? O teste começa nos compo-
nentes do software e vai aumentando seu campo 
de ação de forma a abarcar todo o projeto. Depois 
que os componentes são testados eles precisam 
ser integrados até que todo o sistema seja construí-
do. A partir deste ponto uma série de testes de alto 
nível é executada para descobrir erros relativos aos 
requisitos do cliente. À medida que erros forem en-
contrados, é necessário se fazer um diagnóstico e 
buscar sua correção, através do processo de depu-
ração do sistema.
Testes de Software
8
• O que é uma especificação de testes? É um do-
cumento que relata a abordagem da equipe que 
realiza os testes, definindo um plano que descreve 
a estratégia global e um procedimento que define 
os passos específicos dos testes, bem como quais 
testes serão realizados.
• Como ter certeza que os testes foram feitos cor-
retamente? Para se certificar da corretude do teste 
deve-se realizar uma revisão na especificação do 
teste antes de realizá-lo, de forma a avaliar a com-
pleteza dos casos e das tarefas elencadas. Um pla-
no e procedimento de testes efetivos vão levar à 
construção coordenada do software e à descoberta 
de erros em cada fase da construção do projeto.
Estratégias de Teste
De acordo com RUP (2001), uma estratégia para o tes-
te de um projeto descreve a abordagem geral e os obje-
tivos das atividades de teste. Inclui os estágios de teste 
(unidade, integração e sistema) que devem ser abordados 
e os tipos de teste (de função, desempenho, carga, stress, 
etc.) que devem ser executados. A estratégia deve definir: 
 9 As ferramentas e técnicas de teste a serem em-
pregadas. 
 9 Os critérios de conclusão e êxito do teste a se-
rem usados. 
 
Uma estratégia de testes de software integra 
métodos de projeto de casos de teste em uma 
série bem planejada de passos que resultam na 
construção bem sucedida de software. A estra-
tégia fornece um roteiro que descreve os passos 
a serem conduzidos como parte do teste, quan-
do esses passos são planejados e depois execu-
tados, e quanto de esforço, tempo e recursos 
serão necessários. Fonte: [PRESSMAN, 2010]
Além de enfatizar a importância da estratégia de tes-
tes, Pressman (2010) afirma que esta deve ser suficien-
temente flexível para criar uma abordagem de teste sob 
medida para o projeto em desenvolvimento, mas ao mes-
mo tempo ser rígida para promover um planejamento 
adequado e permitir um acompanhamento gerencial à 
medida em que o projeto progride.
O plano de teste deve definir conjuntos de critérios 
de conclusão para os testes unitário, de integração e de 
sistema. Pode haver diferentes conjuntos de critérios de 
conclusão definidos para iterações individuais. 
Uma estratégia para testes de software pode ser vista 
no contexto da espiral mostrada na figura 3.
O teste de unidade começa no centro da espiral e se 
concentra em cada componente (trecho de código fonte) 
do software. O teste progride movendo-se para fora, ao 
longo da espiral, indo para o teste de integração, que foca 
no projeto e na construção da arquitetura do software. 
Seguindo a espiral, para fora, há o teste de validação, no 
qual os requisitos são validados, ou seja, a especificação 
dos requisitos é confrontada com o software que acabou 
de ser construído. Finalmente chega-se ao teste de siste-
ma, em que os outros elementos do software são testa-
dos como um todo.
Testes de Software
9
Sommerville (2007) e Pressman (2010) descrevem, de 
forma complementar, estes estágios de teste da seguinte 
forma:
• Teste de unidade: é também conhecido como 
teste unitário. Avalia a menor unidade do código. 
Seu objetivo é verificar falhas de funcionamento 
em partes pequenas independentes do software. 
Possibilita uma análise mais profunda e específica 
de uma função independente do resto do código, 
facilitando a descoberta de erros nos limites dos 
módulos. Este teste tem como base estratégica o 
teste de caixa branca. Neste teste, os casos são pro-
jetados para descobrir erros devido a computações 
errôneas, comparações incorretas ou fluxo de con-
trole impróprio.
• Teste de integração: avalia diferentes componen-
tes que são desenvolvidos separadamente mas tra-
balham em conjunto. Ao avaliar estes componentes 
de forma isolada,consegue-se encontrar possíveis 
falhas no resultado apresentado em consequência 
do mal funcionamento ou erro de algum dos com-
ponentes.
• Teste de validação: avalia o software em um am-
biente específico, considerando os requisitos defi-
nidos pelo cliente em uma situação próxima à rea-
lidade. Tem como objetivo provar ao cliente que o 
software atende as solicitações desejadas.
• Teste de sistema: este teste tenta impor a visão 
do cliente, dando normalmente uma perspectiva 
diferente ao testador. Normalmente executa-se em 
um ambiente que se assemelha ao ideal. Seu obje-
tivo é por o sistema desenvolvido completamente 
à prova, com todos os elementos adequadamente 
integrados e realizando suas funções corretamen-
te. Em testes de sistemas encontramos pelo menos 
4 tipos de testes:
o Teste de Recuperação: este procedimen-
to avalia a recuperação de uma falha dentro 
de um tempo especificado em caso de falha. 
Neste teste, podem ocorrem várias falhas 
forçadas para verificar a recuperação.
Figura 3 - Espiral de Estratégia de Testes
Testes de Software
10
o Teste de Segurança: neste caso o testa-
dor tenta penetrar no sistema provocando 
ações que prejudiquem alguém. Ele usa for-
mas ilegais ou impróprias simulando condi-
ções extremas de violação das informações.
o Teste de Estresse: este procedimento 
cria ambientes extremos para utilização do 
software. Volumes anormais e frequência ir-
regular têm como objetivo forçar falhas por 
sobrecarga, verificando as possíveis interrup-
ções e consequências de paradas anormais 
por estresse. Os dados, então, são avaliados 
para ver se não forram corrompidos ou per-
didos.
o Teste de Desempenho: todo sistema de-
senvolvido tem em suas especificação de 
requisitos o desempenho adequado de fun-
cionamento e após a integração dos compo-
nentes uma avaliação é indispensável para se 
obter o seu desempenho real.
De acordo com Pressman (2010), do ponto de vista 
procedimental, o teste no contexto da Engenharia de Sof-
tware é uma série de 4 passos que são implementados 
sequencialmente, conforme mostra a figura 4. 
Figura 4 - Passos de Teste de Software
Testes de Software
11
Inicialmente o teste focaliza cada componente indivi-
dualmente, garantindo que ele funcione adequadamente 
como uma unidade. Em seguida os componentes devem 
ser montados ou integrados para formar um pacote de 
software completo. Depois que o software tiver sido in-
tegrado um conjunto de testes de alto nível é conduzido, 
de forma que critérios de validação de requisitos sejam 
avaliados. O último passo avança para fora dos limites da 
Engenharia de Software indo em direção ao sistema de 
computação. O teste de sistema verifica se todos os ele-
mentos estão ajustados de forma que a função e o de-
sempenho global do sistema sejam alcançados.
Técnicas de Teste
Caro aluno, se testar é determinar se o objetivo está 
sendo alcançado, precisamos obrigatoriamente conhecer 
as técnicas envolvidas. Várias técnicas já existem e outras 
estão sendo criadas ou aperfeiçoadas de acordo com a 
necessidade que surge.
Em Engenharia de Software encontramos algumas téc-
nicas básicas que atualmente estão em prática no merca-
do e que é importante conhecermos, pois poderão servir 
de referência para o desenvolvimento ou aprimoramento 
de técnicas, são elas:
• Caixa Branca
• Caixa Preta
• Regressão 
Consideremos mais detalhadamente estas técnicas 
nas seções a seguir.
Caixa Branca ou Caixa de Vidro
O teste Caixa Branca possui critérios baseados em 
Fluxo de Controle e em Fluxo de Dados, portanto avalia 
a parte estrutural do software. Aplicamos esta prática di-
retamente no código do programa, fazendo teste lógico e 
comportamental. Analisam-se o fluxo de dados e os códi-
gos, usados ou não. 
De acordo com Myers (2004), a técnica de teste de cai-
xa branca é conhecida por vários nomes tais como teste 
estrutural e teste de caixa de vidro. O engenheiro de sis-
tema realiza o teste direto no código fonte do software. 
São determinados os dados de entrada para analisar a ló-
gica do software. Lewis e Veerapillai (2005) afirmam que 
a desvantagem desta técnica está no fato de que não se 
analisa a especificação, concentrando apenas no código 
fonte e não se verifica a lógica da especificação.
Segundo Pressman (2010) os principais testes de Caixa 
Branca são:
• Teste de caminho básico: determina o conjunto 
básico de caminhos para a execução dos testes. 
• Teste de Condição: todas as condições lógicas 
contidas no código são testadas e avaliadas. É co-
mum se deparar com erros de lógica booleana, erro 
de operadores e de expressões aritméticas.
• Teste de fluxo de dados: localiza as variáveis do 
programa e verifica suas definições. Esta técnica é 
mais complexa que as outras, portanto exige maior 
competência na implantação.
• Teste de Laços: em todos os laços definidos no 
programa ocorrerá alguma validação.
Caixa Preta
O nome Caixa Preta (Black Box) vem do sentido de 
que nesse tipo de teste não é necessário saber a estru-
tura interna, bem como o código ou a tecnologia que foi 
utilizada. Nesse tipo de análise essas questões são trans-
parentes para os analistas de teste. Para que se crie um 
projeto de teste bem sucedido é necessário usar a técnica 
de caixa preta junto com o de caixa branca, isto é, deve-se 
analisar, também, a estrutura interna da aplicação.
De acordo com Myers (2004) esta técnica avalia o sof-
tware conforme as entradas e saídas. Aplica-se externa-
mente no software sem considerar o funcionamento in-
terno do mesmo. Os dados de entrada são fornecidos ao 
Testes de Software
12
sistema que os processa e devolve uma saída previamen-
te conhecida pelo testador. Os resultados são compara-
dos para validar a efetividade da funcionalidade testada. 
Este tipo de técnica é baseada na especificação funcional 
e é recomendada para todas as fases de teste, unitário, 
integração, sistema e aceitação.
Este tipo de teste é particularmente útil para revelar 
problemas, tais como:
 9 funções incorretas ou omitidas;
 9 erros de interface;
 9 erros de comportamento ou desempenho e
 9 erros de iniciação e término.
As maratonas de programação geralmente utilizam o teste 
de caixa preta. Os participantes recebem uma especifica-
ção do software a ser desenvolvido e pontuam quando o 
programa entregue passa pelos testes produzindo as saídas 
esperadas de acordo com as entradas dadas. 
Veja:
http://www.youtube.com/watch?v=7TrldtG_wWI
Segundo Lewis e Veerapillai (2005), e complementado 
por Pressman (2010), os principais testes de caixa preta 
são:
• Particionamento de equivalência: o programa é 
dividido em classes, que são testadas com o obje-
tivo de eliminar redundâncias ou de se descobrir 
classes com erros.
• Análise de valor limite: nos limites é que encon-
tramos a maior parte dos erros, então o testador 
extrapola os valores suportados pelo sistema para 
forçar uma situação extrema com o objetivo claro 
de encontrar erros.
• Técnicas de grafo de causa-efeito: servem para 
oferecer uma representação concisa das condições 
lógicas e respectivas ações. A técnica compreende 
4 passos:
1. causas (condições de entrada) e efeitos 
(ações) são relacionados em um módulo e 
atribui-se um identificador para cada;
2. um grafo de causa e efeito é desenvolvi-
do;
3. o grafo é convertido em uma tabela de 
decisão;
4. as regras e tabelas de decisão são conver-
tidas em casos de testes.
Analista de Teste, Analista de Design ou Testador 
(Tester) são nomes utilizados para o profissional 
que identifica os itens de teste-alvo a serem 
avaliados pelo esforço de teste, define os testes 
apropriados necessários e quaisquer dados de 
teste associados,coleta e gerencia os dados de 
teste e avalia o resultado de cada ciclo de testes. 
Fonte: BSTQB (Brazilian Software Testing Quali-
fications Board)
Regressão
Na Psicologia, a regressão faz o paciente voltar ao pas-
sado avaliando acontecimentos e aprendendo com os er-
ros ou acertos obtidos. Pois bem, no método de Regres-
são em testes de softwares vamos encontrar o objetivo 
de avaliar todas as experiências em testes do passado, e 
a cada nova versão disponibilizada executam-se os testes 
já realizados anteriormente e que apresentaram sucesso.
Pressman (2010) afirma que como o método atua de 
modo a confirmar a eficiência já obtida em testes realiza-
dos em versões anteriores, este tipo de teste é mais rápi-
do. Muito embora não seja um método infalível, em vir-
tude de mudanças impactantes que possam ter ocorrido 
no desenvolvimento de uma nova versão, demonstra ser 
relativamente prático e eficiente. Quando a aplicação é 
crítica, o testador pode sugerir um novo desenvolvimento 
e não apenas uma atualização. 
Testes de Software
13
Outros Tipos de Testes
• Caixa Cinza: uma combinação entre teste caixa 
preta e teste caixa branca. Consiste em analisar a 
parte lógica mais a funcionalidade do sistema, com-
parando o que foi realizado com as especificações 
previamente estabelecidas. De acordo com Lewis e 
Veerapillai (2005), o testador, neste método, comu-
nica-se com o desenvolvedor para em comum acor-
do entender e otimizar o sistema. Esta técnica pode 
incluir também o uso de engenharia reversa para 
determinar por exemplo, os limites superiores e in-
feriores das classes, além de mensagens de erro.
• Teste ad hoc: teste realizado informalmente. Não 
ocorre preparação formal, não são usadas técnicas 
reconhecidas de projeto de teste, não há expectati-
va para resultados e a arbitrariedade guia a ativida-
de da execução do teste.
• Teste ágil: prática de teste para projetos que usam 
metodologias ágeis, como por exemplo, o Extreme 
Programming (XP), que trata o desenvolvimento 
como cliente do teste e enfatiza o paradigma de 
testar antes. 
Caro aluno, o anexo 1 traz diversos outros tipos de tes-
tes existentes no mercado. Confira!
Leia mais no artigo da revista Engenharia de Software - 
Introdução à Teste de Software 
Disponível em: http://www.devmedia.com.br/artigo-
-engenharia-de-software-introducao-a-teste-de-softwa-
re/8035#ixzz27Pk4sNNA
Testes de Software
14
Prezado aluno, neste ponto, proponho que faça um exercício simples para que possa 
perceber que para se identificar erros, mesmo em um quadro simples, requer certa con-
centração e disposição. Se isto ocorre com uma simples imagem duplicada com alguns 
erros, imagine um software com milhares de linhas de código.
Testes de Software
15
Exercícios do Capítulo 1 
1 – Testes são divididos em tipos de testes distintos principalmente porque:
a) Cada estágio de teste tem um propósito diferente.
b) Podem ser executados testes diferentes em ambientes diferentes.
c) É mais fácil lidar com testes em estágios.
d) Quanto mais estágios, melhor o teste.
e) Ainda não foram desenvolvidos tipos específicos para alguns processos de desenvolvimento.
2 – Um importante benefício de inspeção de códigos é:
a) É barato.
b) Permite que o código seja testado antes que o ambiente de execução esteja pronto.
c) Pode ser feita pelo desenvolvedor somente.
d) Ajuda a confirmar a capacidade de desenvolvimento.
e) Colabora com a rentabilidade do projeto.
3 – Uma falha:
a) Ocorre quando há uma instrução ou comando incorreto.
b) É um desvio de especificação.
c) É um comportamento inconsistente.
d) É uma informação inadequada fornecida.
e) Nenhuma das anteriores.
4 – O teste tipo caixa cinza, se refere a:
a) Um tipo de teste efetuado com os componentes físicos.
b) Um teste de ação retardada, em que o resultado só aparece a médio ou longo prazo.
c) Uma referencia a um teste ineficiente.
d) Uma combinação entre teste caixa preta e teste caixa branca.
e) Um teste de integridade.
5 – Este teste possui critérios baseados em Fluxo de Controle e em Fluxo de Dados, portanto avalia a parte estrutural 
do software.
a) Teste caixa preta.
b) Teste caixa cinza.
c) Teste ad hoc.
d) Teste ágil.
e) Teste caixa branca.
Testes de Software
16
Automação de Testes
Importância dos Testes de Software
Caro aluno considere novamente a analogia que fize-
mos sobre os recalls que montadoras eventualmente fa-
zem.
Seria correto afirmarmos que, se uma montadora ad-
mite em um recall uma falha em seu carro ou projeto, ela 
deva ser considerada incompetente ou seu produto ser 
um péssimo negócio para seus clientes?
Com certeza nos sentiremos traídos se uma falha for 
detectada e escondida para supostamente não denegrir 
a imagem da empresa. Na verdade esta imagem certa-
mente se denegriria se a empresa não tomasse a atitude 
de admitir o erro, assumir a responsabilidade e corrigir a 
falha detectada.
Então, podemos concluir apropriadamente que encon-
trar um erro, uma falha ou mesmo um defeito em um sof-
tware desenvolvido, não vai necessariamente expor uma 
incompetência. Na verdade, como já dissemos, estranha-
ríamos muito se não fosse encontrado qualquer proble-
ma em um software complexo. Não somos infalíveis, por 
melhores profissionais que sejamos. Isto é importante 
compreender e admitir, tanto o desenvolvedor como o 
testador.
Testes automatizados podem fazer a diferença no que 
diz respeito à confiança que um software desenvolvido 
pode alcançar. Como qualquer artefato, o código fonte 
dos testes automatizados e os documentos gerados re-
querem qualidade. À medida que se aumenta a comple-
xidade do software, os testes automatizados aumentam 
sua abrangência também. 
Segundo Pressman (2010), o teste frequente respon-
de por mais esforço de projeto do que qualquer outra 
atividade de engenharia de software. Se é conduzido ao 
acaso, tempo é desperdiçado, esforço desnecessário é 
despendido e, ainda pior, erros se infiltram sem serem 
descobertos. Assim, seria razoável estabelecer uma estra-
tégia sistêmica para o teste de software. 
A figura 5 mostra 2 imagens que apresentam a distri-
buição de defeitos de software e o esforço de retrabalho 
para sua correção e o custo para se corrigir defeitos inse-
ridos na fase de análise de requisitos e detectados poste-
riormente.
Testes de Software
17
Figura 5 – Origem dos defeitos, esforço de retrabalho e custo de correção
Fonte: http://tmtestes.com.br/conteudo/show/id/113
Testes de Software
18
Voltando à analogia do recall, entendemos que admi-
tir falhas, erros ou defeitos e corrigi-los, contribui para 
a manutenção da existência de grandes montadoras. Da 
mesma forma, identificar e corrigir falhas, erros e defeitos 
em um software, contribuirá para a manutenção da exis-
tência de um software desenvolvido. 
Ciclo de Vida de Testes de Software
Segundo Pressman (2010), o teste e a depuração, são 
atividades diferentes, mas a depuração deve ser acomo-
dada em qualquer estratégia de teste.
Conforme abordado na seção 1.4. Estratégias de Teste, 
temos vários estágios na definição da estratégia de testes, 
no entanto, se considerarmos o seu ciclo de vida ficará 
mais claro o entendimento e a importância da elaboração 
de estratégias para a implementação de testes.
Uma estratégia de teste deve acomodar testes de bai-
xo nível, que atuam na identificação de problemas em um 
pequeno segmento do código fonte e testes de alto nível, 
que validam as principais funções do sistema levando em 
consideração os requisitos do cliente. Uma estratégia for-
nece diretrizes aos profissionais e um conjunto de refe-
rências para o gestor. 
Na analogia anterior, nos referimos a admitira possi-
bilidade de imperfeição no desenvolvimento de algo, no 
caso, um veículo. Em teste de software também admiti-
mos imperfeições, na verdade não apenas admitimos, 
mas lutamos abertamente contra elas. Mesmo sabendo 
que é uma luta impossível de ganhar, é impossível aban-
doná-la tal a importância que ela exerce na busca da qua-
lidade de desenvolvimento.
Neste conceito, temos que considerar a importância 
do ciclo de vida e compreender a incansável busca pela 
qualidade e perfeição, mesmo sendo algo quase humana-
mente impossível de se alcançar. 
De acordo com Bastos et al (2007), quanto mais cedo 
se iniciarem os testes, mais barata será a correção dos er-
ros encontrados e, para conquistar este benefício, o pro-
cesso de teste, assim como o processo de desenvolvimen-
to, deve ter um ciclo de vida, que é definido em fases.
Segundo os autores, o ciclo de vida dos testes de sof-
tware compreende as etapas que envolvem: procedimen-
tos iniciais, planejamento, preparação, especificação, exe-
cução e entrega, de acordo com a figura 6. 
Figura 6 - Ciclo de vida do processo de teste
Fonte: [BASTOS et al, 2007]
Testes de Software
19
Estas etapas serão detalhadas no que se segue.
Procedimentos Iniciais
Aprofunda-se, nesta etapa, um estudo sobre os requi-
sitos do negócio, de forma a garantir que estejam comple-
tos e sem nenhuma ambiguidade. Deve ser traçado tam-
bém um pequeno esboço do processo de teste. É preciso 
elaborar um plano com todas as atividades principais que 
serão executadas.
Planejamento
Nesta etapa são realizadas a elaboração da Estratégia 
de Testes e do Plano de Testes com objetivo de minimi-
zar os principais riscos do negócio e fornecer os caminhos 
para as próximas etapas. Para cumprir esses objetivos, 
algumas diretrizes são necessárias. Esta etapa deve ser 
executada em conjunto com as atividades de captação 
dos requisitos e o planejamento do projeto de desenvol-
vimento do sistema a ser testado. Testes de verificação 
deverão ser executados sobre os requisitos do sistema. 
Deverá também ser preparada a Análise de Risco do pro-
jeto de teste.
Preparação
Conforme a figura 6, esta etapa ocorre paralelamente 
às outras etapas. O objetivo básico é preparar o ambiente 
de teste para que os testes sejam executados corretamen-
te, em um ambiente mais próximo ao que o cliente utiliza.
Especificação
Esta etapa se refere à especi-
ficação dos casos e roteiros de 
teste que são elaborados durante 
o decorrer do projeto. À medida 
que a equipe de desenvolvimento 
conclui alguns módulos ou partes 
do sistema, são elaborados os ca-
sos e roteiros de teste.
Execução
Executar e registrar os resultados dos testes são tare-
fas que precisam obedecer as seguintes diretrizes:
• Os testes deverão ser executados de acordo com 
os casos e roteiros de teste.
• Devem ser usados 
scripts de teste, caso 
seja empregada algu-
ma ferramenta de au-
tomação de testes.
• Os testes deverão ser 
executados integral-
mente, por regressão, 
ou parcialmente, sem-
pre que surgir alguma 
mudança na versão 
dos programas em tes-
Testes de Software
20
A reprodução de um teste automatizado inúmeras ve-
zes, em situações específicas, garante que passos impor-
tantes não sejam esquecidos, e isto, sem dúvida, evitará 
uma situação indesejável.
Além disso, como os casos para verificação são des-
critos através de um código interpretado por um compu-
tador, é possível criar situações de testes bem mais ela-
boradas e complexas do que as realizadas manualmente, 
possibilitando qualquer combinação de comandos e ope-
rações. A magnitude dos testes pode também ser facil-
mente alterada. Por exemplo, é trivial simular centenas 
de usuários acessando um sistema ou inserir milhares de 
registros em uma base de dados, o que não é factível com 
testes manuais.
Uma prática comum no passado (até a década de 
1990) era criar uma função de teste em cada módulo ou 
classe do sistema que continha algumas simulações de 
uso da unidade. O problema desta prática estava na falta 
de organização, já que o código adicional era misturado 
ao próprio sistema afetando a legibilidade do código. Por 
isso, surgiram os frameworks que auxiliam e padronizam 
a escrita de testes automatizados, facilitando o isolamen-
to do código de teste do código da aplicação.
Consideremos um exemplo para aplicações Java com 
o auxílio da versão 4 do JUnit. Os testes são organizados 
em casos de teste definidos através de anotações Java @
Test antes da definição de cada método de teste. O fra-
mework também possui uma gama de métodos auxiliares 
para comparar os efeitos colaterais esperados com os ob-
tidos, tais como assertEquals que compara a igualdade do 
conteúdo de objetos, assertSame que compara se duas 
referências se referem ao mesmo objeto, assertNull que 
verifica se uma dada referência é nula, entre outros (veja 
figura 7).
te e nos ambientes de teste preparados, conforme 
previstos na Estratégia e Plano de Testes.
Entrega
O projeto de teste é finalizado, sendo concluída e ar-
quivada sua documentação. Deve ser recolhida esta do-
cumentação e elaborado um relatório gerencial com as 
conformidades e não-conformidades encontradas.
Testes Automatizados
Testes automatizados são programas ou scripts simples 
que exercitam funcionalidades do sistema sendo testado 
e fazem verificações automáticas nos efeitos colaterais 
obtidos. A grande vantagem desta abordagem, é que to-
dos os casos de teste podem ser facilmente e rapidamen-
te repetidos a qualquer momento e com pouco esforço.
Fonte: http://silvioqualidade.wordpress.com/
Testes de Software
21
O framework JUnit é uma ferramenta automatizada 
de teste de software para teste estrutural. De acordo 
com Sommerville (2007) ele é um grupo de classes na 
linguagem Java, que podem ser estendidas e então criar 
um ambiente de testes automatizados. Esta ferramenta é 
um gerenciador de testes. Delamaro, Maldonado e Jino 
(2007) ratificam que o JUnit tem aumentado muito a sua 
quantidade de usuários. Os autores afirmam que o fra-
mework tem a possibilidade de escrever e executar au-
tomaticamente um conjunto de testes, fornecendo ainda 
um relatório da forma que cada caso de teste, que não 
teve seu comportamento de acordo com o especificado, 
se comportou.
Um exemplo prático que demonstra a criação de teste uni-
tário em uma classe Java usando o JUnit pode ser vista em:
http://youtu.be/f7HvmUmIun4 
De acordo com Lages (2010), a escolha dos testes au-
tomatizados candidatos, ou seja, os mais críticos, deve 
ser realizada com base no planejamento de um projeto 
de automação. O autor afirma que apesar de não existir 
uma categorização amplamente difundida, a experiência 
tem mostrado que os testes candidatos são normalmente 
agrupados nestas 4 áreas:
• Smoke Tests: um conjunto mínimo de testes é 
selecionado com o objetivo de validar um Build ou 
liberação antes do início de um ciclo de testes;
• Testes de Regressão: os testes são selecionados 
com o objetivo de executar o re-teste de uma fun-
cionalidade ou da aplicação inteira;
• Funcionalidades Críticas: os testes são seleciona-
dos com o objetivo de validar as funcionalidades 
críticas que podem trazer riscos ao negócio;
• Tarefas Repetitivas: os testes são selecionados 
com o objetivo de reduzir o envolvimento dos tes-
tadores em atividades manuais repetitivas e sus-
cetíveis a erros, tais como cálculos matemáticos, 
simulações, processamentos, comparações de ar-
quivos ou dados etc.
Testes manuais ou não 
automatizados
A automação de testes tem o objetivo de reduzir o en-
volvimento humano em atividades manuais repetitivas. 
Entretanto, isto não significa que a automação de testes 
Figura 7 - Exemplode teste automatizado com o JUnit 4
Fonte: http://www.ime.usp.br/~kon/papers/EngSoftMagazine-IntroducaoTestes.pdf
Testes de Software
22
deve se limitar apenas a fazer o trabalho repetitivo e cha-
to. Os casos de testes manuais foram criados num con-
texto em que os testes seriam executados manualmente. 
É muito provável que estes casos de testes manuais não 
sejam muito eficientes em um contexto em que os testes 
serão executados automaticamente.
Na prática, a automação de 100% dos testes manuais 
nem sempre é a melhor estratégia. A automação de testes 
é pouco eficaz quando os testes são complexos e exigem 
interações inter-sistemas ou validações subjetivas. Além 
disso, muitas vezes o custo e o tempo para automatizar os 
testes de um projeto são maiores que o custo e o tempo 
do próprio projeto de desenvolvimento. 
Segundo Lages (2010), quando se deseja aplicar a au-
tomação na etapa de execução de testes das funcionali-
dades de um sistema, vários fatores devem ser avaliados 
para se identificar se é vantagem ou não se automatizarem 
os testes. A automação de testes deve ser feita somente 
quando uma rotina específica de teste for executada vá-
rias vezes, pois a automação também demanda tempo de 
criação e manutenção de scripts. Lages ressalta que “70% 
dos testes do mercado são manuais. O teste automatiza-
do serve basicamente para fazer Teste de Regressão. O 
que acha erro mesmo é o teste manual”.
Existem diversos tipos de testes para detectar a ine-
ficiência de um sistema, e antes de muitos deles serem 
automatizados, são executados por várias vezes em modo 
manual, para depois de comprovado sucesso na sua utili-
zação serem automatizados. Alguns deles são:
• Teste de desempenho: teste que determina o 
desempenho de um sistema. As ferramentas que 
apoiam os testes de desempenho possuem duas fa-
cilidades: geração de carga e mensuração das tran-
sações do teste. A geração de carga pode simular 
múltiplos usuários ou grandes volumes de dados de 
entrada. Durante a execução, os tempos de respos-
ta para determinadas transações são medidos e re-
gistrados. As ferramentas de teste de desempenho, 
normalmente, fornecem relatórios baseados nos 
registros dos testes e gráficos da carga em função 
dos tempos de resposta. 
• Teste de carga: teste que mede o comportamento 
de um sistema com uma carga crescente, como por 
exemplo, número de usuários paralelos e/ou nú-
meros de transações, para determinar qual a carga 
que ele pode suportar. Estes testes determinam, 
também, o tempo de resposta de transações e pro-
cessos de negócios com o intuito de determinar se 
a aplicação está de acordo com as expectativas do-
cumentadas e determinadas pelo cliente.
• Teste de estresse: teste que avalia a execução 
de um sistema ou componente no limite (ou aci-
ma dele) dos requisitos especificados. Estes testes 
determinam a carga necessária para que o sistema 
falhe e avalia seu comportamento em condições 
anormais. Podem incluir, além de cargas de traba-
lho extremas, insuficiência de memória e recursos 
de processamento limitados. Avaliam também a 
capacidade que o software tem de se recuperar de 
uma falha mantendo a integridade dos dados.
• Teste de longevidade: neste teste é avaliado o 
funcionamento do sistema em médio e longo pra-
zo. Seu objetivo é detectar influências externas ao 
software, principalmente de hardware ou sistema 
operacional. Fatores como grandes volumes arma-
zenados, tamanho ou limpeza do cache podem ser 
decisivos na eficiência em médio e longo prazo de 
um software. 
• Teste de desempenho: muitos problemas de 
desempenho que podem surgir após o sistema 
ser submetido à carga extrema durante um longo 
período de tempo, só podem ser detectados num 
ambiente controlado. Existem tipos de testes de 
desempenho, como os testes de configuração, que 
da mesma forma que o teste de longevidade, visam 
identificar configurações otimizadas de hardware e 
software para a correta execução da aplicação, e os 
testes de contenção, que avaliam a forma como o 
sistema gerencia demandas para um mesmo recur-
so computacional (memória, dados, processador, 
etc.).
• Teste de Segurança: os testes de segurança nor-
malmente requerem uma infraestrutura similar ao 
Testes de Software
23
do ambiente de produção, pois se espera que este 
exponha as vulnerabilidades do sistema no am-
biente adequado. Garantem a confidencialidade, 
Integridade e disponibilidade das informações. Um 
dos problemas relacionados a este teste é o buffer 
overflow, ou a necessidade maior de capacidade de 
armazenamento.
• Teste de correção: os testes de correção (unida-
de, integração, aceitação, etc) não necessitam das 
mesmas dependências.Têm como objetivo revelar 
a presença de erros, e descobrem o maior número 
possível de erros.
Implementação dos Testes
Uma vez que o software tenha sido elaborado é ne-
cessário fazer a implementação de testes manuais ou 
automatizados. Isto pode exigir conhecimento multidisci-
plinar, ou seja, conhecimento de programação, conheci-
mento de testes de software, conhecimento de linguagem 
de negócio e conhecimento de ferramentas específicas. 
Portanto, o profissional responsável pelos testes automa-
tizados normalmente é diferenciado.
Segundo Schach (2007), “implementação é o processo 
de converter o projeto detalhado em código. Quando isso 
é feito por um único indivíduo, o processo é relativamente 
bem compreendido. Porém, hoje em dia, a maioria dos 
produtos são muito grandes para serem implementados 
por apenas um programador dentro das restrições de 
tempo. Em vez disso, o produto é implementado por uma 
equipe, com todos trabalhando ao mesmo tempo em di-
ferentes componentes do produto.”
O trabalho colaborativo não indica na necessidade 
de todos realizarem tarefas semelhantes, indica apenas 
a integração de ideias que naturalmente ocorre em uma 
equipe integrada. 
De acordo com Pressman (2010), na década de 1970, 
McCall, Richards e Walters categorizaram os fatores que 
afetam a qualidade, relacionados com três áreas distintas: 
operação, transição e revisão. Entre as menções de Mc-
Call encontramos 3 conceitos que são muito importantes 
para o sucesso na implantação e manutenção dos testes 
de software. São elas: comunicação, transparência e cla-
reza.
• Comunicação: O bom comunicador não é aque-
le que possui o “dom da palavra”, mas sim aquele 
não retém informações a respeito de sua atividade 
dentro de uma equipe. Você já prestou atenção al-
guma vez à atitude de alguns jogadores de futebol 
dentro de campo? É muito comum pegá-los con-
versando todo o tempo de paralisação ou tentando 
prever alguma ação de ataque ou contra-ataque. 
Esta situação faz com que o entrosamento se torne 
constante, mesmo nos jogos mais complicados ou 
difíceis. Portanto, durante um jogo, ou um desen-
volvimento, é extremamente importante que haja 
comunicação durante o desenvolvimento de todas 
as atividades do projeto.
• Transparência: É um princípio que se exige da-
queles a quem se delegam responsabilidades. Este 
conceito se torna muito mais importante quando 
envolve trabalho em equipe. Portanto, ser colabo-
rativo significa ser transparente ao revelar dados, 
transferir conhecimentos e atuar como uma equipe 
no objetivo comum de elaborar um software com a 
menor quantidade de erros, falhas ou defeitos.
Fonte: 
http://expressaorp.files.wordpress.com/2011/08/comunicacao_
corporativa1.jpg?w=300&h=225
Testes de Software
24
• Clareza: Ser claro é ser simples e objetivo. Muito 
embora tenha relação com transparência, a clareza 
está relacionada não apenas com a divulgação cor-
reta da informação, mas a não deixar margem para 
um entendimento dúbio. Ser claroé respeitar os 
componentes da equipe em suas atividades e inte-
ressar-se pelo cumprimento das metas da equipe, 
colaborando de modo aberto e espontâneo com o 
atingimento do objetivo comum. É manter os ca-
nais de comunicação sempre abertos.
 
Fonte: 
http://3.bp.blogspot.com/-RG2nG0zSkGg/T49EtJxzdMI/AAAAAAA
Fonte: 
http://etiquetagem.blogspot.com.br/2010/05/comunicando.html
Testes de Software
25
O texto abaixo é da autoria de Abraham Shapiro e ilustra como a comunicação, quando existe falha, pode proporcionar resultados 
desastrosos.
“Clareza tem tudo a ver com resultados”. Meia vida, ou mais, se perde por falta de entendimento claro sobre as coisas. E bastante 
dinheiro vai junto.
Observe como isto é certo. Você solicita algo a um de seus funcionários. Em seguida pergunta: “Entendeu?” Como ninguém admite 
limitações pessoais e geralmente têm um ego elevado, as pessoas respondem sempre: “Entendi, sim senhor!” Em seguida, elas 
saem, fazem as coisas de seu próprio modo, e só ao retornar descobrem que não haviam entendido nada do que você lhes pediu.
Falhas de comunicação viram erros e defeitos com grande facilidade e frequência.
Imagine cada funcionário da sua empresa cometendo erros. E eles cometem! Todos os dias. Erros que não são contabilizados. E 
quem paga? Vá conferir. E de quem é a culpa? Quer saber? É da falta de habilidade na comunicação.
Isto pode mudar, se você quiser. É possível aprender a se comunicar bem. Para começar, olhe para o fato de que você não nasceu sa-
bendo nada do que mais domina hoje. Teve de aprender tudo. Como aprende? Mudando comportamentos. Agora se defronta com a 
realidade de que promover novas mudanças será mais barato do que continuar gastando com retrabalho. E há outro agravante. Você 
não encontra profissional completo ou pronto. Parte da formação desejável no perfil ideal do candidato que você busca, terá de ser 
completada dentro empresa, depois de contratado. Sem isso, não há como salvar os seus funcionários do amadorismo.
E sobre a comunicação? O que fazer? Comece questionando mais. Substitua a frase: “Você entendeu?” por um pedido para que o 
colaborador diga com suas próprias palavras o que pretende praticar após sair de sua sala. Você verá nisso uma atitude que irá pro-
duzir mais acertos, poupando prejuízos e dores de cabeça. “
 Para finalizar, veja o que ocorre nesta cena. O sujeito entra num bar e o garçom chega dizendo:
 - Boa noite, o que o senhor toma?
 O fulano responde:
 - Eu tomo vitamina C pela manhã, o metrô para ir ao serviço e uma aspirina para dor de cabeça.
O garçom, paciente, retifica:
 - Desculpe senhor. Acho que não fui claro. Quis saber o que o senhor gostaria?
 - Tudo bem! – diz o cliente – Eu gostaria de ter uma Ferrari, uma linda namorada e um milhão de dólares na conta.
 - Não é nada disso, cavalheiro! - continua o garçom. - Eu só preciso saber o que o senhor deseja beber.
 - Agora sim! - diz o sujeito - Bem... então me diga o que é que você tem?
 E o garçom:
 - Eu? Nada, não! Imagine. Só estou um pouco chateado porque o meu time perdeu para o Corinthians hoje à tarde!
 Viu só? Imagine como não deve ser nas empresas por aí!”
 Fonte: http://etiquetagem.blogspot.com.br/2010/05/comunicando.html
Testes de Software
26
Ambiente de Testes Automatizados
Cada tipo de teste possui restrições próprias relaciona-
das com o ambiente, que podem ter como dependência a 
flexibilidade e portabilidade das tecnologias utilizadas. Fa-
tores externos de software ou hardware também podem 
influenciar a definição de onde executar os testes.
Um ambiente compartilhado de testes ou ambiente 
de homologação, que é um ambiente criado para replicar 
todas as condições do ambiente de produção, contribui 
para a eficiência na execução dos testes e qualidade final 
da entrega. Não é fácil a criação e manutenção deste am-
biente, então, quando ele já está em uso, deve ser usado 
de forma abrangente.
Com o tempo, é comum esta infraestrutura do am-
biente de homologação correr o risco de ficar desatua-
lizada, e neste momento a equipe deve buscar mostrar 
aos responsáveis da área técnica a importância da manu-
tenção de um ambiente de homologação atualizado. Este 
ambiente deve espelhar o máximo possível o ambiente de 
produção, de forma a buscar garantir sucesso na execução 
dos testes.
Existem várias alternativas para criar ou montar este 
ambiente de homologação, entre elas encontramos, por 
exemplo, a virtualização, que quando usada eficazmen-
te pode gerar um ambiente adequado e de baixo custo. 
Quando há uma grande quantidade de testes sendo exe-
cutados neste ambiente simultaneamente, pode haver 
uma sensível queda de desempenho do sistema, o que 
normalmente não compromete confiabilidade dos testes.
De acordo com Delamaro, Maldonado e Jino (2007), 
os testes de desempenho, de carga, de estresse e de 
longevidade requerem um ambiente de testes similar 
ao ambiente de produção, porque os resultados obtidos 
estão diretamente relacionados com o ambiente. Os tes-
tes de segurança normalmente requerem, também, uma 
infraestrutura similar ao do ambiente de produção, pois 
espera-se que estes testes exponham as vulnerabilidades 
do sistema no ambiente adequado. Os testes de correção 
(unidade, integração, aceitação, etc) não necessitam dos 
mesmos ambientes, produção ou homologação, portanto 
há maior flexibilidade, pois pode-se usar até mesmo em 
um hardware local ou a máquina do desenvolvedor.
Quando executar os testes 
automatizados
Existem testes rápidos e alguns mais demorados para 
serem realizados. A definição de prioridades é essencial 
para o sucesso na execução dos testes.
Bernardo e Kon (2008) alegam que não é uma tarefa 
fácil alcançar uma boa qualidade em um software, pois 
os mesmos são complexos, e envolvem problemas no 
processo de desenvolvimento, como questões humanas, 
técnicas, burocráticas, de negócio e políticas, Pressman 
(2010) garante que o teste de software é um fator decisivo 
para garantir a qualidade de um programa.
Ainda de acordo com Pressman (2010), alguns testes, 
por sua simplicidade, podem ser executados a todo o mo-
mento, como os testes de desempenho e longevidade. Há 
outros que devem ser programados, como os testes de 
segurança e desempenho, os quais geram invariavelmen-
te lentidão pode causa das ferramentas que necessitam 
utilizar. Outros tipos de testes, como carga e estresse, não 
precisam ser executados a todo o momento, pois avaliam 
a infraestrutura e esta normalmente não é alterada com 
frequência.
O custo da criação destes testes automatizados nor-
malmente é bem maior do que a dos testes manuais, 
principalmente por causa da estrutura por trás deste am-
biente.
Saff e Ernst (2003) afirmam que o uso de metodologia 
ágil incentiva a criação do ambiente de integração contí-
nua, no qual se mantém o código fonte sempre testado 
e confiável, diminuindo a alocação de recursos humanos 
Testes de Software
27
em atividades de teste, pois este framework atua com en-
tregas imediatas, o que exige validação imediata. 
Importante destacar que executar testes com frequ-
ência é fundamental. É mais vantajoso executar baterias 
pequenas e frequentes de testes do que uma rara e gran-
de bateria. Além disso, as baterias de testes que não são 
executadas com frequência podem se tornar obsoletas, 
correndo o risco de ficarem desatualizadas e, consequen-
temente, não acompanharem a evolução natural dos 
componentes relacionados. 
É importante destacar que quanto mais obsoleto se 
torna um teste, mais caro fica, comprometendo recursos 
e podendo, no momento mais importante, não atender 
à solicitação de seus usuários. Também a não execução 
periódica causa acúmulos de erros ou falhas que pode 
tornar a implementação de melhorias incompatível como cumprimento de prazos estabelecidos. 
Há softwares gratuitos que podem dar uma base ou 
referência para testes integrados de software. Veja alguns 
exemplos:
 9 JMeter: http://jakarta.apache.org/jmeter
 9 Selenium-IDE: http://selenium-ide.openqa.org
 9 SUnit: http://sunit.sourceforge.net
 9 JUnit: http://www.junit.org
 9 TestNG: http://testng.org
 9 JSUnit: http://www.jsunit.net
 9 CppTest: http://cpptest.sourceforge.net
 9 csUnit: http://www.csunit.org
 9 Eclipse: http://www.eclipse.org
 9 Selenium: http://selenium.openqa.org
 9 Selenium RC: http://selenium-rc.openqa.org
Além destas ferramentas, também existem linguagens 
específicas que podem ser usadas, como:
 9 DOM- Document Object Model que é uma lin-
guagem para permitir que programas acessem e 
modifiquem dinamicamente objetos de um do-
cumento HTML: http://www.w3.org/DOM/
 9 XPath - XML Path Language que é uma lingua-
gem para identificar trechos específicos de um 
arquivo XML: http://www.w3.org/TR/xpath
Conheça a ferramenta de Teste de Software CruiseControl, 
que é um gerenciador de build de código aberto e gratuito, 
escrito em Java, muito utulizada como uma ferramenta de 
teste contínuo:
 http://cruisecontrol.sourceforge.net/
Documentação de Teste de 
software
O IEEE - Institute of Electrical and Electronic Engineers, 
organização sem fins lucrativos responsável por promover 
o conhecimento nas áreas de Engenharia Elétrica, Eletrô-
nica e Computação, define padrões para diversas áreas e 
práticas presentes na Engenharia de Software.
O padrão IEEE 829 está relacionado com o processo 
de testes. Sua abrangência vai desde testes unitários até 
testes de aceitação e inclui a definição de documentos 
consistentes e adequados capazes de definir, registrar e 
prover condições de análise dos resultados obtidos ao 
longo do processo de testes de software.
Esta norma descreve um conjunto de 8 documentos 
que cobrem as tarefas de planejamento, especificação e 
relatórios de testes. São eles:
• Plano de Teste: é um documento que apresenta 
o planejamento para a execução do teste e identifi-
ca os itens e as funcionalidades a serem testados, 
bem como as tarefas e os riscos associados com a 
atividade de teste.
Testes de Software
28
• Especificação de testes: é composta por 3 docu-
mentos (Especificação de Projeto de Teste, Espe-
cificação de Caso de Teste e Especificação de Pro-
cedimento de Teste) que identificam os casos e os 
procedimentos de teste, critérios de aprovação, 
definem dados de entrada e resultados esperados, 
além de especificar os passos para a execução dos 
testes.
• Relatórios de testes: são compostos por 4 docu-
mentos (Diário de teste, Relatório de Incidente de 
Teste, Relatório-Resumo de Teste e Relatório de 
Encaminhamento de Item de Teste) que visam re-
gistrar detalhes relevantes, eventos que ocorrem 
durante os testes e resultados das atividades.
 
Bossi (2010) destaca que esta norma separa as ativida-
des de teste em três etapas: preparação do teste, execu-
ção do teste e registro do teste. A autora afirma que mais 
do que apresentar um conjunto de documentos, esta nor-
ma apresenta um conjunto de informações necessárias 
para teste de produtos, independentemente do tamanho 
ou complexibilidade do software. 
Em sua proposta, a norma IEEE-829 descreve um mé-
todo para implantação do processo de teste de software 
em alguns documentos, cujo teor principal está relaciona-
do abaixo. 
• Guia para Elaboração de Documentos de Teste de 
Software: tem o propósito de servir como referên-
cia para criação de documentos de teste.
• Processos para a Elaboração de Documentos de 
Teste de Software: apresenta os processos que 
abrangem a preparação, a execução e o registro dos 
resultados do teste, estabelecendo uma orientação 
geral. 
 
No site http://www.testexpert.com.br/?q=node/1666
Fábio Martinho (2010) disponibiliza templates da norma IEEE- 829 para download.
Os templates disponibilizados são: 
1. Master Test Plan Template - Plano de Testes Mestre
2. Test Case Specification Template - Especificação de Casos de Teste
3. Test Design Specification Template - Especificação de Design(Projetos) de Teste
4. Test Incident Report Template - Relatório de Incidente de Teste
5. Test Log Template - Log de Teste
6. Test Procedure Specification Template - Especificação de Procedimento de Teste
7. Test Status Report Template - Relatório de Status de Teste
8. Test Summary Report Template - Relatório de Sumário de Teste
9. Unit-Integration Test Plan Template - Plano de Teste para Testes Unitários e Integrados
Recomenda-se que, independentemente da forma como os documentos da norma sejam adaptados para a docu-
mentação dos testes, é importante que incluam o planejamento, o projeto, os casos de teste e os procedimentos de 
teste. Além disso, os resultados e incidentes ocorridos durante o teste devem ser adequadamente registrados e con-
densados num relatório final. Isso garantirá que todo o processo de testes possa ser adequadamente realizado e bem 
documentado.
Testes de Software
29
Exercícios do Capítulo 2 
1 - Identifique que conceito não é importante para o sucesso na implantação e manutenção dos testes de sof-
tware:
a) Clareza
b) Comunicação
c) Transparência
d) Economia
e) Nenhuma das anteriores
2 - Um dos problemas relacionados a este teste é o buffer overflow, ou a necessidade de maior capacidade de 
armazenamento. 
a) Segurança
b) Longevidade
c) Estresse
d) Integração
e) Sistema
3 - Tem como objetivo revelar a presença de erros. Descobre o maior número possível de erros, alguns, depen-
dendo do desenvolvimento previamente já identificado para comprovar a eficiência do teste.
a) Sistema
b) Correção
c) Estresse
d) Integração
e) Nenhuma das anteriores.
4 - São programas ou scripts simples que exercitam funcionalidades do sistema sendo testado e fazem verifica-
ções automáticas nos efeitos colaterais obtidos.
a) Testes oficiais
b) Testes de equivalência 
c) Testes Automatizados
d) Testes frequentes
e) Testes Manuais
5 - Podemos afirmar sobre testes de baixo nível:
a) São testes realizados no fim do projeto.
b) São testes de hardware, por isso de baixo nível.
c) São testes completos do sistema.
d) Atuam nos problemas complexos do programa.
e) Atuam na identificação de problemas em um pequeno segmento do código fonte.
Testes de Software
30
Testes em Modelagem Ágil
Modelos Ágeis e Testes de Software 
Como vimos na disciplina Métodos Ágeis de Programa-
ção, a modelagem ágil pode ser definida como “um fra-
mework para o cotidiano”. Esta definição de modelagem 
ágil é uma realidade para as empresas que necessitam de 
desenvolvimento eficiente. A modelagem ágil estabelece 
um conjunto de práticas no desenvolvimento de software 
que está cada vez mais se tornando habitual. Mas, dife-
rente do que muitos pensam, não existe um modelo pré-
-definido ou um conjunto de regras a serem adotados. 
Na modelagem ágil cada equipe, dentro de suas atri-
buições e de acordo com as características dos projetos da 
empresa, adota uma forma ágil mais adequada para aten-
der suas demandas. Isto quer dizer que em modelagem 
ágil, apenas é mostrado o caminho e a equipe adota as 
práticas mais adequadas dentro do conceito ágil. Não há 
procedimentos ideais pré-estabelecidos apenas princípios 
adotados a partir da necessidade particular do negócio. 
Segundo Highsmith & Cockburn (2001), a novidade 
nos modelos ágeis não está nos métodos ágeis, e sim no 
envolvimento de pessoas que participam no sucesso do 
projeto e que estão focados na capacidade de gestão do 
negócio. 
Uma das importantes fases da modelagem ágil são as 
histórias que são relatadas principalmente pelo product 
owner, responsável porrepresentar o cliente dentro da 
equipe de desenvolvimento. Estas histórias determinarão 
o caminho ideal a ser seguido na modelagem e são cha-
madas de Story-Writing Workshops. 
A modelagem ágil visa colocar em prática o conjunto 
de valores que o negócio já possui. Vamos imaginar um 
brainstorm, no qual todas as ideias são apresentadas e 
depois colocadas em uma desafiadora sequência de ações 
e procedimentos. A modelagem ágil começa a ser aplica-
da desta forma. Durante este procedimento de implan-
tação encontramos os procedimentos relacionados aos 
testes de softwares.
Vamos voltar a um conceito antigo relacionado à lógi-
ca de programação. Os mais experientes se lembram de 
que muito antes de começar a desenvolver um programa, 
o programador desenhava um diagrama de fluxo de da-
dos estruturado do sistema e somente depois começava 
a programação em si. Estes profissionais mais experientes 
entendiam que se você soubesse passar por esta fase an-
tes da programação, a linguagem de programação seria 
apenas um detalhe. Assim, você poderia escolher qual-
quer linguagem, pois a lógica de funcionamento seria a 
mesma. Na modelagem ágil ocorre o mesmo, a linguagem 
é um detalhe que pode ser pensada e adotada depois do 
entendimento dos requisitos que o software precisa aten-
der.
Em teste de software, encontramos a figura do tes-
tador que atua junto com a equipe de desenvolvimento 
estabelecendo técnicas ou definindo conceitos que serão 
aplicados durante o desenvolvimento para testar a inte-
gridade e validar os resultados.
 O testador não precisa ser um componente externo, 
pois dependendo das definições prévias, ele poderá ser 
um dos integrantes de dentro do time ou grupo. Este tes-
tador será um componente valioso e, como tal, participa-
rá ativamente no apoio para as entregas consecutivas que 
ocorrem neste modelo de desenvolvimento.
De acordo Beck (2012), o Manifesto Ágil diz que “Esta-
mos descobrindo maneiras melhores de desenvolver sof-
tware fazendo-o nós mesmos e ajudando outros a fazê-lo. 
Através deste trabalho, passamos a valorizar:
• Indivíduos e interação entre eles mais que pro-
cessos e ferramentas
• Software em funcionamento mais que documen-
tação abrangente
Testes de Software
31
• Colaboração com o cliente mais que negociação 
de contratos
• Responder a mudanças mais que seguir um pla-
no”
Caros alunos, como vimos no nosso estudo de méto-
dos ágeis, nos modelos ágeis os seguintes princípios são 
seguidos: 
 9 maior prioridade é satisfazer o cliente através da 
entrega contínua e adiantada de software com 
valor agregado;
 9 mudanças nos requisitos são bem-vindas, mes-
mo tardiamente no desenvolvimento. 
 9 entregar frequentemente software funcionan-
do, de poucas semanas a poucos meses, com 
preferência à menor escala de tempo;
 9 pessoas de negócio e desenvolvedores devem 
trabalhar diariamente em conjunto por todo o 
projeto;
 9 projetos devem ser construídos em torno de in-
divíduos motivados;
 9 o método mais eficiente e eficaz de transmitir 
informações para e entre uma equipe de desen-
volvimento é através de conversa face a face;
 9 o software funcionando é a medida primária de 
progresso;
 9 os patrocinadores, desenvolvedores e usuários 
devem ser capazes de manter um ritmo cons-
tante indefinidamente;
 9 a contínua atenção, a excelência técnica e o bom 
design aumenta a agilidade;
 9 a simplicidade e a arte de minimizar a quantida-
de de trabalho não realizado são essenciais;
 9 as melhores arquiteturas, requisitos e design 
emergem de equipes auto organizáveis.
Em intervalos regulares, a equipe deve refletir sobre 
como se tornar mais eficaz e então refinar e ajustar seu 
comportamento de acordo. Portanto, podemos perfei-
tamente concluir que as condições ideais existentes que 
levam um negócio a implantar o modelo ágil também são 
ideais para se implantar os testes de software de forma 
muito eficiente.
Assim, o mesmo princípio de modelo ágil se aplica em 
teste de software: não existe uma fórmula mágica padro-
nizada e ideal, cada empresa, de acordo com suas neces-
sidades específicas adotará o procedimento ideal. E se 
este modelo não existir, deve ser criado um que atenda as 
suas necessidades.
Teste de software no Scrum
No Scrum encontramos o ambiente ideal para a ativi-
dade de teste de software.
Como vimos na disciplina “Métodos Ágeis de Progra-
mação”, Scrum é o nome de uma jogada derivada do Ru-
gby, como mostra a figura 8. No Scrum todas as equipes, 
como as responsáveis pela Configuração, Instalação, Ne-
gócios, Teste, Desenvolvimento, entre outras, fazem parte 
de um mesmo Time. Com a fusão das equipes no mesmo 
Time, o Scrum permite que todos trabalhem de forma 
integrada facilitando a comunicação e gerando um am-
biente de parceria na empresa. 
Figura 8 - Scrum no Rugby
Fonte:
http://blog.castsoftware.com/wp-content/uploads/2011/05/rugby-
scrum-kbear65-flickr-300x200.jpg
Testes de Software
32
Desta forma, a equipe de teste não é vista pela equipe 
de desenvolvimento como adversária, mas como parcei-
ra. Assim, existe uma grande interação entre os profissio-
nais que atuam no desenvolvimento, tornando possível 
encontrar o verdadeiro espírito de equipe. Esta condição 
elimina naturalmente algumas barreiras comumente en-
contradas em equipes que são submetidas a testes e ava-
liações por componentes externos.
No Scrum há diversas entregas a serem feitas e o con-
ceito do que está “pronto” para ser entregue, pode ser 
diferente, pois um determinado item pode estar pronto 
dependendo do conceito de conclusão/término estabele-
cido pela equipe. No caso do Scrum, um item “pronto” 
para ser entregue, associado a testes de software, pode 
significar:
 9 Codificação + Teste concluído
 9 Codificação + Teste + Integração concluída
 9 Codificação + Teste + Regressão concluída
 9 Codificação + Teste + Integração + Regressão + 
Instalação concluída 
No Scrum não existe um fase específica de teste fora 
da etapa de implementação. Na prática testes iterativos 
são executados durante todo o desenvolvimento, como 
os testes de unidade e os testes de caixa preta. Uma fun-
cionalidade só é considerada concluída quando todos os 
testes foram executados durante o desenvolvimento. O 
analista de teste, no Scrum, faz parte do time e assume 
várias responsabilidades, como líder, arquiteto e respon-
sável pela automatização. Ele participa ativamente no 
levantamento de requisitos e definição de escopo. Ele 
trata com grande relevância a necessidade do cliente con-
siderando os objetivos que o software deve alcançar na 
medida em que ele é entregue. Ao fim de cada Sprint, o 
analista de testes, junto com o Time, são responsáveis por 
garantir que todos os testes automatizados tenham sido 
executados sem falhas. 
De acordo com Highsmith & Cockburn (2001), para al-
cançar os resultados adequados, o testador realizará algu-
mas tarefas, como:
 9 Participar das discussões de definição de arqui-
tetura;
 9 Participar das definições de tecnologias utiliza-
das;
 9 Identificar as necessidades do ambiente de tes-
te;
 9 Identificar restrições tecnológicas;
 9 Identificar ferramentas de teste necessárias 
para auxiliar na execução do projeto;
 9 Utilizar mapa mental para auxiliar no entendi-
mento das funcionalidades/requisitos;
 9 Identificar os “melhores” analistas de teste para 
o projeto em questão;
 9 Identificar a necessidade de suporte do time de 
suporte/operações.
 9 Estimar o tempo de teste.
Sua participação na definição de usuários e tarefas 
será de grande contribuição para que a equipe continue 
com sua atuação integrada.
Este profissional ganha um papel importante na mo-
delagem ágil, pois participará ativamente do desenvol-vimento, implantando técnicas práticas e eficientes de 
testes de software, levando em consideração o negócio e 
suas necessidades.
A equipe, como um todo, sempre atuará para o bene-
fício do projeto, portanto, o testador, componente agora 
agregado ao time, se integra, participando ativamente e 
colaborando de forma significativa na criação de um sof-
tware com o mínimo de falhas, defeitos e erros.
O analista de testes no Scrum
De acordo com Duong (2009), o Analista de Teste, 
como importante membro do Time, participa ativamente 
de todos os processos, apoiando o Scrum Master, que faz 
a mediação, e consultando o Product Owner para escla-
recer eventuais dúvidas. A figura 9 mostra as principais 
etapas e membros envolvidos num projeto Scrum.
 
Testes de Software
33
Na primeira parte do Planning Meeting (Reunião de 
Planejamento) o Product Owner define a meta da Sprint 
e divulga para o Time os itens prioritários do Product Ba-
cklog. O Time estima os itens e seleciona o que vai ser 
feito. O Analista de Teste participa dessa fase para garan-
tir que os itens selecionados estejam de acordo com as 
metas do projeto de testes, analisa os indicadores de de-
sempenho, gerencia os riscos encontrados e define quais 
serão os tipos de teste (Sistema, Aceitação, Regressão) 
necessários. 
Na segunda parte da Planning Meeting o Time obtém 
mais detalhes dos itens do Select Product Backlog e os 
divide em tarefas gerando o Sprint Backlog. O Analista de 
Teste participa desta fase definindo o nível de regressão 
de teste de acordo com a priorização dos itens/tarefas do 
Sprint Backlog, atualizando a matriz de teste por funcio-
nalidade e atualizando o mapa mental. 
Após a definição da Sprint, o quadro de acompanha-
mento é preparado. Este quadro vai sendo alterado de 
acordo com as necessidades do projeto. O Analista de 
Figura 9 – Projeto Scrum
Fonte: http://alanbraz.wordpress.com/
Teste é a pessoa que aprova. Nada é considerado “pron-
to” em um Sprint até que ele diga que está. É responsável 
por ficar focado na meta da Sprint. Durante a execução da 
Sprint o Analista de Teste realiza as seguintes atividades: 
 9 Monta e configura o ambiente e infraestrutura 
de teste; 
 9 Executa testes; 
 9 Automatiza casos e tarefas de teste; 
 9 Auxilia os desenvolvedores na elaboração dos 
testes unitários automáticos; 
 9 Mostra os resultados dos testes; 
 9 Acompanha os defeitos encontrados.
Na reunião diária (Daily Scrum) de 15 minutos, o Time 
ganha visibilidade de como está o caminho para a meta 
e planeja o dia seguinte de trabalho. Embora o Scrum 
Master seja o facilitador, o Analista de Teste também par-
ticipa dessas reuniões contribuindo com a elaboração e 
atualização dos seguintes documentos: relatório de teste; 
Testes de Software
34
evidência de teste; gráfico S-Curve; lista de defeitos; lista 
de impedimentos; quadro Kanban. 
O Analista de Teste participa de outras 2 reuniões: reu-
nião de Revisão, que possui o propósito de apresentar o 
que foi feito para o Product Owner e convidados e reu-
nião de Retrospectiva que possui o objetivo de represen-
tar o espírito de Inspeção – Adaptação dentro do Scrum. 
Na reunião de Revisão é realizada uma apresentação por 
todo o Time e o Product Owner avalia se a meta foi al-
cançada e faz anotações que podem ser transformar em 
novos itens para o Product. A reunião de Retrospectiva é 
facilitada pelo Scrum Master e nela são apresentadas as 
lições aprendidas. O Time avalia o que foi bom na última 
Sprint, o que deve ser melhorado e quem está no contro-
le. 
Assim, como pudemos ver, o Analista de Teste partici-
pa de todas as fases do Scrum, pois ele faz parte de um 
Time. Não existe Time de Teste ou Time de Desenvolvi-
mento no Scrum, mas como vimos, Time do Scrum. 
Tipos de Testes Usados na 
Modelagem Ágil
Os processos ágeis, como vimos, se destacam dos 
métodos tradicionais de desenvolvimento, devido prin-
cipalmente à priorização das funcionalidades através do 
código executável, ao invés da produção extensa da do-
cumentação escrita. Um ponto essencial para garantir a 
fidelidade das implementações em relação aos requisitos 
está nos testes executados sobre o código produzido.
Hendrickson (2012) afirma que para a implementa-
ção de técnicas ágeis no ambiente de testes é necessá-
rio mudar a maneira que as equipes estão acostumadas 
a trabalhar. Uma das mudanças necessárias é a introdu-
ção ao conceito de colaboração com o cliente, ao invés 
de se utilizar documentação abrangente, em consonân-
cia com o manifesto ágil. Desta maneira passamos a fazer 
um trabalho mais próximo com o cliente, e sua partici-
pação no processo é peça chave para que a técnica ágil 
de testes possa ser adotada. Outro ponto importante é 
que todos da equipe devem realizar testes e não apenas 
o analista de testes. De acordo com a autora, em um mé-
todo ágil costuma-se dizer que a equipe é infectada por 
testes e desta maneira o sistema é construído para estar 
testado desde o início do projeto e não apenas no fim da 
codificação.A qualidade passa a ser da equipe e não ape-
nas dos analistas de testes ou profissionais que possuem 
a palavra “qualidade” nos seus cargos.
Os requisitos de testes para a metodologia ágil não 
possuem grande diferenciação em processos guiados por 
planos. O que realmente difere é o grau de importância 
dado aos testes em cada um dos processos.
Nos processos guiados por planos, existe uma série 
extensa de artefatos documentais resultantes da análise 
profunda realizada sobre o sistema a ser desenvolvido. Os 
testes, neste caso, são apenas mais um artefato produ-
zido pelo processo, visando garantir a detecção de erros 
antes da liberação da versão final.
O projeto que nasce com cobertura de teste desde iní-
cio permite a realização de Teste de Regressão, que impli-
ca em se executar testes em todo o sistema e não apenas 
na funcionalidade implementada.
Ainda de acordo Elisabeth Hendrickson (2012) um sis-
tema com cobertura de testes desde o início deve reali-
zar o máximo possível de testes automatizados para que 
o trabalho manual e repetitivo não venha a ocorrer. Isso 
trará ganho de tempo na execução do teste e o custo de 
transformar um caso de teste em automatizado rapida-
mente se paga. A autora afirma que “eu tenho observado 
em minhas equipes um custo de 30% a mais na execução 
e transformação do teste em automatizado, mas após a 
3ª vez que eu executo a bateria de testes, eu já vejo como 
este custo de 30% foi pequeno”. A autora segue dizendo 
que o tempo de execução do teste automatizado em rela-
ção ao manual é incomparável, os ganhos de velocidade 
de execução e a possibilidade de a qualquer momento re-
alizar um teste de regressão são maiores.
Testes de Software
35
Os testes em métodos ágeis devem seguir o conceito 
de pequenas interações para que a informação de como 
o sistema está sendo construído e os erros que são detec-
tados possam ser rapidamente identificados e corrigidos. 
Ao término de uma interação, todos os testes devem ter 
sido executados com êxito.
Segundo Erdogmus et al (2005), os testes nas meto-
dologias ágeis, são importantes e os autores fazem as se-
guintes considerações em relação aos tipos de teste: 
• Testes Manuais: objetivam utilizar o sistema para 
tentar encontrar anomalias no funcionamento do 
software. Geralmente são pouco eficientes, pois di-
ficilmente se conseguiria chegar à exaustão detec-
tando todas as anomalias. Mas, mesmo com pouca 
eficiência e fragilidade, ainda são utilizados pela 
facilidade e simplicidade de sua aplicação, já que 
basta inserir o sistema em ambiente de validação, 
simular as entradas e considerar os resultados obti-
dos.
• Testes Automatizados: