TODAS AULAS QUALIDADE SOFTWARE - RESPOSTAS PARA PROVAS

Prévia do material em texto

1 
 
 
 
 
 
 
 
 
 
 
 
QUALIDADE DE SOFTWARE 
AULA 1 
 
 
 
 
 
 
 
 
 
 
 
 
Prof.a Maristela Regina Weinfurter Teixeira 
 
2 
 
CONVERSA INICIAL 
Olá, seja bem-vindo. Assista ao primeiro vídeo da professora Maristela 
Regina Weinfurter Teixeira, que irá apresentar e contextualizar esta disciplina, 
bem como os assuntos que serão estudados nesta primeira aula. 
CONTEXTUALIZANDO 
Vamos trabalhar um conceito importantíssimo dentro da Engenharia de 
Software: A Qualidade de Software. É inevitável não associarmos engenharia 
de software e qualidade de software, pois quando retomamos o histórico da 
engenharia de software percebemos que está se originou devido à terrível crise 
do software. E o que teria sido então esta crise? Justamente problemas que 
deixaram desenvolvedores noites e noites sem dormir para refazerem milhares 
de linhas de código. Segundo Pressman, na década de 90, grandes empresas 
falavam em bilhões de dólares por ano que eram desperdiçados em software 
que não apresentava as características e as funcionalidades prometidas. 
(PRESSMAN, 2011). 
São décadas que falamos em engenharia e qualidade de software, porém 
continuamos com códigos mal feitos nesse mercado. Estamos falando de 45% 
de tempo de inatividade dos sistemas e 100 bilhões de dólares em 2010. 
(PRESSMAN, 2011). Alguns especialistas apontam que 3 ou 4 defeitos a cada 
1.000 linhas de código são suficientes para que o programa execute de forma 
inadequada. Agora, multiplique isto a milhões de linhas de código em vários 
produtos comerciais pelo mundo. Sim, é assustador! E como isto reflete nos 
custos? Precisamos consertar aquilo que não foi feito corretamente, bem como 
aquilo que não passou por bons TESTES! Logo, estamos falando de 
RETRABALHO! E as pessoas trabalham e necessitam receber sua 
remuneração, logo, quando falamos em códigos mal escritos e ineficientemente 
testados, estamos falando que alguém terá que pagar esta conta! 
 
3 
 
Muito bem, falamos dos custos para escrevermos e mantermos 
funcionalidades de software, porém, os custos, gastos e investimentos vão além 
dos funcionários da área de TI. Quando um software está inativo, são clientes e 
mais clientes que são prejudicados, por meio de notas fiscais que não são 
emitidas, empresas que deixam de faturar, bancos que deixam de fazer 
operações com milhões de correntistas, pedidos que não são recebidos, entre 
tantas outras funcionalidades automatizadas que deixam de executar! 
Mas não paramos apenas nos problemas de funcionalidades por conta de 
erros nos códigos dos programas. São requisitos mal elaborados e validados 
com clientes, são aspectos da interação humano-computador que geram 
problemas (usabilidade e acessibilidade), são bancos de dados e classes mal 
projetados! Se começássemos uma lista de todos os problemas que levam um 
software a parar, falhar ou funcionar parcialmente, teríamos algumas páginas 
para escrever sobre a ausência da qualidade do software. 
Enfim, não obstante, podemos ainda falar sobre os problemas inerentes 
ao processo de desenvolvimento de software. Quando pensamos na qualidade 
de um produto genérico, logo somos remetidos ao processo pelo qual este 
passou para ser fabricado. Software, apesar de não ser um produto, também 
caminha dentro de um ciclo de desenvolvimento. Se este ciclo não possuir 
processos, atividades e tarefas consolidadas e em conformidade com normas, 
metodologias, regras e outras formas de garantia da qualidade, a possibilidade 
de nosso produto não atingir a qualidade desejada pelos clientes é grande. 
Então, estamos falando da qualidade do software e também do seu processo de 
desenvolvimento! Qualidade aplicada a processos e produtos! 
Leitura obrigatória 
Uma Introdução à Qualidade de Software: 
https://www.infoq.com/br/news/2012/05/An-Introduction-Software-Quality 
 
4 
 
Saiba mais 
O mercado de software brasileiro conta com o Simpósio Brasileiro de 
Qualidade de Software. É um evento anual da Comissão Especial de 
Engenharia de Software da Sociedade Brasileira de Computação (SBC) e do 
Comitê do Programa Brasileiro da Qualidade e Produtividade em Software 
(PBQP-SW), tem como objetivo reunir empresários, profissionais, professores, 
pesquisadores e estudantes de diversas áreas, interessados em questões 
relativas à qualidade de software, em um evento de divulgação e troca de 
experiências, promovendo a integração Universidade – Empresa. 
O simpósio está em sua 16.ª edição. Informações, artigos e dissertações 
de mestrado sobre a 15.ª edição podem ser encontrados em: 
http://sbqs2015.com.br/apresentacao/ 
Pesquise 
Utilize o link abaixo e identifique os temas que mais foram discutidos em 
2015. Você verificará várias linhas de atuação da qualidade de software 
aplicadas em situações de testes, de requisitos, de melhorias de processos. 
Tente encontrar temas que lhe despertem mais interesse, pois a área de 
qualidade de software é bastante extensa. 
http://sbqs2015.com.br 
Leitura obrigatória 
 http://sbqs2015.com.br/apresentacao 
 Temas como automatização de testes são discutidos? 
 O que fazer para aplicarmos testes a todo o processo de desenvolvimento 
de software? 
 Quais são as tendências na área de qualidade e testes de software? 
 
5 
 
TEMA 1 - CONCEITOS SOBRE QUALIDADE 
Como definirmos o que é qualidade, como saber o que ela representa ou 
compreendermos quando ela não existe? 
Definir qualidade é algo complexo à primeira vista, porém, com um 
exemplo mais prático ficará um pouco mais tangível para você. Vamos 
ao exemplo: 
Imagine-se em um restaurante, para o qual, em especial hoje, você pagou 
mais caro que o seu hábito. Se alguém lhe perguntar se a comida tinha 
qualidade, você certamente saberá responder com rapidez, sim, não ou se faltou 
algo para que ficasse melhor ainda. Em todos os momentos estamos falando 
sobre qualidade de algo, seja do transporte público, demora no atendimento em 
alguma loja ou banco. Estamos envoltos com este conceito a todo momento em 
nossas vidas, porém, se eu lhe pedir para definir qualidade, você pensará um 
pouco para tentar colocar em palavras aquilo que lhe é familiar e ao mesmo 
tempo tão subjetivo! 
Subjetivo? Sim, porém se você estiver neste mesmo restaurante que lhe 
propus anteriormente com outra pessoa, esta poderá ter outra visão sobre a 
qualidade da mesma comida! Isso não quer dizer que ela invalidará a sua 
avaliação sobre a refeição. Isso nos mostra que precisamos analisar melhor o 
que esperamos da qualidade, seja de produtos ou de serviços. 
Qualidade, segundo o INMETRO, “é uma variável precisa e mensurável, 
oriunda do grau de conformidade do planejado com o executado. Esta 
abordagem dá ênfase a ferramentas estatísticas.”. (INMETRO, 2015). 
Já para Shigunov Neto (2016), qualidade 
é uma filosofia de gestão empresarial ou um modelo de gestão 
administrativa que visa atingir permanentemente a melhoria de 
produtos ou serviços oferecidos, por meio da mudança dos processos 
 
6 
 
produtivos, da redução de custos, de uma transformação cultural e do 
envolvimento e do comprometimento dos trabalhadores. 
 
Alguns nomes são importantes para a área de qualidade, e cada qual tem 
um enfoque (SHIGUNOV, 2016). Dentre eles temos: 
1. Deming (1950) – Máxima utilidade para o consumidor; 
2. Feigenbaum (1951) – Perfeita satisfação do usuário; 
3. Juran (1954-1964) – Satisfação das aspirações do usuário. Maximização 
das aspirações do usuário e adequação ao uso; 
4. Crosby (1979) – Conformidade com os requisitos do cliente. 
Quando olhamos pela ótica da Engenhariade Software, podemos dizer 
que as palavras-chave para qualidade, em se tratando de software, segue o que 
ilustra a Figura 1. 
Figura 1: Qualidade de Software 
 
Fonte: Pressman, 2011. 
A qualidade de software pode ser definida, segundo Pressman, como 
“uma gestão de qualidade efetiva aplicada de modo a criar um produto útil que 
forneça valor mensurável para aqueles que o produzem e para aqueles que o 
utilizam.” Para que isso ocorra, precisamos garantir uma boa gestão de 
qualidade, um produto útil e valor agregado tanto para o desenvolvedor quanto 
para os stakeholders de um produto de software. Assim como para fabricação 
satisfação do 
usuário
produto 
compatível
boa 
qualidade
entrega 
dentro do 
orçamento
entrega 
dentro prazo
 
7 
 
de qualquer produto ou prestação de serviços, precisamos ter foco na qualidade 
tanto de processos quanto de produtos (resultados). 
Leitura obrigatória 
http://www.inmetro.gov.br/qualidade/iaac/pdf/fundamentos-qualidade.pdf 
Saiba mais 
Qualidade, qualidade de software e garantia da qualidade de software são as 
mesmas coisas? 
Quais suas diferenças e complementaridades. 
http://www.linhadecodigo.com.br/artigo/1712/qualidade-qualidade-de-software-
e-garantia-da-qualidade-de-software-sao-as-mesmas-coisas.aspx 
 
TEMA 2: DIMENSÕES DA QUALIDADE DE SOFTWARE 
Sabemos então que qualidade se aplica tanto a produtos/serviços quanto 
aos processos e, em complemento a tudo isto, podemos ainda visualizar a 
qualidade sob algumas dimensões (PRESSMAN, 2011): 
1. Qualidade do desempenho: funcionalidades e recursos especificados 
devem estar de acordo com o produto/serviço entregue; 
2. Qualidade dos recursos: o software deve fornecer recursos que 
surpreendam e encantem os stakeholders; 
3. Confiabilidade: o software deve funcionar sem falhas, erros e disponível 
a qualquer momento; 
4. Conformidade: o software deve estar de acordo com padrões locais e 
externos; 
 
8 
 
5. Durabilidade: o software pode ser mantido ou corrigido sem a geração de 
efeitos colaterais; 
6. Facilidade de manutenção: o software pode ser mantido ou corrigido por 
período de tempo aceitável; 
7. Estética: elegância com um fluir único e uma presença difíceis de 
quantificar; 
8. Percepção: pode ser maculada por produtos anteriores entregues sem 
qualidade ou pode ser superestimada por produtos anteriores entregues 
com sucesso. 
Já segundo o INMETRO (2015), estas dimensões ou categorias da 
qualidade podem ser catalogadas da seguinte forma: 
1. Desempenho 
2. Características 
3. Confiabilidade 
4. Durabilidade 
5. Atendimento 
6. Estética 
7. Qualidade percebida 
8. Conformidade 
Podemos observar que mesmo autores diferentes possuem compreensão 
muito similar quanto aos quesitos que compõem as dimensões da qualidade de 
um produto/serviço. 
Leitura obrigatória 
http://www.inmetro.gov.br/qualidade/iaac/pdf/fundamentos-qualidade.pdf 
Saiba mais 
O que é o INMETRO? 
 
9 
 
O INMETRO é um instituto nacional de metrologia, qualidade e tecnologia. À 
primeira vista, muitos imaginam que ele atende à indústria, porém com a 
necessidade cada vez maior por questões relacionadas à qualidade de software, 
o mesmo vem atendendo também a esta área que cresce a cada dia no país. 
 http://www.inmetro.gov.br/inmetro/oque.asp 
Caminhamos mais um pouco no conhecimento da qualidade de software 
e de processo de software. Pudemos observar alguns pontos importantes para 
compreendermos melhor o trabalho que teremos pela frente para garantirmos 
todo o processo e atingirmos os melhores resultados na construção de software. 
TEMA 3: FATORES DE QUALIDADE 
Até o momento falamos sobre conceitos e definições importantes para a 
compreensão da qualidade e qualidade de software. Visualizamos que qualidade 
não é um conceito novo, mas quando falamos de desenvolvimento de software 
ainda temo um caminho longo a trilhar para atingirmos os melhores resultados, 
visto que partimos sempre do subjetivo para o objetivo. Partimos de ideias e as 
transformamos em códigos que resultam em produtos capazes de agilizar 
atividades tanto operacionais quanto estratégicas de nossos stakeholders. 
Agora vamos compreender um pouco sobre os fatores de qualidade 
atrelados ao software. Observando que teremos três importantes aspectos em 
um produto de software (PRESSMAN, 2011): 
1. Características operacionais; 
2. Habilidade de suportar mudanças; 
3. Adaptabilidade a novos ambientes. 
 
 
10 
 
A figura 2 relaciona estes três aspectos subdivididos em outras 
abordagens importantes para considerarmos a qualidade de software. 
Figura 2: Fatores de qualidade de software 
 
Fonte: Pressman, 2011. 
Começando pelo grupo Revisão do Produto dos fatores de qualidade de 
software, teremos as seguintes definições dos subgrupos (PRESSMAN, 2011): 
1. Facilidade de manutenção: é o esforço necessário para localização e 
correção de um erro dentro de um programa. 
2. Flexibilidade: é o esforço necessário para modificação de um programa 
que já esteja em operação. 
3. Testabilidade: é o esforço necessário para o teste de um programa para 
garantia de seu desempenho e função destinada. 
 
Revisão do 
Produto
• Facilidade de manutenção
• Flexibilidade
•Testabilidade
Transição do 
Produto
•Portabilidade
•Reusabilidade
• Interoperabilidade
Operação do 
Produto
•Correção
•Confiabilidade
•Usabilidade
•Integridade
•Eficiência
 
11 
 
O próximo grupo, Transição do Produto, possui as seguintes 
competências: 
1. Portabilidade: é o esforço necessário para transferência de um programa 
em um ambiente de hardware/software para outro. 
2. Reusabilidade: é o quanto o programa pode ser reutilizado em outras 
aplicações, ou partes deste. 
3. Interoperabilidade: é o esforço necessário para integração de um 
sistema ao outro. 
 
E finalmente, o último grupo, Operação do Produto, possui as seguintes 
atribuições: 
1. Correção: é o quanto o programa satisfaz a sua especificação e atende 
objetivos dos stakeholders. 
2. Confiabilidade: é o quanto se pode esperar que um programa realize a 
função pretendida com a precisão exigida. 
3. Usabilidade: é o esforço necessário para aprender, operar, preparar a 
entrada de dados e interpretar a saída de um programa. 
4. Integridade: é o quanto o acesso ao software ou dados por pessoas não 
autorizadas pode ser controlado. 
5. Eficiência: é a quantidade de recursos computacionais e código exigidos 
por um programa para desempenhar sua função. 
Temos também a versão dos fatores de qualidade segundo a ISO 9126, 
que é um padrão desenvolvido para identificação dos atributos fundamentais de 
qualidade para software de computador. Segundo esta versão de fatores, 
possuímos seis aspectos diferentes (PRESSMAN, 2011): 
 
 
12 
 
1. Funcionalidade: que corresponde ao grau de satisfação das 
necessidades elicitadas. 
2. Confiabilidade: é a quantidade de tempo que o software fica disponível 
para uso, bem como sua maturidade, tolerância a falhas e facilidade de 
recuperação. 
3. Usabilidade: diz respeito ao grau de facilidade de utilização do software 
(compreensão, aprendizagem e operabilidade). 
4. Eficiência: é o grau de otimização do uso dos recursos do sistema 
(comportamento em relação a tempo e recursos). 
5. Facilidade de manutenção: corresponde à facilidade de correção do 
software (facilidade de análise, mudanças, estabilidade e testabilidade). 
6. Portabilidade: quão ágil é passar o software de um ambiente 
(plataforma) para outro (adaptabilidade, facilidade de instalação, conformidadee facilidade de substituição). 
De acordo com esta visão sobre os fatores de qualidade, é fácil concluir 
que teremos um longo caminho a percorrer para construirmos um software com 
qualidade, bem como propor um processo capaz de agregar tais requisitos de 
qualidade em seu ciclo de vida. 
Leitura obrigatória 
http://www.linhadecodigo.com.br/artigo/1712/qualidade-qualidade-de-software-
e-garantia-da-qualidade-de-software-sao-as-mesmas-coisas.aspx 
 
 
 
 
13 
 
TEMA 4: DILEMAS DA QUALIDADE 
Estudamos anteriormente o que seriam os princípios básicos da 
Qualidade de Software. Agora precisamos mergulhar em um mundo de dilemas 
em relação à qualidade do processo de desenvolvimento e do software. 
Considere a seguinte entrevista à Bertrand Meyer (VENNERS, 2003 apud 
PRESSMAN, 2011): 
Se produzirmos um sistema de software de péssima qualidade, 
perdemos porque ninguém irá querer comprá-lo. Se, por outro lado, 
gastamos um tempo infinito, um esforço extremamente grande e 
grandes somas de dinheiro para construir um software absolutamente 
perfeito, então isso levará muito tempo para ser completado, e o custo 
de produção será tão alto que iremos à falência. Ou perdemos a 
oportunidade de mercado ou então simplesmente esgotamos todos os 
nossos recursos. Dessa maneira, os profissionais desta área tentam 
encontrar aquele meio-termo mágico onde o produto é suficientemente 
bom para não ser rejeitado logo de cara, como, por exemplo, durante 
uma avaliação, mas também não é o objeto de tamanho 
perfeccionismo e trabalho que levaria muito tempo ou que custaria 
demasiadamente para será finalizado. 
A grande questão encontra-se em um esforço racional e objetivo para 
atingirmos a melhor qualidade possível, porém dentro de prazos e custos 
tangíveis. Então surge a questão: O que é um software bom o suficiente? 
Ele deverá fornecer funções e características de alta qualidade que os 
usuários desejam, porém dentro de um tempo e custo dentro do estabelecido 
para o projeto do software. (PRESSMAN, 2011). 
Agora precisamos olhar para os custos. Qualidade é importante, mas 
sempre terá um custo (tempo e dinheiro). 
 
 
14 
 
Figura 3: Custos da Qualidade 
 
Quando falamos em custos da qualidade precisamos incluir todos os 
custos necessários para a busca de qualidade e para a execução de atividades 
relacionadas à qualidade ou pela falta de qualidade. Isso é possível quando 
reunimos métricas para promoção de uma base de custo corrente da qualidade, 
identificando-se oportunidades para redução. Este é dividido em custos de 
prevenção, avaliação e falhas (Figura 3). 
Os Custos de Prevenção contêm os seguintes itens: 
1. Custos de atividades de gerenciamento (planejamento, coordenação, 
controle e garantia de qualidade). 
2. Custos de atividades técnicas adicionais (requisitos e projeto). 
3. Custos de planejamento de testes. 
4. Custos de treinamento para todas as atividades anteriores. 
Já os Custos de Avaliação incluem custos: 
1. Para a execução de revisões técnicas. 
Custos de Qualidade
Falhas
Avaliação
Prevenção
 
15 
 
2. Que abordem a coleta de dados, bem como a avaliação por meio 
de métricas. 
3. Para testes e depuração dos programas (PRESSMAN, 2011). 
Finalmente, os Custos de Falhas comportam: 
1. A percepção da necessidade de retrabalhos e correção de erros. 
2. Valores relacionados ao efeito colateral no caso dos retrabalhos. 
3. Tudo que esteja associado às reuniões para aplicação das métricas de 
qualidade. (PRESSMAN, 2011). 
 
Figura 4: Custos da Qualidade de Software X Ciclo de Vida dos Sistemas 
 
Fonte: Pressman, 2011. 
Segundo Pressman (2011): “O custo médio da indústria de software para 
correção de um defeito durante a geração de código é de aproximadamente 977 
dólares por erro. Para correção do mesmo erro na fase de testes é de 7136 por 
erro”. Ou seja, à medida que avançamos no projeto, encontrar e corrigir um erro 
torna-se cada vez mais caro. A Figura 4 nos demonstra graficamente, em 
milhares de dólares, o quanto encontrar erros e falhas em um projeto de software 
torna-se drasticamente mais caro à medida que evoluímos nas etapas do projeto. 
 
16 
 
Além de todos estes custos, ainda entramos nos quesitos riscos, 
responsabilidade civil, segurança e o impacto das ações administrativas sobre o 
processo de desenvolvimento de software, considerando-se aspectos de 
qualidade. Quanto aos riscos, encontramos pessoas que entregam seus 
empregos, segurança, entretenimento, decisões e a vida em software. Com isso, 
precisamos avaliar os riscos envolvidos quando um software possui falhas e 
erros. Isso deve ser muito bem pensado ao se desenvolver um software que 
envolva altos riscos. 
Outro aspecto fica por conta de sistemas que se tornam lentos, com 
recursos e funções suscetíveis a erros sem a aprovação dos usuários, tornando 
o pagamento pelo software algo que entra na esfera judicial. Usuários dizem que 
os desenvolvedores foram negligentes, ocasionando um problema sério de fluxo 
de caixa para a empresa desenvolvedora. 
A segurança é um requisito extremamente importante atualmente, visto a 
quantidade de sistemas via Web e aparelhos móveis. A segurança implica 
diretamente em questões de falhas arquiteturais. E, finalmente, quanto às 
questões administrativas, encontramos problemas relacionados a estimativas, 
cronogramas e riscos que acabam por interferir em todo o processo de 
desenvolvimento e qualidade do processo. 
Terminamos com o seguinte pensamento de Meskimen 
(PRESSMAN, 2011): “Nunca há tempo para fazer a coisa certa, mas sempre há 
tempo para fazê-la de novo. Meu conselho: tomar o tempo necessário para fazer 
certo da primeira vez quase nunca é uma decisão errada.” 
Leitura obrigatória 
http://www.linhadecodigo.com.br/artigo/1712/qualidade-qualidade-de-software-
e-garantia-da-qualidade-de-software-sao-as-mesmas-coisas.aspx 
 
 
17 
 
TEMA 5: ALCANÇANDO A QUALIDADE DE SOFTWARE 
Chegamos até aqui com muitas definições, conceitos e filosofando sobre 
o que é e o que não é qualidade. Como pensarmos em todas as questões 
relacionadas à qualidade do processo e do software. Realmente, a qualidade de 
software é uma área extensa e que merece um esforço reflexivo bastante 
grande, porque depois que estivermos inseridos em um projeto e este estiver no 
ar, não há mais tempo para refletirmos. A reflexão fica por conta primeiramente 
de nossa visão bastante clara sobre os problemas futuros que podemos ter e 
que, por meio de algumas iniciativas relacionadas à qualidade, poderemos evitar 
em nossos projetos e em nossa vida profissional. 
Vamos então listar algumas ações de controle de qualidade e garantia da 
qualidade que poderão salvar nossos projetos e nossas noites e finais de 
semana de trabalho ou retrabalho (PRESSMAN, 2011): 
1. Métodos de engenharia de software: primeiro passo, compreender com 
clareza qual é o problema a ser resolvido. Sermos capazes de criar um 
projeto adequado ao problema. 
2. Técnicas de gerenciamento de software: Estimativas de datas plausíveis, 
cronogramas sem atalhos e planejamento de riscos orientado a 
problemas e não ao caos. 
3. Controle de qualidade: Conjunto de ações de engenharia de software para 
auxiliar na garantia de que cada produto atinja suas metas de qualidade. 
Modelos revistos e códigos inspecionados, corrigidos antes dos testes. 
Testes para descoberta de erros na lógica, na manipulação dos dados e 
na comunicação da interface. Feedbacks com a equipe de software. 
4. Garantia da qualidade: infraestrutura com métodos sólidos de engenharia 
de software, gerenciamento racional de projeto e açõesde controle 
de qualidade 
 
 
18 
 
Conforme os anos passam na história da engenharia de software, nossos 
critérios de qualidade de software crescem, tornando-os cada vez mais efetivos. 
Utilizarmos, por exemplo, a ISO 9126 estabelecerá características de 
confiabilidade, usabilidade, facilidade de manutenção, funcionalidade e 
possibilidade como indicadores da existência da qualidade de software. 
(PRESSMAN, 2011). 
E não temos como fugir, a qualidade de software só existe quando 
olharmos para os métodos da engenharia de software, práticas administrativas 
consistentes e controle de qualidade completo. Não podemos esquecer que os 
custos e desastres em relação à falta de qualidade, tanto do processo quanto do 
software, serão substanciais e muitas vezes insolúveis. 
Leitura obrigatória 
http://www.linhadecodigo.com.br/artigo/1712/qualidade-qualidade-de-software-
e-garantia-da-qualidade-de-software-sao-as-mesmas-coisas.aspx 
 
TROCANDO IDEIAS 
Que tal analisarmos, diante de nossa pouca ou muita experiência e de 
exemplos de outros, qual a real importância da qualidade de software e quão 
extensa esta área pode ser dentro da área de desenvolvimento de software? 
SÍNTESE 
 Quando falamos de qualidade de sistemas ou processos de 
desenvolvimento, não estamos querendo discutir metodologias, técnicas e 
ferramentas para colocarmos em nosso currículo. A qualidade vai além da sala 
de aula. Ela é um elemento fundamental para o sucesso ou a sua ausência para 
o fracasso de um software. Vimos que quando pensamos em qualidade não 
 
19 
 
estamos falando apenas em tirarmos os erros de código, não que isto não seja 
importante, mas estamos vislumbrando o software como um conjunto não só de 
códigos que seguem uma determinada lógica, mas um software que manipule 
dados e se comunica com pessoas. Usuários estão cada vez mais exigentes e 
querem respostas rápidas, eficientes, confiáveis, por meio de interfaces simples. 
Nosso desafio então é aplicarmos a qualidade de software, observando-se 
obviamente o escopo de nosso projeto diante de seus custos. Não temos como 
fazer milagres, mas podemos nos cercar de pontos importantes a serem 
analisados diante de todo o processo de software, vislumbrando um software e 
um processo de desenvolvimento de software que busque sua excelência 
em qualidade. 
REFERÊNCIAS 
INMETRO. Fundamentos da Qualidade. Disponível em: 
<http://www.inmetro.gov.br/qualidade/iaac/pdf/fundamentos-qualidade.pdf>. 
Acesso em: maio de 2016. 
LÉLIS, E. C. Gestão da qualidade. São Paulo: Pearson Prentice Hall, 2012. 
PRESSMAN, R. S. Engenharia de software: uma abordagem profissional. 7. 
ed. Porto Alegre: AMGH, 2011. 
SOMMERVILLE, I. Engenharia de software. 9. ed. São Paulo: Pearson 
Prentice Hall, 2011. 
SHIGUNOV NETO, A. Introdução à gestão da qualidade e produtividade: 
conceitos, história e ferramentas. Curitiba: InterSaberes, 2016. 
VENNERS, B. Design by contract: a conversation with Bertrand Meyer. Artima 
Developer, December 8, 2003. Disponível em: 
<www.artima.com/intv/contracts.html>. 
 
20 
 
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. 
 
 
1 
 
 
 
 
 
 
 
 
 
 
 
 
QUALIDADE DE SOFTWARE 
AULA 2 
 
 
 
 
 
 
 
 
 
 
 
Prof.a Maristela Regina Weinfurter Teixeira 
 
2 
 
CONVERSA INICIAL 
Olá, seja bem-vindo. Assista ao segundo 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 
Após conhecermos um pouco sobre a qualidade de software, vamos 
estudar sua amplitude por meio de conceitos da garantia da qualidade 
de software. A garantia da qualidade de software (SQA), segundo 
Pressman (2011), contém as seguintes etapas: 
1. Um processo de SQA. 
2. Tarefas específicas e controle da qualidade (revisões técnicas e 
estratégia de testes multiescalonados). 
3. Prática efetiva de engenharia de software (métodos e ferramentas). 
4. Controle de todos os artefatos de software e as mudanças feitas nesses 
produtos. 
5. Um procedimento para garantir a conformidade com os padrões de 
desenvolvimento de software. 
6. Mecanismos de medição e de relatórios. 
 
A garantia da qualidade pode-se dizer que é um conjunto de atividades 
essenciais para qualquer empresa de produtos a serem usados por terceiros, 
isso falando em termos gerais. Agora, focando na área de desenvolvimento de 
software, até os anos 60 a qualidade no desenvolvimento de software era de 
responsabilidade exclusiva de cada programador. Nos anos 70, as coisas 
começam a mudar e surge então a preocupação na criação de padrões para 
garantia da qualidade no desenvolvimento de software, em especial pela 
indústria militar dos Estados Unidos, o que rapidamente foi absorvido por todo o 
mercado de software. (PRESSMAN, 2011). E tal preocupação cresceu à medida 
que o software passou a ser integrado em cada aspecto da vida cotidiana. 
 
3 
 
Desenvolver softwares nos dias atuais deixou de ser algo para 
programadores independentes e solitários e se tornou um trabalho que 
experimenta a colaboração e cooperação entre profissionais com 
especializações dentro da engenharia de software e de outras áreas. Assim, 
vamos verificar, claro que cuidando das devidas proporções de tamanhos de 
projetos e empresas desenvolvedoras, profissionais especializados no projeto, 
na codificação, em testes e outras tantas atividades que agregam os cuidados 
que a garantia da qualidade de software nos oferece. 
 
Leitura obrigatória 
SOMMERVILLE, 2011 
Saiba mais 
Este curta metragem é pequeno, mas ao mesmo tempo nos traz uma boa 
percepção do que é desenvolvermos um software apenas por meio da tentativa 
e erro em vez de irmos direto às muitas orientações sobre como podemos ter 
mais produtividade, melhoria de processos e um produto/serviço que de fato 
atenda a nossos usuários. 
https://www.youtube.com/watch?v=LOyX-vgdQGQ 
Consulte também livros da biblioteca virtual ou sites da internet que falem 
sobre garantia da qualidade. 
 
Antes de entrarmos de fato na garantia da qualidade de software, 
pesquise sobre o assunto, focado para produtos e serviços em geral. Você é 
consumidor de algum tipo de produto ou serviço e então liste o que é bom ou 
ruim em algum produto/serviço para que logo após reflita sobre: 
1. O que poderia melhorar neste produto? 
2. Como isto poderia ser feito? 
3. Como será o processo de fabricação/serviço até que eu receba meu 
produto/serviço? 
 
4 
 
Quando fazemos este exercício com algo que nos afeta diretamente, fica 
mais fácil compreendermos e absorvermos todas as preocupações da garantia 
da qualidade de software. 
 
TEMA 1: ELEMENTOS DA GARANTIA DA QUALIDADE DE SOFTWARE 
Para prosseguirmos na nossa trajetória sobre garantia da qualidade, 
vamos compreender a ideia da estrutura de gerenciamento de software segundo 
(HUMPHREY,1989 apud SOMMERVILLE, 2011): 
1. Introdução ao produto. Uma descrição do produto, seu 
mercado pretendido e as expectativas de qualidade do produto. 
2. Planos de produto. As datas críticas de release e 
responsabilidades para o produto, junto com os planos para a 
distribuição e prestação de serviço do produto. 
3. Descrições de processo. Os processos de desenvolvimento e 
serviço são padrões que devem ser usados para o gerenciamento e 
desenvolvimento de produto. 
4. Metasde qualidade. As metas de qualidade e planos para o 
produto, incluindo uma identificação e uma justificativa para os 
atributos críticos de qualidade do produto. 
5. Riscos e gerenciamento de riscos. Os riscos mais importantes 
que podem afetar a qualidade do produto e as ações que devem ser 
tomadas ao lidar com eles. 
Seguindo estas ideias, podemos dividir a garantia da qualidade 
de software em três categorias (CAMPOS, 2016), que podem ser visualizadas 
na Figura 1: 
 
 
 
 
 
 
 
 
5 
 
Figura 1: Elementos da Garantia da Qualidade de Software 
 
 Fonte: adaptado de Campos, 2016. 
1. Teste de Software: Inclui atividades de verificação e validação. É 
importante que o software seja testado para verificação desde o início da 
elicitação dos requisitos funcionais e não funcionais até o momento de 
entrega do software. 
2. Controle da Qualidade: nesta fase se monitora o trabalho, observando 
se os requisitos estão sendo satisfeitos. Revisar e remover defeitos antes 
que o software seja entregue. Cheklists bem definidos e especificados no 
plano de garantia da qualidade. Dentro das revisões, inspeção é 
considerado como um sinal de grande grau de maturidade do processo 
de controle de qualidade. 
3. Gerenciamento de Configuração de Software: fase em que 
se identifica, rastreia e controla mudanças nos elementos do software de 
um sistema. Ele ainda controla a evolução do sistema de 
software, gerenciando versões dos componentes de software e 
seus relacionamentos. 
Caminhando mais um pouco, podemos ampliar nossas preocupações e 
atividades que se concentram na gestão e garantia da qualidade 
(PRESSMAN, 2011): 
Teste de 
Software
Controle de 
Qualidade
Gerenciamento 
de 
Configuração 
de Software
 
6 
 
1. Padrões: IEEE, ISO e outras organizações de padronizações. 
2. Auditorias e Revisões: revisões técnicas são atividade de controle de 
qualidade para revelação de erros. Auditoria é um tipo de revisão para 
nos assegurar de que as diretrizes de qualidade estejam sendo seguidas. 
3. Testes: fazem parte do controle de qualidade com o objetivo principal a 
descoberta de erros. 
4. Coleta e análise de erros/defeitos: melhoria do desempenho das 
melhores práticas para garantia da qualidade por meio de medições. 
5. Gerenciamento de mudanças: são aspectos negativos dentro do 
desenvolvimento de software, porém ocorrem a todo instante. 
6. Educação: aperfeiçoamento dos desenvolvedores e interessados. 
7. Gerência de fornecedores: pacotes comerciais, software sob 
encomenda devem ser avaliados por meio da garantia de qualidade de 
software antes da aquisição. 
8. Administração da segurança: crimes cibernéticos e novas 
regulamentações governamentais quanto à privacidade devem fazer 
parte das políticas de proteção de dados em todos os níveis. 
9. Proteção: o software envolve vidas humanas e o impacto de defeitos e 
falhas pode ser catastrófico. 
10. Administração de riscos: garantir a gestão de riscos de forma 
apropriada em relação aos planos de contingência. 
Com base nestes elementos, sabemos que temos várias subáreas para 
nos preocuparmos e estudarmos até o final deste módulo para conseguirmos 
dimensionar em nosso dia a dia em como garantir a qualidade dos processos de 
desenvolvimento de software e do próprio software resultante. 
Leitura obrigatória 
SOMMERVILLE, 2011 
CAMPOS, 2016 
 
 
7 
 
Saiba mais 
Este artigo nos traz outra forma de visualizar o gerenciamento da qualidade de 
software e assegurar a garantia da mesma: 
 http://tenstep.com.br/blog/?p=839 
 
TEMA 2: TAREFAS, METAS E MÉTRICAS 
Garantir a qualidade de software pressupõe que temos métricas que nos 
auxiliam por meio de estatísticas para acompanhamento dos resultados do 
processo de desenvolvimento de software. E esta é composta por um conjunto 
de tarefas, que tem por responsabilidade o planejamento, supervisão, 
manutenção de registros, análise e relatórios. (PRESSMAN, 2011). O pessoal 
da garantia da qualidade tem por responsabilidade auxiliar a equipe de software 
na obtenção de um produto final com alta qualidade. Essa mesma equipe de 
garantia da qualidade para cada projeto prepara um plano de atividades de 
garantia da qualidade, participa no desenvolvimento da descrição da gestão de 
qualidade do projeto, revisa as atividades de engenharia de software para 
verificação das conformidades, audita produtos de software resultantes para 
verificação de sua conformidade, garante que desvios de trabalho de software e 
produtos resultantes sejam documentados e registra qualquer não aderência, 
bem como relata ao gerenciamento superior do projeto. 
As ações do grupo de garantia da qualidade devem atingir um conjunto 
de metas pragmáticas (PRESSMAN, 2011): 
1. Qualidade dos requisitos: correção, completude e consistência do 
modelo de requisitos. 
2. Qualidade do projeto: avaliação de todo elemento do modelo de projeto 
para garantir que apresente alta qualidade e que o projeto esteja de 
acordo com os requisitos. 
 
8 
 
3. Qualidade do código: tanto o código-fonte quanto os produtos 
relacionados devem estar em conformidade com os padrões locais de 
codificação e apresentar características para facilitar a manutenção. 
4. Eficácia do controle de qualidade: a equipe de software aplica recursos 
limitados para obtenção da maior probabilidade possível de atingir um 
resultado de alta qualidade. Agora vamos detalhar estas metas e 
identificar atributos indicadores de qualidade para cada meta discutida 
(adaptado de HYA, 96 apud PRESSMAN, 2011). Veja a tabela 1 a seguir: 
 
Tabela 1: Metas, atributos e métricas para qualidade de software 
 
Meta Atributo Métrica 
Qualidade das 
necessidades 
Ambiguidade 
 
Número de modificadores ambíguos 
 
Completude 
 
Número de TBA, TBD 
 
Compreensibilidade 
 
Número de seções/subseções 
Volatilidade 
 
Número de mudanças por requisito 
Tempo por atividade quando solicitada a mudança 
Facilidade de atribuição 
 
Número de requisitos não atribuíveis ao projeto/código 
Clareza do modelo Número de modelos UML 
Número de páginas descritivas por modelo 
Número de erros UML 
Qualidade do 
projeto 
Qualidade do 
código 
Integridade da 
arquitetura 
Existência do modelo da arquitetura 
Completude dos 
componentes 
Número de componentes que se atribui ao modelo da 
arquitetura 
Complexidade da 
interface 
Número médio de cliques para chegar a uma função ou 
conteúdo típico 
 Layout apropriado 
Padrões Número de padrões usados 
Complexidade Complexidade ciclométrica 
 
9 
 
Facilidade de 
manutenção 
Fatores de projeto 
Compreensibilidade Porcentagem de comentários internos 
Convenções de atribuição de variáveis 
Reusabilidade Porcentagem de componentes reutilizados 
Documentação Índice de legibilidade 
Eficiência do 
controle de 
qualidade 
Alocação de recursos Porcentagem de horas de pessoa por atividade 
Taxa de completude Tempo de finalização real versus previsto 
Eficácia da revisão Ver métricas de revisão 
Eficácia dos testes Número de erros encontrados 
Esforço exigida para corrigir um erro 
Origem do erro 
Fonte: Pressman, 2011. 
Temos ainda uma longa jornada dentro do incrível mundo da garantia da 
qualidade. Conseguirmos atingir todas as metas expostas na tabela 1 é uma 
tarefa árdua. Caminharemos para o próximo tema com a ideia de tornarmos 
estas metas e métricas em estatísticas eficientes. 
Leitura obrigatória 
SOMMERVILLE, 2011 
CAMPOS, 2016 
 
Saiba mais 
Alguns links interessantes que falam sobregestão e garantia da qualidade: 
 www.asq.org/software 
 www.sei.cmu.edu 
 www.isospice.com 
 
TEMA 3: ESTATÍSTICA 
Já conversamos sobre metas e métricas, agora vamos falar a respeito da 
estatística da garantia da qualidade. Esta reflete uma tendência crescente em 
 
10 
 
toda a indústria de software. Segundo Pressman (2011), a estatística da 
qualidade implica nas seguintes etapas: 
1. Informações sobre erros e defeitos coletados e classificados. 
2. Associação de cada erro e defeito a sua causa (erros de projeto, violação 
de padrões, comunicação inadequada com cliente). 
3. Uso do princípio de Pareto (80% dos defeitos podem ser associados a 
20% de suas possíveis causas), isolando 20% a poucas causas vitais. 
4. Correção dos problemas que provocaram os erros e defeitos. 
Aparentemente, pode-se pensar que é tão simplista, mas este tipo de 
conceito já impacta na criação de uma gestão de qualidade adaptativa com 
mudanças feitas e melhorias nos elementos do processo que introduziram 
os erros. 
Vamos listar algumas causas mais comuns encontradas em estatísticas 
deste tipo: 
1. (IES) Especificações incompletas. 
2. (MCC) Problema com interpretação da comunicação com o cliente. 
3. (IDS) Desvio intencional nas especificações. 
4. (VPS) Violação dos padrões de programação. 
5. (EDR) Erro na representação de dados. 
6. (ICI) Interface inconsistente de componentes. 
7. (EDL) Erro na lógica de projeto. 
8. (IET) Testes incompletos ou errados. 
9. (IDD) Documentação incompleta ou sem precisão. 
10. (PLT) Erro na tradução do projeto para linguagem de programação. 
11. (HCI) Interface homem-computador ambígua ou inconsistente. 
12. (MIS) Outros. 
 
É claro que esta lista nos dá uma ideia de algumas causas encontradas e 
não necessariamente serão adotadas dessa forma. Para cada empresa é 
importante observação e experimentos até que se encontrem as causas mais 
 
11 
 
aderentes aos projetos. A Figura 2 reflete a utilização desta lista para 
exemplificação de como coletarmos estes dados. 
 
Figura 2: Coleta de dados para estatística de garantia da qualidade 
 
Fonte: Pressman, 2011. 
 
Uma vez apurada estatisticamente nossos problemas, conseguiremos 
aperfeiçoar substancialmente a qualidade de nossos processos e produtos. Ao 
aplicarmos a estatística e o princípio de Pareto, sintetizaremos em uma única 
sentença, segundo Pressman (2011): “Invista seu tempo concentrando-se em 
coisas que realmente importam, mas, primeiramente, certifique-se de ter 
entendido aquilo que realmente importa!”. 
 
Leitura obrigatória 
SOMMERVILLE, 2011 
CAMPOS, 2016 
 
 
 
 
12 
 
TEMA 4: CONFIABILIDADE DE SOFTWARE 
Agora vamos falar um pouco sobre a confiabilidade do software, 
pensando um pouco nas consequências caso esse falhe frequentemente e 
repetidamente. Não iremos nos importar se os outros fatores de qualidade são 
aceitáveis, o fato é que isto atrapalha em muito a produtividade de quem o 
esteja utilizando. 
Aqui estamos pensando nas falhas de programas de computador em um 
determinado ambiente por um determinado tempo. Podemos estimar que um 
programa, após oito horas em funcionamento, tenha um grau de confiabilidade 
de 0,999, ou seja, é provável que ele opere corretamente e sem falhas por 
999 vezes. 
Para compreendermos o conceito de confiabilidade de software, precisaremos 
refletir sobre o que é falha. Falha é um termo que corresponde à falta de 
conformidade com os requisitos de software. Mesmo essa definição possui 
algumas variações. As falhas podem ser apenas problemáticas ou catastróficas. 
Quando uma falha pode ser corrigida em segundos, outras precisarão até de 
meses para serem corrigidas. E outro perigo é que, após a correção de tal falha, 
esta pode resultar na introdução de outros erros que resultarão em outras falhas. 
E este tema vem de longa data. Já tentaram trabalhar falhas por meio da 
teoria da confiabilidade de hardware para previsão da confiabilidade de software 
— matemática — (PRESSMAN, 2011). Todas as falhas de software podem ser 
associadas a problemas de projeto ou implementação. Uma medida de 
confiabilidade simples pode ser encontrada pelo uso da seguinte fórmula: 
MTBF=MTTF+MTTR, em que MTBF (tempo médio entre falhas), MTTF (tempo 
médio para falhar) e MTTR (tempo médio para reparar). 
Há uma polêmica entre pesquisadores que acreditam que o MTBF é uma 
medida mais útil do que quaisquer outras métricas de software, dentro da 
garantia da qualidade. E tal fato ocorre porque o usuário se preocupa com falhas 
e nunca com o número total de defeitos. Se observarmos, cada defeito em um 
 
13 
 
programa não representa a mesma taxa de falhas, além de como o número total 
de defeitos pode sinalizar indicação da confiabilidade de um sistema. Como 
medida para garantira a confiabilidade, temos a falha ao longo do tempo (FIT), 
que é uma medida estatística para estimar quantas falhas um componente 
poderá ter ao longo de um bilhão de horas de operação. (PRESSMAN, 2011). 
Além da confiabilidade, precisamos nos preocupar com a disponibilidade de 
software, ou seja, a probabilidade de que um programa esteja operando de 
acordo com os requisitos em um dado instante: 
Disponibilidade = (MTTF)/(MTTF+MTTR)*100% 
Para finalizarmos este assunto, vamos trabalhar o conceito de proteção 
de software. Esta atividade, também da garantia da qualidade, concentra-se na 
identificação e avaliação de potenciais problemas que podem afetar 
negativamente o software e provocar falha em todo o sistema. 
Estas são questões que também devem ser tratadas e consideradas em 
um bom planejamento de garantia de qualidade no processo de desenvolvimento 
de um software. 
 
Leitura obrigatória 
SOMMERVILLE, 2011 
CAMPOS, 2016 
 
TEMA 5: PADRÕES DE QUALIDADE 
Chegamos até aqui com muitas definições, conceitos e avaliando os 
detalhes importantes para garantirmos a qualidade do processo de 
desenvolvimento de software. Agora vamos conversar sobre padrões de 
software. Estes padrões desempenham um papel muito importante no 
gerenciamento da qualidade de software segundo (SOMMERVILLE, 2011). 
Precisamos escolher ferramentas e métodos para suportar o uso desses 
 
14 
 
padrões. Após esta escolha, definimos processos específicos para o 
monitoramento do uso dos padrões e verificação se os mesmos estão sendo 
seguidos. A figura 3 demonstra essa qualidade baseada em processos. 
 
Figura 3: Qualidade com base em processos 
 
 
 
 
 
 
 
 
 
 
 
 
 Fonte: Sommerville, 2011. 
 
 
Padrões são importantes por várias razões, entre elas, segundo 
Sommerville (2011): 
1. Capturar conhecimento da organização. 
2. Fornecer um framework para definição do significado de qualidade para a 
organização. 
3. Ajudar na continuidade dos trabalhos realizados por um profissional e 
continuado por outro. 
4. Padrões de produto aplicam-se a produto de software que está em 
desenvolvimento. (Documentação). 
5. Padrões de processo que os definem para serem seguidos durante todo 
o processo de desenvolvimento de software. É importante que 
encapsulem as boas práticas de desenvolvimento. 
Definir processo Desenvolver 
produto 
Melhorar 
processo 
Desenvolver 
produto 
Qualida
de ok? 
Padronizar 
processo 
 
15 
 
 
Os padrões entregam valor sob a forma de maior qualidade de produto. 
Organismos nacionais e internacionais apoiam a produção de padrões. Entre 
eles encontram-se: ANSI, BSI, OTAN e IEEE. Tais padrões estão em linguagens 
de programação como Java e C++, notações, gráficos, símbolos eprocedimentos para derivação e escrita de requisitos de software, procedimentos 
de garantia de qualidade e processos de verificação e validação de software. 
O framework de normas ISO 9001 aplica-se a organizações que projetam, 
desenvolvem e mantêm produtos, inclusive software. Este foi desenvolvido em 
1987, e sua mais nova revisão é de 2008. Este define princípios gerais da 
qualidade, descreve os processos gerais de qualidade e estabelece os padrões 
organizacionais e os procedimentos que devem ser definidos. Estes são 
documentados em um manual de qualidade da organização. Na Figura 4 
encontramos os processos essenciais da ISO 9001. 
 
Figura 4: Processos Essenciais da ISO 9001 
 
Fonte: Sommerville, 2011. 
 
16 
 
 
Além da ISO 9001, temos também a IEEE 829-2008, uma norma 
adequada aos padrões do PMI para gerência de projetos. Neste caso, 
consideramos a fase de testes como um projeto paralelo ao desenvolvimento de 
software, seguindo as abordagens desta norma. Ela trata exclusivamente de 
teste de software, suprindo uma carência dos padrões da PMI. Segundo esta 
norma, a atividade de teste de software deve fornecer informações objetivas 
sobre a qualidade do software que está em desenvolvimento. 
Sabemos que a certificação ISO 9001 não garante completamente que o 
desenvolvimento de software e o produto final de fato estejam de acordo com o 
que nossos usuários precisam e esperam, mas que todos os processos estão 
em conformidade com a norma. É claro que se a empresa é certificada, ela fará 
o possível para garantir tanto processos quanto software de acordo com o 
desejado pelos usuários finais. 
 
Leitura obrigatória 
SOMMERVILLE, 2011 
CAMPOS, 2016 
 
TROCANDO IDEIAS 
Refletir sobre a introdução da garantia de qualidade, por meio de metas, 
métricas, estatísticas e padrões em projetos de desenvolvimento de software. 
Quais seriam os custos para introduzirmos tantas avaliações, correções e 
padronizações? Precisaríamos de profissionais habilitados para tais tarefas, ou 
bastaria utilizarmos o próprio pessoal do desenvolvimento? 
 
SÍNTESE 
Estudamos até aqui sobre elementos importantes para garantia da 
qualidade. Tanto o gerenciamento quanto a garantia da qualidade querem 
 
17 
 
assegurar que o software tenha poucos defeitos e esteja em conformidade com 
padrões de manutebilidade, confiabilidade e portabilidade. Os padrões são muito 
importantes para a garantia de qualidade, pois por meio de suas melhores 
práticas oferecem uma base para construção de software de boa qualidade. 
O processo de documentação, que é um elemento bastante importante dentro 
da área de qualidade, pode ser baseado em um conjunto de procedimentos da 
garantia de qualidade sugeridas pela ISO 9001. Optar por revisões e inspeções 
garantirão melhoria no processo e no produto. As revisões dos entregáveis são 
técnicas usadas para avaliação da qualidade, enquanto que inspeção de 
programas ou revisão em pares buscam possíveis erros e omissões. Quando 
falamos em medição de software, usamos coleta de dados quantitativos capazes 
de subsidiarem métricas de software para garantir a qualidade tanto do produto 
quanto do processo. 
 
REFERÊNCIAS 
CAMPOS, F. M. Qualidade, qualidade de software e garantia da qualidade 
de software são as mesmas coisas?. Disponível em: 
http://www.linhadecodigo.com.br/artigo/1712/qualidade-qualidade-de-software-
e-garantia-da-qualidade-de-software-sao-as-mesmas-coisas.aspx em maio de 
2016. 
INMETRO. Fundamentos da Qualidade. Disponível em: 
<http://www.inmetro.gov.br/qualidade/iaac/pdf/fundamentos-qualidade.pdf>. 
Acesso em: maio de 2016. 
LÉLIS, E. C. Gestão da qualidade. São Paulo: Pearson Prentice Hall, 2012. 
PRESSMAN, R. S. Engenharia de software: uma abordagem profissional. 7. 
ed. Porto Alegre: AMGH, 2011. 
SOMMERVILLE, I. Engenharia de software. 9. ed. São Paulo: Pearson 
Prentice Hall, 2011. 
 
18 
 
SHIGUNOV NETO, A. Introdução à gestão da qualidade e produtividade: 
conceitos, história e ferramentas. Curitiba: InterSaberes, 2016. 
VENNERS, B. Design by contract: a conversation with Bertrand Meyer. Artima 
Developer, December 8, 2003. Disponível em: 
<www.artima.com/intv/contracts.html>. 
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. 
 
 
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 
classificadosem 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 organizada nã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 executadas entre 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 acordocom 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 quanto em 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