Qualidade de Software: Testes e Bugs

Prévia do material em texto

1 
 
 
 
 
 
 
 
 
 
 
 
 
QUALIDADE DE SOFTWARE 
AULA 3 
 
 
 
 
 
 
 
 
 
 
Prof.a Maristela Regina Weinfurter Teixeira 
 
2 
 
CONVERSA INICIAL 
Olá, seja bem-vindo. Assista ao terceiro vídeo da professora Maristela 
Regina Weinfurter Teixeira, que irá apresentar e contextualizar esta disciplina, 
bem como os assuntos que serão estudados nesta aula. 
 
CONTEXTUALIZANDO 
Estudamos questões importantes para a garantia da qualidade, e um 
conjunto de atividades de suma importância para a qualidade tanto do software 
quanto de seu processo são os testes. A estratégia de testes de software nos 
oferece roteiros que descrevem passo a passo cada procedimento a ser aplicado 
e em qual momento do processo de desenvolvimento. Sendo assim, toda 
estratégia de teste deve incorporar planejamento de teste, projeto de casos de 
teste, execução dos testes e avaliação dos dados resultantes, segundo 
(PRESSMAN, 2011). 
Historicamente a execução de testes vem se transformando há 
décadas (RIOS, 2008). Nos anos 70, os testes eram feitos pelos próprios 
desenvolvedores, e a nossa garantia era de que o produto funcionasse. Entre os 
anos 80 e 90 já tínhamos testes feitos pelos desenvolvedores e usuários para 
garantia dos requisitos iniciais do projeto. Entre os anos 90 e 2000, a garantia se 
baseava no produto funcionando, atendendo os requisitos e sem defeitos. Estes 
testes eram executados por meio de processos de testes feitos pelos 
desenvolvedores, usuários e testadores. Nos últimos anos, a complexidade tanto 
do desenvolvimento quanto dos testes aumentou significativamente, incluindo 
agora questões de segurança e performance. 
Mas quando olhamos para nosso dia a dia no desenvolvimento de 
software, quase que todos os problemas se tornam um bug. Sim, bug é 
considerado um defeito, uma falta, um problema, um incidente, uma anomalia ou 
qualquer outro problema que ocorra durante a execução de nosso software. 
 
3 
 
(PINHEIRO, 2015). Também temos uma definição mais formal sobre bug 
(PATTON, 2005 apud PINHEIRO, 2015): 
 
Um bug ocorre quando uma ou mais das opções abaixo for verdadeira: 
 O software NÃO faz algo que a especificação diz que ele deveria 
fazer; 
 O software FAZ algo que a especificação diz que ele NÃO 
deveria fazer; 
 O software faz algo que a especificação não menciona; 
 O software NÃO faz algo que a especificação NÃO menciona, 
mas deveria mencionar; e 
 O software é difícil de usar, entender, ou na visão do testador 
pode ser visto pelo usuário final como não estando correto. 
 
E o velho discurso vem à tona novamente: “O custo de um bug está 
diretamente associado à fase do ciclo de desenvolvimento em que o bug é 
encontrado. Um bug encontrado durante a especificação pode custar um dólar. 
O mesmo bug encontrado no release pode custar 100 vezes mais.” (PINHEIRO, 
2015). Quando analisamos os erros, 85% são simples de correção (menos de 1 
hora), 1% dos erros leva mais que alguns dias para correção, 80% do esforço de 
manutenção é gasto com 20% dos erros. (PINHEIRO, 2015). 
Agora falando um pouco mais sobre os famosos bugs, eles podem ser 
classificados em 3 principais tipos (PINHEIRO, 2015): 
 ERRO, que ocorre devido à ação humana, resultado de um software com 
defeitos; 
 DEFEITO, o qual ocorre devido a problemas de informações, de dados, 
de instruções incorretas; e 
 FALHA, que ocorre quando um programa não se comporta conforme o 
estabelecido ou apresenta resultados inconsistentes. 
 
 
 
 
 
 
 
 
4 
 
Figura 1: Erros, defeitos e falhas 
 
Fonte: Claudio, 2016. 
 
Teremos muito a evoluir para atingirmos níveis de excelência na área de 
testes de software. Uma das grandes consequências da importância desta área 
dentro do desenvolvimento de software encontra-se nos vários cursos de 
pós-graduação espalhados mundo afora para suprir uma grande carência de 
profissionais. Isso porque, normalmente, os estudantes gostam de atuar no 
desenvolvimento dos projetos de software como desenvolvedores ou analistas, 
mas dificilmente gostam de atuar como profissionais da área de testes. É uma 
área que exige um grau de detalhe bastante grande, o que por vezes torna-se 
cansativo e repetitivo para alguns perfis de profissionais. 
 
Leitura obrigatória 
SOMMERVILLE, 2011 
 
Saiba mais 
http://www.linhadecodigo.com.br/artigo/2775/introducao-ao-teste-de-
software.aspx 
 
 
 
 
5 
 
Gostaria que agora você olhasse e refletisse sobre o número de 
oportunidades profissionais que esta área de qualidade de software pode 
oferecer-lhe. Utilize o link: <http://ibqts.com.br/> para compreender e ampliar sua 
visão sobre possibilidades de atuação na área de engenharia de software, 
focando em questões de qualidade e testes de software. Liste as certificações 
existentes, bem como suas finalidades dentro do processo de desenvolvimento 
de software. 
http://ibqts.com.br/ 
 
 
TEMA 1: O QUE É TESTE DE SOFTWARE? 
Nada melhor do que compreendermos sempre as definições e conceitos 
existentes para uma nova área de conhecimento que estejamos estudando. 
Então vamos à pergunta mais simples desde que iniciamos nossos encontros: O 
que é teste de software? “Teste de software é um conjunto de atividades que 
podem ser planejadas com antecedência e executadas sistematicamente. ”, 
segundo Pressman (2011). Todo teste deverá contar com um modelo (template) 
para utilização de técnicas específicas de projeto de caso, de teste e métodos 
de testes. Toda estratégia de testes deve acomodar testes de baixo nível, para 
verificação de um pequeno segmento de código fonte, bem como testes de alto 
nível, que validem funções do sistema de acordo com os requisitos elicitados. 
Cada estratégia fornece diretrizes para que o profissional responsável consiga 
cumprir uma série de metas. Não é novidade que desenvolvemos software 
sempre sob pressão em relação a prazos e custos, então, é importante obtermos 
formas de medição do progresso dos testes bem como dos problemas revelados 
e corrigidos o mais breve possível dentro do processo de desenvolvimento de 
software. 
A triste notícia é que podemos seguir muitos métodos, adotar muitas 
técnicas, adotar certificações de padrões de qualidade, mas mesmo assim ainda 
não ficaremos livres dos bugs. Diríamos que ainda é impossível testarmos todas 
 
6 
 
as possibilidades de formas e alternativas de entrada de dados, bem como as 
diversas possibilidades e condições criadas pela lógica de algoritmos de cada 
desenvolvedor. Há estimativas que garantem que a média do número de defeitos 
em programas liberados para testes é de 1 a 3 por 100 instruções executáveis 
(RIOS, 2008). E então você se perguntará: Se não conseguimos atingir 100% de 
excelência na área de testes, por que testar? Teremos que lembrá-lo que o 
propósito dos testes é a descoberta e correção dos problemas com foco na 
melhoria e na qualidade do software. Então, quanto ele deve melhorar? De 
acordo com o que a empresa está consciente em investir numa equipe de testes, 
capaz de tornar a quantidade de defeitos tendendo a zero. Logo, quanto mais 
tempo e recursos financeiros dedicados ao processo de testes, mais perto da 
satisfação do cliente chegaremos. 
Nunca devemos esquecer que o processo de desenvolvimento de 
software é feito por seres humanos, e que, apesar dos melhores métodos ou 
técnicas, profissionais também erram. E alguns problemas, dos quais já 
conversamos, podem advir de uma especificação incompleta ou errada, com 
limitações de hardware ou software, com uma base de dados organizadanão da 
melhor forma, além de obviamente erros nos algoritmos. 
Compreendemos que por mais que criemos técnicas, métodos e 
ferramentas que apoiam o teste de software, continuaremos uma longa jornada 
com seres humanos que, em algum momento, podem errar por problemas 
simples, como falha na comunicação com seus stakeholders. Então, quando 
falamos de testes de software, estamos olhando para o produto e para o 
processo como um todo, e acabamos entrando em questões que não são 
meramente técnicas, mas subjetivas em relação à comunicação humana. 
Leitura obrigatória 
SOMMERVILLE, 2011 
 
 
 
 
7 
 
Saiba mais 
O IBQTS, Instituto Brasileiro de Qualidade em Testes de Software, é uma 
entidade de caráter de pesquisa e órgão certificador de profissionais da área 
de Engenharia de Requisitos e Engenharia de Testes de Software, reconhecido 
oficialmente por empresas e instituições de ensino, tanto no Brasil quanto no 
exterior. 
As certificações fornecidas pelo Instituto qualificam analistas de sistemas 
e negócio, desenvolvedores e testadores com interesse em obter um atestado 
de reconhecimento técnico válido para o mercado nacional e internacional, 
e estão aderentes a padrões internacionais de qualidade. 
Fundado em 2006, o IBQTS nasceu com a missão de aprimorar a 
capacidade produtiva dos profissionais de TI, melhorando a qualidade dos 
requisitos, desenvolvimento e testes. Com a necessidade cada vez maior de 
profissionais qualificados, o instituto certifica profissionais para a crescente 
competição internacional nas áreas de Engenharia Testes e Requisitos. Essas 
certificações oferecem a oportunidade de um diferencial competitivo. 
Disponível em: http://ibqts.com.br/ 
 
TEMA 2: PROCESSOS DE TESTES 
Como temos falado ao longo de nossos módulos que envolvem o 
desenvolvimento de software, sempre voltamos ao assunto: processo! 
Sim, processos são responsáveis pela organização de todas as tarefas e 
atividades que sejam necessárias para que atinjamos algum resultado em 
nossos projetos. E com o projeto de testes de software não é diferente! O 
processo de teste deve ter como base uma metodologia que seja aderente à 
metodologia que adotamos para o desenvolvimento do software. Deve possuir 
especialistas qualificados, ambiente e ferramentas adequados para que os 
resultados sejam alcançados. (RIOS, 2008). Uma metodologia de teste está 
descrita em um documento que organiza a atividade de teste dentro do contexto 
 
8 
 
do domínio do problema ou da organização. Esta metodologia deverá conter as 
fases do seu ciclo de vida, como por exemplo na Figura 2. 
 
Figura 2: Fases do ciclo de vida do processo de testes 
 
 
 
 
 
 
 
 
Fonte: Rios, 2008. 
 
Observando cada fase desta proposta de metodologia de testes, podemos 
descrevê-las da seguinte forma: 
Procedimentos Iniciais: consideram a elaboração de um documento chamado 
Guia Operacional de Testes (GOT), que estabelece o acordo entre as partes 
envolvidas no projeto de teste (usuários, desenvolvedores, pessoal de testes 
e de produção). 
Planejamento: consiste na elaboração e revisão da estratégia a ser adotada 
no plano de testes. 
Preparação: consiste no ambiente de teste (equipamentos, rede, pessoal, 
software e ferramentas). 
Especificação: elaboração e revisão dos casos de teste (ou scripts de teste), 
uso de ferramentas de automação e roteiros de teste e execução dos testes de 
verificação da documentação do sistema. Testes estáticos. 
Execução: execução de todo planejamento de testes conforme os casos de 
teste e roteiros de teste, registrando-se os resultados. 
Entrega: entrega do sistema testado e de dos devidos registros. 
Planejamento 
Preparação 
Procedimentos 
iniciais 
Entrega Especificação Execução 
 
9 
 
Na tabela 1 mostramos um detalhamento de cada fase de um processo 
de testes com suas ações requeridas e verificações. 
Processo de 
Teste 
Processo de 
Desenvolvimento 
Ações Requeridas 
Verificação/ 
Validação 
P
la
n
e
ja
m
e
n
to
 
Planejamento do 
projeto de 
desenvolvimento 
Integração dos planos. 
Preparação da estratégia de 
testes e planos de testes. 
Verificação (Revisões 
/ WalkThrough / 
Inspeção) 
E
s
p
e
c
if
ic
a
ç
ã
o
 
Projeto lógico e físico 
Revisão dos planos de 
testes 
Elaboração e revisão dos 
casos de teste e dos roteiros 
de teste 
Atualização do plano de 
projeto de desenvolvimento 
Verificação (Revisões 
/ WalkThrough / 
Inspeção) 
E
x
e
c
u
ç
ã
o
 
Construção 
Busca de defeitos e 
correções 
Verificação (Revisões 
/ WalkThrough / 
Inspeção e testes 
unitário, de 
integração de 
sistema) 
E
x
e
c
u
ç
ã
o
 
Implantação 
Busca de defeitos e 
correções 
Validação (Testes de 
aceitação) e 
Verificação (Revisões 
/ WalkThrough/ 
Inspeção) 
 
É sempre bom lembrarmos que quanto mais tarde um defeito for 
identificado, mais caro ficará para corrigi-lo. O aumento é sempre exponencial 
em relação ao trabalho de testes através das fases do projeto. 
Leitura obrigatória 
SOMMERVILLE, 2011 
 
TEMA 3: TIPOS DE TESTE 
Percebemos que precisamos montar um bom plano de ação e execução 
de testes que seja adequado ao tamanho de nosso projeto de desenvolvimento, 
pois envolverá um valor relativamente alto ao considerarmos o melhor dos 
 
10 
 
mundos. Vamos classificar estes testes existentes e suas características para 
compreendermos o que utilizar e em qual momento do nosso planejamento e 
execução de testes. 
Tipos de teste segundo Rios (2008): 
 Testes de regressão: garantem que o software atenda aos requisitos 
mesmo depois de sofrer manutenções. Um conjunto de dados e scripts 
contém uma baseline e executam para verificação de mudanças 
introduzidas posteriormente. Discrepâncias são resolvidas antes de se 
atingir o próximo nível de testes. 
 Testes de carga: avaliam a resposta de um software com pesada carga 
de dados e/ou grande número de usuários simultaneamente para 
verificação do nível de escalabilidade, confrontando o tempo de 
resposta ou falha. 
 Teste de estresse: simulação de situações que possam ocorrer em 
produção, como falta de memória, falta de espaço em disco. 
 Teste Back-to-back: executado em versões diferentes do software com 
comparação dos resultados. 
 Teste de configuração: verifica a aptidão do software para rodar em 
diferentes versões ou configurações de ambientes (hardware, browsers 
ou versões de browsers). 
 Teste de usabilidade: verificação do nível de facilidade de uso do 
software pelos usuários. Efetuado principalmente em aplicações Web em 
decorrência do grande número de navegações entre páginas. Clareza de 
linguagem, mensagens de erro e links para páginas também são testados. 
 Testes de instalação: verificação da instalação parcial, total ou 
atualização de aplicativo. 
 Testes de Segurança: validação da capacidade e qualidade da 
recuperação do software após crashes, falhas de hardware ou outros 
problemas catastróficos. 
 
11 
 
 Teste de compatibilidade: validação da capacidade do software em 
executar em um ambiente específico (hardware/software/sistema 
operacional/rede). 
 Teste de desempenho: garante que o sistema atenda aos níveis de 
desempenho e tempo de resposta acordados com os usuários e definidos 
nos requisitos. (Performance). 
 Testes funcionais: grupos de testes que avaliam a especificação versus 
a implementação. 
 Testes de qualidade de código: verificação do código fonte dos 
programas em conformidade com padrões, melhores práticas, instruções 
não executadasentre outros. 
 Testes de alterações: rastreiam alterações de programas durante o 
processo de testes. 
 Testes de recuperação de versões: verificação da capacidade de 
retorno a uma versão anterior do sistema. 
 Testes de interoperabilidade: avaliação das condições de integração 
com outros ambientes/sistemas (troca de informações). 
 Testes de sobrevivência (confiabilidade ou disponibilidade): 
avaliação da capacidade do software em continuar operando quando 
algum outro elemento pare de funcionar ou fique inoperante (hardware, 
por exemplo). 
 Testes estáticos: avaliação da documentação do projeto (modelos, 
requisitos). 
 Testes embutidos: avaliação da integração entre hardware e software. 
 Testes de verificação do site Web: verificação de problemas com 
determinados sites Web (links inválidos, arquivos órfãos, páginas lentas). 
 Testes de conferência de arquivos: verificação da alteração de arquivos 
utilizados. 
 Testes Alfa: executados em ambiente de desenvolvimento na 
proximidade da conclusão. 
 
12 
 
 Testes Beta: executados durante a fase desenvolvimento e testes, mas 
praticamente concluídos, com o maior número possível de defeitos e 
problemas encontrados antes do release final. 
 
Além de toda essa classificação de tipos de testes, temos ainda o que 
chamados de técnicas de testes e níveis de testes. 
Como técnicas de testes, temos testes de caixa preta e de caixa branca. 
Os testes de caixa preta testam a funcionalidade e sua aderência aos requisitos 
sem conhecimento do código e da lógica interna do sistema em teste, enquanto 
que os testes de caixa branca testam cláusulas de 
código, lógica interna e cada componente codificado, além de outros 
elementos técnicos. 
Estágios ou níveis de testes, segundo Rios (2008), consideram os seguintes 
grupos: 
 
 Testes unitários: estágio mais baixo na escala de testes. São testes de 
componentes versus suas especificações para que características e 
funcionalidades sejam verificadas independentemente do sistema total. 
Realizados pelos desenvolvedores. 
 Testes de integração: execução de uma combinação de componentes 
para verificação da execução em conjunto, conforme as especificações. 
Realizados pelos desenvolvedores. 
 Testes de sistema: realizados pela equipe de testes, observando a 
execução completa do sistema e seus subsistemas, dentro de um 
ambiente operacional controlado, para validação das funcionalidades 
do sistema. Uso de dados de teste para validação de situações 
mais próximas da realidade, que ocorrerá no momento do ambiente 
de produção. 
 Testes de aceitação: testes finais de execução do sistema, juntamente 
com usuários, tendo-se em mente que as soluções deverão atender aos 
objetivos do negócio e dos requisitos. Funcionalidade e usabilidade são 
 
13 
 
observadas neste momento. Usuários com suporte da equipe técnica de 
testes são responsáveis por este teste. 
 
Vimos que há uma quantidade razoável de tipos de testes, níveis e 
estágios. Só de observarmos toda esta possibilidade de testes, podemos 
concluir a quão custosa pode ser a tarefa de teste de software. Por isso é 
importante adotarmos um plano aceitável de acordo com o tamanho do projeto 
de software e de sua equipe de desenvolvimento e testes. 
 
Leitura obrigatória 
SOMMERVILLE, 2011 
CAMPOS, 2016 
 
Saiba mais 
Os 13 principais tipos de testes de software: 
http://www.targettrust.com.br/blog/desenvolvimento/testes/os-13-principais-
tipos-de-testes-de-software/ 
 
TEMA 4: REVISÕES E INSPEÇÕES 
Como a área de garantia da qualidade de software é muito abrangente, é 
comum errarmos ao utilizarmos determinados termos técnicos. Os termos 
comumente utilizados erroneamente são: revisões, inspeções, validações 
e verificações. 
Vamos iniciar pelos termos revisões e inspeções. As inspeções e 
revisões de software são atividades e técnicas estáticas que avaliam 
problemas na construção de software sem a necessidade de que o software seja 
executado em um ambiente computacional. 
Encontramos normalmente o processo de revisão estruturado em três 
fases (Sommerville, 2011): 
 
14 
 
1. Atividade de pré-revisão: são atividades preparatórias essenciais para 
a eficácia da revisão. Atividades relacionadas com planejamento e 
preparação da revisão. Envolve uma equipe de revisão, organização de 
tempo e lugar para que ocorram as revisões. Os envolvidos compreendem 
o que o software deverá fazer, bem como os documentos de padrões 
relevantes. Os revisores podem fornecer comentários sobre o software, 
caso não participem de alguma reunião de revisão. 
2. Reunião de revisão: durante a reunião o líder da revisão encaminha um 
documento com todos os problemas e questões de qualidade a serem 
discutidos. Este líder será responsável por garantir que todos os 
comentários escritos sejam considerados no relatório final. Além dos 
comentários, deverão ser registradas todas as ações corretivas 
acordadas durante a reunião. 
3. Atividades pós-revisão: todas as questões e problemas levantados 
devem ser abordados. Esse processo envolve a correção de bugs de 
software, refatoração de software entre outras técnicas para que esteja 
em conformidade com os padrões de qualidade ou necessidade de nova 
redação de documentos. Ao término, o presidente do grupo de revisões 
deve averiguar se todos os comentários foram levados em consideração. 
Dependendo do caso, será necessária nova reunião para apuração da 
conformidade com as reuniões de revisão. 
A Figura 3 nos demonstra de forma objetiva o processo de revisão de 
software, seguindo as atividades tratadas anteriormente. 
 
 
 
 
 
 
15 
 
Figura 3: Processo de revisão de software 
 
Fonte: Sommerville, 2011. 
 
Em um desenvolvimento ágil, o processo de revisão de software 
geralmente é mais informal. Por exemplo, na metodologia de desenvolvimento 
SCRUM, ocorre uma reunião de revisão após a conclusão de cada iteração do 
software (revisão de Sprint), na qual os problemas e as questões de qualidade 
podem ser discutidos. Já na XP (Extreme Programming), a programação em 
pares garante que o código esteja sendo examinado e revisto à medida que esse 
é desenvolvido pela equipe. As reuniões diárias de equipe trabalham as 
questões de qualidade. Normalmente, as abordagens ágeis não adotam 
padrões, logo as questões de conformidade são desconsideradas. 
Sempre é um contraponto a questão do uso de métodos ágeis para 
desenvolvimento quando abordamos questões de qualidade. A essência destes 
métodos encontra-se justamente na desburocratização e em não exagerar na 
documentação de software. Porém, percebemos o quanto é necessária a 
geração de documentos e modelos para efetuarmos a garantia da qualidade por 
meio de testes, inspeções, revisões e conformidade com padrões. 
Tomando o rumo das inspeções de programas, estas são consideradas 
revisões em pares, nas quais membros da equipe colaboram para a descoberta 
de bugs no programa em desenvolvimento. Modelos de UML podem ser 
checados pela utilização de casos de teste. As inspeções auxiliam na descoberta 
de problemas com testes, melhorando a eficácia desses testes ao se detectar 
 
16 
 
bugs no programa. Elas envolvem equipes de diferentes origens, as quais 
revisam linha por linha o código-fonte dos programas, buscando defeitos e 
problemas e os descrevem em relatórios nas reuniões de inspeção. Os defeitos 
podem ser erros lógicos, anomalias no código ou detalhes dos modelos de 
projeto. 
O interessante é lembrarmos que inspeções e revisões são estáticas e 
podem ser aplicadas tanto em código de programas quantoem modelos e 
documentação de projeto de software. Elas podem ser prejudicadas quando 
utilizamos métodos ágeis para o desenvolvimento de software, uma vez que a 
utilização de documentações com modelos do projeto não é comum em 
desenvolvimento ágil. 
Leitura obrigatória 
SOMMERVILLE, 2011 
 
 
TEMA 5: VERIFICAÇÕES E VALIDAÇÕES 
Conversamos sobre inspeções e revisões e agora nos resta 
compreendermos melhor o que são verificações e validações quando falamos 
em garantia da qualidade de software. Teste de software é um elemento muitas 
vezes conhecido como validação e verificação (V&V). Segundo Pressman 
(2011), “verificação refere-se ao conjunto de tarefas que garantem que o 
software implemente corretamente uma função específica. Validação refere-se 
a um conjunto de tarefas que asseguram que o software foi criado e pode ser 
rastreado segundo os requisitos do cliente.” 
Se fôssemos transformar em duas perguntas, teríamos as seguintes 
questões: 
“Verificação: Estamos criando o produto corretamente?” (PRESSMAN, 
2011). 
“Validação: Estamos criando o produto certo?” (PRESSMAN, 2011). 
 
17 
 
Esta definição V&V contém muitas atividades da garantia da qualidade de 
software. Incluem atividades como revisões técnicas, auditorias de qualidade e 
configuração, monitoramento de desempenho, simulação, estudo de viabilidade, 
revisão de documentação, revisão de base de dados, análise de algoritmo, teste 
de desenvolvimento, teste de usabilidade, teste de qualificação, testes de 
aceitação e teste de instalação (PRESSMAN, 2011). A garantia e a qualidade 
utilizam o teste como último elemento para estimar mais pragmaticamente seus 
erros descobertos. Na fase de verificação, utilizamos todos ou alguns dos testes 
que foram classificados no tema “tipos de testes”. Lá pudemos conhecer um 
pouco de cada tipo de teste e sua importância para a qualidade de software. 
Ao terminarmos a fase de verificação com o uso das técnicas escolhidas 
para cada projeto, voltamo-nos para a fase de validação. Agora nos 
preocuparemos com o sistema que é visualizado e reconhecido pelos usuários. 
Seu principal objetivo é apontar o sucesso do funcionamento do software, 
confrontando o esperado com o realizado. Os testes da validação demonstram 
conformidade com os requisitos. Logo, é importante que o plano de testes 
descreva as classes de testes a serem conduzidas e um procedimento de testes 
para definição dos casos de testes específicos que garantam os requisitos 
funcionais de acordo com as expectativas dos clientes. Alguns exemplos de 
requisitos cumpridos estarão em conformidade com transportabilidade, 
compatibilidade, recuperação de erro, manutenibilidade. Caso sejam 
descobertos desvios de especificação, cria-se uma lista de deficiências que 
serão corrigidas conforme um plano com prazos e negociações junto aos 
clientes. 
Percebemos até aqui que o tema sobre garantia da qualidade de processo 
e de software é extenso e carece de adaptação a cada tipo e tamanho de projeto. 
Que há diferenças conceituais entre revisões, inspeções, verificações e 
validações. Que cada uma tem seu grau de importância dentro do nosso 
processo de testes e qualidade de software. Que entraremos num dilema ao 
utilizar métodos ágeis com a aplicação de garantia da qualidade de software. 
Mas nada que não possa ser resolvido utilizando-se do bom senso. A área de 
 
18 
 
engenharia de software é muito ampla e repleta de métodos, técnicas, 
ferramentas e frameworks. Cabe a cada líder de projeto adaptar o que seja mais 
conveniente com o intuito de garantir um processo e um software com qualidade 
esperada pelos stakeholders. 
 
Leitura obrigatória 
SOMMERVILLE, 2011 
http://www.devmedia.com.br/a-importancia-da-validacao-e-da-
verificacao/24559 
 
TROCANDO IDEIAS 
Refletir sobre a introdução da garantia de qualidade, utilizando os 
conceitos de inspeções, revisões, verificações e validações em projetos que 
utilizem métodos ágeis. Quais as maneiras de garantirmos a qualidade sem 
perdermos a essência destes métodos de desenvolvimento de software? 
 
SÍNTESE 
Estudamos até aqui sobre inspeções, revisões, verificações e 
validações de software para garantia da qualidade. Nosso objetivo é termos 
uma visão geral sobre as várias formas de efetuarmos testes, sejam eles 
estáticos ou dinâmicos. Sejam eles em modelos seguindo nossos casos de 
testes ou a nível de classes, componentes, código-fonte, integração ou 
quaisquer outros tipos. Nosso desafio é a entrega de um software que alcance 
os resultados esperados com a menor quantidade possível de erros e falhas. 
Que nossos sistemas sejam usáveis, seguros, portáveis, de fácil manutenção, 
que nos assegure de riscos. Percebemos que há uma diferença quando 
conceituamos erro, defeito ou falha. Lembrando então que (CLAUDIO, 2016): 
 ERRO, que ocorre devido à ação humana, resultado de um software com 
defeitos; 
 
19 
 
 DEFEITO, o qual ocorre devido a problemas de informações, de dados, 
de instruções incorretas; e 
 FALHA, que ocorre quando um programa não se comporta conforme o 
estabelecido ou apresenta resultados inconsistentes. 
 
Enfim, nossa expectativa é conseguirmos traçar um panorama sobre o 
que é melhor e adaptável a cada tipo e tamanho de projeto para o qual estejamos 
atuando. Vimos também o quão importante são as equipes de revisões, as 
reuniões de inspeções, os documentos gerados após a aplicação dos testes, 
bem como os planos de ação para melhorarmos e deixarmos o nosso software 
cada vez mais próximo das expectativas reais de 
nossos usuários. 
 
REFERÊNCIA 
CLAUDIO, A. Testes de Software. Disponível em: 
<http://www.devmedia.com.br/artigo-engenharia-de-software-introducao-a-
teste-de-software/8035>. Acesso em: maio de 2016. 
PRESSMAN, R. S. Engenharia de software: uma abordagem profissional. 7. 
ed. Porto Alegre: AMGH, 2011. 
LÉLIS, E. C. Gestão da qualidade. São Paulo: Pearson Prentice Hall, 2012. 
PINHEIRO, A. F. Fundamentos da engenharia de software: qualidade com 
testes e gerência. v. 6. Pernambuco, Amazon Publishing, 2015. 
SOMMERVILLE, I. Engenharia de software. 9. ed. São Paulo: Pearson 
Prentice Hall, 2011. 
RIOS, E. Documentação de teste de software. 2. ed. Iteste: Instituto de teste 
de software. 2008. 
 
20 
 
SHIGUNOV NETO, A. Introdução à gestão da qualidade e produtividade: 
conceitos, história e ferramentas. Curitiba: InterSaberes, 2016. 
XIV Simpósio Brasileiro de Qualidade de Software. Anais. 17-21 de agosto de 
2015. Manaus. Disponível em: 
<https://drive.google.com/file/d/0B4ZBCAydIkutSUFuVVhCdXVnbDA/view>. 
Acesso em: maio de 2016.