Gerenciamento de Testes de Software

Prévia do material em texto

AULA 12 - Gerenciamento de testes
Apresentação
Você já se deu conta de como a sua vida está imersa em sistemas eletrônicos digitais? Já observou 
o quanto está rodeado por diferentes equipamentos e dispositivos digitais que estão, 
continuamente, monitorando, processando, controlando e, em última análise, atendendo a todas as 
suas vontades e necessidades? Observe também que a programação inserida nesses sistemas, 
denominada software (de forma técnica e genérica), governa todas as ações realizadas, 
influenciando com seus resultados, direta ou indiretamente, nas atividades cotidianas. Exemplos 
desse processo podem ser vistos na área econômica, com o pagamento de contas; no turismo, com 
a compra de passagens aéreas; na saúde, com o registro nacional de doadores voluntários de 
medula óssea; entre outros.
Uma falha em um desses programas poderá gerar erros em cadeia, com danos financeiros, materiais 
e até para a própria vida humana. Além disso, a falha pode tornar o produto de software inaceitável 
ao usuário, causando prejuízos significativos ao fabricante.
Como é possível, então, evitar as falhas? Testando o software. Assim, testar de formas diferentes e 
de modo organizado, documentado e estruturado, compõe o objetivo do gerenciamento de testes.
Nesta Unidade de Aprendizagem, você conhecerá o gerenciamento de testes, aprendendo os 
conceitos principais e os fundamentos que orientam essa importante atividade, e aprenderá uma 
metodologia básica de gestão de testes, o bug tracking. Por último, verá a aplicação do 
gerenciamento de testes a partir de usos de ferramentas que utilizam o bug tracking.
Bons estudos.
Ao final desta Unidade de Aprendizagem, você deve apresentar os seguintes aprendizados:
Definir o que é gerenciamento de testes.•
Analisar a gestão de gerenciamento de teste por meio de sistemas de bug tracking.•
Aplicar o gerenciamento de teste por meio de sistemas de bug tracking.•
Infográfico
O processo de gestão de testes é fundamental na garantia da qualidade do software, sem falar dos 
aspectos de segurança e de aceitação por parte do usuário. No entanto, na medida em que se 
explora esse assunto, fica clara a complexidade do processo de realizar o acompanhamento e o 
adequado entendimento do que concretamente precisa ser testado quando é necessário executar 
efetivamente o gerenciamento de testes.
Neste Infográfico, você encontrará uma síntese objetiva do que deve ser avaliado em cada etapa de 
testes do processo de gerenciamento.
A imagem a seguir possui audiodescrição. Para acessar o recurso, clique aqui
https://creator-files.plataforma.grupoa.education/undefined/20538_Audiodescricao_Infografico-2025-09-29T12:15:59-03:00.docx
Aponte a câmera para o 
código e acesse o link do 
conteúdo ou clique no 
código para acessar.
https://statics-marketplace.plataforma.grupoa.education/sagah/1c219276-c29d-4f9e-be15-760b5873c5b7/cf5ec1d2-7c49-4452-89c7-fd291917018b.jpg
Conteúdo do Livro
Hoje, em pleno século XXI, pode-se afirmar, sem nenhuma dúvida, que vivemos em uma sociedade 
essencialmente digital. Não é possível mais prescindir de sistemas e processos digitais, garantindo, 
a todo momento, segurança, conforto e bem-estar aos usuários. Como parte inerente desse 
ambiente digital, os softwares programados nesses sistemas digitais realizam todo o processamento, 
estabelecendo a realização de toda sorte de tarefas e processos. Nesse contexto, é de fundamental 
importância a execução sem falhas, pois do contrário os dados e prejuízos causados por alguma 
falha podem ter consequências trágicas, incluindo até perdas de vidas.
 
O gerenciamento de testes é uma tarefa fundamental para o desenvolvimento adequado de 
softwares, procurando-se obter como resultado um sistema tão livre de falhas quanto possível.
 
No capítulo Gerenciamento de teste, do livro Testes de software e gerência de configuração, você 
aprenderá os conceitos e fundamentos sobre o processo de testagem de software. Também 
conhecerá uma metodologia de rastreamento de defeitos, o bug tracking, além de exemplos sobre 
como funcionam ferramentas que realizam o bug tracking.
 
Boa leitura.
 
Os elementos gráficos deste capítulo possuem audiodescrição. Para acessar o recurso, 
clique aqui
https://creator-files.plataforma.grupoa.education/undefined/20538_Audiodescricao_Conteudo_do_livro-2025-09-22T17:42:20-03:00.docx
TESTES DE 
SOFTWARE E 
GERÊNCIA DE 
CONFIGURAÇÃO 
Rubem Dutra Ribeiro Fagundes
Gerenciamento de testes
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:
  Definir o que é gerenciamento de testes.
  Analisar o gerenciamento de testes por meio de sistemas de bug 
tracking.
  Aplicar o gerenciamento de testes por meio de sistemas de bug 
tracking.
Introdução
Neste capítulo, você vai conhecer com maior profundidade uma das 
atividades mais importantes do desenvolvimento de softwares: o 
gerenciamento de testes de software. Ele é responsável pelo funcio-
namento correto, pela segurança e pela aceitação de um produto por 
parte do usuário.
Ao longo do capítulo, você vai conhecer a definição de gerenciamento 
de testes e analisar a realização do processo de gestão por meio de siste-
mas de bug tracking. Por fim, vai aplicar de forma efetiva o gerenciamento 
de testes por meio de sistemas de bug tracking.
Definição e fundamentos
Hoje, mais do nunca, vive-se numa sociedade essencialmente digital. O fun-
cionamento, a segurança e o bem-estar da população do Planeta dependem 
de sistemas de software e automação, que continuamente coletam dados, 
monitoram e controlam processos, atendendo às mais variadas necessidades 
do homem. Os programas, ou softwares, é que governam todos esses sistemas 
digitais. Em síntese, os softwares são a inteligência implantada nos sistemas 
por profi ssionais da área de Tecnologia da Informação (TI), que utilizam 
diferentes linguagens de programação.
Nesse cenário, é fácil perceber a importância do desenvolvimento correto 
de um software, visto que quaisquer ações indevidas realizadas por um ou 
mais sistemas podem acarretar sérios problemas. Por isso, na engenharia de 
software, a realização de testes é fundamental. Não se admite que qualquer 
produto de software seja utilizado sem passar por uma etapa de testagem 
durante o seu desenvolvimento.
Segundo Sommerville (2011), o gerenciamento de testes é uma etapa 
fundamental. Ela faz parte do processo de gerenciamento de configuração 
(Configuration Management — CM). Afinal, um software não se resume à 
programação. Ele é desenvolvido em etapas que envolvem pessoas e equipes, 
requisitos e necessidades sobre o produto, além de tomadas de decisão em 
inúmeros momentos. Em essência, o software necessita de gerenciamento 
para existir como produto. Assim, o gerenciamento de configuração lida 
diretamente com os processos de mudanças que o software sofre durante o 
seu desenvolvimento.
O gerenciamento de software é composto pelas atividades de (SOMMERVILLE, 2011):
  gerenciamento de alterações, que inclui gerenciamento de testes;
  gerenciamento de versões;
  construção do sistema;
  gerenciamento de finalização.
Inicialmente, você deve compreender o que é testar um software: é submetê-
-lo a um conjunto de situações tanto de funcionamento quanto de inspeção em 
sua estrutura, analisando-o em relação às suas especificações. Esse procedi-
mento de teste, chamado de testagem ou processo de testagem, é realizado 
com a intenção explícita de encontrar alguma falha (SINGH, 2012).
Na Figura 1, você pode ver um estudo do custo de identificar e corrigir 
uma falha em cada etapa do desenvolvimento de um software.
Gerenciamento de testes2
Figura 1. Gráfico custo de correção × etapa de detecção do erro. No eixo hori-
zontal, estão as fases de desenvolvimento do software ao longo do tempo; no 
eixo vertical, o custo do reparo de um erro.
Fonte: Singh (2012, p. 15).
Observe que, quanto mais cedo você identifica uma falha, menor é o custo 
de correção do erro. Durantea etapa de análise e especificação, o custo de 
identificação e correção do erro é mínimo. No entanto, o custo sobe de forma 
exponencial na medida em que a detecção e a correção ocorrem nas fases 
finais de testagem e entrega (release) (SINGH, 2012).
Outra questão importante é: quem deve testar o software? É consenso 
entre os especialistas da área que um software nunca deve ser testado por 
quem o desenvolveu. Os programadores não são as pessoas indicadas para 
realizar os testes justamente porque estão diretamente envolvidos e não irão 
identificar os erros que cometeram. Afinal, como você vai ver adiante, uma 
falha em um software é consequência de um erro humano cometido durante 
a codificação do programa.
3Gerenciamento de testes
Categorias e tipos de testes
A testagem deve ser realizada por uma equipe de testadores, coordenada por 
um gerente de testes. O gerente deve realizar tanto a preparação de um plano 
de testes para o software quanto o acompanhamento da execução dos testes e 
dos resultados. E isso durante todas as fases de desenvolvimento do software.
Na Figura 2, veja o diagrama V, que mostra os níveis de testes que devem 
ser realizados em cada etapa de desenvolvimento de um software.
Figura 2. Níveis de testes e etapas de desenvolvimento de um software.
Fonte: Braga (2016, p. 28).
O gerenciamento de testes consiste, então, em essência, no planejamento, 
na geração e na aplicação de conjuntos de testes específicos, bem como na 
coleta de resultados, na análise e nas correções, acompanhando todas as etapas 
de desenvolvimento do software.
Existem diferentes categorias de testes para cada etapa do desenvolvimento 
(BRAGA, 2016). Veja a seguir.
  Teste de unidade: é o teste mais básico e possibilita que cada módulo 
do sistema seja analisado de maneira individual. A ideia é verificar se 
a funcionalidade está correta. Essa avaliação pode ser feita até mesmo 
com trechos de código específicos.
Gerenciamento de testes4
  Teste de integração: é o teste que avalia a comunicação entre os mó-
dulos do software. Nessa categoria de testes, os módulos são agrupados 
de acordo com a estrutura do sistema e o aparecimento de erros é 
verificado de forma incremental.
  Teste de sistema: é o teste feito com o sistema completo e funcionando 
com todas as suas partes constituintes. Em tese, esse teste já é capaz 
de detectar erros que seriam encontrados pelo usuário final, ainda que 
não se considere o produto finalizado.
  Teste de aceitação: é o teste realizado na etapa final de entrega, envol-
vendo usuários alfa e beta e testes específicos definidos pelo cliente/
usuário ainda no momento da especificação do sistema.
Em engenharia de software, o uso e a distribuição de diferentes versões do produto 
são largamente empregados. Eles se destinam à realização de testes com o usuário, 
que fornecerá informações valiosas sobre o funcionamento do software. Veja a seguir 
(SOMMERVILLE, 2011):
  Versão alfa: destinada aos usuários do software que também trabalham junto à 
equipe de desenvolvimento. Essa versão é distribuída apenas internamente, não 
envolvendo clientes e tampouco o público externo.
  Versão beta: destinada a um grupo limitado de usuários externos que aceitam uti-
lizar o produto e relatar detalhes sobre funcionamento, falhas ocorridas, satisfação 
quanto ao atendimento das especificações definidas para o produto, diferentes 
ambientes de execução, etc.
  Versão de aceitação: destinada ao usuário final, mais especificamente em caso de 
software sob encomenda. O usuário utiliza intensivamente o produto, analisando 
o atendimento detalhado das especificações definidas na encomenda, com o 
objetivo de aceitar ou rejeitar a entrega do produto e a conclusão do projeto.
Observe que, para cada categoria de testes apresentada, existem vários 
tipos de testes que podem ser aplicados. Entre eles, destacam-se os listados 
a seguir.
  Teste de integridade de dados: testa a proteção dos dados quanto a 
alterações anormais, apagamentos e degradação.
  Teste de instalação e configuração: testa as condições de funciona-
mento, os procedimentos de instalação e os parâmetros de ambiente 
de sistema operacional.
5Gerenciamento de testes
  Teste de performance:
 ■ teste de estresse — testa as condições de funcionamento em situações 
de alta solicitação por parte do usuário ou grupo de usuários em 
atendimento simultâneo;
 ■ teste de carga — testa as condições de funcionamento com capacidade 
máxima de dados sendo processados simultaneamente.
  Teste de estabilidade: testa as condições de funcionamento regular 
do software, mantendo-se constantes as mesmas respostas, dados os 
mesmos estímulos.
  Testes não funcionais: testam o funcionamento e o uso do software em 
condições de campo e conforme padrões de comportamento do usuário.
Burnstein (2010) apresenta, de forma completa, a descrição desses tipos de testes. Ele 
detalha os procedimentos para o planejamento dos testes e descreve as diferentes 
abordagens de realização, como testes caixa-preta e testes caixa-branca.
Verificação e validação
É importante você entender que todas as categorias e tipos de testes devem, 
em essência, realizar duas ações básicas inerentes ao processo de teste, de 
acordo com Singh (2012):
TESTAGEM = VERIFICAÇÃO + VALIDAÇÃO
A seguir, você vai ver em que consiste cada uma dessas ações.
  Verificação: às vezes conhecida como “teste estático”, a verificação 
consiste na inspeção de todos os documentos, listagens de código, 
descrições e especificações, relatórios gerados pelos programadores 
a cada nova versão de módulo, relatórios gerados por ferramentas de 
projeto e relatórios de compiladores. A verificação procura encontrar 
possíveis erros antes mesmo da execução do software, seja em mó-
dulo ou sistema integrado, reduzindo ao mínimo a incidência de erro 
humano. Ferramentas de controle de versão, manuais de boas práticas 
Gerenciamento de testes6
de codificação, metodologias e protocolos definidos de geração de 
documentação de uso, instalação e configuração são procedimentos 
adotados em gerenciamento de configuração e que são indispensáveis 
ao processo de verificação.
  Validação: analisa o funcionamento do software desde a execução mó-
dulo a módulo, com os teste de unidade, até o funcionamento como um 
sistema integrado. Por ser uma análise dinâmica, o plano de testes deve 
prever as formas possíveis de realização dos testes a partir de diferentes 
cenários de funcionamento — os testes de cenário também são conhecidos 
como “testes de caso” (test case) — e de testes caixa-preta, analisando 
e comparando os resultados com as especificações de funcionamento.
Você ainda deve notar que o gerenciamento de testes é coordenado por meio 
de uma ou mais ferramentas que realizam a gestão dos testes, os testadores 
e os resultados.
Análise de gerenciamento de testes por meio 
de sistemas de bug tracking
No gerenciamento de testes, muitos dados são coletados, em várias situações, 
no decorrer do desenvolvimento do software como produto. Essa coleta vai 
desde as fases de avaliação e correção de erros, ainda sob responsabilidade 
dos programadores, até as fases fi nais de conclusão do sistema, com o uso de 
versões alfa, beta e gama.
Nesse contexto, é imprescindível a utilização de sistemas de apoio à coleta, 
que deve ser organizada e registrada com base em uma metodologia estruturada 
de acompanhamento dos testes, dos resultados esperados e dos resultados 
obtidos. Também é fundamental relacionar esses resultados com o módulo 
e/ou a etapa de desenvolvimento do produto. Assim, desde a realização do 
teste, passando pela identificação do defeito e pela correta identificação das 
partes do sistema causadoras do funcionamento anormal, é necessário o uso 
de ferramentas que permitam:
  rastrear os módulos constituintes;
  verificar qual é a versão correspondente a cada módulo ou biblioteca;
  determinar quem foi o programador ou a equipe de desenvolvimento 
envolvida nacodificação;
  apontar em qual ambiente de execução o defeito foi encontrado.
7Gerenciamento de testes
Tais informações devem estar corretamente descritas e documentadas. 
A metodologia e os sistemas de software utilizados como ferramentas de 
gerenciamento de testes são conhecidos como sistemas bug tracking.
Falha, erro, defeito e bug
Antes de você conhecer melhor os sistemas bug tracking, deve ter em mente 
o que são: falhas, erros, defeitos e bugs. Segundo Singh (2012), o termo bug 
signifi ca tanto “erro” quanto “defeito”, indistintamente. Em última análise, 
um tracking bug system rastreia erros ou defeitos no software sob teste.
Para entender melhor os conceitos de erro, defeito e falha, observe a Figura 
3 e as definições a seguir (BRAGA, 2016), retiradas do International Software 
Testing Qualifications Board (ISTQB, 2014).
Figura 3. Defeito, erro e falha.
Fonte: Adaptada de Braga (2016).
  Erro: é uma falha humana e produz um resultado incorreto. Como exemplo, 
considere uma falha na codificação de uma ou mais partes de um software.
  Defeito: é o resultado de codificação malfeita, de código mal escrito. 
Ou seja, é um erro que causa anomalias no funcionamento do sistema. 
No entanto, o usuário não tem conhecimento desse defeito.
  Falha: ocorre durante a execução do sistema. O código defeituoso 
apresenta uma falha, uma manifestação para o usuário de um funcio-
namento inesperado e fora da especificação definida em projeto. Essa 
é a camada em contato com o usuário.
Gerenciamento de testes8
Observe que, em última análise, um sistema de bug tracking tem como 
objetivo o rastreamento de erros ou defeitos, usando como principal pista as 
falhas detectadas durante a fase de teste.
O ISTQB é uma entidade internacional dedicada à promoção e à formação de profis-
sionais para testar softwares. O ISTQB realiza exames para vários níveis de certificações 
em testes de software e possui representações em vários países, incluindo o Brasil. 
Saiba mais no link a seguir.
http://www.bstqb.org.br
Ciclo de vida do defeito
Também conhecido como bug life cycle, é uma sequência de fatos e/ou ações 
que compõem as diferentes situações que podem ocorrer durante o processo 
de teste de software. É a partir desse ciclo de vida que as ferramentas de bug 
tracking são empregadas para controlar, monitorar, registrar e documentar 
todos os tipos, etapas e resultados dos testes realizados pela equipe de testes, 
em concordância com o plano de testes previamente defi nido. Na Figura 4, 
você pode ver o ciclo de vida do defeito.
Figura 4. Ciclo de vida do defeito.
Fonte: ISTQB (2014, documento on-line).
9Gerenciamento de testes
Observe, na Figura 4, o fluxo de detecção e tratamento de falhas. A seguir, 
veja também algumas definições importantes (conforme documentos do 
ISTQB, 2014).
  New (novo): a partir de uma notificação ou relatório de teste, é observada 
uma falha no software. O relatório é encaminhado à equipe de testes 
para que ela avalie a validade da notificação, visto que, em alguns casos, 
não existe uma falha, mas sim desinformação sobre o funcionamento 
do software ou suas especificações. Caso a notificação seja considerada 
válida, a ocorrência passa para o estado open.
  Open (aberto): uma vez considerada válida a notificação da falha, é 
realizado um relatório de abertura. Nele, são coletadas e organizadas 
as informações referentes à falha e ao ambiente em que ela ocorre. Por 
exemplo: configuração da máquina, versão do sistema operacional, 
detalhamento da instalação realizada, entre outras especificações de 
configuração. Além disso, um extrato demonstrativo do erro deve fazer 
parte do relatório.
  Assign (designação): nessa situação, a falha reportada é encaminhada 
a uma equipe de testes. Um testador, preferencialmente não envolvido 
na fase anterior de aceitação nem envolvido com a equipe de desenvol-
vimento, realiza uma nova avaliação sobre a falha reportada, podendo 
seguir, a partir daí, para três situações diferentes:
 ■ rejected (rejeitado) — nesse caso, a falha pode não existir. Uma ava-
liação mais detalhada revela erros de instalação ou de configuração 
de ambiente de funcionamento, e o software em si está funcionando 
dentro da especificação definida em projeto. Outra situação é a de 
que a falha não pode ser reproduzida, exigindo maiores informações 
do relatório de testes. Nesse caso, o testador rejeita a falha por não 
constatar o erro reportado.
 ■ deferred (adiado) — nessa situação, o testador reconhece a fa-
lha, porém é uma falha já documentada e, devido às suas carac-
terísticas e à forma como ela deveria ser consertada, a equipe 
de desenvolvimento decide por lidar com o defeito na próxima 
versão do software, não sendo então possível realizar o reparo 
na constatação do teste.
 ■ test (teste) — a falha é avaliada, passando por uma bateria de testes 
adicionais, que irão detalhar quais erros envolvem a falha apresentada 
Gerenciamento de testes10
e a extensão em que o erro (ou os erros) afeta os demais módulos 
e partes do software. Então, o conserto é realizado. Ao final dessa 
etapa, o testador pode encaminhar o software para verificação, ou 
ainda pode ocorrer o surgimento de nova falha como consequência do 
reparo executado. Nesse caso, o testador encaminhará para reopen, 
reportando a nova falha.
  Verified (verificado): a falha é verificada como não mais existente. Ela 
foi reparada e é encaminhada para conclusão.
  Close (fechamento/conclusão): a falha reportada é considerada resolvida 
e um relatório de fechamento é expedido. Nele, constam as mudanças 
realizadas, a natureza do erro e as atualizações de software utilizadas. 
O relatório será utilizado preventivamente nas próximas atualizações 
e projetos das equipes de desenvolvimento envolvidas.
  Reopen (reabertura): nessa situação, existe nova falha constatada pela 
equipe de testes como resultado dos reparos feitos em alguma falha 
anterior. Essa nova falha entra novamente no ciclo na fase de assign.
É importante você notar que, para o acompanhamento correto de cada 
uma dessas etapas, exige-se uma ferramenta adequada para registro. Desse 
modo, o sistema de reastreamento de bugs é a ferramenta que registra de forma 
operacional o ciclo de vida do defeito.
Demonstração do gerenciamento de testes 
por meio de sistemas de bug tracking
Atualmente, existem no mercado cerca de 40 aplicativos de bug tracking 
disponíveis. Uma parcela signifi cativa desses aplicativos é gratuita. Outros, 
como Jira, Asana, Bugzilla e MantisBT, são consagrados pelos profi ssionais 
da área de testes de software. Além disso, há aplicativos disponíveis para 
uso completamente on-line, sem a necessidade de instalações em máquina, 
podendo ser executados em qualquer parte do mundo.
Desse modo, a escolha da ferramenta mais adequada depende da equipe de 
testes e da familiaridade com alguma ferramenta em particular. Além disso, 
depende da complexidade dos relatórios que cada ferramenta fornece, da flexi-
bilidade de uso e configuração, entre outros aspectos de natureza operacional. 
Assim, independentemente da ferramenta, é importante você compreender o 
11Gerenciamento de testes
sistema de bug tracking. A partir daí, você vai conseguir reconhecer os módulos 
e funções que devem estar presentes nas ferramentas. São eles:
  registro e acompanhamento de plano de testes;
  registro de defeitos;
  acompanhamento das etapas do ciclo de vida do defeito.
As ferramentas existentes hoje no mercado garantem ótimo atendimento 
às funções listadas, incluindo o compartilhamento de uma base de dados de 
defeitos via internet. Isso ajuda muito no processo de identificação e reparo de 
defeitos, visto que muitos deles são frequentes e conhecidos pelas comunidades 
de programadores existentes no mundo.
Registro e acompanhamento do plano de testes
O plano de testes, como o próprio nome sugere, é um documento em que 
estão defi nidos os tipos e conjuntos de testes realizados ao longo da traje-
tóriade desenvolvimento do sistema. Ele é o primeiro passo na gestão de 
testes. A grande maioria das ferramentas de bug tracking possui funções e 
recursos para registro e posterior acompanhamento do plano de testes. De 
acordo com a norma IEEE 829:2008, um plano de teste deve conter os itens 
listados a seguir.
  Identificador: identificação do plano de teste.
  Histórico de versões: registro das versões do documento, identificando 
o que foi alterado e o responsável por cada versão.
  Descrição: determinação do objetivo e do escopo do plano de teste, 
definindo também os recursos e restrições técnicas e orçamentárias.
  Itens de teste:
 ■ descrição de todos os elementos que serão testados;
 ■ definição da prioridade de cada elemento a ser testado.
  Funcionalidades que serão testadas:
 ■ descrição das funcionalidades a serem testadas, sob o ponto de vista 
do usuário;
 ■ definição do nível de risco (ou prioridade) de cada funcionalidade, 
de modo que seja compreensível para o usuário.
Gerenciamento de testes12
  Funcionalidades que não serão testadas:
 ■ lista das funcionalidades que não serão testadas, do ponto de vista 
do usuário;
 ■ razão pela qual tais funcionalidades não serão testadas.
Além disso, devem constar os itens listados a seguir:
  descrição das estratégias que serão usadas para cada teste, identificando 
atividades e ferramentas usadas;
  descrição dos critérios de validação de cada teste;
  identificação da preparação/configuração do ambiente de testes;
  gerenciamento dos testes;
  cronograma, detalhando riscos e contingências;
  aprovação do documento, ou seja, aprovação do plano de testes pelos 
envolvidos.
Registro de defeitos
Essa é a principal funcionalidade de uma ferramenta de bug tracking. Afi nal, 
registrar defeitos relacionando-os com as falhas encontradas nos testes é 
fundamental para a correção e a atualização do software. Um registro de 
defeitos deve conter as seguintes informações:
  produto;
  componente (módulo ou funcionalidade);
  descrição do componente;
  versão;
  severidade;
  hardware;
  sistema operacional;
  nome para o defeito;
  descrição do defeito;
  documentos adicionais.
Na Figura 5, veja um exemplo de registro de defeitos.
13Gerenciamento de testes
Figura 5. Registro de defeito pela ferramenta MantisBT.
A seguir, na Figura 6, veja outro exemplo de registro.
Figura 6. Registro de defeito pela ferramenta Bugzilla.
Gerenciamento de testes14
Acompanhamento das etapas do ciclo 
de vida do defeito
O bug life cycle é um importante roteiro, isto é, uma sequência, ou ainda 
procedimento, para atendimento do processo completo de teste, desde a des-
coberta até o reparo. Algumas ferramentas de bug tracking possuem um ciclo 
de vida, conhecido como workfl ow. Outras permitem que o gerente implante o 
seu próprio ciclo. Veja a Figura 7, a seguir, que ilustra o ciclo de vida adotado 
por uma ferramenta de bug tracking.
Figura 7. Ciclo de vida do bug pela ferramenta Bugzilla.
Fonte: Bugzilla (2019, documento on-line).
Na Figura 7, cada etapa do ciclo de vida do defeito é monitorada pela 
ferramenta, que fornece diversos relatórios de acompanhamento e registro 
de ocorrências, de modo a garantir pleno suporte ao gerenciamento de testes. 
Observe, a seguir, exemplos de telas com diferentes tipos de relatórios de 
acompanhamento. Primeiramente, veja a Figura 8.
15Gerenciamento de testes
Figura 8. Registro de defeito confirmado, dados sobre o defeito, testador designado para 
analisá-lo, número de horas estimada para a realização do conserto e data limite para a 
conclusão.
Na Figura 9, a seguir, veja o mesmo produto com o status “resolvido” 
(observe o bug life cycle da ferramenta Bugzilla).
Figura 9. Listagem de bugs.
Gerenciamento de testes16
Agora veja a Figura 10. No exemplo, existem 215 defeitos críticos, 667 
defeitos normais e 32 triviais (de acordo com a classificação adotada pela 
ferramenta Bugzilla).
Figura 10. Relatório visual gráfico: quantidade de bugs e sua severidade.
Os exemplos que você acabou de ver são apenas uma pequena amostra das 
funcionalidades que as ferramentas de restreamento de bugs podem oferecer, 
bem como da importância de todo o processo de gerenciamento de testes.
BRAGA, P. (org). Teste de software. São Paulo: Pearson, 2016.
BUGZILLA. Editing bug. [2019]. Disponível em: https://bugzilla.readthedocs.io/en/latest/
using/editing.html#life-cycle-of-a-bug. Acesso em: 28 maio 2019.
BURNSTEIN, I. Practical software testing. Chicago: Springer, 2010.
IEEE STANDARDS ASSOCIATION. IEEE 829-2008: IEEE Standard for Software and System 
Test Documentation. Piscataway: IEEE Standards Association, 2008. 
ISTQB. Defect life cycle. 2014. Disponível em: http://istqbrm.blogspot.com/2014/07/
defect-life-cycle.html. Acesso em: 28 maio 2019.
17Gerenciamento de testes
SINGH, Y. Software testing. Cambridge: Cambridge University Press, 2012.
SOMMERVILLE, I. Engenharia de software. 9. ed. São Paulo: Pearson, 2011.
Leitura recomendada
FLYNT, J. P.; SALEM, S. Software engineering for game developers. Independence: Course 
Technology PTR, 2005.
Gerenciamento de testes18
Dica do Professor
Até o momento, você aprendeu sobre o gerenciamento de testes de software como etapa 
fundamental e contínua durante e mesmo após a sua conclusão. No entanto, é importante ter um 
conhecimento um pouco mais abrangente, visto que hoje a atuação profissional influencia 
diretamente vários segmentos da sociedade.
Nesse contexto, e ainda dentro do assunto referente a testes, veja na Dica do Professor, como é 
feito o gerenciamento de testes no hardware dos sistemas digitais.
As imagens do vídeo a seguir possuem audiodescrição. Para acessar o recurso, 
clique aqui
Aponte a câmera para o código e acesse o link do conteúdo ou clique no código para acessar.
https://creator-files.plataforma.grupoa.education/undefined/20538_Audiodescricao_Dica_do_Professor-2025-09-23T14:05:17-03:00.docx
https://fast.player.liquidplatform.com/pApiv2/embed/cee29914fad5b594d8f5918df1e801fd/9f7a4820c35ad6e9f6b4d8ffe7d4f299
Exercícios
1) Você foi recém contratado para integrar uma equipe de testes de uma empresa que fabrica 
impressoras 3D. Você foi designado para realizar a verificação do módulo de driver de 
impressão para um dado sistema operacional, como parte do processo de testes. Você 
então:
A) instala o software e executa-o em várias máquinas com o mesmo sistema operacional em 
várias configurações diferentes, e elabora um relatório dos resultados.
B) reúne-se com o programador do módulo; afinal, ele, melhor do que ninguém, sabe dizer como 
foi elaborado o driver.
C) vai à procura dos documentos de especificação do produto final, pois lá é possível encontrar 
uma descrição fiel de como opera a impressora 3D naquele sistema operacional específico.
D) coleta e analisa as listagens de codificação do módulo, os relatórios do programador 
referentes ao programa que ele fez e os relatórios gerados na etapa de compilação, 
procurando indícios de algum erro ou anomalia.
E) reescreve o módulo, pois, na verificação, deve-se pressupor que o módulo está com defeito, 
por isso precisou ser verificado e deverá ser reescrito pela equipe de testes.
2) Você foi recém contratado para integrar uma equipe de testes de uma empresa que fabrica 
impressoras 3D, e agora está designado a fazer a recepção das notificações de novas falhas 
de funcionamento do produto. Um usuário enviou uma solicitação de defeito, relatando que 
aparece uma mensagem com um X vermelho dizendo "impressora não conectada”. Ao ler a 
notificação, você deve:
A) imediatamente registrar como defeito novo e encaminhar para a equipe de testes, para que 
designem um testador para esse defeito. Afinal, se foi feita uma notificação, ela precisa ser 
testada.
B) ler a notificação e observar que o usuário registra ter conectado a impressora na porta de 
comunicação do computador, mas a mesma notificação salienta que o produto não está com 
o led indicativode alimentação de energia aceso. Você então não abre o chamado, pois 
considera que há desinformação sobre o funcionamento do produto pelo usuário.
C) solicita informações adicionais sobre o usuário, grau de instrução, experiência do usuário em 
programação, pois considera que essas informações são fundamentais para análise e 
aceitação da notificação da falha.
D) registra a notificação de falha nova, com base no Código de Defesa do Consumidor, que 
estabelece como responsabilidade da empresa fabricante o devido respeito às exigências por 
parte do usuário no que se refere a qualquer tipo de defeito.
E) desconsidera a notificação, pois entende que somente devem ser considerados como defeitos 
novos aqueles notificados pelas equipes de testes. Produtos já liberados ao mercado não 
apresentam mais falhas de espécie alguma.
 
Um usuário adquiriu uma impressora 3D, para uso em seu ateliê de arte. Durante 
aproximadamente 90 dias, não houve qualquer problema e a impressora apresentou 
comportamento dentro do esperado. No entanto, após esse tempo, ao enviar para a impressão 
uma peça com uma das medidas axiais maiores do que a capacidade de impressão, o produto 
iniciou a impressão diretamente em uma das paredes do cubo de vidro onde fica confinado o 
mecanismo de impressão, como pode ser observado na figura a seguir:
A imagem a seguir possui audiodescrição. Para acessar o recurso, clique aqui
Sobre essa situação, você entende que:
3) 
https://creator-files.plataforma.grupoa.education/undefined/20538_Audiodescricao_Exercicios-2025-09-22T16:25:48-03:00.docx
 
A) é possível constatar uma falha do produto, resultante de um defeito (provavelmente código 
de driver de impressão mal escrito) e originada em um erro do programador (inexperiente na 
codificação do módulo driver).
B) o usuário está diante de um erro sistêmico e o seu conhecimento sobre uso da impressora e 
códigos de programação já orientará diretamente a equipe do reparo.
C) o usuário deve conformar-se, pois está diante de um erro não encontrado pelo fabricante; 
porém, depois de 90 dias, todos os erros podem ser desconsiderados, porque não estão mais 
cobertos pelo Código de Defesa do Consumidor.
D) é possível constatar uma falha mecânica, resultante de um defeito também mecânico, porém 
sem nenhum erro humano.
E) deve-se esclarecer ao usuário que não existe falha alguma. Imprimir nas paredes da caixa de 
impressão é algo absolutamente normal.
4) Você foi designado como gerente de testes e precisa montar, de imediato, uma equipe de 
profissionais. Para realizar os testes de unidade, você irá recrutar:
A) profissionais analistas de sistema e sem conhecimentos de programação, pois deverão testar 
e analisar as especificações de software durante o desenvolvimento.
B) profissionais de marketing, pois deverão realizar testes de campo em relação às necessidades 
do público-alvo do software.
C) profissionais programadores, pois testes de unidade são realizados separadamente em cada 
módulo do sistema.
D) ninguém, porque, para teste de unidade, não há necessidade de recrutamento de 
profissionais, mas sim um contato com empresas parceiras que queiram realizar testes beta 
do software.
E) ninguém, porque, para teste de unidade, não há necessidade de recrutamento de 
profissionais. Deve-se realizar uma rodada de testes com a equipe de desenvolvimento do 
software, pois ninguém melhor do que eles para saber sobre o sistema.
Observe o cenário a seguir: uma falha foi notificada para o grupo de testes e foi 
encaminhada para atendimento. A falha foi então testada, corrigida e verificada, sendo 
encaminhada, em seguida, para relatório final e conclusão. No entanto, durante a correção, 
5) 
uma nova falha foi detectada, o que gerou nova notificação. Essa outra falha foi analisada e a 
equipe de testes decidiu pela realização do reparo na próxima atualização de versão. De 
acordo com a descrição acima, a sequência percorrida no bug life cycle foi:
A) NOVA – DESIGNAÇÃO – TESTE – VERIFICAÇÃO – CONCLUSÃO
B) NOVA – DESIGNAÇÃO – REJEIÇÃO
C) NOVA – DESIGNAÇÃO – TESTE – VERIFICAÇÃO (falha 1) – REABERTURA (falha 2) – 
CONCLUSÃO (falha 1) – DESIGNAÇÃO (falha2) – REJEIÇÃO (falha 2)
D) NOVA – DESIGNAÇÃO – ADIADO
E) NOVA – DESIGNAÇÃO – TESTE – VERIFICAÇÃO (falha 1) – REABERTURA (falha 2) – 
CONCLUSÃO (falha 1) – DESIGNAÇÃO (falha 2) – ADIADO (falha 2)
Na prática
A gestão de testes de software envolve várias etapas durante todo o processo de desenvolvimento; 
além disso, constitui procedimento fundamental para garantia da qualidade, segurança e aceitação 
do software como produto no mercado. Para essa tarefa, as ferramentas de rastreamento de 
defeitos conhecidas como bug tracking são indispensáveis para dar atendimento a todos os 
processos envolvidos no ciclo de vida do defeito.
Neste Na Prática, você irá vivenciar o processo de implantação de uma ferramenta de bug tracking 
na empresa NewMind e gerenciar as falhas detectadas no projeto do novo produto, o Mindecision.
A imagem a seguir possui audiodescrição. Para acessar o recurso, clique aqui
Conteúdo interativo disponível na plataforma de ensino!
https://creator-files.plataforma.grupoa.education/undefined/20538_Audiodescricao_Na_Pratica-2025-09-22T16:10:39-03:00.docx
Saiba mais
Para ampliar o seu conhecimento a respeito desse assunto, veja abaixo as sugestões do professor:
Canal TI
Canal com muito material para todos os profissionais da área de Tecnologias da Informação. 
Disponibiliza cursos on-line sobre vários assuntos técnicos em linguagem acessível, sem perder a 
profundidade do tema. Abriga vários vídeos sobre conteúdos relacionados a Teste de software.
Aponte a câmera para o código e acesse o link do conteúdo ou clique no código para acessar.
ISTQB
O ISTQB é uma entidade internacional voltada totalmente para a formação de profissionais em 
teste de software. É uma oportunidade para aqueles que gostariam de seguir uma carreira como 
profissional de Tecnologias da Informação. A entidade promove certificações para diferentes 
categorias de profissionais de teste e há um escritório da entidade no Brasil.
Aponte a câmera para o código e acesse o link do conteúdo ou clique no código para acessar.
Gerenciamento de teste de software: um comparativo entre 
ferramentas open source
Este artigo científico compara ferramentas open source para gerenciamento de teste. Aspectos 
como usabilidade e desempenho são bem avaliados. Trata-se de uma excelente fonte para quem 
quiser decidir por uma ferramenta de gestão de teste sem custos com licenças.
http://www.canalti.com.br 
https://www.istqb.org/
Aponte a câmera para o código e acesse o link do conteúdo ou clique no código para acessar.
https://periodicos.ufpe.br/revistas/index.php/gestaoorg/article/view/22555