Qualidade e Testes de Software

Prévia do material em texto

Qualidade e 
testes de software
Sandro Lopes Bianchini
Qualidade e 
testes de software
Sandro Lopes Bianchini
Bianchini, Sandro Lopes
Qualidade e testes de software. Sorocaba/SP, 2020. 62 f. Ed. 1.
Validador: Iremar Nunes de Lima.
Instituto Cultural Newton Paiva Ferreira Ltda. | ED+ Content Hub, 2020.
Assuntos:
1. Computadores - Software;
2. Control de qualidade;
3. Engenharia de software.
Formato: digital.
Recurso: PDF e HTML.
Requisitos do sistema operacional:
• Windows 8.1 ou superior;
• Mac OSX 10.6 ou superior;
• Linux - ChromeOS.
Configurações técnicas:
• 2GB de memória RAM;
• 2.5GHz de processador;
• 10GB de espaço em disco.
Navegadores:
• Google Chrome – Versão mais atualizada;
• Mozilla Firefox – Versão mais atualizada.
Dispositivos móveis:
• iOS 10 ou superior;
• Android 5 ou superior.
Modo de acesso: área restrita - Ambiente Virtual de Aprendizagem.
Todos os direitos desta edição são reservados ao Centro Universitário Facens.
Rodovia Senador José Ermírio de Moraes, 1425, km 1,5 – Sorocaba/SP
CEP: 18.085-784 | tel.: 55 15 3238 1188
Nenhuma parte desta publicação poderá ser reproduzida por qualquer meio ou forma sem autorização.
A violação dos direitos autorais é crime estabelecido pela Lei n.º 9.610/98 e punido pelo artigo 184 do Código Penal.
Todas as imagens, vetores e ilustrações são creditados ao Shutterstock Inc., salvo quando indicada a referência.
Conteúdo
Unidade 1
Introdução à qualidade de software ................................................ 6
Unidade 2
Processos de garantia de qualidade de software ......................... 19
Unidade 3
CMMI .................................................................................................. 32
Unidade 4
Modelo MPS.br .................................................................................. 47
Unidade 5
Introdução à atividade de teste de software ................................ 61
Unidade 6
Fases ou níveis do teste de software ............................................. 77
Unidade 7
Técnicas de teste de software ......................................................... 88
Unidade 8
Outros aspectos do teste de software ......................................... 109
Qualidade e testes de software | Unidade 1 - Introdução à qualidade de software
5
PALAVRAS DO AUTOR
Ao iniciar a jornada por essa disciplina, gostaria que você refletisse sobre os produtos que você consome. 
Você já se irritou com um defeito em um carro? Em um aparelho tocador de vídeo ou música? Uma 
peça de roupa com costura frágil? Irritou-se por ter adquirido um produto sem qualidade? Além desses 
produtos citados, muito provavelmente você já deve ter utilizado um aplicativo em um smartphone ou 
computador que exibiu uma mensagem de erro sem motivo aparentemente (apesar de você ter usado 
conforme as instruções do fabricante) ou ainda sofreu com alguma lentidão utilizando esse software. Ou 
seja, qualidade é importante em tudo aquilo que utilizamos para o bem-estar e atividades do cotidiano, 
sejam elas de lazer ou profissionais. No caso do software que você utiliza, essa afirmação não é diferente.
Diante dessa realidade, você conhecerá, por meio da disciplina de Qualidade e teste de software, o 
significado do termo qualidade para o produto conhecido por software dentro do contexto da atividade 
de engenharia de software, bem como as motivações que levam à sua prática e técnicas, processos e 
conceitos utilizados para alcançar a qualidade de software. Entre esses itens, por exemplo, a atividade 
de teste de software é tida como essencial para alcançar esse objetivo.
Uma vez que você compreenda os conceitos apresentados, poderá aplicá-los para a construção de 
produtos de software (aplicativos, software comerciais, sistemas críticos, sistemas operacionais, entre 
outros) que satisfaçam as necessidades das pessoas e evitem exatamente algum tipo de aborrecimento 
ou irritação ao utilizar um produto sem qualidade.
Seja bem-vindo(a) ao mundo da engenharia de software, que você conhecerá nessa disciplina.
Bons estudos!
Qualidade e testes de software | Unidade 1 - Introdução à qualidade de software
6
Unidade 1 Introdução à qualidade de software
Objetivo da aprendizagem:
• Esclarecer o que é qualidade em software e seus fundamentos, conceitos, termos e histórico.
Tópicos de estudo:
• Introdução à engenharia de software.
• O que é qualidade de software?
• Aspectos de qualidade de software.
Iniciando os estudos:
Você já reparou que, provavelmente, o dispositivo que esteja utilizando para ler este livro possua capa-
cidade computacional provida por um conjunto de hardware e software? Além desse dispositivo, outros 
equipamentos de seu cotidiano também utilizam recursos de hardware e software, seja sua televisão, 
seu telefone e até seu relógio? E especificamente, em relação ao software que os acompanha, ele foi 
projetado, desenvolvido e testado sob um processo rigoroso para enfim ser disponibilizado de forma 
comercial? Em vista disso, nessa unidade você verá um histórico da engenharia de software e como é 
possível conceituar o termo qualidade para um software.
Qualidade e testes de software | Unidade 1 - Introdução à qualidade de software
7
1 INTRODUÇÃO À ENGENHARIA DE SOFTWARE
Considerando o mundo que nos cerca, você pode perceber a presença de sistemas computacionais 
controlados tanto por hardwares quanto por softwares capazes de executar diversas funções. Há 
sistemas que controlam uma planta fabril desde a entrada da matéria-prima ao produto final; há outros 
que controlam o próprio sistema financeiro. Você encontrará ainda exemplos na indústria de entreteni-
mento, seja no desenvolvimento de jogos de computador, cinema, televisão e música. Nesses sistemas 
o uso de software é intenso (SOMMERVILLE, 2011).
Dada a utilização de software nos mais variados nichos, pode-se dizer que o software possui um duplo 
papel: ele é um produto e ao mesmo tempo é o veículo para se distribuir um produto. Além disso, 
é possível também ressaltar que o software distribui o produto mais importante de nossos tempos: a 
informação. Ele transforma dados pessoais em informações úteis de modo que possam ser utilizadas em 
um determinado contexto; gerencia informações comerciais para aumentar competitividade; fornece 
um portal para redes mundiais de informação e ainda os meios para a obtenção dessas informações. 
Isso nos leva a procurar entender como o software é produzido. Desde o início do desenvolvimento de 
software, quando esses eram construídos por programadores solitários até os dias atuais onde tem-se 
equipes inteiras destinadas a esse fim, muitas questões acerca do desenvolvimento de software são as 
mesmas (PRESSMAN; MAXIM, 2016):
• Por que leva tanto tempo para concluir o desenvolvimento de software?
Figura 1 - O mundo está em constante contato com a presença 
de sistemas computacionais, controlados tanto por hardwares 
quanto por softwares capazes de executar diversas funções.
Qualidade e testes de software | Unidade 1 - Introdução à qualidade de software
8
• Por que os custos de desenvolvimento de um software são tão altos?
• Por que não conseguimos encontrar todos os erros antes de entregarmos o software 
aos clientes?
• Por que gastamos tanto tempo e esforço mantendo programas existentes?
• Por que se continua a ter dificuldade em medir o progresso tanto do desenvolvimento 
quanto a manutenção do software?
Essas e outras questões levam à prática da engenharia de software.
O termo engenharia de software foi proposto em 1969 em uma conferência da OTAN, justamente para 
a discussão de questões relacionadas ao desenvolvimento de software, como as citadas anteriormente, 
por exemplo (SOMMERVILLE, 2011). Procurando na literatura, você encontrará diversas definições para 
o termo engenharia de software. Uma delas é a da IEEE (1990): “(1) A aplicação de uma abordagem siste-
mática, disciplinada e quantificável no desenvolvimento, na operação e na manutenção de software. (2) 
O estudo de abordagenscomo definido em (1).”
Em linhas gerais, a engenharia de software tem por objetivo apoiar o desenvolvimento profissional 
de software. Ela inclui técnicas que apoiam a especificação, projeto e evolução de programas. É uma 
disciplina de engenharia cujo foco está em todos os aspectos da produção de software, desde os está-
gios iniciais da especificação do sistema até sua manutenção, quando o sistema já está em utilização.
A ciência da computação se preocupa com as teorias e métodos que sustentam 
sistemas computacionais e de software, ao passo que a engenharia de software 
se preocupa com os problemas práticos de produção de software. Algum 
conhecimento de ciência da computação é essencial para engenheiros de 
software, da mesma forma que algum conhecimento de física é essencial para 
engenheiros elétricos.
Reflita
Para compreender melhor a engenharia de software, Pressman e Maxim (2016, p. 39) a define como 
uma tecnologia em camadas, como você pode observar na figura 2.
Qualidade e testes de software | Unidade 1 - Introdução à qualidade de software
9
Como a pedra fundamental que sustenta a engenharia de software, tem-se o foco na qualidade, impres-
cindível em qualquer abordagem de engenharia inclusive. A próxima camada é o processo, que mantém 
as camadas de tecnologia coesas, possibilitando que o software seja produzido de forma racional e 
respeitando os prazos estabelecidos. O processo, em geral, deve definir uma metodologia para o uso 
efetivo da tecnologia de engenharia de software. Por meio do processo, encontram-se subsídios para 
o gerenciamento de projetos, que estabelecem um contexto no qual são utilizados métodos técnicos 
e artefatos são produzidos (documentação, diagramas, relatórios etc). Além disso, são estabelecidos 
marcos, que possibilitam a garantia da qualidade e ainda o controle sobre as mudanças que podem ser 
feitas durante o desenvolvimento do software.
Para saber mais sobre o conteúdo, você pode ver o vídeo abaixo.
Título: O que um engenheiro de software faz?
Acesso em: 08/10/2019.
Disponível em: https://www.youtube.com/watch?v=wdU9L3DqU2w
Aprofunde-se
Informações técnicas sobre como um software pode ser produzido são encontradas na camada método. 
Nessa camada, você encontrará tarefas que incluem comunicação, análise de requisitos, modelagem de 
projeto, codificação do programa, testes e suporte.
Figura 2 - Engenharia de software: uma tecnologia em camadas.
Fonte: adaptado de Pressman e Maxim (2016).
ED+ Content Hub © 2019
https://www.youtube.com/watch?v=wdU9L3DqU2w
Qualidade e testes de software | Unidade 1 - Introdução à qualidade de software
10
Por fim, na camada ferramentas, existem utilidades que fornecem suporte automatizado ou semiauto-
matizado para o processo e para os métodos. Uma vez integradas, de modo que informações geradas 
por uma ferramenta possam ser utilizadas em outra, tem-se um sistema para o suporte ao desenvol-
vimento de software, denominado engenharia de software com o auxílio do computador (do inglês 
Computer-Aided Software Engineering, comumente conhecido como ferramentas CASE) (IEEE,1990).
Considerando a camada de processo, segundo Sommerville (2011, p. 5), existem muitos processos de 
software diferentes, porém todos devem possuir quatro atividades fundamentais:
1. Especificação de software: a funcionalidade do software e as restrições ao seu funcio-
namento devem ser definidas.
2. Projeto e implementação de software: o software deve ser produzido para atender 
às especificações.
3. Validação de software: o software deve ser validado para garantir que atenda às 
demandas do cliente.
4. Evolução de software: o software deve evoluir para atender às necessidades de 
mudança dos clientes.
Acesse na plataforma o vídeo: Atividades fundamentais de 
processos de engenharia de software.
Assista
Portanto, ao aplicar qualquer processo da engenharia de software que implemente essas atividades, de 
alguma maneira você garantirá qualidade. No próximo tópico será discutido sobre qualidade de software.
Para saber mais sobre o conteúdo, você pode ler o livro abaixo.
Título do livro: Guide to the Software Engineering Body of Knowledge (SWEBOK(R)) 
Local: Los Alamitos, CA.
Editora: IEEE Computer Society Press.
Data da publicação: 17/01/2014.
Aprofunde-se
2 O QUE É QUALIDADE DE SOFTWARE?
Como você viu no tópico anterior, a pedra fundamental da tecnologia da engenharia de software é o foco 
na qualidade. Todavia, antes de continuar, pense em um produto qualquer e reflita: o que é qualidade 
para você? Acredito que a definição exata para essa questão não deva ter sido encontrada facilmente. 
Qualidade e testes de software | Unidade 1 - Introdução à qualidade de software
11
Se essa questão for lançada para um grupo de alunos, provavelmente haverá respostas baseadas nas 
percepções pessoais de cada um. Ao retornar para o contexto de software, encontrará possivelmente a 
mesma dificuldade.
O aumento do uso de software trouxe proble-
mas para seus desenvolvedores, como pressão 
por entregas, aumento dos custos, sistemas 
apresentando falhas e mal escritos.
Problemas
Aplicar princípios da engenharia clássica para 
o desenvolvimento de software, a fim de 
profissionalizar essa atividade, com foco na 
criação de um produto com qualidade.
Solução
Nos anos iniciais, software era desenvolvido 
por programadores solitários, focados apenas 
na codificação deles.
Início
Endereçar o desenvolvimento de software de modo que o produto atenda aos anseios dos usuá-
rios, tanto por meio de suas funcionalidades (um editor de texto deve permitir editar textos e 
salvá-los em disco) quanto por meio de outros atributos não funcionais (o software de navegação 
de um avião não pode travar, deve ser resiliente).
Qualidade
Com a adoção de computadores pessoais, 
software passou a ganhar importância para 
as pessoas e empresas.
Uso intenso
Software, como qualquer produto desenvolvido, requer qualidade para atingir os resultados esperados por 
seus usuários. Além de cumprir com as funcionalidades esperadas, precisa possuir características 
relacionadas a aspectos como segurança e proteção.
Infográfico 1 - A importância da qualidade no software.
ED
+ 
Co
nt
en
t H
ub
 ©
 2
01
9
Qualidade e testes de software | Unidade 1 - Introdução à qualidade de software
12
Para chegar em um conceito mais formal sobre o que é qualidade de software, deve-se antes construir 
o conceito de qualidade.
Segundo Garvin (1984, p. 25), citado por Pressman e Maxim (2016, p. 359), o conceito de qualidade é 
complexo e possui várias faces, podendo ser descrito por cinco pontos de vista diferentes. Esses pontos 
de vista são:
• Visão transcendental: a qualidade é algo que é reconhecido de imediato, porém não 
se consegue definir explicitamente.
• Visão do usuário: a qualidade é vista em termos de metas específicas de um usuário final.
• Visão do fabricante: a qualidade é definida em termos da especificação original do 
produto. Significa que se um produto atender às especificações, ele apresenta qualidade.
• Visão do produto: sugere que a qualidade pode estar ligada às características intrín-
secas do produto, como funções e recursos.
• Visão baseada em valor: a qualidade é medida tomando-se por base o quanto um 
cliente estaria disposto a pagar por um produto.
Esse artigo explora a qualidade, sob a ótica dos autores relacionados a um 
software, como seus usuários, desenvolvedores e patrocinadores de um 
software.
Título: Uma introdução à qualidade de software
Link: https://www.infoq.com/br/news/2012/05/An-Introduction-Software-Quality/
Aprofunde-se
Na indústria, a definição de qualidade seguiu, em linhas gerais, a visão do fabricante mencionada ante-
riormente. De acordo com Crosby (1979, apud SOMMERVILLE, 2011, p. 456), a qualidade é baseada na 
conformidade de um produto em relação a uma especificação detalhada e na noção de tolerân-
cias. A partir disso, obteve-se o entendimento que produtos poderiam ser especificados por completo e 
procedimentospoderiam ser criados para avaliar se um produto estivesse de acordo com suas especi-
ficações. Naturalmente, os produtos nem sempre cumprirão com todas as suas especificações, por isso 
admitiu-se tolerância. Se um produto estivesse ‘quase certo’, era considerado aceitável.
Entretanto, qualidade de software não pode ser comparada diretamente à qualidade na indústria. Tole-
rância é um conceito não aplicável aos sistemas digitais e, considerando as razões listadas abaixo, talvez 
seja impossível concluir objetivamente se um sistema de software atende ou não suas especificações 
(SOMMERVILLE, 2011). As razões são as seguintes:
1. Clientes e desenvolvedores de software podem interpretar os requisitos de modo 
diferente. Chegar a um acordo sobre se o software cumpre suas especificações ou não 
pode ser impossível.
https://www.infoq.com/br/news/2012/05/An-Introduction-Software-Quality/
Qualidade e testes de software | Unidade 1 - Introdução à qualidade de software
13
2. Em geral, as especificações integram requisitos de várias classes de stakeholders. 
Esses requisitos são um compromisso e podem não incluir os requisitos de todos os 
grupos de stakeholders. Os stakeholders excluídos podem perceber o sistema como um 
sistema de baixa qualidade, mesmo que esse implemente os requisitos acordados.
3. É impossível medir determinadas características de qualidade diretamente, por 
exemplo o quão facilitada é a manutenção de um software.
Acesse na plataforma o vídeo: Qualidade para softwares.
Assista
Tendo em vista essas razões, é possível considerar que a qualidade de software é um processo subjetivo, 
onde é necessário que uma equipe de gerenciamento de qualidade julgue se um software alcançou um 
nível aceitável de qualidade, considere se o software é adequado para sua finalidade ou não e também 
se responde às questões sobre características de um sistema, por exemplo:
• Durante o processo de desenvolvimento, os padrões de programação e documentação 
foram seguidos?
• O software foi devidamente testado?
• O software é suficientemente confiável para ser colocado em uso?
• O desempenho do software é aceitável para o uso normal?
• O software é útil?
• O software é bem estruturado e compreensível?
Esse artigo detalha o conceito de qualidade e sua evolução na história.
Título: Uma breve história da engenharia de qualidade
Link: https://www.dcce.ibilce.unesp.br/~adriana/ceq/Material%20
complementar/histquali.pdf
Aprofunde-se
Para cada uma das questões mencionadas, você encontrará aspectos que as permeiam. Esses aspectos 
serão discutidos no próximo tópico.
https://www.dcce.ibilce.unesp.br/~adriana/ceq/Material%20complementar/histquali.pdf
https://www.dcce.ibilce.unesp.br/~adriana/ceq/Material%20complementar/histquali.pdf
Qualidade e testes de software | Unidade 1 - Introdução à qualidade de software
14
3 ASPECTOS DA QUALIDADE DE SOFTWARE
Como você viu anteriormente, a qualidade de um sistema de software é subjetiva. Mais do que simples-
mente considerar sua funcionalidade, ou seja, avaliar se um software foi implementado corretamente, o 
entendimento sobre qualidade de software deve considerar atributos não funcionais, relacionados com 
a percepção do sistema por parte dos usuários. Na tabela 1 é possível ver 15 atributos sugeridos por 
Boehm et al. (1978, apud SOMMERVILLE, 2011, p. 457):
Segurança Compreensibilidade Portabilidade
Proteção Testabilidade Usabilidade
Confiabilidade Adaptabilidade Reusabilidade
Resiliência Modularidade Eficiência
Robustez Complexidade Capacidade de aprendizado
Outro aspecto vital na qualidade de software é a medição. Na engenharia de software, toda medição é 
nomeada com uma métrica. Uma métrica é uma medida, como custo ou tamanho, que pode ser aplicada 
ao software (BELL, 2005). A proposta do uso de métricas incluem os seguintes tópicos:
• Predizer atributos de qualidade para o software que será construído;
• Julgar a qualidade sobre o software ou uma porção dele que foi desenvolvida;
• Monitorar e melhorar o processo de desenvolvimento de software;
• Comparar e avaliar diferente abordagem de desenvolvimento.
Entre as métricas existentes é possível relacionar as métricas básicas. A medida mais simples que você 
encontrará para um software é seu tamanho. Geralmente é medido por linhas de código ou pontos por 
função. O tamanho em bytes afeta a memória principal e os requisitos de armazenamento, que por sua 
vez impactam no desempenho.
Para saber mais sobre o conteúdo, você pode ver o vídeo abaixo.
Título: O que é a análise de pontos de função?
Acesso em: 09/10/2019.
Disponível em: https://www.youtube.com/watch?v=9N1FMXrB9Kk
Aprofunde-se
Tabela 1 - Atributos não funcionais da qualidade de software.
Fonte: adaptado de Sommerville (2011).
https://www.youtube.com/watch?v=9N1FMXrB9Kk
Qualidade e testes de software | Unidade 1 - Introdução à qualidade de software
15
Outra métrica importante é a pessoas-mês, que pode ter um detalhamento maior, como pessoas-hora, 
uma medida do esforço de desenvolvimento. É uma métrica que impacta diretamente no custo do software. 
Essa informação pode ser utilizada por empresas para predizer o tempo de futuros desenvolvimentos.
A outra métrica básica é o número de bugs ou falhas. Essa métrica permitirá predizer quantos bugs 
podem permanecer ao final do desenvolvimento.
Esse artigo explora métricas para avaliação de qualidade.
Título: Métricas de Qualidade de Software
Link: https://www.tiespecialistas.com.br/metricas-de-qualidade-de-software/
Aprofunde-se
Existem também as métricas de complexidade, que se referem a quanto o código de um software é complexo. 
Uma métrica comumente utilizada nesse tipo é a análise de pontos por função. A ênfase aqui é que os 
programas sejam escritos de maneira clara e simples e, portanto, fáceis de checar, entender e modificar.
Acesse na plataforma o vídeo: Aspectos funcionais, não funcionais e 
estruturais: detalhando o conceito de qualidade de software.
Assista
https://www.tiespecialistas.com.br/metricas-de-qualidade-de-software/
Qualidade e testes de software | Unidade 1 - Introdução à qualidade de software
16
CONSIDERAÇÕES FINAIS
Nesta unidade você pôde conhecer melhor o que é a engenharia de software, seu histórico e seus obje-
tivos enquanto disciplina para profissionais da área de desenvolvimento de software. Como parte dos 
objetivos dessa disciplina, você também aprendeu que qualidade é um requisito essencial para a enge-
nharia de software. Por fim, também pôde entender que para se alcançar qualidade em um software, 
mais do que implementar suas funcionalidades propostas, é necessário considerar outros aspectos não 
funcionais, como confiabilidade e robustez.
Você seguirá seus estudos, aprofundando o conceito de qualidade, visando entender processos que 
possam garanti-la em um projeto de software.
Qualidade e testes de software | Unidade 1 - Introdução à qualidade de software
17
GLOSSÁRIO
IEEE: Institute of Electrical and Electronic Engineers.
Stakeholders: termo utilizado para designar todas as pessoas, em diferentes níveis, que estejam interes-
sadas em um projeto de software. Poderia ser traduzido como interessados.
Bug: defeito, falha ou erro no código de um programa que provoca seu funcionamento incorreto.
Qualidade e testes de software | Unidade 1 - Introdução à qualidade de software
18
REFERÊNCIAS
BELL, D. Software Engineering for Students. 4. ed. Addison-Wesley, 2005. 424 p. ISBN 9780321261274.
IEEE Std. 610.12. IEEE Standard Glossary of Software Engineering Terminology. The Institute of Elec-
trical and Electronics Engineers, New York, 1990.
PRESSMAN, Roger S; MAXIM, Bruce R. Engenharia de Software - Uma Abordagem Profissional. 8. ed. 
Porto Alegre: Amgh Editora, 2016. 968 p.
SOMMERVILLE, I. Engenharia de Software. Tradução Ivan Bosnic e Kalinga G. de O. Gonçalves. 9. ed. São 
Paulo: Pearson Prentice Hall, 2011. 529 p.
Qualidade e testes de software | Unidade 2 - Processos de garantia de qualidade de software
19
Unidade2 Processos de garantia de qualidade de software
Objetivo de aprendizagem:
• Apresentar ao aluno o processo que tem por objetivo controlar e garantir a qualidade dentro 
dos diversos processos de desenvolvimento de software.
Tópicos de estudo:
• Processos de garantia e de gestão da qualidade de software;
• Gestão da qualidade de produto;
• Gestão da qualidade de processo.
Iniciando os estudos:
Como você viu, a qualidade de software é um dos pilares da engenharia de software. A busca pela qualidade 
em um software representará a satisfação dos usuários por meio do fornecimento de um produto robusto, 
estável e que cumpre com a funcionalidade desejada desses usuários.
Para alcançar essa qualidade, no entanto, é necessário também que durante o processo de desenvolvimento 
haja algum elemento que determine e diga se a qualidade está em conformidade com aquilo que se espera. 
É necessário garantir que a qualidade no software esteja presente por meio de atividades que façam gestão e 
controle de todo o processo.
Nesta unidade, serão abordados processos de gestão e garantia da qualidade e você perceberá como eles 
apoiam o desenvolvimento de software.
Qualidade e testes de software | Unidade 2 - Processos de garantia de qualidade de software
20
1 PROCESSOS DE GARANTIA E DE 
GESTÃO DA QUALIDADE DE SOFTWARE
Se você pudesse observar o comportamento de muitos desenvolvedores de software espalhados nas 
muitas empresas que desenvolvem software, perceberia que ainda hoje eles acreditam que qualidade 
de software é algo que só deve ser considerado após a codificação do software em si. Porém, esse 
pensamento não poderia estar mais distante da verdade. A garantia da qualidade de software (SQA, do 
inglês Software Quality Assurance, muitas vezes ainda denominada gestão da qualidade) é um processo 
universal e deve ser aplicado em todo processo no qual se deseja obter qualidade (PRESSMAN; MAXIM, 
2016, p. 387).
Na indústria de software, SQA pode ter diferentes interpretações. Por vezes, apenas pode significar a 
definição de processos, procedimentos e padrões que têm por objetivo reforçar que a qualidade de 
software seja atingida. Em outras vezes, sua interpretação também inclui todo o gerenciamento de confi-
guração, atividades de verificação e validação aplicadas após o produto ter sido entregue. Pode-se consi-
derar que o SQA possui três principais preocupações em diferentes níveis (SOMMERVILLE, 2011, p. 454):
1. No nível organizacional, a gestão de qualidade está preocupada com o estabelecimento 
de um arcabouço de processos organizacionais e padrões que levem a softwares de 
alta qualidade. A consequência disso é que uma equipe de gestão de qualidade deve 
assumir a responsabilidade de definir os processos de desenvolvimento do software 
que serão usados e os padrões que devem ser usados nele, que incluem a documen-
tação relacionada, os requisitos de sistema, projeto e código.
• No nível de projeto, a gestão de qualidade envolve a aplicação de processos específicos 
de qualidade, que checam se os processos planejados foram seguidos e garantem que 
as saídas de projeto estejam em conformidade com os padrões aplicáveis ao projeto.
• No nível de projeto ainda, a gestão de qualidade também está preocupada com o esta-
belecimento de um plano de qualidade, em que devem ser definidas as metas de quali-
dade para o projeto e quais processos e padrões devem ser utilizados.
Para saber mais sobre o conteúdo, você pode ver o vídeo abaixo.
Título: Qual a diferença entre controle da qualidade e garantia da qualidade?
Acesso em: 20/10/2019.
Disponível em: https://www.youtube.com/watch?v=qNGgcVaHiSc
Aprofunde-se
https://www.youtube.com/watch?v=qNGgcVaHiSc
Qualidade e testes de software | Unidade 2 - Processos de garantia de qualidade de software
21
A gestão de qualidade fornece uma verificação diferente do processo de desenvolvimento de software. 
Cada entregável do processo de desenvolvimento é verificado para garantir que sejam consistentes 
com os objetivos organizacionais. Na figura abaixo, você pode observar que cada entregável (E1, E2, E3 
e assim por diante) do processo de desenvolvimento de software passa para o processo de gestão de 
qualidade, que segue seu próprio caminho.
Processo de
desenvolvimento
de software Entregável 1
Padrões e
procedimentos
Relatórios de
revisão de
qualidade
………Plano dequalidade
Entregável 2 Entregável 3 Entregável 4
Processo de
gestão de
qualidade
Ressalta-se que, além de seguir com um processo complementar ao desenvolvimento de software, 
a equipe que tem como função o SQA deve desempenhar o papel do cliente, funcionando como um 
serviço de defesa desse mesmo cliente, examinando o software sob sua ótica (PRESSMAN; MAXIM, 2016).
Acesse na plataforma o vídeo: A busca pela qualidade passa 
por processos de gestão e garantia.
Assista
1.1 ELEMENTOS DA GARANTIA DA QUALIDADE DE SOFTWARE
No SQA, engloba-se um amplo aspecto de preocupações e atividades que podem ser relacionadas da 
seguinte maneira (HORSH, 2003 apud PRESSMAN; MAXIM, 2016):
• Padrões: o IEEE, a ISO e outras organizações desenvolveram um conjunto de padrões 
para a engenharia de software e seus documentos relacionados. Os padrões podem 
ser adotados voluntariamente por uma organização de engenharia de software ou 
impostos pelo cliente ou demais interessados. A função do SQA aqui é garantir que 
os padrões, que por ventura tenham sido adotados, sejam seguidos e que todos os 
produtos resultantes estejam em conformidade com eles.
Figura 1 - Gestão de qualidade vs Processo 
de desenvolvimento de software. 
Fonte: adaptado de Sommerville (2011).
ED+ Content Hub © 2019
Qualidade e testes de software | Unidade 2 - Processos de garantia de qualidade de software
22
• Revisões e auditorias: as revisões técnicas são uma atividade de controle de quali-
dade realizada por engenheiros de software para engenheiros de software. Seu propó-
sito é o de revelar erros. Auditorias são um tipo de revisão efetuadas pela equipe de 
SQA com o intuito de assegurar que as diretrizes de qualidade estejam sendo seguidas 
no trabalho de engenharia de software. Por exemplo, uma auditoria de processo 
de revisão pode ser realizada para garantir que as revisões estejam sendo feitas de 
maneira que conduza a maior probabilidade possível de alcançar seu objetivo primário.
• Testes: os testes de software são uma função de controle de qualidade com um obje-
tivo principal: descobrir erros. Aqui, a função do SQA é garantir que os testes sejam 
planejados apropriadamente e conduzidos eficientemente de modo que se tenha a 
maior chance possível de alcançar seu objetivo primário.
• Coleta e análise de erros/defeitos: para melhorar, medir o próprio desempenho é 
essencial. O SQA reúne e analisa dados de erros e defeitos para melhor compreender 
como os erros são introduzidos e quais atividades de engenharia de software melhor 
se adaptam para sua eliminação.
• Gerenciamento de mudanças: as mudanças são um dos aspectos mais negativos em 
qualquer projeto de software. Se não forem administradas, podem gerar confusão, 
o que pode levar a uma qualidade aquém da desejada. O SQA garante que práticas 
adequadas de gerenciamento de mudanças tenham sido instituídas.
• Educação: um fator fundamental para se aprimorar as práticas de engenharia de 
software é a educação de engenheiros, gerentes e demais interessados. A organização 
de SQA assume a liderança nesse processo de aperfeiçoamento do software e é um 
proponente e patrocinador de programas educacionais.
• Gerência de fornecedores: pode-se encontrar três categorias de software oferecidas 
por fornecedores externos: pacotes prontos/comerciais (conhecidos como software de 
prateleira, como o Microsoft Office, oferecidos em caixas); software customizado (possui 
um esqueleto básico, como o oferecido em caixas, porém personalizado de acordo com 
as necessidades do comprador); e software sob encomenda (projetado e construído 
desde o início, a partir de especificações fornecidaspela empresa-cliente). Aqui, a função 
do SQA é garantir a qualidade do software por meio da sugestão de práticas de garantia 
de qualidade que o fornecedor, em linhas gerais, deve seguir e incorporar exigências de 
qualidade como parte de qualquer contrato com um fornecedor externo.
• Administração da segurança: com o aumento de crimes cibernéticos e novas regula-
mentações referentes à privacidade, toda organização de software deve instituir polí-
ticas que protejam os dados em todos os níveis, desde firewalls até checar modificações 
não autorizadas. O SQA garante o emprego de processos e tecnologias apropriadas 
voltadas para a segurança.
• Proteção: como o software é um componente fundamental de sistemas que envolvem 
vidas humanas, o impacto de defeitos escondidos pode ser trágico. O SQA pode ser 
Qualidade e testes de software | Unidade 2 - Processos de garantia de qualidade de software
23
responsável por avaliar o impacto de falhas de software e por iniciar as etapas necessá-
rias para a redução de riscos.
• Administração de riscos: embora a análise e redução de riscos seja uma preocupação 
de engenheiros de software, o grupo de SQA garante que as atividades da gestão de 
riscos sejam conduzidas corretamente e que planos de contingência relacionados a 
riscos tenham sido estabelecidos.
Além de analisar diferentes abordagens de processos utilizados para o SQA, esse artigo 
analisa também os custos decorrentes dos processos envolvidos sob a ótica financeira.
Título: The economics of sotfware quality assurance
Link: https://pdfs.semanticscholar.org/2d91/50f879c44bc9ac82e59dcb4b51c2e83e211f.pdf
Aprofunde-se
Somadas a essas atividades e preocupações, você poderá ver ainda o SQA envolvida na garantia de que 
atividades de suporte ao software, como manutenção, suporte online, documentação e manuais, sejam 
produzidas tendo como foco a qualidade.
2 GESTÃO DA QUALIDADE DE PRODUTO
Como você viu, uma das preocupações do SQA é o uso de padrões em seus processos de gestão. Um 
desses padrões são as normas ISO 9000. Essas normas podem ser aplicadas a uma variedade de orga-
nizações, desde a produção até a indústria de serviços. Por exemplo, a mais geral dessas normas, a 
ISO 9001, pode ser aplicada às organizações que projetam, desenvolvem e mantêm produtos, inclu-
sive softwares (SOMMERVILLE, 2011). Todavia, especificamente para o desenvolvimento de software, em 
1991, foi criada a ISO/IEC 9216. Foi traduzida para o Brasil em 1996, sob o nome NBR 13596. Posterior-
mente, essa norma brasileira foi substituída pela NBR ISO/IEC 9126-1.
A ISO/IEC 9126 é dividida em quatro partes (ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS, 2003):
• ISO/IEC 9126-1 - Modelo de Qualidade;
• ISO/IEC 9126-2 - Métricas Externas;
• ISO/IEC 9126-3 - Métricas Internas;
• ISO/IEC 9126-4 - Métricas de Qualidade em Uso.
A parte 1 apresenta um modelo de qualidade para o produto de software que será discutido adiante. As 
partes 2, 3 e 4 contemplam um conjunto de métricas para avaliação de atributos de qualidade interna 
(características dos produtos intermediários dos processos de desenvolvimento de software), qualidade 
externa (características do produto final de software gerado) e qualidade em uso (características do 
produto final, porém sob a perspectiva do usuário).
https://pdfs.semanticscholar.org/2d91/50f879c44bc9ac82e59dcb4b51c2e83e211f.pdf
Qualidade e testes de software | Unidade 2 - Processos de garantia de qualidade de software
24
O texto aborda o conceito de qualidade total do produto e seus determinantes, 
bem como as dimensões que compõem essa qualidade.
Título: Qualidade total do produto
Link: https://bit.ly/2Wpo1mW
Aprofunde-se
2.1 MODELO DE QUALIDADE
A parte 1 apresenta um conjunto de características para a definição de um modelo de qualidade, 
podendo ser aplicada a qualquer produto de software. Esse modelo, por sua vez, é composto de duas 
partes. Umas delas é o Modelo de Qualidade Interna e Externa (veja na figura abaixo).
Qualidade
interna e externa
• Funcionalidade
- Adequação
- Acurácia
- Interoperabilidade
- Segurança de acesso
- Conformidade
• Confiabilidade
- Maturidade
- Tolerância a falhas
- Recurerabilidade
- Conformidade
• Usabilidade
- Inteligibilidade
- Apreensibilidade
- Operacionalidade
- Atratividade
- Conformidade
• Eficiência
- Comportamento em
relação ao tempo
- Utilização de recursos
- Conformidade
• Manutenibilidade
- Analisabilidade
- Modificabilidade
- Estabilidade
- Testabilidade
- Conformidade
• Portabilidade
- Adaptabilidade
- Capacidade para
ser instalado
- Coexistência
- Capacidade para
substituir
- Conformidade
Nesse modelo, qualidade interna e externa são definidas por um conjunto de seis características básicas 
que um software deve possuir para ser considerado um produto de software de qualidade. Cada carac-
terística é dividida em um conjunto de subcaracterísticas. As características são:
• Funcionalidade: relacionada à finalidade do produto;
• Confiabilidade: diz respeito à frequência de falhas e recuperabilidade do software;
• Usabilidade: relacionada ao esforço para se utilizar/aprender o produto;
• Eficiência: refere-se ao desempenho do produto de software;
Figura 2 - Modelo de Qualidade Interna e Externa com suas 
características e subcaracterísticas.
Fonte: adaptado de Associação Brasileira de Normas Técnicas (2003).
ED+ Content Hub © 2019
https://bit.ly/2Wpo1mW
Qualidade e testes de software | Unidade 2 - Processos de garantia de qualidade de software
25
• Manutenibilidade: relacionada ao esforço para se modificar o software;
• Portabilidade: diz respeito à capacidade de transferir o produto para outros ambientes.
Acesse na plataforma o vídeo: A busca pela qualidade passa 
por processos de gestão e garantia.
Assista
Esse artigo possui um estudo de caso, onde a norma ISO/IEC 9126 é adaptada 
para sua aplicação em um domínio específico, no caso, aplicações B2B.
Lembrando que, ao acessar o link, você precisa realizar gratuitamente o login 
para baixar o conteúdo.
Título: Customizing ISO 9126 quality model for evaluation of B2B applications
Link: https://bit.ly/2BWONcU
Aprofunde-se
A segunda parte do modelo é formada pelo Modelo de Qualidade em Uso, dividida por quatro caracte-
rísticas de qualidade. Em linhas gerais, qualidade em uso é, para o usuário, o efeito combinado das seis 
características de qualidade do produto de software apresentadas anteriormente.
As características do Modelo de Qualidade em Uso são:
• Eficácia: é a capacidade do produto de software de permitir que usuários atinjam obje-
tivos especificados com acurácia e completitude em um contexto de uso especificado.
• Produtividade: é a capacidade do produto de software de permitir que seus usuá-
rios utilizem quantidade apropriada de recursos em relação à eficácia obtida em um 
contexto de uso especificado. Ressalta-se que recursos relevantes podem incluir tempo 
para término da tarefa, esforço do usuário, materiais ou custos financeiros.
• Segurança: é a capacidade do produto de software de apresentar níveis aceitáveis de 
riscos de danos a pessoas, negócios, software, propriedades ou ao ambiente em um 
contexto de uso especificado. De um modo geral, os riscos são decorrentes das defi-
ciências na funcionalidade (incluindo segurança de acesso), confiabilidade, usabilidade 
ou manutenibilidade.
• Satisfação: é a capacidade do produto de software de satisfazer usuários em um contexto 
de uso especificado. Em relação à satisfação, você deve considerar que é a resposta do 
usuário à interação com o produto e inclui atitudes relacionadas ao uso do produto.
https://bit.ly/2BWONcU
Qualidade e testes de software | Unidade 2 - Processos de garantia de qualidade de software
26
2.2 MÉTRICAS INTERNAS E EXTERNAS
Na parte 2 e 3 da ISO/IEC 9126 são apresentadas medições para a Qualidade Interna e a Externa. Quando 
os requisitos de qualidade do produto de software são definidos, as características de qualidade do 
produto que contribuem com os requisitos de qualidadesão listadas. Logo, as métricas externas compa-
tíveis com esses requisitos são especificadas para quantificar os critérios de qualidade que validam se o 
software atende às necessidades do usuário.
Os atributos de qualidade interna do software são definidos na sequência e especificados, com o obje-
tivo de atingir a qualidade externa e a qualidade em uso requeridas e considerá-las no produto durante 
seu desenvolvimento. Métricas internas compatíveis são especificadas para quantificar os atributos de 
qualidade interna, de modo que eles possam ser utilizados para verificar se os produtos intermediá-
rios resultantes do processo de desenvolvimento de software atendem às especificações de qualidade 
interna durante esse processo.
É importante levar em consideração que as métricas internas utilizadas tenham uma relação tão forte 
quanto possível com as métricas externas escolhidas, de modo que possam ser utilizadas para prever os 
valores de métricas externas. Entretanto, é difícil elaborar um modelo teórico rigoroso que estabeleça 
um relacionamento forte entre métricas internas e externas.
2.3 MÉTRICAS DA QUALIDADE EM USO
Na parte 4 da norma ISO/IEC 9126, estão reunidas métricas para avaliação das características de quali-
dade em uso do software.
Métricas de qualidade em uso medem o quanto um produto atende às necessidades de usuários para 
que atinjam objetivos especificados com eficácia, produtividade, segurança e satisfação em um contexto 
de uso especificado.
A avaliação de qualidade em uso valida a qualidade do produto de software em cenários de uso espe-
cífico. O relacionamento da qualidade em uso com as outras características de qualidade depende dos 
seguintes atores do processo de desenvolvimento de software:
• Do usuário final, para quem qualidade em uso é, principalmente, resultante de funcio-
nalidade, confiabilidade, usabilidade e eficiência;
• Da pessoa que mantém o software, para quem qualidade em uso é resultante de 
manutenibilidade;
• Da pessoa encarregada de portar o software, para quem qualidade em uso é resultante 
de portabilidade.
Qualidade e testes de software | Unidade 2 - Processos de garantia de qualidade de software
27
ED+ Content Hub © 2019
3 GESTÃO DA QUALIDADE DE PROCESSO
A qualidade de um produto de software também pode ser definida pela qualidade dos processos utili-
zados para o seu desenvolvimento. A qualidade do processo de software é esperada desde a coleta dos 
requisitos de usuário até a entrega do produto final, passando por um ciclo de vida que oferece uma 
análise crítica do contrato e estende-se à sua instalação e manutenção (LODI; CORDENONZI, 2002).
Pode-se encontrar uma relação direta entre qualidade do processo 
e a qualidade desejada para um produto. Com isso, uma vez 
melhorando o processo de construção, melhora-se o produto em 
si. Portanto, como melhorá-lo?
Facilidade de
compreensão: 
Todos os membros da equipe 
devem ser capazes de entender o 
processo no qual atuam;
Confiabilidade: 
Erros devem ser evitados ou 
ainda antecipados;
Facilidade
de adaptação: 
Mudanças devem ser 
facilmente implementadas;
Agilidade na
entrega do produto:
Há ganho de tempo na entrega 
de um produto de software 
com qualidade;
• Medir: procura melhorar as medidas de acordo 
com os objetivos da organização envolvida na 
melhoria de processos.
• Analisar: o processo atual é avaliado e os 
gargalos e pontos fracos são identificados.
• Mudar: mudanças são propostas para 
resolver pontos fracos identificados no processo. 
Ciclos de
avaliação contínua: 
Melhoria do processo 
de desenvolvimento de 
software
Infográfico 1 - Melhoria do processo 
de desenvolvimento de software.
Qualidade e testes de software | Unidade 2 - Processos de garantia de qualidade de software
28
Para tanto, encontram-se na literatura e na indústria modelos para definição, avaliação e melhoria de 
processos de software, entre eles:
• O CMM, também chamado de SW-CMM (Software CMM). Seu objetivo inicial foi estabelecer 
um padrão de qualidade para o software desenvolvido para as forças armadas americanas.
Esse artigo descreve os componentes do CMM e suas motivações.
Título: As características do CMM e o desenvolvimento de software com qualidade
Link: https://bit.ly/2WtSmk9
Aprofunde-se
• O SPICE, nome do projeto de elaboração da norma ISO/IEC 15504, que foi lançado 
em 1993, com o objetivo de gerar normas para a avaliação de processos, visando a 
melhoria contínua do processo e a determinação de sua capacitação.
• A ISO/IEC 12207, que foi aprovada em agosto de 1995 e estabelece os processos de 
atividades e tarefas a serem aplicados durante a aquisição, fornecimento, desenvolvi-
mento, operação e manutenção de software (ROCHA et al., 2001). Atualmente foi revi-
sada pela norma ISO/IEC/IEEE 12207:2017.
Acesse na plataforma o vídeo: Descrição da ISSO/IEC 12207.
Assista
https://bit.ly/2WtSmk9
Qualidade e testes de software | Unidade 2 - Processos de garantia de qualidade de software
29
CONSIDERAÇÕES FINAIS
Para que um produto atinja níveis aceitáveis de qualidade, você viu que diferentes aspectos e abor-
dagens devem ser considerados. A qualidade pode ser abordada analisando a qualidade do produto 
desenvolvido, considerando-se atributos como confiabilidade e usabilidade, por exemplo.
Outra abordagem vista é que a qualidade também deve ser atingida no que tange à qualidade dos 
processos envolvidos no próprio desenvolvimento de software.
Qualidade e testes de software | Unidade 2 - Processos de garantia de qualidade de software
30
GLOSSÁRIO
B2B: Business-to-Business.
CMM: Capability Maturity Model.
Entregável: (deliverables) são documentos, protótipos e também todos os demais itens intangíveis (tais 
como treinamento e homologação) que um processo produz e deve ser entregue quando for completado.
IEEE: em português, Instituto de Engenheiros Eletricistas e Eletrônicos.
ISO: International Organization for Standardization.
SPICE: Software Process Improvement and Capability Determination.
Qualidade e testes de software | Unidade 2 - Processos de garantia de qualidade de software
31
REFERÊNCIAS
ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR 9126-1: Engenharia de Software - Qualidade do 
Produto. Rio de Janeiro, 2003.
PRESSMAN, Roger S; MAXIM, Bruce R. Engenharia de Software - uma abordagem profissional. 8.ed. 
Porto Alegre: Amgh Editora, 2016.
LODI, Silvanna; CORDENONZI, Walkiria. Aplicação de produto do software utilizando a ISO/IEC 9126. 
Disciplinarum Scientia|Ciências Naturais e Tecnológicas, v. 3, n. 1, p. 11-27, 2016.
ROCHA, Ana Regina Cavalcanti da et al. Qualidade de Software: teoria e prática. São Paulo: Prenttice 
Hall, 2001.
SOMMERVILLE, I. Engenharia de Software. Tradução Ivan Bosnic e Kalinga G. de O. Gonçalves. 9. ed. São 
Paulo: Pearson Prentice Hall, 2011.
Qualidade e testes de software | Unidade 3 - CMMI
32
Unidade 3 CMMI
Objetivo da aprendizagem:
• Apresentar o modelo CMMI, sua descrição e como ele auxilia na melhoria de processos de 
desenvolvimento de software.
Tópicos de estudo:
• Sobre o CMMI;
• Representações do CMMI;
• Áreas de processo do CMMI;
• Obtendo a certificação.
Iniciando os estudos:
Na constante busca por qualidade no desenvolvimento de software, com a finalidade de entregar aos 
clientes e usuários um produto de qualidade, é necessário também direcionar esforços para a promoção 
dos processos envolvidos.
Nesse sentido, você conhecerá em detalhes o modelo CMMI, ferramenta criada para auxiliar organizações 
desenvolvedoras de software na implementação da qualidade de processo até a qualidade do produto.
Qualidade e testes de software | Unidade 3 - CMMI
33
1 SOBRE O CMMI
O CMMI é um modelo de maturidade criado com o objetivo de proporcionar condições para a evolução 
das boas práticas de engenharia de software. Foi desenvolvido pelo Instituto de Engenharia de Software 
da Universidade de Carnegie Mellon (SEI/CMU), localizado em Pittsburg, nos Estados Unidos. O resul-
tado de uma série de estudosiniciais culminou na criação do CMM (Capability Maturity Model), Modelo 
de Capacidade e Maturidade (MACHADO, 2016).
No CMM, dependendo da área de aplicação, diferentes modelos foram criados, como o SW-CMM (CMM 
para Software) e SA-CMM (CMM para aquisição de Software). Procurando então evoluir e integrar esses 
modelos em um volume único, substituindo-os, o SEI criou o CMMI (Capability Maturity Model Integra-
tion) ou Integração de Modelos de Capacidade e Maturidade.
O objetivo do CMMI, em linhas gerais, é melhorar os processos de uma organização ao adotá-lo. 
Como um modelo de referência, serve como uma estruturação de práticas e abordagens de sucesso 
comprovado. Essas práticas procuram contribuir com a organização através da disponibilização de 
orientações sobre:
• Como avaliar a maturidade da organização e sua capacidade por área de processos;
• Como estabelecer atividades prioritárias para as melhores propostas;
• Como implementar as melhorias propostas.
O modelo de referência é composto por múltiplos modelos de processo em conjunto a seus manuais e 
material de treinamento e de avaliação. Esses modelos integram o gerenciamento de qualidade, utilizando 
as melhores práticas aplicadas a determinados domínios sobre as práticas de mudança da organização. 
Além disso, o CMMI fornece um mecanismo de avaliação bem estabelecido de maturidade de processo.
Acesse na plataforma o vídeo: Componentes do CMMI.
Assista
No CMMI você encontrará duas representações, por estágios e contínua. Nessas representações, encon-
tram-se os seguintes componentes (SOMMERVILLE, 2011):
1. Um conjunto de áreas de processo relacionadas às atividades de processos de software. 
O CMMI identifica áreas de processo relevantes para a melhoria e a capacidade de 
processo de software. Essas são organizadas em quatro grupos no modelo CMMI. Na 
representação contínua e na representação por estágios, aparecem em cada um deles.
2. Um número de metas, que são descrições abstratas de um estado desejável a ser atin-
gido por uma organização. O CMMI tem metas específicas, associadas a cada área de 
processo, e define o estado desejável para cada área. Ele também define metas gené-
ricas associadas com a institucionalização das boas práticas.
Qualidade e testes de software | Unidade 3 - CMMI
34
3. Um conjunto de boas práticas, que são as descrições das formas de como alcançar 
uma meta. Várias práticas específicas e genéricas podem ser associadas com cada 
meta dentro de uma área de processo. No entanto, o CMMI reconhece que o mais 
importante é a meta e não a maneira como ela é alcançada. As organizações podem 
usar quaisquer práticas adequadas para atingir qualquer uma das metas do CMMI, pois 
não precisam de fato adotar as práticas recomendadas no próprio CMMI.
Breve introdução ao CMMI, contendo conceitos, definições e motivações.
Título: CMMI: uma visão geral
Link: https://www.devmedia.com.br/cmmi-uma-visao-geral/25425
Aprofunde-se
Por fim, segundo Smith (apud MACHADO, 2016), o CMMI se tornou um veículo popular para a determina-
ção de maturidade de processo de desenvolvimento de software de organizações em diversos domínios.
Esse artigo foca nas razões por trás da adoção do CMMI e inclusive traz 
motivações existentes para o mercado brasileiro de software.
Título: Desmistificando o CMMI
Link: http://asrconsultoria.com.br/index.php/2016/06/22/desmistificando-o-cmmi/
Aprofunde-se
2 REPRESENTAÇÕES DO CMMI
Como você viu, o modelo CMMI possui duas representações: a representação por estágios e a repre-
sentação contínua. Na representação por estágios, o modelo é utilizado para avaliar a capacidade da 
organização como um todo. Na representação contínua, a medição é feita sobre a maturidade das áreas 
de processo específicas dentro da organização.
2.1 REPRESENTAÇÃO POR ESTÁGIOS
A representação por estágios se concentra nas melhores práticas que uma organização pode utilizar 
para melhorar processos das áreas do nível que se deseja atingir. Antes de iniciar a utilização do modelo 
CMMI, os processos da organização devem ser mapeados em relação aos processos e áreas de processo 
do CMMI. Esse mapeamento permitirá controlar a melhoria do processo da organização por meio da 
possibilidade de analisar o nível de conformidade da organização em relação ao modelo. Ressalta-se 
https://www.devmedia.com.br/cmmi-uma-visao-geral/25425
http://asrconsultoria.com.br/index.php/2016/06/22/desmistificando-o-cmmi/
Qualidade e testes de software | Unidade 3 - CMMI
35
que não é necessário que todas as áreas de processo do CMMI mapeiem exatamente um por um 
os processos de uma organização.
Na representação por estágios, há uma sequência de atividades e práticas que deve ser respeitada em 
cada estágio, uma vez que servem de base para se alcançar o estágio seguinte. Cada um dos estágios é 
conhecido por níveis de maturidade (Maturity Levels). Na figura abaixo, você encontrará os cinco níveis 
de maturidade propostos na representação por estágios do CMMI:
Você pode compreender os níveis da representação por estágios da seguinte maneira:
• Nível 1 – Inicial: os processos de uma organização são imprevisíveis, pouco contro-
lados e caóticos.
• Nível 2 – Gerenciado: os processos de uma organização são caracterizados por 
projeto e geralmente as ações são frequentemente reativas.
• Nível 3 – Definido: os processos de uma organização são bem caracterizados e 
compreendidos pela organização (envolvem toda a organização) e são proativos.
• Nível 4 – Gerenciado quantitativamente: aqui os processos de uma organização são 
medidos e controlados.
• Nível 5 – Otimizado: nesse nível, os processos de uma organização estão sob cons-
tante melhoria.
Figura 1 - Níveis de maturidade da 
representação por estágios do CMMI.
Fonte: adaptado de Sommerville (2011).
ED
+ 
Co
nt
en
t H
ub
 ©
 2
01
9
Qualidade e testes de software | Unidade 3 - CMMI
36
Acesse na plataforma o vídeo: A representação por estágios do CMMI.
Assista
Título: 1 - ISD BRASIL - o que é o nível 1 de maturidade do CMMI
Acesso em: 28/10/2019.
Disponível em: https://youtu.be/kF8sxDDoRns
Aprofunde-se
Comumente, você encontrará organizações avaliadas nos níveis de maturidade do CMMI, sendo referen-
ciadas, por exemplo, como: “a organização X está no nível 3 do CMMI”.
Título: 2 - ISD BRASIL - implementando o CMMI nível 3 de maturidade
Acesso em: 28/10/2019.
Disponível em: https://youtu.be/PiQh_bzoJoc
Aprofunde-se
2.2 REPRESENTAÇÃO CONTÍNUA
Na representação contínua do CMMI, ou CMMI Contínuo, diferentemente da representação por estágios, 
não se tem a maturidade de uma organização medida por níveis preestabelecidos. Nessa representação, 
a maturidade é medida em cada processo individualmente. Para avaliação dos processos, são utilizados 
níveis de capacidade (Capability Levels) (MACHADO, 2016):
• Nível 0 - Incompleto (Ad hoc).
• Nível 1 - Executado (definido): o processo é executado de modo a completar somente 
o trabalho necessário demandado.
• Nível 2 - Gerenciado: é sobre planejar a execução e confrontar o executado contra o 
que foi planejado.
• Nível 3 - Definido: o processo é construído sobre as diretrizes do processo existente e 
é mantida uma descrição do processo.
• Nível 4 - Quantitativamente gerenciado/ Gerido quantitativamente: é quando o 
processo é gerenciado quantitativamente através de estatísticas e outras técnicas.
• Nível 5 - Em otimização (ou otimizado): o processo gerido quantitativamente é alte-
rado e adaptado para atender às necessidades negociais/estratégicas da empresa.
https://youtu.be/PiQh_bzoJoc
Qualidade e testes de software | Unidade 3 - CMMI
37
Acesse na plataforma o vídeo: A representação contínua do CMMI
Assista
Esse artigo se concentra especificamente na representação contínua 
e seus níveis de capacidade de maneira simplificada.
Título: CMMI - Representação Contínua - Níveis de Capacidade
Link: https://bit.ly/375B0z0
Aprofunde-se
Quando uma organização busca apenas melhorar processos específicos, a representaçãocontínua é 
indicada. Por exemplo, em uma organização você poderá encontrar processos tanto no nível de capaci-
dade 1 quanto no nível 4. Talvez por uma decisão interna ou qualquer outro fator, a organização queira 
melhorar apenas o processo que se encontra no nível 1. Na figura abaixo, há um possível perfil de 
avaliação de processo nos diferentes níveis de capacidade da representação contínua. Nessa figura, você 
pode observar que diferentes processos possuem diferentes níveis de capacidade atribuídos.
Figura 2 - Exemplo de um perfil de avaliação de 
processos em níveis de capacidade.
Fonte: adaptado de Sommerville (2011).
https://bit.ly/375B0z0
Qualidade e testes de software | Unidade 3 - CMMI
38
Esse artigo apresenta uma comparação entre as representações do CMMI 
em inglês.
Título: SEI CMMI Representations
Link: https://www.tutorialspoint.com/cmmi/cmmi-representations.htm
Aprofunde-se
3 ÁREAS DE PROCESSO DO CMMI
Acesse na plataforma o vídeo: Áreas de processo.
Assista
Em cada uma das representações do CMMI, existem áreas de processo distribuídas tanto nos níveis de 
maturidade (representação por estágios) quanto nos níveis de capacidade (representação contínua). Uma 
área de processo é o agrupamento de práticas relacionadas a determinado contexto que, quando execu-
tadas de forma coletiva, satisfazem uma série de metas consideradas importantes para alcançar uma 
melhora significativa naquele contexto (ou seja, atingir um certo nível de maturidade) (MACHADO, 2016).
Na tabela abaixo, você poderá visualizar as áreas de processo existentes na representação por estágios. 
Cada nível é composto por uma coleção de áreas de processo.
Nível de maturidade Áreas de processo
Nível 2 - Gerenciado
Gestão de requisitos; 
Planejamento de projeto; 
Monitorização e controle de projeto; 
Gestão do acordo com o fornecedor;
Medição e análise; 
Garantia da qualidade do processo e do produto; 
Gestão de configurações.
Nível 3 - Definido
Desenvolvimento de requisitos; 
Solução técnica; 
Integração do produto; 
Verificação; 
Validação; 
Enfoque no processo organizacional; 
Definição do processo organizacional;
Formação organizacional; 
Gestão integrada do projeto; 
Gestão de risco; 
Integração de equipes; 
Gestão integrada de fornecedores; 
Ambiente organizacional para integração; 
Análise das decisões e resolução.
Nível 4 - Gerenciado quantitativamente
Performance do processo; 
Organizacional;
Gestão quantitativa do projeto.
Nível 5 - Otimizado Inovação e desenvolvimento organizacional; Análise e resolução de causa.
Tabela 1 - Níveis de maturidade da representação por 
estágios do CMMI e suas respectivas áreas de processo.
Fonte: adaptado de Machado (2016).
https://www.tutorialspoint.com/cmmi/cmmi-representations.htm
Qualidade e testes de software | Unidade 3 - CMMI
39
Já em relação à representação contínua, as áreas de processo são divididas por categoria, como pode 
ser visto na tabela a seguir:
Categoria Áreas de processo
Gestão de processos
Enfoque no processo organizacional; 
Definição do processo organizacional; 
Formação organizacional;
Desempenho de processo organizacional; 
Inovação e implementação organizacional.
Gestão de projeto
Planejamento de projeto; 
Monitorização e controle de projeto; 
Gestão do acordo com o fornecedor; 
Gestão integrada do projeto;
Gestão de risco de integração de equipes; 
Gestão integrada de fornecedores; 
Gestão quantitativa do projeto.
Engenharia
Gestão de requisitos; 
Desenvolvimento de requisitos; 
Solução técnica;
Integração do produto; 
Verificação; 
Validação.
Suporte
Gestão de configurações; 
Garantia da qualidade do processo e do produto; 
Medição e análise;
Análise das decisões e resolução; 
Ambiente organizacional para integração; 
Análise e resolução causal.
Esse artigo apresenta uma descrição detalhada de práticas genéricas e 
específicas de cada área de processo do CMMI em inglês.
Título: CMMI - Key Process Areas
Link: https://www.tutorialspoint.com/cmmi/cmmi_process_areas.htm
Aprofunde-se
Por fim, para cada área de processo, como já mencionado, existem metas genéricas e específicas. Na 
tabela abaixo, você pode ver alguns exemplos de metas associadas às áreas de processo:
Meta Área de processo
Ações corretivas são gerenciadas até a conclusão, quando 
o desempenho ou os resultados do projeto se desviam 
significativamente do plano.
Monitoração e controle de projeto (meta específica).
O desempenho atual e o progresso do projeto são monitorados 
frente ao planejamento do próprio projeto.
Monitoração e controle de projeto (meta específica).
Os requisitos são analisados e validados e uma definição da 
funcionalidade requerida é desenvolvida.
Desenvolvimento de requisitos (meta específica).
Causas raiz de defeitos e outros problemas são sistematicamente 
determinados.
Análise causal e resolução (meta específica).
O processo é institucionalizado como um processo definido. Meta genérica.
Tabela 2 - Categorias da representação contínua do 
CMMI e suas áreas de processo associadas.
Fonte: adaptado de Machado (2016).
Tabela 3 - Exemplos de metas para algumas áreas de processo do CMMI.
Fonte: adaptado de Sommerville (2011).
https://www.tutorialspoint.com/cmmi/cmmi_process_areas.htm
Qualidade e testes de software | Unidade 3 - CMMI
40
Essa dissertação de mestrado apresenta um trabalho relevante ao 
mapear as áreas de processo do CMMI em relação a métodos ágeis de 
desenvolvimento em inglês.
Título: Mapping CMMI process areas to agile best practices
Link: https://run.unl.pt/bitstream/10362/60403/1/TGI0186_final.pdf
Aprofunde-se
4 OBTENDO A CERTIFICAÇÃO
A obtenção da certificação CMMI traz consigo uma série de benefícios para a organização que pretende 
adotá-la (PROMOVE, 2018):
• Maior controle produtivo: o objetivo principal da implantação desse modelo é a 
capacidade de monitorar e controlar os processos de desenvolvimento e entrega de 
softwares e serviços. Com isso, a organização que o obtiver terá uma visão geral do 
fluxo produtivo, desde seu planejamento até a execução. Com indicadores compara-
tivos relevantes, facilita o processo de compreensão de onde estão os pontos fortes 
e fracos da sua equipe e de seus projetos, adaptando o desenvolvimento às necessi-
dades encontradas.
• Mais produtividade: processos otimizados e um fluxo simplificado de trabalho vão se 
traduzir em aumento de produtividade no mundo corporativo. Somado a isso, a certifi-
cação CMMI permite a inclusão de uma estrutura inteligente de comunicação interna. 
A empresa tem mais ferramentas para produzir e mais integração para colaborar.
• Iteração constante: nos níveis mais altos do CMMI, o controle da produção é inte-
grado ao trabalho do gestor, facilitando seu trabalho em buscar constantemente a 
melhora de processos e o aumento da produtividade citada anteriormente. Além disso, 
ao mesmo tempo em que se busca otimizar o trabalho de uma equipe, essa mesma 
equipe possui as ferramentas necessárias para otimizar um código, refinar um produto 
ou aprimorar a entrega de um serviço. Por isso a iteração constante é uma vantagem 
competitiva importante para quem trabalha com produtos de softwares.
Em 2007, a empresa Ci&T, especializada em desenvolvimento e outsourcing de 
aplicações, obteve o nível CMMI 5. Para tanto, foi necessário o investimento do 
montante de aproximadamente US$1 milhão. Esse investimento foi necessário 
para um treinamento de quatro anos, com preparação e adequação de processos.
Fonte: https://www.baguete.com.br/noticias/software/13/04/2007/cit-investe-us-1-milhao-na-
conquista-do-cmmi5
Reflita
https://run.unl.pt/bitstream/10362/60403/1/TGI0186_final.pdf
https://www.baguete.com.br/noticias/software/13/04/2007/cit-investe-us-1-milhao-na-conquista-do-cmmi5
https://www.baguete.com.br/noticias/software/13/04/2007/cit-investe-us-1-milhao-na-conquista-do-cmmi5
Qualidade e testes de software | Unidade 3 - CMMI
41
• Agilidade para atender demandas: as demandas de clientes acompanham a velo-
cidadecom que a tecnologia avança. Portanto, as organizações que obtêm sucesso 
nesse mercado são aquelas que identificam e alcançam nichos antes de concorrentes, 
consolidando-se como uma referência entre aquela clientela. Para conseguir atingir 
esse ponto de agressividade, qualquer negócio precisa de uma TI organizada e pronta 
para responder a uma demanda o mais rápido possível. Nesse sentido, a certificação 
CMMI garante que você tenha a inteligência e a otimização de processos necessárias 
para conseguir esse feito.
• Menos riscos no planejamento: se há controle na capacidade produtiva de uma 
organização, os riscos no planejamento são menores. É possível mapear demandas e 
sugerir processos que atinjam seus objetivos gastando-se menos e com qualidade na 
entrega. Previsibilidade é uma das palavras-chave para organizações que buscam a 
certificação em CMMI.
• Maior satisfação do cliente: processos definidos e monitorados, agilidade na resposta 
às demandas e, principalmente, qualidade na entrega ao cliente são as características 
que levam sua organização a satisfazer sua clientela com sucesso. Em um mercado 
acirrado e volátil, essa satisfação significa entregar um produto ou serviço de qualidade 
com preço acessível e que supere expectativas. No caso das concorrências públicas, 
trata-se de uma forma de se destacar como uma solução prática, confiável e segura.
Acesse na plataforma o vídeo: Razões para a certificação.
Assista
Qualidade e testes de software | Unidade 3 - CMMI
42
Aspectos para obtenção
da certificação CMMI 
Há diversos aspectos que devem ser contemplados para a obtenção da certificação CMMI. Tais 
aspectos vão de encontro a um processo rigoroso de avaliação. 
O planejamento da avaliação 
dura em média 3 meses.
A condução da avaliação 
dura de 6 a 8 dias.
Resultado da avaliação: 
ocorre imediatamente após a 
condução da avaliação.
A avaliação tem duração de 3 
anos. Após esse período, é 
necessário realizar uma nova 
avaliação.
Deve ser definido por quem 
deseja obter a certificação de 
qual será o escopo organizacional.
Avaliação
• Coletar dados para entender os 
processos implementados;
• Determinar nível de aderência de um 
processo em relação aos componentes 
do CMMI;
• Determinar grau de satisfação das 
metas investigadas;
• Identificar pontos fortes e fracos do 
processo;
• Atribuir classificação.
1
A avaliação deve ser conduzida 
por um profissional capacitado 
chamado “lead appraiser”. 
2
34
5
6 7
ED
+ 
Co
nt
en
t H
ub
 ©
 2
01
9
Infográfico 1 - Aspectos para obtenção da certificação CMMI.
Qualidade e testes de software | Unidade 3 - CMMI
43
Esse artigo apresenta o método SCAMPI em detalhes, método utilizado em 
avaliações do SEI para organizações que almejam a certificação CMMI.
Título: Standard CMMI® Appraisal Method for Process Improvement 
(SCAMPI) Version 1.3b
Link: https://cmmiinstitute.com/resources/standard-cmmi-appraisal-method-
process-improvement-scampi-version-13b-method-definition
Aprofunde-se
Em 2017, a DB1 Global Software, multinacional de tecnologia sediada em Maringá 
(PR), renovou a certificação CMMI Nível 3, emitida pelo CMMI Institute, que 
atesta aderência ao padrão internacional de qualidade de software. A primeira 
certificação foi concedida à DB1 em 2013 e, desde então, vem credenciando a 
empresa ao crescimento nos negócios e à participação em licitações oficiais.
Fonte: https://bit.ly/2q4l53B
Reflita
https://cmmiinstitute.com/resources/standard-cmmi-appraisal-method-process-improvement-scampi-version-13b-method-definition
https://cmmiinstitute.com/resources/standard-cmmi-appraisal-method-process-improvement-scampi-version-13b-method-definition
https://bit.ly/2q4l53B
Qualidade e testes de software | Unidade 3 - CMMI
44
CONSIDERAÇÕES FINAIS
Nesta unidade, você pôde conhecer o modelo CMMI, muito utilizado em organizações de desenvolvi-
mento de software, no intuito de melhorarem seus processos.
Uma vez melhorados seus processos, por consequência a organização ganha reconhecimento no 
mercado, facilitando a captação de novos clientes e solidifica sua marca.
Qualidade e testes de software | Unidade 3 - CMMI
45
GLOSSÁRIO
SEI/CMU: Software Engineering Institute/Carnegie Mellon University.
Qualidade e testes de software | Unidade 3 - CMMI
46
REFERÊNCIAS
MACHADO, Felipe Nery Rodrigues. Análise e Gestão de Requisitos de Software - Onde nascem os 
sistemas. 3. ed. São Paulo: Érica, 2015.
PROMOVE. Certificação CMMI: conheça os benefícios alcançados por empresas brasileiras, 2018. 
Disponível em: https://www.promovesolucoes.com/certificacao-cmmi-conheca-os-beneficios-alcancados-por-
-empresas-brasileiras/. Acesso em: 31 nov. 2019.
SOMMERVILLE, I. Engenharia de Software. Tradução Ivan Bosnic e Kalinga G. de O. Gonçalves. 9. ed. São 
Paulo: Pearson Prentice Hall, 2011.
https://www.promovesolucoes.com/certificacao-cmmi-conheca-os-beneficios-alcancados-por-empresas-bras
https://www.promovesolucoes.com/certificacao-cmmi-conheca-os-beneficios-alcancados-por-empresas-bras
Qualidade e testes de software | Unidade 4 - Modelo MPS.br
47
Unidade 4 Modelo MPS.br
Objetivo da aprendizagem:
• Apresentar o modelo MPS.br.
Tópicos de estudo:
• O que é o MPS.br;
• Componentes do MPS.br;
• Comparação entre modelos.
Iniciando os estudos:
Seguindo seu estudo no mundo da engenharia de software, com foco na qualidade, você já percebeu que 
a qualidade de um produto de software só pode ser alcançada por meio do aperfeiçoamento e melhoria 
dos seus próprios processos de desenvolvimento.
Para atingir esse objetivo, você pode contar com frameworks, normas e modelos, que fornecem suges-
tões das melhores práticas para a melhoria de processos. Um desses modelos, focando o mercado 
nacional, é o MPS.br.
Nesta unidade, você conhecerá então o modelo MPS.br, seu histórico, motivações e sua estrutura.
Qualidade e testes de software | Unidade 4 - Modelo MPS.br
48
1 O QUE É O MPS.BR
Como você já viu, um dos pilares da engenharia de software é a busca por qualidade. Por meio da 
melhoria dos processos de desenvolvimento, objetiva-se a construção de produtos de qualidade. 
No Brasil, desde 1993, com o Programa Brasileiro de Qualidade e Produtividade de Software (PBQP 
Software), o País tem investido na melhoria de qualidade de software. Porém, a partir de um estudo do 
MIT (Massachusetts Institute of Technology) foi constatado que empresas nacionais que seguiram com 
iniciativas para melhoria de processos de desenvolvimento de software, utilizaram a certificação ISO 
9000, ao invés de outros modelos específicos para software (WEBER, 2006).
De acordo com dados do Ministério da Ciência e Tecnologia, em 2003, 214 empresas que desenvolviam 
software no Brasil tinham certificação ISO 9000 e outras 30 empresas possuíam certificações CMM do 
SEI/CMU. Dessas últimas, a maioria era subsidiária de multinacionais. Em relação às suas certificações, 
24 empresas possuíam certificação nível 2, cinco no nível 3, uma no nível 4 e nenhuma no nível 5 até 
então (WEBER, 2005).
Para facilitar o uso de um modelo específico para software, a Associação para Promoção da Excelência 
do Software Brasileiro, Softex, propôs o projeto MPS.br – Melhoria de Processo de Software Brasileiro. 
O programa iniciou-se em 2003, sob coordenação da Softex, contando com a participação de universi-
dades, indústrias e do governo brasileiro. O principal objetivo do MPS.br é desenvolver e semear um 
modelo de melhoria de processos visando estabelecer um caminho economicamente viável para que 
organizações, incluindo as pequenas e médias empresas (PMEs), alcancem benefícios da melhoria de 
processos e da utilização de boas práticas da engenharia de software em um intervalo de tempo acei-
tável (KALINOWSKI et al., 2011).
Figura 1 - Em 2003, 214 empresas que desenvolviam 
software no Brasil tinham certificação ISO 9000.
Qualidade e testes de software | Unidade 4 - Modelo MPS.br
49
Assim como outros modelos de referência, o MPS.br possui uma página 
web ondeexibe as atuais empresas que possuem níveis de maturidade 
atestados pelo modelo. Essas empresas e seus níveis podem ser vistas no 
endereço https://softex.br/mpsbr/avaliacoes/
Aprofunde-se
O programa tem duas metas a serem alcançadas a médio e longo prazo, a meta técnica e a meta de negó-
cios (SOFTEX, 2016). A meta técnica visa o aprimoramento do programa em si e é composta pelos itens:
A. Guias de modelos de maturidade do MPS;
B. Formação de Instituições Implementadoras (II), credenciadas para prestar serviço de 
consultoria dos modelos do MPS, sendo eles o modelo de referência para software 
(MR-MPS-SW), modelo de referência para serviços (MR-MPS-SV) e modelo de referência 
para gestão de pessoas (MR-MPS-RH);
C. Formação de Instituições Avaliadoras (IA), credenciadas para prestar serviços de 
avaliação, seguindo modelo proposto pelo MPS;
D. Formação de Instituições de Consultoria de Aquisição (ICA), credenciadas para prestar 
serviços de aquisição de software ou serviços relacionados.
Já a meta de negócios, tem por objetivo a disseminação e viabilização dos modelos MPS para a melhoria 
de competitividade das PMEs (como foco principal) e até de grandes organizações privadas e governa-
mentais. É composta por:
A. Criação e aprimoramento do modelo de negócio chamado de MN-MPS;
B. Realização de cursos, provas e workshops MPS;
C. Apoio para organizações que implementaram o modelo MPS;
D. Transparência para as organizações que realizaram a avaliação MPS.
Acesse na plataforma o vídeo: O que é o MPS.br.
Assista
https://softex.br/mpsbr/avaliacoes/
Qualidade e testes de software | Unidade 4 - Modelo MPS.br
50
ED
+ 
Co
nt
en
t H
ub
 ©
 2
01
9
Na figura abaixo, você pode ver que o programa MPS.br foi concebido por entidades que utilizaram 
modelos e normas preestabelecidos e também observaram a realidade das empresas brasileiras:
Modelos
e normas
(ISO/IEC, CMM)
Realidade das
empresas
brasileiras
Softex
Governo
Universidades
Este artigo apresenta os resultados de uma pesquisa realizada com o 
objetivo de identificar dificuldades e fatores de sucesso relacionados à 
implementação de processos de software utilizando o MR-MPS e o CMMI.
Título: Dificuldades e Fatores de Sucesso na Implementação de Processos 
de Software Utilizando o MR-MPS e o CMMI
Link: https://www2.unifap.br/furtado/files/2017/04/007.pdf
Aprofunde-se
2 COMPONENTES DO MPS.BR
O modelo MPS possui cinco componentes, como ilustrado na figura abaixo. Como já mencionado no 
tópico anterior, possui o modelo de referência MPS para software (MR-MPS-SW), o modelo de referência 
MPS para serviços (MR-MPS-SV), o modelo de referência MPS para gestão de pessoas (MR-MPS-RH), o 
método de avaliação (MA-MPS) e o modelo de negócio (MN-MPS).
Acesse na plataforma o vídeo: MPS.br e seus componentes.
Assista
Figura 2 -Síntese do MPS.br.
Fonte: adaptado de Weber (2011).
https://www2.unifap.br/furtado/files/2017/04/007.pdf
Qualidade e testes de software | Unidade 4 - Modelo MPS.br
51
Na figura abaixo, você pode ver a composição do modelo MPS e a integração entre seus componentes:
Modelo MPS
ISO/IEC
15504
Modelo de Referência
para Software
MR-MPS-SW
Modelo de Referência
para Serviço
MR-MPS-SV
Guia Geral
de Serviço
Modelo de Referência
para Gestão de Pessoas
MR-MPS-RH
Guia Geral
de Gestão
de Pessoas
Método de Avaliação Modelo de Negócio
MN-MPSMA-MPS
Guia de
Avaliação
Guia Geral
de Software
Guia de
Aquisição
CMMI
ISO/IEC
12207
Documento
do Projeto
O Modelo de Referência para o Processo de Software do MPS (MR-MPS-SW) (SOFTEX, 2016) contém 
todos os requisitos que as organizações devem possuir para serem compatíveis com o modelo MPS. A 
estrutura do modelo é formada por níveis de maturidade que são a combinação entre os processos e 
sua capacidade.
O MR-MPS-SW segue definições contidas nas normas ISO/IEC 12207 e ISO/IEC 15504. Além disso, foi 
construído para ser compatível com o modelo do SEI/CMU CMMI.
O Guia de Aquisição é um documento adicional e complementar que fornece subsídios para organi-
zações que almejem adquirir software e serviços correlatos com base em normas internacionais e em 
práticas sugeridas internacionalmente. Em linhas gerais, esse guia não contém requisitos do MR-MPS, 
mas sim boas práticas de aquisição de software e serviços correlatos.
O Método de Avaliação descreve como seu próprio nome sugere um processo de avaliação. Esse processo 
de avaliação é composto por requisitos para os avaliadores se capacitarem na avaliação em si e também 
descreve os requisitos necessários para que organizações se tornem aderentes ao MR-MPS.
O Modelo de Negócio, por sua vez, contém a descrição das regras de negócio para três domínios: o 
domínio do projeto MPS.br, o domínio das instituições implementadoras do modelo e instituições avalia-
doras e, por fim, o domínio das empresas e organizações que queiram fazer uso do modelo MPS para 
melhorar seus processos de software.
Figura 3 - Modelo MPS.
Fonte: adaptado de Softex (2016).
ED
+ 
Co
nt
en
t H
ub
 ©
 2
01
9
Qualidade e testes de software | Unidade 4 - Modelo MPS.br
52
2.1 MODELO DE REFERÊNCIA MPS PARA SOFTWARE
Como já mencionado, o Modelo de Referência é composto por níveis de maturidade. São ao todo sete 
níveis de maturidade que são sequenciais e acumulativos. Em cada um desses níveis, você encontrará 
processos e suas capacidades.
O progresso nos níveis de maturidade é obtido quando são atendidos todos os resultados, propósitos 
e atributos dos processos relacionados a determinado nível. Na figura abaixo, você pode visualizar a 
estrutura do Modelo de Referência.
Os níveis do MR-MPS são:
• Nível A – Em otimização;
• Nível B – Gerenciado quantitativamente;
• Nível C – Definido;
• Nível D – Largamente definido;
• Nível E – Parcialmente definido;
• Nível F – Gerenciado;
• Nível G – Parcialmente gerenciado.
Figura 4 - Estrutura do MR-MPS.
Fonte: Weber (2011).
ED
+ 
Co
nt
en
t H
ub
 ©
 2
01
9
Qualidade e testes de software | Unidade 4 - Modelo MPS.br
53
Título: Introdução ao nível G do Modelo MPS de Software
Acesso em: 03/11/2019.
Disponível em: https://www.youtube.com/watch?v=TWwTk4Spcgc
Aprofunde-se
O nível inicial é o nível G, mais imaturo, enquanto o nível A é o mais maduro. A graduação em sete níveis 
permite uma implementação e reconhecimento mais gradual de melhoria de processo, facilitando a 
adequação de pequenas e médias empresas, com obtenção de resultados em prazos menores. Dentro 
de cada, tem-se caracterizadas as capacidades do processo que são representadas por um conjunto de 
atributos de processo (AP). A capacidade de processo expressa o grau de refinamento e institucionali-
zação com o processo que é executado na organização ou unidade organizacional.
No MPS.br temos os seguintes atributos de processo:
• AP 1.1 - O processo é executado: o processo realiza o que foi proposto para ele, produ-
zindo os resultados esperados.
• AP 2.1 - O processo é gerenciado: a execução do processo possui alguma gestão.
• AP 2.2 - Os produtos de trabalho são gerenciados: os produtos de trabalho originados 
pelo processo são gerenciados, isto é, produzidos, controlados e mantidos.
• AP 3.1 - O processo é definido: há um padrão a ser seguido e o mesmo apoia a imple-
mentação do processo.
• AP 3.2 - O processo está implementado: o processo, agora padronizado, é de fato 
implementado para atingir os seus objetivos.
• AP 4.1 - O processo é medido: algumas medições são usadas para garantir que o desem-
penho do processo ajude a alcançar os objetivos para o qual esse processo foi proposto.
• AP 4.2 - O processo é controlado: o processo é controlado estatisticamente, permitindo 
se ter previsibilidade, estabilidade e capacidade de execução.
• AP 5.1 - O processo é o objeto de inovações: as mudanças no processo são identificadas 
a partir da análise dos seus indicadores e da investigação de possíveis inovações.
• AP 5.2 - O processo é otimizado continuamente: significa que as mudanças no 
processo têm, de fato, impactono alcance dos objetivos no que se refere aos aspectos 
relevantes de melhoria do próprio processo.
Esse artigo apresenta um estudo de caso sobre a implementação 
do nível E do MPS.br em uma instituição de pesquisa.
Título: Indicadores da Implementação do Nível E do MR-MPS 
em uma Instituição de Pesquisa
Link: https://bit.ly/332hDno
Aprofunde-se
https://www.youtube.com/watch?v=TWwTk4Spcgc
https://bit.ly/332hDno
Qualidade e testes de software | Unidade 4 - Modelo MPS.br
54
Na tabela abaixo, você encontrará os atributos relacionados aos processos de cada nível do modelo MPS 
e a qual nível se referem.
Nível Processos Atributos de processo
A Inovação e Implantação na Organização – IIO AP 1.1, AP 2.1, AP 2.2, AP 3.1, AP 3.2, 
AP 4.1, AP 4.2 , AP 5.1 e AP 5.2Análise e Resolução de Causas – ARC
B Gerência de Projetos – GPR (evolução) AP 1.1, AP 2.1, AP 2.2, AP 3.1, AP 3.2, 
AP 4.1 e AP 4.2
C Gerência de Riscos – GRI AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2
Desenvolvimento para Reutilização – DRU
Gerência de Decisões – GDE
D Verificação – VER AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2
Validação – VAL
Projeto e Construção do Produto – PCP
Integração do Produto – ITP
Desenvolvimento de Requisitos – DRE
E Gerência de Projetos – GPR (evolução) AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2
Gerência de Reutilização – GRU
Gerência de Recursos Humanos – GRH
Definição do Processo Organizacional – DFP
Avaliação e Melhoria do Processo Organizacional – AMP
F Medição – MED AP 1.1, AP 2.1 e AP 2.2
Garantia de Qualidade – GQA
Gerência de Portfólio de Projetos – GPP
Gerência de Configuração – GCO
Aquisição – AQU
G Gerência de Requisitos – GRE AP 1.1 e AP 2.1
Gerência de Projetos – GRP
3 COMPARAÇÃO ENTRE MODELOS
Como já mencionado, o MR-MPS-SW foi baseado nas normas ISO/IEC 12207 e ISO/IEC 15504 e cons-
truído de modo a ser compatível com o CMMI do SEI. Porém, apesar de guardar similaridades com essas 
normas e modelo de capacidade, existem particularidades presentes no MPS.br. Entre esses modelos, 
encontram-se vantagens e desvantagens.
Tabela 1 - Relação de níveis de maturidade, processos e 
atributos de processo do MPS.br.
Fonte: Weber (2011).
Qualidade e testes de software | Unidade 4 - Modelo MPS.br
55
Esse artigo apresenta um estudo de caso envolvendo uma organização 
que adotou o MPS.br.
Título: ISO 9001:2000, MPS.BR Nível F e CMMI Nível 3: Uma Estratégia de 
Melhoria de Processos na BL Informática
Link: https://bit.ly/2OtVqJA
Aprofunde-se
Figura 5 - Comparação entre os níveis dos modelos CMMI 
e MPS.br. Observe que o MPS.br possui uma granularidade 
maior: por exemplo, os três níveis C, D e E equiparam-se a 
somente um nível do CMMI, no caso o nível 3.
Fonte: adaptado de Silveira (2012).
ED
+ 
Co
nt
en
t H
ub
 ©
 2
01
9
https://bit.ly/2OtVqJA
Qualidade e testes de software | Unidade 4 - Modelo MPS.br
56
O MPS.br, apesar de concebido para ser compatível com o modelo do SEI CMMI, possui características 
que o diferencia. Veja a seguir.
Nem todos os requisitos do MPS.br 
estão no CMMI.
Todos os requisitos das áreas de 
processo do CMMI estão presentes 
no MPS.br.
O MPS.br não possui representação 
contínua, apenas por estágios.
O CMMI possui representação 
contínua.
O MPS.br é aceito como modelo de 
maturidade para licitações.
O CMMI é aceito como modelo de 
maturidade para licitações.
As avaliações são bienais no MPS.br.As avaliações não são bienais no CMMI.
No MPS.br o custo de certificação é 
mais acessível.
O custo de certificação do CMMI não 
é tão acessível.
O MPS.br é mais conhecido no Brasil 
e na América Latina. O CMMI é conhecido internacionalmente.
O MPS.br tem foco em pequenas e 
médias empresas. 
O CMMI não possui foco em empresas 
de tamanho específico.
O MPS.br possui foco no mercado 
nacional brasileiro.
O CMMI não apresenta definições 
particulares de mercado.
Em linhas gerais, a adoção de um modelo ou outro deverá estar alinhada com os objetivos da organização. 
Se for uma organização nacional ou com presença no âmbito da América Latina, talvez seja uma boa estra-
tégia iniciar avaliações por meio do MPS.br – por ser mais acessível financeiramente – e então utilizar as 
lições aprendidas com essa implantação para a eventual obtenção de uma certificação CMMI no futuro.
Infográfico 1 - Comparação entre CMMI e MPS.br.
ED
+ 
Co
nt
en
t H
ub
 ©
 2
01
9
Qualidade e testes de software | Unidade 4 - Modelo MPS.br
57
Acesse na plataforma o vídeo: Comparando o MPS.br.
Assista
Esse artigo apresenta um estudo envolvendo o uso do MPS 
em diversas organizações.
Título: iMPS - Resultados de Desempenho de Organizações 
que Adotaram o Modelo MPS
Link: https://bit.ly/2Ob06Fz
Aprofunde-se
https://bit.ly/2Ob06Fz
Qualidade e testes de software | Unidade 4 - Modelo MPS.br
58
CONSIDERAÇÕES FINAIS
Como você viu nesta unidade, a comunidade científica, acadêmica e industrial do Brasil conta com um 
modelo para amparar o desenvolvimento de software com qualidade. Compatível com demais modelos, 
pode ser usado principalmente por organizações e empresas que convivem com as condições de 
mercado presentes no país.
Qualidade e testes de software | Unidade 4 - Modelo MPS.br
59
GLOSSÁRIO
Frameworks: arcabouços, conjuntos de ferramentas de trabalho.
Qualidade e testes de software | Unidade 4 - Modelo MPS.br
60
REFERÊNCIAS
KALINOWSKI, Marcos et al. From software engineering research to Brazilian software quality impro-
vement. Disponível em: https://bit.ly/2OBBl47 Acesso em: 8 nov. 2019.
SILVEIRA, Artur Rafael. O que é o MPS.br? Disponível em: https://bit.ly/2XH8TBZ Acesso em: 4 nov. 2019.
SOFTEX. MPS.BR - Melhoria de Processo do Software Brasileiro - Guia Geral MPS de Software. Dispo-
nível em: https://bit.ly/2OEoQEU Acesso em: 8 nov. 2019.
WEBER, Kival Chaves. MPS.BR - Melhoria de Processo do Software Brasileiro. Disponível em: https://
bit.ly/2QIMMtE Acesso: 6 nov. 2019.
WEBER, Kival et al. Melhoria de Processo do Software Brasileiro (MPS.BR): um programa mobili-
zador. Disponível em: https://bit.ly/2QIayWo Acesso em: 8 nov. 2019.
WEBER, Kival Chaves et al. Modelo de Referência e Método de Avaliação para Melhoria de Processo de 
Software – versão 1.0 (MR-MPS e MA-MPS). Disponível em: https://bit.ly/2KKJNgy Acesso em: 1 out. 2019.
https://bit.ly/2OBBl47
https://bit.ly/2XH8TBZ
https://bit.ly/2OEoQEU
https://bit.ly/2QIMMtE
https://bit.ly/2QIMMtE
https://bit.ly/2QIayWo
https://bit.ly/2KKJNgy
Qualidade e testes de software | Unidade 5 - Introdução à atividade de teste de software
61
Unidade 5 Introdução à atividade de teste de software
Objetivo de aprendizagem:
• Introduzir à atividade de teste de software.
Tópicos de estudo:
• Introdução ao teste de software;
• Planejamento do teste de software;
• Tipos de teste.
Iniciando os estudos:
Nesta unidade, você conhecerá mais sobre a atividade de teste de software, seu histórico, motiva-
ções e conceitos.
Além disso, compreenderá o quão essa atividade é imprescindível para obtenção de qualidade em 
produtos de software.
Qualidade e testes de software | Unidade 5 - Introdução à atividade de teste de software
62
1 INTRODUÇÃO AO TESTE DE SOFTWARE
A engenharia de software evoluiu consideravelmente nos últimos anos com o objetivo de produzir 
técnicas, critérios, métodos e ferramentas para o desenvolvimento de software frente ao aumento do 
uso de software e sistemas baseados em computação em virtualmente todas as áreas da atividade 
humana (BARBOSA et al., 2000).
O processo de desenvolvimento de software envolve várias atividades nas quais, apesar das técnicas, 
métodos e ferramentas utilizados, erros no software podem acontecer. Atividades reunidas sob o nome 
de Garantia de Qualidade de Software têm sido inseridas ao longo de todo o processo de desenvolvi-
mento. Entre elas, atividades conhecidas sob a sigla VV&T – Verificação, Validação e Teste, com o obje-
tivo de minimizar a ocorrência de erros em um produto de software e riscos associados à atividade de 
desenvolvimento.Dentre as técnicas de verificação e validação, a atividade de teste é uma das mais 
utilizadas e constitui um elemento para fornecer evidências da confiabilidade do software em comple-
mento a outras atividades, como por exemplo o uso de revisões e de técnicas formais e rigorosas de 
especificação e de verificação (BARBOSA et al., 2000).
O histórico do teste de software iniciou-se há tempos, porém foi em 1957 que o conceito de teste se tornou 
o processo de detecção de erros e não simplesmente verificar se o software funciona. E foi em 1979 que 
Glenford Myers produziu os primeiros trabalhos complexos sobre o processo de teste. Nessa época, já 
se dizia que o teste deveria ter a intenção de encontrar erros. Com o passar do tempo, os projetos de 
Figura 1 - A prática da engenharia de software, com suas 
técnicas e atividades, surgiram para suprir a necessidade 
de uso de software de qualidade em praticamente todas 
as áreas de atividade humana.
Qualidade e testes de software | Unidade 5 - Introdução à atividade de teste de software
63
software foram tendo mais problemas em razão da complexidade dos sistemas. Segundo Bartié (2002 
apud DEVMEDIA, 2013), “mais de 30% dos projetos são cancelados antes de serem finalizados e mais de 
70% dos projetos falham nas entregas de funcionalidade”. Essas falhas criaram então um ambiente de 
caos e de problemas para os gestores, logo criou-se a necessidade de criação de processos de qualidade 
que busquem estabelecer procedimentos que sirvam de garantia e gerenciamento de qualidade.
Diante desse cenário, a atividade de teste consistirá em uma análise dinâmica do produto e é uma ativi-
dade relevante na descoberta e eliminação de erros que persistem. Em relação à qualidade do processo, 
o teste sistemático é uma atividade obrigatória para a obtenção de certificação do nível 3 do Modelo 
CMMI do Software Engineering Institute – SEI. Além disso, o conjunto de informações que resulta da 
atividade de teste é insumo para as atividades de depuração, manutenção e estimativa de confiabilidade 
de software (BARBOSA et al., 2000).
Acesse na plataforma o vídeo: A importância do teste de software
Assista
Por fim, a atividade de teste de software tem sido apontada como uma das mais custosas no desenvol-
vimento de software e, apesar desse fato, Myers (1979), mencionado por Barbosa et al. (2000), observa 
que aparentemente conhece-se muito menos sobre teste de software do que sobre outros aspectos e/
ou atividades do desenvolvimento de software.
Título: Área de testes de software: minha trajetória
Acesso em: 15/11/2019.
Disponível em: https://youtu.be/ZEimv-1bKZ0
Aprofunde-se
1.1 CONCEITOS E DEFINIÇÕES
Para você conhecer o universo do teste de software é necessário esclarecer alguns conceitos rela-
cionados a essa atividade. Os principais conceitos ao teste de software são relacionados aos termos: 
defeitos, erros e falhas. No infográfico abaixo, são apresentadas definições que seguem terminologias 
da IEEE (NETO, 2007):
https://youtu.be/ZEimv-1bKZ0
Qualidade e testes de software | Unidade 5 - Introdução à atividade de teste de software
64
Infográfico 1 - Conceitos básicos do teste de software.
Fonte: adaptado de Bartko (2012).
ED+ Content Hub © 2019
Qualidade e testes de software | Unidade 5 - Introdução à atividade de teste de software
65
No infográfico de título Terminologias do teste de software deste tópico, você pôde conferir a definição 
dos conceitos e observou uma figura que expressa a relação entre esses conceitos. Defeitos fazem parte 
do universo físico (o produto de software em si, seus arquivos, executáveis ou scripts) e são causados por 
pessoas, geralmente um desenvolvedor (o que remete ao seu próprio universo) ao cometer um engano, 
por exemplo, através do mau uso de alguma tecnologia. Defeitos podem ocasionar a manifestação de 
erros em um produto, ou seja, a construção de um software de forma diferente do que foi especificado 
(consistindo no universo de informação – a necessidade que gerou os requisitos do software). Por fim, 
os erros geram falhas, que são comportamentos inesperados em um software que afetam diretamente 
o usuário final da aplicação (universo do usuário, uso do software) e podem inviabilizar a utilização de 
um software. Com essas informações, pode-se dizer que o teste de software acaba por revelar simples-
mente falhas em um produto. Após a execução dos testes, em geral, é necessário executar um processo 
de depuração (popularmente conhecimento como o ato de “debugar”) para a identificação e correção 
dos defeitos que originaram essa falha (NETO, 2007).
Por fim, você também deve conhecer os seguintes elementos que compõem a atividade de teste de 
software:
Caso de teste (tópico 2.2): descreve uma condição particular a ser testada e é composto por valores de 
entrada, restrições para a sua execução e um resultado ou comportamento esperado (veja mais deta-
lhes no tópico 2.2).
Procedimento de teste ou roteiro de teste (tópico 2.3): é uma descrição dos passos necessários para 
executar um caso (ou um grupo de casos) de teste.
Critério de teste: serve para selecionar e avaliar casos de teste de forma a aumentar as possibilidades 
de provocar falhas ou, quando isso não ocorre, estabelecer um nível elevado de confiança na correção 
do produto (ROCHA et al., 2001 apud NETO, 2007). Os critérios de teste podem ser utilizados como:
• Critério de cobertura dos testes: permite a identificação de partes do programa que 
devem ser executadas para garantir a qualidade do software e indicar quando o mesmo 
foi suficientemente testado. Ou seja, determinar o percentual de elementos necessários 
por um critério de teste que foram executados pelo conjunto de casos de teste.
• Critério de adequação de casos de teste: quando, a partir de um conjunto de casos 
de teste T qualquer, ele é utilizado para verificar se T satisfaz os requisitos de teste 
estabelecidos pelo critério. Ou seja, esse critério avalia se os casos de teste definidos 
são suficientes ou não para avaliação de um produto ou uma função.
• Critério de geração de casos de teste: quando o critério é utilizado para gerar um 
conjunto de casos de teste T adequado para um produto ou função, ou seja, esse 
critério define as regras e diretrizes para geração dos casos de teste de um produto 
que esteja de acordo com o critério de adequação definido anteriormente.
Qualidade e testes de software | Unidade 5 - Introdução à atividade de teste de software
66
Título: Tudo o que você queria saber sobre testes, mas não 
tinha pra quem perguntar
Acesso em: 14/11/2019.
Disponível em: https://youtu.be/GHB86yxT-W8
Aprofunde-se
2 PLANEJAMENTO DO TESTE DE SOFTWARE
Uma atividade essencial no desenvolvimento de todo e qualquer projeto é o planejamento. Um plano 
tem o papel semelhante ao de um "mapa". Sem um mapa, um plano ou qualquer outra fonte de infor-
mação similar, você não conhecerá seus objetivos, nem aonde quer chegar e jamais terá a certeza de ter 
alcançado sua meta. Perceba que entender o propósito do planejamento é de suma importância a fim 
de monitorar a execução de atividades, sendo também importante conhecer o papel dos riscos no plane-
jamento bem como diferenciar estratégias de planos. Planejamento engloba três atividades principais:
1. Definir um cronograma de atividades: estabelecer as atividades que devem ser reali-
zadas, as etapas a serem seguidas e a ordem cronológica de execução.
2. Fazer alocação de recursos: definir quem realiza as atividades e quais ferramentas/
recursos devem ser utilizados.
3. Definir marcos de projeto: estabelecer os marcos, ou milestones, a serem alcançados 
com objetivo de se fazer o acompanhamento.
De maneira geral, a atividade de teste de software também precisará de planejamento para que seja 
executada de modo a produzir seu principal benefício – garantir qualidade ao produto de software. O 
planejamento do teste de software exige documentos essenciais: plano de teste, casos de teste e roteiro 
de teste (PIERRI, 2013).Nos próximos tópicos você explorará cada um deles.
2.1 PLANO DE TESTE
Um plano de teste é produzido para ajudar no desenvolvimento de um software. É por meio desse 
plano que os componentes técnicos, funcionais, estruturais etc. serão verificados e validados, de modo 
a garantir o bom funcionamento do programa junto ao usuário final. Sendo assim, um plano de teste de 
software tem como objetivo garantir a confiabilidade e segurança de um produto de software, identifi-
cando possíveis erros e falhas durante ou após a sua produção (VIEGAS, 2017).
https://youtu.be/GHB86yxT-W8
Qualidade e testes de software | Unidade 5 - Introdução à atividade de teste de software
67
Ele deve ser elaborado em conjunto com a proposta do software, sendo aplicado em cada etapa do 
projeto e não somente no final. Na figura acima é possível ver, pelo exemplo do processo RUP (Rational 
Unified Process), que os testes permeiam praticamente todo o processo de desenvolvimento. Em linhas 
gerais, o plano de teste funciona como (DEVMEDIA, 2009):
• Um integrador entre diversas atividades de testes no projeto;
• Mecanismo de comunicação para os stakeholders (i.e. à equipe de testes e outros inte-
ressados);
• Guia para execução e controle das atividades de testes.
O plano de teste, que pode ser elaborado pelo gerente de projeto ou gerente de testes, visa planejar as 
atividades a serem realizadas, definir os métodos a serem empregados, planejar a capacidade neces-
sária e estabelecer métricas e formas de acompanhamento do processo. Em relação ao seu conteúdo, o 
plano de teste deve conter:
• Os itens a serem testados, ou seja, o escopo e objetivos do plano devem ser estabele-
cidos no ponto inicial do projeto.
• Atividades e recursos a serem empregados, ou seja, as estratégias de testes e recursos 
utilizados devem ser definidos bem como toda e qualquer restrição imposta sobre as 
atividades e/ou recursos.
• Os tipos de teste a serem realizados e as ferramentas empregadas, ou seja, os tipos de 
teste e a ordem temporal de sua ocorrência são estabelecidos no plano.
• Critérios para avaliar os resultados obtidos: métricas devem ser definidas para acom-
panhamento dos resultados alcançados.
Figura 2 - Processo RUP: testes estão presentes 
em todo o processo de desenvolvimento.
Fonte: adaptado de Devmedia (2009).
Qualidade e testes de software | Unidade 5 - Introdução à atividade de teste de software
68
Título: Teste de software - plano de teste
Acesso em: 15/11/2019.
Disponível em: https://youtu.be/oMzCQkPN3Ug
Aprofunde-se
2.2 CASOS DE TESTE
Casos de teste descrevem uma condição particular a ser testada. Possuem valores de entrada, limitações 
para a sua execução e também um resultado ou comportamento esperado. O processo de criação de 
casos de teste pode também ajudar a encontrar falhas nos próprios requisitos, identificando cenários 
não abordados pelos requisitos que originaram a demanda pelo sistema.
Título: Casos de testes
Acesso em: 15/11/2019.
Disponível em: https://youtu.be/t7lqIeOkwrw
Aprofunde-se
A estrutura de um caso de teste é composta pela descrição de sua precondição, pela descrição do proce-
dimento a ser executado e pela descrição do resultado esperado. Sobre esses componentes do caso de 
teste, é possível detalhá-los da seguinte maneira:
• A precondição é um requisito para o comportamento do sistema antes da execução do 
caso de teste.
• No procedimento estão passos para a execução do caso de teste. Esse procedimento 
não deve fugir do foco descrito na descrição do caso de teste.
• O resultado esperado descreve como o sistema deveria se comportar após a execução 
do procedimento do caso de teste.
De maneira geral, em um produto de software, seja ele um aplicativo desktop ou uma página da internet, 
existem testes que são considerados fundamentais para garantir uma qualidade mínima para a utili-
zação por um usuário. A seguir uma listagem desses casos de teste fundamentais, segundo Rocha (2008):
• Layout: no início de cada roteiro de teste, é necessário que sejam feitos casos de teste 
específicos para o layout (posicionamento dos elementos gráficos – caixas de texto, 
botões, áreas de digitação, tabelas etc.) de cada tela do sistema.
• Campos obrigatórios: casos de teste que verificam se os campos obrigatórios estão 
sendo corretamente tratados. Por exemplo: verificar se ao deixar um campo obriga-
https://youtu.be/oMzCQkPN3Ug
https://youtu.be/t7lqIeOkwrw
Qualidade e testes de software | Unidade 5 - Introdução à atividade de teste de software
69
tório em branco está aparecendo a mensagem, ou seja, ressaltar para o usuário que o 
campo deve ser preenchido.
• Máscara: verificar se os campos estão sendo preenchidos com suas respectivas 
máscaras (formato de como um valor deve ser inserido). Por exemplo: o campo CPF 
deve ser preenchido com a máscara NNN.NNN.NNN-NN
• Valores permitidos: verificar se os campos estão sendo validados no caso de rece-
berem valores não permitidos. Por exemplo: campos numéricos não devem aceitar 
caracteres especiais e/ou letras.
• Valores nulos: verificar se um campo que só pode aceitar valor maior que zero, aceita 
valor menor ou igual a zero.
• Valores limite: verificar qual o valor máximo e mínimo permitido para certo campo. 
Testar, ao inserir um valor fora do limite, se está aparecendo a devida mensagem.
• Verificação de caracteres especiais: verificar se os campos de texto estão aceitando 
caracteres especiais.
• Validação de campos (data, CPF, CNPJ): verificar se foi digitado uma data, CPF ou 
CNPJ válido.
• Eventos do mouse: realizar testes que copiam textos com o mouse e colam e verificam 
se esses campos estão sendo validados corretamente.
• Espaços em branco: num campo obrigatório, preencher com espaços em branco e 
verificar se o sistema detectou que o campo estava vazio.
• Ortografia: verificar a ortografia de todo e qualquer texto do sistema, inclusive de 
mensagens de alerta.
Em relação especificamente aos sistemas web, destacam-se:
• Navegador: os sistemas web geralmente possuem comportamentos diferentes 
quando são visualizados em diferentes navegadores. Com isso, é importante criar um 
caso de teste para executar o sistema nos principais navegadores, como por exemplo, 
IE7, IE8, Chrome, Firefox e Safari.
• Resolução do monitor: os sistemas web também podem ter exibições diferentes 
dependendo da resolução do monitor do usuário. Nesse caso, é importante que seja 
criado um caso de teste para verificar o comportamento do sistema nas principais 
resoluções, como por exemplo, resoluções de 800x600 e 1027x768.
• Perfil do usuário: há sistemas que possuem diferentes perfis de usuários com dife-
rentes privilégios. Nesse caso, é importante criar diferentes casos de teste consi-
derando na precondição o perfil do usuário. Inclusive deve haver casos de teste 
considerando que um usuário comum não pode acessar as funcionalidades de um 
administrador do sistema.
Qualidade e testes de software | Unidade 5 - Introdução à atividade de teste de software
70
• Autenticação: quando o sistema possui autenticação do usuário, é importante criar 
casos de teste para não permitir que um usuário não autenticado, com a devida 
permissão concedida por algum administrador, acesse o sistema.
• Caracteres especiais: é importante criar casos de teste que verifiquem o comporta-
mento do sistema quando são inseridos em campos de texto um link ou uma imagem, 
pois, se o sistema processar o código HTML inserido, o link pode ser direcionado para 
um vírus ou para imagem indevida.
• Integridade dos dados: verificar no banco de dados se os valores foram atualizados 
ou excluídos corretamente.
• Clique duplo: ao criar um roteiro de teste para uma tela de cadastro, incluir um caso 
de teste que verifique o comportamento do sistema quando o usuário clica duas vezes 
no botão Salvar. Nesse caso, o sistema não deve incluir dois registros.
• Tempo de processamento: verificar o tempo de processamento para carregar uma 
página ou se um combo box não ultrapassao tempo máximo esperado. No caso de 
listas, pode ser necessário incluir paginação para melhorar o tempo de processamento.
• Dados em uma tabela: verificar se o texto contido em uma tabela possui alguma orde-
nação, se o alinhamento dos campos estão de acordo com o padrão especificado.
• Alerta de confirmação: é importante que hajam alertas de confirmação em botões 
cuja ação é de excluir ou cancelar uma operação. Criar casos de teste que verifiquem 
se ao clicar em Não, o sistema realmente não exclui ou não cancela a operação.
Título: Web Page Screen Resolution Simulator
Acesso em: 16/11/2019.
Disponível em: http://www.webconfs.com/web-page-screen-resolution.php
Aprofunde-se
2.3 ROTEIRO DE TESTE
O roteiro de teste descreve os passos necessários para a execução de um caso de teste ou um grupo de 
casos de teste. Esse roteiro é elaborado a partir dos documentos de especificação de um determinado 
caso de uso, como a especificação funcional, guia de interface ou modelagem do banco de dados. O 
roteiro de teste ainda é conhecido como projeto de teste, especificação de teste ou script de teste. É 
importante no momento da execução dos testes, pois o testador (no inglês conhecido como tester), o 
profissional que realiza os testes, consegue realizar uma sequência de passos de forma coerente, sem a 
necessidade de consultar todos os documentos de especificação no momento dos testes, podendo ficar 
focado apenas na própria execução dos testes (ROCHA, 2007).
http://www.webconfs.com/web-page-screen-resolution.php
Qualidade e testes de software | Unidade 5 - Introdução à atividade de teste de software
71
Além do que é especificado pelo cliente, o roteiro de teste também possui procedimentos que testam a 
eficiência do sistema. Como já mencionado, um roteiro de teste é composto por um conjunto de casos 
de teste, mas além desses há também seções de localização (local no produto de software) e de objeto 
de teste. A seção de localização do roteiro de teste serve para definir em qual tela do sistema será execu-
tado um subconjunto de casos de teste, os quais fazem parte daquela localização. A localização pode ser 
escrita da seguinte forma: Tela Consultar Funcionários > Tela Manter Funcionários.
Segundo Rocha (2007), em uma localização pode existir um ou mais objetos de teste, onde esse pode 
ser definido como a ideia global de um conjunto de casos de teste. Por exemplo, na localização descrita 
anteriormente, Tela Manter Funcionários, um possível objeto de teste seria cadastro de funcionários 
no sistema. Outro objeto de teste para essa mesma localização poderia ser alteração de funcionários no 
sistema. Essa estratégia de teste poderia ser compreendida como um agrupamento de casos de teste 
em torno de um objetivo comum. O objeto de teste, por sua vez, pode conter um ou mais casos de teste. 
Acesse na plataforma o vídeo: Porquê planejar o teste de software
Assista
Figura 3 - A atividade de teste de software 
requer planejamento detalhado, elaborado 
por uma equipe qualificada.
Qualidade e testes de software | Unidade 5 - Introdução à atividade de teste de software
72
3 TIPOS DE TESTE
Por meio dos processos hoje existentes na engenharia de software, há diversos procedimentos para 
realizar o teste de software. De modo geral, existem técnicas que foram utilizadas em sua maioria em 
sistemas desenvolvidos sobre linguagens estruturadas que ainda hoje podem ter serventia para sistemas 
orientados a objetos. Apesar de serem paradigmas de desenvolvimento diferentes, o objetivo principal 
dessas técnicas continua a ser o mesmo: encontrar falhas no produto de software. As técnicas de teste 
são categorizadas de acordo com a origem das informações utilizadas para estabelecer os requisitos de 
teste. Elas contemplam diferentes perspectivas do software e impõem a necessidade de se estabelecer 
uma estratégia de teste que contemple as vantagens e os aspectos complementares dessas técnicas 
(NETO, 2005).
Acesse na plataforma o vídeo: Tipos de teste
Assista
Os tipos de teste vão diferir quanto às suas técnicas. As técnicas existentes são: técnica funcional (caixa-
-preta) e estrutural (caixa-branca). A seguir, você encontrará tipos de teste especificados dentro das 
técnicas citadas. Com relação aos testes do tipo caixa-preta, você pode encontrar (DEVMEDIA, 2012):
• Regressão: toda vez que algo for mudado, deve ser testada toda a aplicação nova-
mente.
• Requisitos: verifica se o sistema é executado conforme o que foi especificado. São 
realizados através da criação de condições de testes e cheklists de funcionalidades.
• Controle: assegura que o processamento seja realizado conforme sua intenção. Entre 
os controles estão a validação de dados, a integridade dos arquivos, as trilhas de audi-
toria, o backup e a recuperação, a documentação, entre outros.
• Usabilidade: tem por objetivo verificar a facilidade que o software ou site possui de ser 
claramente compreendido e manipulado pelo usuário.
• Aceitação: testa se a solução será bem avaliada pelo usuário. Ex.: caso exista um botão 
pequeno demais para executar alguma operação (aqui cabem itens fora da interface 
também).
Qualidade e testes de software | Unidade 5 - Introdução à atividade de teste de software
73
Título: Teste de regressão visual
Acesso em: 13/11/2019.
Disponível em: https://youtu.be/rIWmT0nFKoE
Aprofunde-se
Para evitar problemas com a equipe de desenvolvimento, algumas 
empresas têm utilizado a terceirização da atividade de teste por empresas 
conhecidas como fábricas de testes. O conceito de uma fábrica de testes 
sugere uma empresa parceira ou ainda um departamento separado dentro 
da própria empresa, com equipe e infraestruturas próprias e dedicadas. 
Você pode conferir mais detalhes no seguinte endereço: http://blog.quality.
com.br/fabrica-de-testes-e-qualidade-de-software-o-que-e-o-que-faz/
Reflita
Abaixo, uma listagem com os tipos de teste caixa-branca existentes (DEVMEDIA, 2012):
• Desempenho: verifica se o tempo de resposta é o desejado para o momento de utili-
zação da aplicação.
• Carga: verifica o funcionamento da aplicação com a utilização de uma quantidade 
grande de usuários simultâneos.
• Estresse: testa a aplicação sem situações inesperadas. Testa caminhos, às vezes, antes 
não previstos no desenvolvimento/documentação.
• Conformidade: verifica se o software foi desenvolvido de acordo com padrões, 
normas, procedimentos e guias de TI.
• Contingência: verifica se o sistema é capaz de retornar ao estado anterior antes da falha.
• Segurança: avalia a adequação dos procedimentos de proteção e as contramedidas 
projetadas para garantir a confidencialidade das informações e a proteção dos dados 
contra o acesso não autorizado de terceiros.
Título: Boas práticas de testes
Acesso em: 12/11/2019.
Disponível em: https://youtu.be/WO6TMMzryi0
Aprofunde-se
https://youtu.be/rIWmT0nFKoE
http://blog.quality.com.br/fabrica-de-testes-e-qualidade-de-software-o-que-e-o-que-faz/
http://blog.quality.com.br/fabrica-de-testes-e-qualidade-de-software-o-que-e-o-que-faz/
https://youtu.be/WO6TMMzryi0
Qualidade e testes de software | Unidade 5 - Introdução à atividade de teste de software
74
CONSIDERAÇÕES FINAIS
Nesta unidade, foram apresentados conceitos, termos, técnicas e procedimentos referentes à ativi-
dade de teste de software que, por sua vez, é uma atividade essencial para a obtenção da qualidade de 
software. Para que a atividade de teste de software cumpra seu objetivo, você pode ver a necessidade 
de um bom planejamento e, nesse planejamento, a utilização do tipo de teste mais alinhado com a 
proposta do software, pode facilitar o caminho.
Qualidade e testes de software | Unidade 5 - Introdução à atividade de teste de software
75
GLOSSÁRIO
Glenford Myers: é um cientista da computação, empresário e autor americano. Ele fundou duas 
empresas de alta tecnologia bem-sucedidas, criou oito livros didáticos em ciências da computação e fez 
importantes contribuições na arquitetura de microprocessadores(WIKIPEDIA, 2019).
HTML (Hypertext Markup Language): linguagem utilizada pelos sistemas web e é interpretada pelo 
software conhecido como navegador de internet.
IEEE: Institute of Electrical and Electronics Engineers.
Rational Unified Process: O Processo Unificado da Rational conhecido como RUP (Rational Unified 
Process), é um processo de engenharia de software criado para apoiar o desenvolvimento orientado 
a objetos, fornecendo uma forma sistemática para se obter vantagens no uso da UML. Foi criado pela 
Rational Software Corporation e adquirido em fevereiro de 2003 pela IBM.
Sistemas web: aplicações baseadas no protocolo HTTP, por meio da rede mundial de computadores, a 
internet. Normalmente são operadas e manipuladas por um usuário utilizando um software conhecido 
como navegador de internet.
Qualidade e testes de software | Unidade 5 - Introdução à atividade de teste de software
76
REFERÊNCIAS
BARBOSA, Ellen Francine et al. Introdução ao teste de software, 2000. Disponível em: https://www.
researchgate.net/publication/306255146_INTRODUCAO_AO_TESTE_DE_SOFTWARE Acesso em: 3 fev. 2020.
BARTKO, William. Crixus-Trucov: uma ferramenta para apoiar o teste estrutural de Sistemas Embarcados 
Críticos. 62 f. Trabalho de Conclusão de Curso – Curso Superior de Tecnologia em Sistemas para Internet, 
Universidade Tecnológica Federal do Paraná – UTFPR. Campo Mourão, 2012. Disponível em: http://reposi-
torio.roca.utfpr.edu.br/jspui/bitstream/1/706/1/CM_COINT_2012_1_02.pdf Acesso em: 28 nov. 2019.
DEVMEDIA. Introdução à garantia de qualidade de software e ferramentas para teste, 2013. Dispo-
nível: https://www.devmedia.com.br/introducao-a-garantia-de-qualidade-de-software-e-ferramentas-para-
-teste/28027 Acesso em: 13 nov. 2019.
DEVMEDIA. Plano de Teste - Um Mapa Essencial para Teste de Software, 2009. Disponível em: https://
www.devmedia.com.br/plano-de-teste-um-mapa-essencial-para-teste-de-software/13824 Acesso em: 10 nov. 
2019.
DEVMEDIA. Testes de Desempenho, Carga e Stress, 2012. Disponível: https://www.devmedia.com.br/
testes-de-desempenho-carga-e-stress/26546 Acesso em: 13 nov. 2019.
GRUPO DE TESTADORES DE SOFTWARE. Casos de Teste Fundamentais, 2008. Disponível em: http://
gtsw.blogspot.com/2008/02/casos-de-teste-fundamentais.html Acesso em: 12 nov. 2019.
GRUPO DE TESTADORES DE SOFTWARE. Como Elaborar um Roteiro de Testes, 2007. Disponível em: 
https://gtsw.blogspot.com/2007/10/como-elaborar-um-roteiro-de-testes.html Acesso em: 12 nov. 2019.
MATERA. Planejamento de testes de sistema, 2013. Disponível em: http://www.matera.com/blog/post/
planejamento-de-testes-de-sistema Acesso em: 10 nov. 2019.
NETO, Arilo. Introdução a teste de software. Engenharia de Software Magazine, v. 1, p. 22, 2007. Dispo-
nível em: https://www.researchgate.net/profile/Arilo_Neto/publication/266356473_Introducao_a_Teste_de_
Software/links/5554ee6408ae6fd2d821ba3a/Introducao-a-Teste-de-Software.pdf Acesso em: 28 nov. 2019.
ONE DAY TASTING. Teste de software: introdução, conceitos básicos e tipos de testes, 2017. Disponível 
em: https://blog.onedaytesting.com.br/teste-de-software/ Acesso em: 11 nov. 2019.
WIKIPEDIA. Glenford Myers, 2019. Disponível em: https://en.wikipedia.org/wiki/Glenford_Myers Acesso 
em: 25 nov. 2019.
https://www.researchgate.net/publication/306255146_INTRODUCAO_AO_TESTE_DE_SOFTWARE
https://www.researchgate.net/publication/306255146_INTRODUCAO_AO_TESTE_DE_SOFTWARE
http://repositorio.roca.utfpr.edu.br/jspui/bitstream/1/706/1/CM_COINT_2012_1_02.pdf
http://repositorio.roca.utfpr.edu.br/jspui/bitstream/1/706/1/CM_COINT_2012_1_02.pdf
https://www.devmedia.com.br/introducao-a-garantia-de-qualidade-de-software-e-ferramentas-para-teste/28027
https://www.devmedia.com.br/introducao-a-garantia-de-qualidade-de-software-e-ferramentas-para-teste/28027
https://www.devmedia.com.br/plano-de-teste-um-mapa-essencial-para-teste-de-software/13824
https://www.devmedia.com.br/plano-de-teste-um-mapa-essencial-para-teste-de-software/13824
https://www.devmedia.com.br/testes-de-desempenho-carga-e-stress/26546
https://www.devmedia.com.br/testes-de-desempenho-carga-e-stress/26546
http://gtsw.blogspot.com/2008/02/casos-de-teste-fundamentais.html
http://gtsw.blogspot.com/2008/02/casos-de-teste-fundamentais.html
https://gtsw.blogspot.com/2007/10/como-elaborar-um-roteiro-de-testes.html
http://www.matera.com/blog/post/planejamento-de-testes-de-sistema
http://www.matera.com/blog/post/planejamento-de-testes-de-sistema
https://www.researchgate.net/profile/Arilo_Neto/publication/266356473_Introducao_a_Teste_de_Software/links/5554ee6408ae6fd2d821ba3a/Introducao-a-Teste-de-Software.pdf
https://www.researchgate.net/profile/Arilo_Neto/publication/266356473_Introducao_a_Teste_de_Software/links/5554ee6408ae6fd2d821ba3a/Introducao-a-Teste-de-Software.pdf
https://blog.onedaytesting.com.br/teste-de-software/
https://en.wikipedia.org/wiki/Glenford_Myers
Qualidade e testes de software | Unidade 6 - Fases ou níveis do teste de software
77
Unidade 6 Fases ou níveis do teste de software
Objetivo de aprendizagem:
• Apresentar as fases ou níveis de teste de software.
Tópicos de estudo:
• Teste de unidade;
• Teste de integração;
• Teste de sistema.
Iniciando os estudos:
Nesta unidade, você poderá compreender como os testes de software podem diferir quanto a sua granu-
laridade. No teste de software, você encontrará as fases ou níveis de teste de unidade, teste de inte-
gração e teste de sistema. A questão-chave para a compreensão de cada um desses níveis é entender o 
objetivo de teste em cada um deles.
Qualidade e testes de software | Unidade 6 - Fases ou níveis do teste de software
78
1 TESTE DE UNIDADE
O teste de unidade tem como foco as menores unidades de um programa, que podem ser funções, 
procedimentos, métodos ou classes. Nesse contexto, espera-se que sejam identificados erros relacio-
nados a algoritmos incorretos ou mal implementados, estruturas de dados incorretas ou simples erros 
de programação. Como cada unidade é testada separadamente, o teste de unidade pode ser aplicado à 
medida que ocorre a implementação das unidades e pelo próprio desenvolvedor, sem a necessidade de 
dispor-se do sistema totalmente finalizado (DELAMARO et al., 2016).
Para você compreender melhor o conceito, observe o pseudocódigo abaixo:
função soma(a, b)
 início
 retorne a + b;
	 fim
Seja soma uma função hipotética de soma, que recebe dois parâmetros e retorna a soma entre eles. 
Para que o teste seja realizado é necessário executar ao menos uma vez essa função:
resultado <= soma (1, 2);
se resultado é igual a 3 então
 imprima (“Função está correta”);
Ao programar os trechos exibidos, você terá concluído um teste unidade ou unitário.
Título: C#: como criar e executar testes de unidade
Acesso em: 27/11/2019.
Disponível em: https://youtu.be/uBI2vtflrRo
Aprofunde-se
Veja, foi construído um novo código para realizar o teste de unidade. Em um primeiro momento pode 
parecer tentador não escrever um novo código para validar um outro código. Porém, ressalta-se que no 
ciclo de vida de um produto de software esse mesmo software passará por sucessivos ciclos de manu-
tenção, com a adição de novas funcionalidades ou correções de funcionalidades já existentes. Nesse 
contexto, o código-fonte base, ao final de vários ciclos, será grande o suficiente para tornar a manu-
tenção custosa e realizar testes nesse código de forma manual será uma tarefa humanamente difícil, 
dado seu tamanho. Com essa motivação, a construção de testes de unidade surge como alternativa para 
https://youtu.be/uBI2vtflrRo
Qualidade e testes de software | Unidade 6 - Fases ou níveis do teste de software
79
facilitar a manutenção do produto de software, frente a sucessivas modificações/inclusões de código no 
ciclo de vida do produto de software, utilizando-se, inclusive, de recursos para automatização desses 
testes (LIMA, 2017).
Título: 5 maneiras de aplicar ou otimizar seus testes de unidade
Acesso em: 27/11/2019.
Disponível em: https://youtu.be/oIMsTXRN8QgAprofunde-se
Acesse na plataforma o vídeo: Custo dos testes unitários
Assista
Para resumir a importância do teste unitário hoje na cadeia de desenvolvimento de software, considere 
a imagem a seguir:
Na figura acima, é exemplificado que testes de unidade ou unitários são mais baratos e rápidos (como 
coelhos) que testes de usuários (UI) que são mais caros e lentos (como tartarugas).
Figura 1 - Relação em testes unitários e de interface de usuário. 
Fonte: Lima (2017).
https://youtu.be/oIMsTXRN8Qg
Qualidade e testes de software | Unidade 6 - Fases ou níveis do teste de software
80
2 TESTE DE INTEGRAÇÃO
No teste de integração, que deve ser realizado após serem testadas as unidades individualmente, a 
ênfase é dada na construção da estrutura do sistema. À medida que as diversas partes do software 
são colocadas para trabalhar juntas, é preciso verificar se a interação entre elas funciona de maneira 
adequada e não leva a erros. Também nesse caso é necessário um grande conhecimento das estruturas 
internas e das interações existentes entre as partes do sistema e, por isso, o teste de integração tende a 
ser executado pela própria equipe de desenvolvimento (DELAMARO et al., 2016).
O teste de integração possui duas estratégias para sua realização: as abordagens bottom-up e top-down 
(LOURENÇO, 2010).
Na abordagem bottom-up, o software é desenvolvido a partir de rotinas, funções e métodos básicos 
que fornecem serviços às demais rotinas, funções ou métodos de uma camada superior do software. 
Por exemplo, uma verificação de CPF pode ser chamada em vários pontos de um sistema de software. 
Provavelmente será uma das primeiras a serem implementadas.
Já na abordagem top-down, faz-se o contrário. O desenvolvedor elabora seu código supondo que o 
código de uma camada inferior do sistema de software já esteja pronto. Utilizando-se o exemplo anterior 
de verificação de CPF, o desenvolvedor pode codificar chamadas (fazer o uso nominal da função) para a 
verificação de CPF, mesmo sabendo que ela ainda não existe. Nesse exemplo, utiliza-se o recurso conhe-
cido como stubs, que são rotinas vazias que retornam valores explícitos, definidos pelo programador.
Na realização de testes para a abordagem de desenvolvimento bottom-up, devem ser escritos códigos 
que invoquem as rotinas de camadas inferiores, testando-as com diversas combinações de parâmetros. 
As rotinas escritas para esses testes são conhecidas como drivers (você viu um breve exemplo no tópico 
1, no teste de unidade ou unitário), pois sua função é acionar o código que deve ser testado.
Muitas organizações encontram dificuldades com as atividades de teste. Em geral, 
tal situação é justificada pela falta de profissionais especializados na área ou 
mesmo uma dificuldade de implementar os processos de teste. Para esses casos, 
o CenPRA (Centro de Pesquisas Renato Archer) desenvolveu uma metodologia 
para auxiliar as empresas nesses processos. Saiba mais em: http://tecnologia.
alinebossi.com/2010/09/20/teste-de-software-no-contexto-da-melhoria/
Reflita
Há testes que necessitam de dados oriundos de arquivos. Nessa situação, é comum que testadores 
criem bases de dados falsas contendo registros para realizá-los, simulando os dados necessários para o 
teste. Esses dados, inclusive, podem ser inconsistentes, contendo informação incorreta para verificar o 
comportamento de rotinas.
http://tecnologia.alinebossi.com/2010/09/20/teste-de-software-no-contexto-da-melhoria/
http://tecnologia.alinebossi.com/2010/09/20/teste-de-software-no-contexto-da-melhoria/
Qualidade e testes de software | Unidade 6 - Fases ou níveis do teste de software
81
Uma vez que cada componente tenha sido testado, seja com os drivers ou os stubs, esses elementos são 
substituídos pelas rotinas reais. Após a substituição, é recomendado que os testes de integração sejam 
executados novamente, de modo que o processo todo se repita até a conclusão do projeto.
Título: Testes de integração: comece a pensar no todo!
Acesso em: 27/11/2019.
Disponível em: https://youtu.be/sa448ZG9p9U
Aprofunde-se
2.1 TESTE DE REGRESSÃO E ACEITAÇÃO
Existem também os testes de aceitação e testes de regressão. O teste de aceitação (também conhecido 
por UAT, do inglês User Acceptance Tests) tem por objetivo verificar a conformidade com os requisitos 
de negócio e usuário na última fase do ciclo de desenvolvimento, validando o produto para entrega. Eles 
são realizados geralmente por um grupo restrito de usuários finais do sistema.
Figura 2 - Utilização de drivers e stubs para uso em 
testes de integração.
Fonte: adaptado de Albano et al. (2015).
ED
+ 
Co
nt
en
t H
ub
 ©
 2
01
9
https://youtu.be/sa448ZG9p9U
Qualidade e testes de software | Unidade 6 - Fases ou níveis do teste de software
82
Acesse na plataforma o vídeo: Testes de regressão e teste de aceitação
Assista
Já o teste de regressão acontece a cada modificação efetuada no sistema após a liberação de nova 
versão. Nesses processos, corre-se o risco de que novos defeitos sejam introduzidos. Por esse motivo, 
é necessário, após a manutenção, realizar testes que mostrem que as modificações efetuadas estão 
corretas, ou seja, que os novos requisitos implementados (se for o caso) funcionam como o esperado e 
que os requisitos anteriormente testados continuam válidos. De maneira geral, os testes de regressão 
tratam de uma nova execução do conjunto de casos de teste já executados (DELAMARO et al., 2016).
Esse artigo confronta as características do paradigma de orientação a 
objetos para a criação de testes de integração.
Título do artigo: Testes de integração aplicados a software orientado a 
objetos: heurísticas para ordenação de classes
Link: https://www.cos.ufrj.br/uploadfile/es63204.pdf
Aprofunde-se
3 TESTE DE SISTEMA
Depois que se tem o sistema completo, com todas as suas partes integradas, inicia-se o teste de sistema. 
O objetivo é verificar se as funcionalidades especificadas nos documentos de requisitos estão todas 
corretamente implementadas. Aspectos de correção, completude e coerência devem ser explorados, 
bem como requisitos não funcionais como segurança, performance e robustez. Muitas organizações 
adotam a estratégia de designar uma equipe independente para realizar o teste de sistema (DELAMARO 
et al., 2016).
Acesse na plataforma o vídeo: Ambientes de teste
Assista
https://www.cos.ufrj.br/uploadfile/es63204.pdf
Qualidade e testes de software | Unidade 6 - Fases ou níveis do teste de software
83
Os seguintes pontos sumarizam o teste de sistema (SOMMERVILLE, 2011):
• Se os componentes são compatíveis;
• Se eles interagem corretamente;
• Se transferem os dados certos no momento certo, por meio de suas interfaces.
Título: Testes de aceitação
Acesso em: 27/11/2019.
Disponível em: https://youtu.be/0B3dKp07Qe4
Aprofunde-se
Ainda, segundo Sommerville (2011), os testes de sistema se sobrepõem aos testes de integração, 
possuindo as seguintes diferenças entre eles:
1. Durante o teste de sistema, os componentes reusáveis que tenham sido desenvolvidos 
separadamente e os sistemas de prateleira que eventualmente foram adquiridos, 
podem ser integrados com componentes recém-desenvolvidos. Então, o sistema 
completo é testado.
2. Nesse estágio, componentes desenvolvidos por diferentes membros da equipe ou 
grupos podem ser integrados. O teste de sistema é um processo coletivo, não indivi-
dual. Em algumas empresas, o teste de sistema pode envolver uma equipe indepen-
dente, sem participação de projetistas e programadores.
https://youtu.be/0B3dKp07Qe4
Qualidade e testes de software | Unidade 6 - Fases ou níveis do teste de software
84
Esse artigo lista seis regras práticas para melhorar o teste de sistemas 
em geral.
Título do artigo: 6 regras simples para melhorar o teste de sistemas
Link: https://blogbrasil.comstor.com/6-regras-simples-para-melhorar-o-
teste-de-sistemas
Aprofunde-se
Infográfico 1 - Comparação entre as fases ou níveis de teste.
Fonte: adaptado de https://bit.ly/2OszyiL Acesso em:5 dez. 2019.
ED
+ 
Co
nt
en
t H
ub
 ©
 2
01
9
https://blogbrasil.comstor.com/6-regras-simples-para-melhorar-o-teste-de-sistemas
https://blogbrasil.comstor.com/6-regras-simples-para-melhorar-o-teste-de-sistemas
https://bit.ly/2OszyiL
Qualidade e testes de software | Unidade 6 - Fases ou níveis do teste de software
85
CONSIDERAÇÕES FINAIS
Nesta unidade, os chamados níveis ou fases de teste foram apresentados detalhando seus escopos e em 
qual ponto do desenvolvimento devem ocorrer.
De posse das informações aqui apresentadas, você poderá avaliar quando e onde poderá aplicar testes 
de unidade, de integração ou sistema durante o desenvolvimento de um produto de software.
Qualidade e testes de software | Unidade 6 - Fases ou níveis do teste de software
86
GLOSSÁRIO
Drivers: são responsáveis pelo controle do teste de uma unidade ou conjuntos de unidades de um 
sistema. É uma operação que exercita o módulo sob teste, envia valores (dados de entrada dos casos de 
teste), coleta e compara resultados.
Stubs: são implementações que simulam determinadas situações esperadas. Normalmente possuem a 
mesma assinatura dos métodos, funções ou rotinas que se deseja simular, porém retornam um compor-
tamento fixo determinado pelo desenvolvedor.
UI (User Interface): dispositivo pelo qual o usuário troca informações com o software. É o meio pelo qual 
o usuário comunica-se com o software.
Qualidade e testes de software | Unidade 6 - Fases ou níveis do teste de software
87
REFERÊNCIAS
ALBANO, Edson Lucas; AMARAL, Eduardo; BENITTI, Fabiane Barreto Vavassori, 2015. Teste de Integração. 
Disponível em: https://www.inf.ufsc.br/~fabiane.benitti/byebug/objetos/OA31/integracao/presentation_html5.html. 
Acesso em: 23 nov. 2019.
DELAMARO, Márcio Eduardo; MALDONADO, José Carlos; JINO, Mário. Introdução ao Teste de Software. 
2. ed. Rio de Janeiro: Campus - Elsevier, 2016.
LIMA, Dayvson. Entenda de uma vez por todas o que são testes unitários, para que servem e como fazê-los, 
2017. Disponível em: https://medium.com/@dayvsonlima/entenda-de-uma-vez-por-todas-o-que-s%C3%A3o-tes-
tes-unit%C3%A1rios-para-que-servem-e-como-faz%C3%AA-los-2a6f645bab3. Acesso em: 23 nov. 2019.
LOURENÇO, Marcelo. Teste de Integração, 2010. Disponível em: http://qualidade-de-software.blogspot.
com/2010/01/teste-de-integracao.html. Acesso em: 24 nov. 2019.
SOMMERVILLE, I. Engenharia de Software. Tradução Ivan Bosnic e Kalinga G. de O. Gonçalves. 9. ed. São 
Paulo: Pearson Prentice Hall, 2011.
https://www.inf.ufsc.br/~fabiane.benitti/byebug/objetos/OA31/integracao/presentation_html5.html
https://medium.com/@dayvsonlima/entenda-de-uma-vez-por-todas-o-que-são-testes-unitários-para-que-servem-e-como-fazê-los-2a6f645bab3
https://medium.com/@dayvsonlima/entenda-de-uma-vez-por-todas-o-que-são-testes-unitários-para-que-servem-e-como-fazê-los-2a6f645bab3
http://qualidade-de-software.blogspot.com/2010/01/teste-de-integracao.html
http://qualidade-de-software.blogspot.com/2010/01/teste-de-integracao.html
Qualidade e testes de software | Unidade 7 - Técnicas de teste de software
88
Unidade 7 Técnicas de teste de software
Objetivo de aprendizagem:
Apresentar técnicas de teste de software.
Tópicos de estudo:
• Técnicas de teste funcionais;
• Técnicas de teste estruturais;
• Técnicas de teste baseado em erros.
Iniciando os estudos:
Nesta unidade, você encontrará apoio para compreender as principais técnicas de teste de software e 
seus conceitos. A partir do conhecimento dessas técnicas, você será capaz de utilizá-las para o planeja-
mento de sessões de teste bem como de escolher a técnica que melhor se encaixará para o seu projeto 
de software.
Qualidade e testes de software | Unidade 7 - Técnicas de teste de software
89
1 TÉCNICAS DE TESTE FUNCIONAIS
As técnicas de teste funcionais, ou teste funcional, são conhecidas como teste caixa-preta. Essa alcunha 
surgiu porque nessa técnica o software em si é considerado uma caixa-preta e a sua implementação, 
seu código-fonte, não é conhecido. Para a realização dos testes nessa técnica, são fornecidos dados de 
entradas e as saídas produzidas pelo software são avaliadas para verificar se estão em conformidade 
com os objetivos especificados. O software é avaliado do ponto de vista do usuário.
De maneira geral, o teste funcional pode detectar todos os defeitos, uma vez que você pode submeter 
um programa ou sistema a todas as entradas possíveis, o que é denominado teste exaustivo (DELA-
MARO et. al., 2016 apud MAYERS et al., 2004). No entanto, o domínio de entrada pode ser infinito ou ainda 
muito grande, de modo a tornar o tempo da atividade de teste inviável, fazendo assim com que essa 
alternativa se torne impraticável. Essa limitação da atividade de teste, que não permite afirmar no geral 
que o programa esteja correto, fez com que fossem definidas as técnicas de teste e os diversos critérios 
pertencentes a cada uma delas. Assim, é possível conduzir essa atividade de maneira mais sistemática e, 
dependendo do critério utilizado, ter uma avaliação quantitativa da atividade de teste.
Figura 1 - Na técnica de teste funcional ou caixa-preta, o 
testador não possui conhecimento da implementação do 
software. Apenas são conhecidas as entradas fornecidas 
pelo usuário e as saídas produzidas pelo software.
ED+ Content Hub © 2019
Qualidade e testes de software | Unidade 7 - Técnicas de teste de software
90
Esse artigo apresenta um jogo utilizado para o ensino de teste funcional.
Título: Avaliando a viabilidade do BlackBox em sala de aula: um jogo sério 
para ensino de teste funcional de software
Link: https://br-ie.org/pub/index.php/sbie/article/view/7610/5406
Aprofunde-se
Acesse na plataforma o vídeo: Teste funcional ou caixa-preta
Assista
1.1 CRITÉRIOS DE TESTE FUNCIONAL
Os critérios mais conhecidos da técnica de teste funcional são Particionamento de equivalência, Análise do 
valor limite, Grafo causa-efeito e Error guessing. Além desses, também existem outros como, por exemplo, 
Teste funcional sistemático, Syntax testing, State transition testing e Graph matrix (DELAMARO et al., 2016). 
Como todos os critérios da técnica funcional baseiam-se apenas na especificação do produto testado, a 
qualidade de tais critérios depende diretamente da existência de uma boa especificação de requisitos.
Especificações ausentes ou mesmo incompletas tornarão difícil a aplicação dos critérios funcionais. 
Esses mesmos critérios também podem apresentar a limitação de não garantir que partes essenciais 
ou críticas do produto em teste sejam exercitadas. Por outro lado, os critérios funcionais podem ser 
aplicados em todas as fases de testes e em produtos desenvolvidos com qualquer paradigma de progra-
mação, pois não levam em consideração os detalhes de implementação.
https://br-ie.org/pub/index.php/sbie/article/view/7610/5406
Qualidade e testes de software | Unidade 7 - Técnicas de teste de software
91
1.1.1 PARTICIONAMENTO DE CLASSES DE 
EQUIVALÊNCIA
Esse critério divide o domínio de entrada de um programa em classes de equivalência a partir das quais 
os casos de teste são criados. Ele tem por objetivo minimizar o número de casos de teste, selecionando 
apenas um caso de teste de cada classe, pois a princípio todos os elementos de uma classe devem se 
comportar de maneira equivalente. Eventualmente, pode-se também considerar o domínio de saída 
para a definição das classes de equivalência (NETO, 2007 apud ROCHA et al., 2001). Uma classe de equi-
valência representa um conjunto de estados válidos e inválidos para uma determinada condição de 
entrada. Tipicamente uma condição de entrada pode ser um valor numérico específico, uma faixa de 
valores, um conjunto de valores relacionados ou, ainda, uma condição lógica. As seguintes diretrizes 
podem ser aplicadas:
• Se uma condição de entrada especifica uma faixa de valores ou requer um valor espe-
cífico, uma classe de equivalência válida (dentro do limite) e duas inválidas (acima e 
abaixo dos limites) são definidas.
• Se uma condiçãode entrada especifica um membro de um conjunto ou lógica, uma 
classe de equivalência válida e uma inválida são definidas.
Você deve seguir tais passos para geração dos testes usando estes critérios:
• Identificar classes de equivalência (um processo heurístico):
• Condição de entrada;
• Se são válidas e inválidas.
• Definir os casos de teste:
• Enumerar as classes de equivalência;
• Casos de teste para as classes válidas;
• Casos de teste para as classes inválidas.
Barbosa et al. (2000) apresenta a aplicação do critério de Particionamento por equivalência utilizando um 
programa que verifica se uma cadeia de caracteres é um identificador de variáveis válido ou não para a 
linguagem C. Para exemplificar o uso desse critério de teste, atente na descrição de um identificador na 
linguagem C:
“Um identificador válido deve começar com uma letra e conter apenas letras ou dígitos. Além disso, deve 
ter no mínimo um caractere e no máximo seis de comprimento. Exemplo: ‘abc12’ (válido), ‘cont*1’ (invá-
lido), ‘1soma’ (inválido) e ‘a123456’ (inválido)”.
O primeiro passo é a identificação das classes de equivalência. A tabela abaixo mostra essa identificação:
Qualidade e testes de software | Unidade 7 - Técnicas de teste de software
92
Encontradas as classes de equivalência, consegue-se definir quais serão os casos de teste necessários. 
Veja que, para ser válido, um identificador deve atender às condições (1), (3) e (5), portanto é preciso 
definir um caso de teste válido que cubra todas essas condições. Além disso, será necessário um caso 
de teste para cada classe inválida: (2), (4) e (6). Assim, o conjunto mínimo de casos de teste é composto 
por quatro elementos, sendo uma das opções possíveis: T0 = {(a1, Válido), (2B3, Inválido), (Z-12, Inválido), 
(A1b2C3d, Inválido)}.
1.1.2 ANÁLISE DO VALOR LIMITE
Por razões não completamente identificadas, um grande número de erros tende a ocorrer nos limites 
do domínio de entrada ao invés do “centro”. Esse critério de teste explora os limites dos valores de cada 
classe de equivalência para preparar os casos de teste, sendo um complemento do critério de Particio-
namento de classes de equivalência (PRESSMAN et al., 2016). Se uma condição de entrada especifica uma 
faixa de valores limitada em a e b, casos de teste devem ser projetados com valores a e b e imediata-
mente acima e abaixo de a e b. Exemplo: seja o seguinte intervalo igual a {1..10}. Os possíveis casos de 
teste são {1, 10, 0,11}. Como exemplo, veja a seguinte regra de negócio de um hipotético sistema que 
calcula descontos em planos de saúde:
O cálculo do desconto por dependente é feito da seguinte forma: a entrada é a idade do dependente 
que deve estar restrita ao intervalo [0..24]. Para dependentes até 12 anos (inclusive) o desconto é 
de 15%. Entre 13 e 18 (inclusive) o desconto é de 12%. Dos 19 aos 21 (inclusive) o desconto é de 5%, 
e dos 22 aos 24 de 3% (BARBOSA et al., 2000).
Considerando a descrição dessa regra, se você aplicar o teste de valor limite você poderá obter casos de 
teste semelhantes a esses:
{-1,0,12,13,18,19,21,22,24,25}.
Tabela 1 - Classes de equivalência para o 
programa que verifica identificadores.
Fonte: Neto (2007).
Qualidade e testes de software | Unidade 7 - Técnicas de teste de software
93
Título: Casos de teste funcional de software
Acesso em: 12/12/2019.
Disponível em: https://youtu.be/Z8n5wxIXQ8o
Aprofunde-se
1.1.3 TESTE FUNCIONAL SISTEMÁTICO
Esse critério é uma combinação dos critérios Particionamento de equivalência e Análise do valor limite 
(DELAMARO et al., 2016). Uma vez que os domínios de entrada e de saída foram particionados, esse 
critério requer no mínimo dois casos de teste de cada partição para minimizar o problema de que 
defeitos coincidentes ocultem falhas. Ele também requer a avaliação no limite de cada partição e subse-
quente a ele. Para facilitar a identificação desses casos de teste, o critério fornece as seguintes diretrizes:
A. Valores numéricos
Para o domínio de entrada, selecionar os seguintes valores:
(a) Valores discretos: testar todos os valores;
(b) Intervalo de valores: testar os extremos e um valor no interior do intervalo.
Para o domínio de saída, selecionar valores de entrada que resultem nos valores de saída que 
devem ser gerados pelo software. Os tipos das saídas podem não coincidir com os tipos dos 
valores de entrada. Por exemplo, valores de entrada distintos podem produzir um intervalo de 
valores de saída, dependendo de outros fatores, ou um intervalo de valores de entrada pode 
produzir somente um ou dois valores de saída como verdadeiro e falso. Portanto, os valores 
de saída devem ser escolhidos da seguinte forma:
(a) Valores discretos: gerar cada um deles;
(b) Intervalo de valores: gerar cada um dos extremos e ao menos um valor no interior 
do intervalo.
B. Tipos de valores diferentes e casos especiais
Tipos de valores diferentes devem ser utilizados na entrada e na saída como, por exemplo, um 
espaço em branco, que pode ser interpretado como zero em um campo que aceite números. 
Casos especiais como zero sempre devem ser selecionados individualmente, mesmo que ele 
esteja dentro de um intervalo de valores. O mesmo serve para valores nos limites da repre-
sentação binária dos dados. Por exemplo, para campos inteiros de 16 bits, os valores -32768 e 
+32767 deveriam ser selecionados.
https://youtu.be/Z8n5wxIXQ8o
Qualidade e testes de software | Unidade 7 - Técnicas de teste de software
94
C. Valores ilegais
Valores que correspondem a entradas ilegais (entradas não permitidas pelo software) também 
devem ser incluídos nos casos de teste para se certificar que o software os rejeita. Deve-se 
também tentar utilizar valores ilegais que não sejam bem-sucedidos. É importante que sejam 
selecionados os limites dos intervalos numéricos, tanto inferiores quanto superiores, valores 
imediatamente fora dos limites desses intervalos e também os valores imediatamente subse-
quentes aos limites do intervalo e pertencentes a ele.
D. Números reais
Valores reais envolvem adicionar novos problemas, além de problemas similares aos valores 
inteiros, uma vez que na entrada são apresentados como números decimais, no processa-
mento são armazenados na forma binária e na saída são convertidos em decimais novamente. 
Verificar o limite para números reais pode não ser exato, mas, ainda assim, essa verificação 
deve ser incluída como caso de teste. Deve ser definida uma margem de erro de tal forma que, 
se ultrapassada, então o valor pode ser considerado distinto. Além disso, devem ser selecio-
nados números reais bem pequenos e também o zero.
E. Intervalos variáveis
Acontece quando o intervalo de uma variável depende do valor de outra variável. Suponha que 
o valor da variável x pode variar de zero ao valor da variável y e que y é um inteiro positivo. 
Nesse caso, os seguintes dados de entrada devem ser definidos:
1. i) x = y = 0;
2. ii) x = 0 < y;
3. iii) 0 < x = y;
4. iv) 0 < x < y.
Os valores ilegais também devem ser selecionados:
1. y = 0 < x;
2. 0 < y < x;
3. x < 0; e 
4. y < 0.
F. Arranjos (Arrays)
Quando se usa um arranjo, tanto como entrada quanto saída, deve-se considerar o fato de o 
tamanho do arranjo ser variável bem como os dados também serem variáveis. Os elementos 
do arranjo devem ser testados como se fossem variáveis comuns, como mencionado nos itens 
anteriores. Além disso, o tamanho do arranjo deve ser testado com valores intermediários, 
com os valores mínimo e máximo. Para simplificar o teste, podem-se considerar as linhas e 
colunas de um arranjo como se fossem subestruturas a serem testadas separadamente. Assim, 
o arranjo deve ser testado primeiro como uma única estrutura, depois como uma coleção de 
subestruturas e cada subestrutura deve ser testada independentemente.
Qualidade e testes de software | Unidade 7 - Técnicas de teste de software
95
G. Texto ou string
Nesse caso, o dado de entrada deve explorar comprimentos variáveis e também validar os 
caracteresque o compõe, pois algumas vezes o dado de entrada pode ser apenas alfabético, 
ou alfanumérico, e outras pode possuir caracteres especiais.
Além desses casos, o critério funcional sistemático requer que dois elementos de uma mesma classe de 
equivalência sejam explorados para evitar erros do seguinte tipo: imagine que um programa receba um 
valor de entrada e produza o quadrado desse valor. Se o valor de entrada for 2 e o valor produzido como 
saída for 4, embora o resultado esteja correto, ainda assim não se pode afirmar qual das operações o 
programa realizou, pois poderia ser 2 * 2 como também 2 + 2.
1.1.4 GRAFO CAUSA-EFEITO
Esse critério de teste checa o efeito combinado de dados de entrada. As causas (condições de entrada) 
e os efeitos (ações) são identificados e combinados em um grafo a partir do qual é montada uma tabela 
de decisão e, a partir dessa, são derivados os casos de teste e as saídas (NETO, 2007 apud ROCHA et 
al., 2001). Esse critério é baseado em quatro passos. Para exemplificar esses passos, atente em outro 
exemplo extraído de Barbosa et al. (2000):
“Em um programa de compras pela internet, a cobrança ou não do frete é definida seguindo tal regra: 
se o valor da compra for maior que R$60,00 e foram comprados menos que três produtos, o frete é 
gratuito. Caso contrário, o frete deverá ser cobrado”.
1. Para cada módulo, causas (condições de entrada) e efeitos (ações realizadas às dife-
rentes condições de entrada) são relacionados, atribuindo-se um identificador para 
cada um.
• Causa: valor da compra > 80 e #produtos < 3
• Efeito: frete grátis.
2. Em seguida, um grafo de causa-efeito (árvore de decisão) é desenhado como na figura 
abaixo:
Qualidade e testes de software | Unidade 7 - Técnicas de teste de software
96
3. Nesse ponto, o grafo é transformado em uma tabela de decisão, como exemplificado 
na tabela abaixo:
4. As regras da tabela de decisão são, então, convertidas em casos de teste.
Para a elaboração dos casos de teste, você deve seguir todas as regras extraídas da tabela. Esse 
critério deve ser combinado a outros já apresentados em tópicos anteriores para a criação de 
casos de teste válidos (extraídos das regras) e inválidos (valores fora da faixa definida). Os 
casos de teste que refletem somente as regras extraídas da tabela de decisão são os seguintes:
(valor, qtd produtos, resultado esperado) =
{ (61,2,“frete grátis”);
(61,3,“cobrar frete”);
(60, qualquer quantidade,“cobrar frete”) }.
Figura 2 - Árvore de decisão - grafo de causa-efeito.
Fonte: Neto (2007).
Tabela 2 - Tabela de decisão para programa de 
compra pela internet.
Fonte: Neto (2007).
Qualidade e testes de software | Unidade 7 - Técnicas de teste de software
97
1.1.5 ERROR GUESSING
Essa técnica corresponde a uma abordagem ad-hoc, na qual é praticada por uma pessoa, inconscien-
temente, para projeto de casos de teste, supondo por intuição e experiência alguns tipos prováveis de 
erros e, a partir disso, definem-se casos de teste que poderiam detectá-los (DELAMARO et al., 2016). A 
ideia do critério é enumerar possíveis erros ou situações sujeitas a erros e então definir casos de teste 
para explorá-los. Por exemplo, se o que está sendo testado é um módulo de ordenação de um programa, 
as seguintes situações poderiam ser exploradas:
1. Uma lista de entrada vazia;
2. Uma lista com apenas uma entrada;
3. Todas as entradas com o mesmo valor; 
4. Uma lista de entrada já ordenada.
2 TÉCNICAS DE TESTE ESTRUTURAIS
A técnica estrutural (ou caixa-branca ou ainda teste caixa de vidro) estabelece os requisitos de teste com 
base na implementação fornecida de um programa, requerendo a execução de partes ou de compo-
nentes do programa. Os caminhos lógicos do software são testados, fornecendo-se casos de teste que 
colocam à prova tanto conjuntos específicos de condições e/ou laços, quanto pares de definições e usos 
de variáveis.
Figura 3 - Conceito do teste estrutural: construir casos 
de teste baseados na implementação do software.
ED+ Content Hub © 2019
Qualidade e testes de software | Unidade 7 - Técnicas de teste de software
98
Em linhas gerais, usando métodos de teste de caixa-branca, o engenheiro de software pode criar casos 
de teste que: (1) garantam que todos os caminhos independentes de um módulo foram exercitados 
pelo menos uma vez; (2) exercitam todas as decisões lógicas nos seus estados verdadeiro e falso; (3) 
executam todos os ciclos em seus limites e dentro de suas fronteiras operacionais; e (4) exercitam estru-
turas de dados internas para assegurar a sua validade (PRESSMAN; MAXIM, 2016).
Os critérios pertencentes à técnica estrutural são classificados com base na complexidade, no fluxo de 
controle e no fluxo de dados. A técnica estrutural apresenta uma série de limitações e desvantagens 
decorrentes das limitações inerentes à atividade de teste de programa como estratégia de validação. 
Tais aspectos introduzem sérios problemas na automatização do processo de validação de software 
(DELAMARO et al., 2016):
• Não existe um procedimento de teste de propósito geral que possa ser usado para 
provar a correção de um programa;
• Dados dois programas, é indecidível se eles computam a mesma função;
• É indecidível, em geral, se dois caminhos de um programa, ou de programas diferentes, 
computam a mesma função;
• É indecidível, em geral, se um dado caminho é executável, ou seja, se existe um 
conjunto de dados de entrada que leve à execução desse caminho.
Existem também limitações que são inerentes à técnica estrutural:
• Caminhos ausentes: se o programa não implementa algumas funções, não existirá 
um caminho que corresponda a essas mesmas funções; consequentemente, nenhum 
dado de teste será requerido para exercitá-las.
• Correção coincidente: o programa pode apresentar, coincidentemente, um resultado 
correto para um dado em particular de entrada, satisfazendo um requisito de teste 
e não revelando a presença de um defeito; entretanto, se escolhido outro dado de 
entrada, o resultado obtido poderia ser incorreto.
Independentemente dessas desvantagens, a técnica estrutural é vista como complementar às demais 
técnicas de teste existentes, uma vez que cobre classes distintas de defeitos. De fato, os conceitos e 
experiências obtidos com o teste estrutural podem ser abstraídos e incorporados às demais técnicas e, 
ainda, as informações obtidas pela aplicação de critérios estruturais têm sido consideradas relevantes 
para as atividades de manutenção, depuração e avaliação da confiabilidade de software.
Qualidade e testes de software | Unidade 7 - Técnicas de teste de software
99
2.1 CRITÉRIOS DO TESTE ESTRUTURAL
Os critérios estruturais são, em geral, classificados em:
• Critérios baseados na complexidade;
• Critérios baseados em fluxo de controle;
• Critérios baseados em fluxo de dados.
A seguir são apresentados e discutidos os principais critérios de teste associados a cada uma dessas 
classes, em nível de unidade.
2.1.1 CRITÉRIOS BASEADOS NA COMPLEXIDADE
Os critérios baseados na complexidade utilizam informações sobre a complexidade de um programa 
para derivar os casos de teste. Um critério bastante conhecido dessa classe é o critério de McCabe (ou 
teste de caminho básico), que utiliza a complexidade ciclomática de um Grafo de Fluxo de Controle 
(GFC – veja um exemplo na figura abaixo) para derivar os casos de teste. A complexidade ciclomática 
é uma métrica de software que proporciona uma medida quantitativa da complexidade lógica de um 
programa. Utilizado no contexto do teste de caminho básico, o valor da complexidade ciclomática esta-
belece o número de caminhos linearmente independentes do conjunto básico de um programa, ofere-
cendo um limite máximo para o número de casos de teste que devem ser derivados a fim de garantir 
que todas as instruções sejam executadas pelo menos uma vez (DELMARARO et al., 2016).
Figura 4: Exemplo de Grafo de Fluxo de Controle (GFC).
Fonte: adaptado de Delamaro et al. (2016).
Qualidade e testes de software| Unidade 7 - Técnicas de teste de software
100
Acesse na plataforma o vídeo: Grafo de Fluxo de Controle
Assista
Um caminho linearmente independente é qualquer caminho do programa que introduza pelo menos 
um novo conjunto de instruções de processamento ou uma nova condição. Quando estabelecido em 
termos de um GFC, um caminho linearmente independente deve incluir pelo menos um arco que não 
tenha sido atravessado antes que o caminho seja definido. Assim, cada novo caminho introduz um arco. 
Caminhos linearmente independentes estabelecem um conjunto básico para o GFC.
Ou seja, se casos de teste puderem ser projetados a fim de forçar a execução desses caminhos (um 
conjunto básico), cada instrução do programa terá a garantia de ser executada pelo menos uma vez e 
cada condição terá sido executada com verdadeiro e falso. Observe que o conjunto básico não é único. 
Podem existir diferentes conjuntos básicos derivados para um determinado GFC. Para saber quantos 
caminhos devem ser procurados, é necessário calcular a complexidade ciclomática V (G), que pode ser 
computada de três maneiras (DELMARARO et al., 2016):
1. O número de regiões em um GFC. Uma região pode ser informalmente descrita como 
uma área inclusa no plano do grafo. O número de regiões é computado contando-se 
todas as áreas delimitadas e a área não delimitada fora do grafo; ou
2. V (G) = E − N + 2, tal que E é o número de arcos e N é o número de nós do GFC G; ou
3. V (G) = P + 1, tal que P é o número de nós-predicativos (nós-predicativos são aqueles que 
podem desviar o fluxo da execução: if, while, switch etc.) contido no GFC G.
O valor da complexidade ciclomática V (G) oferece um limite máximo para o número de caminhos linear-
mente independentes que constitui o conjunto básico e, consequentemente, um limite máximo do 
número de casos de teste que deve ser projetado e executado para garantir a cobertura de todas as 
instruções de programa. Segundo Pressman e Maxim (2016), visto que o número de regiões aumenta 
conforme o número de caminhos de decisão e laços, a métrica de McCabe acaba por oferecer uma 
medida quantitativa da dificuldade de conduzir os testes e uma indicação da confiabilidade final.
Qualidade e testes de software | Unidade 7 - Técnicas de teste de software
101
2.1.2 CRITÉRIOS BASEADOS EM FLUXO DE CONTROLE
Os critérios baseados em fluxo de controle utilizam apenas características de controle da execução do 
programa, como comandos ou desvios, para determinar quais estruturas são necessárias. Os critérios 
mais conhecidos dessa classe são:
• Todos-nós: exige que a execução do programa passe, ao menos uma vez, em cada vértice 
do GFC, ou seja, que cada comando do programa seja executado pelo menos uma vez.
• Todas-arestas (ou Todos-arcos): requer que cada aresta do grafo, isto é, cada desvio 
de fluxo de controle do programa, seja exercitado pelo menos uma vez;
• Todos-caminhos: requer que todos os caminhos possíveis do programa sejam execu-
tados.
Ressalta-se que a cobertura do critério Todos-nós é o mínimo esperado de uma boa atividade de teste, 
pois, do contrário, o programa testado é entregue sem a certeza de que todos os comandos presentes 
foram executados ao menos uma vez.
Além disso, apesar de desejável, executar todos os caminhos de um programa é, na maioria dos casos, 
uma tarefa impraticável. Isso se deve ao fato de que, na presença de laços, o número de caminhos de um 
programa pode ser muito grande ou até mesmo infinito. Essa foi uma das motivações para a introdução dos 
critérios baseados em fluxo de dados (DELAMARO et al., 2016), que serão apresentados no próximo tópico.
Título: Teste de software: técnica de teste de caixa-branca
Acesso em: 12/12/2019.
Disponível em: https://youtu.be/UtN4BGK82Ew
Aprofunde-se
https://youtu.be/UtN4BGK82Ew
Qualidade e testes de software | Unidade 7 - Técnicas de teste de software
102
2.1.3 CRITÉRIOS BASEADOS EM FLUXO DE DADOS
Os critérios baseados em fluxo de dados utilizam a análise de fluxo de dados como fonte de informação 
para derivar os requisitos de teste. Uma característica comum aos critérios dessa categoria é que eles 
requerem o teste das interações que envolvam definições de variáveis e referências posteriores a essas 
definições. Uma motivação para a introdução dos critérios baseados em fluxo de dados foi a indicação 
de que, mesmo para programas pequenos, o teste baseado unicamente no fluxo de controle não era 
eficaz para revelar a presença mesmo de defeitos simples e triviais. Nesse sentido, a introdução dessa 
classe de critérios procurou estabelecer uma hierarquia entre os critérios Todas-arestas e Todos-cami-
nhos, visando tornar o teste estrutural mais rigoroso.
De acordo com Delamaro et al. (2016 apud URAL, 1988), critérios baseados em fluxo de dados são mais 
adequados para certas classes de defeitos, tais como defeitos computacionais, uma vez que dependências 
de dados são identificadas e, portanto, segmentos funcionais são requeridos como requisitos de teste.
Entre os principais critérios baseados em fluxo de dados que você encontrará, têm-se os critérios de 
Rapps e Weyuker (DELAMARO et al., 2016). Esses critérios são caracterizados pelo uso de um Grafo 
Def-Uso, que consiste em uma extensão de um CFG. Nesse grafo estendido, são adicionadas informa-
ções a respeito do fluxo de dados do programa, caracterizando associações entre pontos nos quais esse 
valor é utilizado (referência ou uso de variável). Os casos de teste são determinados com base nessas 
associações. Outro critério que pode ser encontrado é o dos Potenciais-usos. De maneira geral, esses 
critérios requerem associações independentemente da ocorrência explícita de uma referência (um uso) 
a uma definição de variável. Portanto, se essa definição tiver um uso definido (há um caminho livre de 
definição até certo nó ou arco, isto é, um Potencial-uso), a Potencial-associação entre a definição e o 
Potencial-uso é caracterizada e eventualmente requerida.
Este artigo investiga critérios estruturais, com foco no software livre e em 
aumentar a confiança nesses produtos.
Título: Qualidade de conjuntos de teste de software de código aberto: uma 
análise baseada em critérios estruturais
Link: https://bit.ly/36zEZmf
Aprofunde-se
https://bit.ly/36zEZmf
Qualidade e testes de software | Unidade 7 - Técnicas de teste de software
103
3 TÉCNICAS DE TESTE BASEADO EM ERROS
Nessa técnica são utilizados defeitos típicos do processo de implementação de software para que sejam 
derivados os requisitos de teste. Um critério conhecido dentro dessa técnica é o teste de mutação ou 
análise de mutante. No caso do teste de mutação, o programa que está sendo testado é alterado diversas 
vezes, criando-se um conjunto de programas alternativos conhecidos como mutantes, como se defeitos 
estivessem sendo inseridos no programa original. O trabalho do testador é escolher casos de teste que 
mostrem a diferença de comportamento entre o programa original e os programas mutantes.
Assim como nas demais técnicas, cada mutante determina um subdomínio do domínio de entrada, 
formado por aqueles dados capazes de distinguir o comportamento do programa original e do mutante. 
A diferença, nesse caso, é que cada subdomínio está claramente relacionado com a capacidade de 
revelar um defeito específico. Por fim, a partir da “hipótese do programador competente” e do “efeito de 
acoplamento”, pode-se argumentar que um conjunto de casos de teste capaz de distinguir um conjunto 
de mutantes escolhido de forma criteriosa, e que represente boa parte dos defeitos mais comuns, seria 
capaz de revelar, também, outros tipos de defeitos (DELAMARO et al., 2016).
A “hipótese do programador competente” diz que 
programadores experientes escrevem programas corretos ou 
bem próximos dos corretos. Já o “efeito de acoplamento” diz 
que casos de teste capazes de revelar erros simples são tão 
sensíveis que, implicitamente, também são capazes de revelar 
erros mais complexos.
Reflita
Título: Teste de mutantesAcesso em: 12/12/2019.
Disponível em: https://youtu.be/LfC4j7qq1Sg
Aprofunde-se
 
https://youtu.be/LfC4j7qq1Sg
Qualidade e testes de software | Unidade 7 - Técnicas de teste de software
104
Infográfico 1 - Como se configura o teste de mutação.
Fonte: adaptado de Delamaro et al. (2016).
Qualidade e testes de software | Unidade 7 - Técnicas de teste de software
105
Este artigo apresenta os resultados de um experimento baseado no teste 
de mutação.
Título: Equivalência de programas e o teste de software: resultados de um 
experimento de aplicação do critério análise de mutantes
Link: https://www.inf.pucrs.br/~zorzo/iiiwtf/camera/m.pdf
Aprofunde-se
Acesse na plataforma o vídeo: Análise de mutantes - mutante
Assista
https://www.inf.pucrs.br/~zorzo/iiiwtf/camera/m.pdf
Qualidade e testes de software | Unidade 7 - Técnicas de teste de software
106
CONSIDERAÇÕES FINAIS
Esta unidade trouxe até você o conceito e técnicas do teste de software, uma atividade fundamental 
para a busca de qualidade em um produto de software – objetivo primordial da engenharia de software.
Entre as técnicas apresentadas, destaco a você a técnica funcional (caixa-preta), baseada nas possí-
veis entradas de um software e as saídas que ele produz; a técnica estrutural (caixa-branca), que exige 
do testador o conhecimento estrutural do software, ou seja, sua implementação; e, por fim, a técnica 
baseada em erros, o teste de mutação, que cria a partir do código-fonte original versões alteradas a 
partir dos erros mais comuns cometidos pelos desenvolvedores.
Qualidade e testes de software | Unidade 7 - Técnicas de teste de software
107
GLOSSÁRIO
Ad-hoc: significa “para esta finalidade”, “para isso” ou “para este efeito”. É uma expressão latina, geral-
mente usada para informar que determinado acontecimento tem caráter temporário e que se destina 
para aquele fim específico. Um exame ad-hoc, um método ad-hoc, um cargo ou uma função ad-hoc são 
exemplos que definem a criação de algo provisório, que vai atender apenas determinado propósito.
Complexidade ciclomática (ou complexidade condicional): é uma métrica de software usada para 
indicar a complexidade de um programa de computador. Mede a quantidade de caminhos de execução 
independentes a partir de um código-fonte.
GFC (Grafo de Fluxo de Controle ou Grafo de Programa): um programa P pode ser decomposto em 
um conjunto de blocos disjuntos de comandos. A execução do primeiro comando de um bloco acarreta 
a execução de todos os outros comandos desse bloco na ordem dada. Todos os comandos de um bloco, 
possivelmente com exceção do primeiro, têm um único predecessor e exatamente um único sucessor, 
exceto possivelmente o último comando.
Qualidade e testes de software | Unidade 7 - Técnicas de teste de software
108
REFERÊNCIAS
BARBOSA, Ellen Francine et al. Introdução ao teste de software, 2000. Disponível em: https://www.
researchgate.net/publication/306255146_INTRODUCAO_AO_TESTE_DE_SOFTWARE Acesso em: 3 fev. 2020.
DELAMARO, Márcio Eduardo; MALDONADO, José Carlos; JINO, Mário. Introdução ao Teste de Software. 
2. ed. Rio de Janeiro: Campus - Elsevier, 2016.
NETO, Arilo. Introdução a teste de software. Engenharia de Software Magazine, v. 1, p. 22, 2007. Dispo-
nível em: https://www.researchgate.net/profile/Arilo_Neto/publication/266356473_Introducao_a_Teste_de_
Software/links/5554ee6408ae6fd2d821ba3a/Introducao-a-Teste-de-Software.pdf. Acesso em: 17 dez. 2019.
PRESSMAN, Roger S.; MAXIM, Bruce R. Engenharia de Software - uma abordagem profissional. 8. ed. 
Porto Alegre: Amgh Editora, 2016.
https://www.researchgate.net/publication/306255146_INTRODUCAO_AO_TESTE_DE_SOFTWARE
https://www.researchgate.net/publication/306255146_INTRODUCAO_AO_TESTE_DE_SOFTWARE
https://www.researchgate.net/profile/Arilo_Neto/publication/266356473_Introducao_a_Teste_de_Software
https://www.researchgate.net/profile/Arilo_Neto/publication/266356473_Introducao_a_Teste_de_Software
Qualidade e testes de software | Unidade 8 - Outros aspectos do teste de software
109
Unidade 8 Outros aspectos do teste de software
Objetivo de aprendizagem:
Apresentar outros aspectos do teste de software, novas técnicas, abordagens e ferramentas.
Tópicos de estudo:
• Outras técnicas de teste de software;
• TDD;
• Automatização.
Iniciando os estudos:
Nesta unidade, você conhecerá outras técnicas e demais aspectos, como automatização que envolvem 
a atividade de teste de software. Novas técnicas serão apresentadas, inclusive uma técnica que permite 
que desenvolvimento e testes sejam conciliados para facilitar a construção de um sistema de software.
Qualidade e testes de software | Unidade 8 - Outros aspectos do teste de software
110
1 OUTRAS TÉCNICAS DE TESTE DE SOFTWARE
Além das técnicas de testes encontradas na literatura como particionamento de classes de equivalência 
ou a técnica de análise de mutantes (DELAMARO et al., 2016), existem outras técnicas que são utilizadas 
no dia a dia de empresas que produzem software. Neste tópico, você conhecerá em detalhes alguma das 
técnicas mais utilizadas.
1.1 TESTE DE PERFORMANCE
O teste de performance se divide em três tipos: teste de carga (testa o software sob as condições normais 
de uso. Exemplos: tempo de resposta, número de transações por minuto, usuários simultâneos etc.); 
teste de stress (testa o software sob condições extremas de uso, como grande volume de transações 
e usuários simultâneos. Considera-se também a situação na qual ocorrem picos excessivos de carga 
em curtos períodos de tempo); e teste de estabilidade (testa se o sistema se mantém funcionando de 
maneira satisfatória após um período de uso) (DRATOVSKY, 2017).
Te
m
po
 d
e 
re
sp
os
ta
Carga
0 segundos
Experiência aceitável
Experiência questionável
Experiência inaceitável
Crise
? segundos
? segundos
? segundos
Figura 1 - Gráfico que representa o teste de performance.
Fonte: adaptado de Prime Control (2019).
ED
+ 
Co
nt
en
t H
ub
 ©
 2
01
9
Qualidade e testes de software | Unidade 8 - Outros aspectos do teste de software
111
A figura acima ilustra como é realizada uma parte dos testes de performance. Para cada volume de 
acessos, é medido o tempo de resposta. Os critérios de aceitação são então estabelecidos de acordo 
com o tipo do projeto e com a necessidade do demandado pelo cliente.
De modo geral, o teste de performance é organizado da seguinte maneira:
• Em conjunto com o cliente, são mapeadas as principais operações realizadas nos 
sistemas e identificadas as que exigem mais recursos.
• Na etapa seguinte, são criados scripts de automação que simularão as operações simul-
tâneas de diversos usuários. Tais scripts serão executados estrategicamente, podendo 
focar na performance da aplicação, do banco de dados, do ambiente ou das redes.
• Novamente junto ao cliente, com base preferencialmente nas estatísticas de uso 
anteriores, é estimado o volume de acesso esperado nos picos, estabelecendo uma 
referência. Os testes simularão uma quantidade igual, inferior e superior à referência, 
medindo o tempo de resposta dos sistemas em cada cenário.
Neste artigo, os autores fazem a proposta de uma abordagem para o teste 
de performance em aplicações distribuídas desde os estágios iniciais do 
desenvolvimento, baseados nos middlewares existentes na composição 
desse tipo de software.
Título do artigo: Early performance testing of distributed software 
applications
Link: https://discovery.ucl.ac.uk/id/eprint/871/1/3.6_paper.pdf
Aprofunde-se
Dessa forma, os administradores terão uma visão bastante confiável da carga suportada pelos seus 
sistemas e infraestrutura. Poderão inclusive utilizar os resultados como base de comparação para a 
implantação de atualizações e melhorias (PRIME CONTROL, 2019).
A empresa Testar.me possui um processo específico para o teste de 
performance, onde é possível encontrar desde o planejamento do 
mesmo até sua execução. Veja mais detalhes em: https://www.testar.me/
teste-de-performance
Reflita
https://discovery.ucl.ac.uk/id/eprint/871/1/3.6_paper.pdfhttps://www.testar.me/teste-de-performance
https://www.testar.me/teste-de-performance
Qualidade e testes de software | Unidade 8 - Outros aspectos do teste de software
112
1.2 TESTE DE CONFIGURAÇÃO
O teste de configuração ou de instalação verifica o comportamento do sistema em diferentes configura-
ções de software e hardware. Testa se o software funciona no hardware a ser instalado e sob diferentes 
condições (DRATOVSKY, 2017).
Em relação à questão envolvendo software, pontos que podem ser abordados:
• Sistema operacional: se o software possui como requisito ser executado em sistemas 
operacionais diferentes como Windows, Linux ou Unix, é necessário configurá-lo e 
executá-lo em todos eles.
• Bibliotecas: se o software utiliza alguma biblioteca de desenvolvimento ou API, é 
necessário checar sua compatibilidade em relação a diferentes versões existentes.
• Navegadores: se o sistema testado é uma aplicação web, é necessário checar sua 
execução em diferentes navegadores.
Quanto ao hardware, os seguintes pontos podem ser questionados:
• Processador: se o software executa tarefas críticas, verificar se o processador é capaz 
de suprir o processamento necessário.
• Memória: verificar se a memória que existe no ambiente onde o software será utili-
zado é suficiente e não provoque lentidão.
• Espaço em disco: verificar se o espaço disponível no ambiente é capaz de permitir a 
instalação do software.
• Rede: se o software funcionará em um ambiente seja de uma rede corporativa (intranet) 
ou uma rede aberta (internet), verificar se há conectividade para os recursos existentes.
Acesse na plataforma o vídeo: Testes além do código
Assista
Qualidade e testes de software | Unidade 8 - Outros aspectos do teste de software
113
1.3 TESTE DE USABILIDADE
O teste de usabilidade valida atributos que evidenciam o esforço necessário para utilizar o produto. Em 
geral são considerados os seguintes aspectos:
• Fatores humanos: verifica a curva de aprendizagem, o quão fácil ou difícil é para um 
software ser aprendido.
• Estéticos ou de interface: verifica se a utilização de cores, utilização de fontes com 
boa legibilidade, consistência da interface (elementos são parecidos entre si, botões 
aparecem sempre na mesma ordem) ajudam ou interferem na utilização do software.
• Documentação: verifica se há documentação disponível (online, impressa) para os usuá-
rios e permite então, que os mesmos possam utilizar o software de maneira autônoma.
Decorrente dos aspectos relacionados, você pode encontrar como exemplo de um problema de usabi-
lidade determinadas circunstâncias quando uma característica do sistema ocasiona perda de tempo, 
compromete a qualidade da tarefa ou mesmo inviabiliza sua realização, aborrecendo o usuário da apli-
cação. Geralmente um problema de usabilidade pode decorrer de um problema de ergonomia. Por sua 
vez, problemas de ergonomia decorrem de aspectos da interface que tornam a operação do sistema 
desagradável, ineficiente, custosa ou impossível para um usuário típico (um usuário que tenha recebido 
treinamento básico para a operação do software e possua conhecimento da operação de um compu-
tador) em uma situação típica (tarefa cotidiana para executar o trabalho do usuário) (WITCZAK et al., 2009).
Esse artigo, focado na área de Interação Homem-Computador, aborda oito 
fatores humanos para diferentes tipos de teste de usabilidade.
Título do artigo: A proposed index of usability: a method for comparing 
the relative usability of different software systems
Link: https://bit.ly/3baTfoK
Aprofunde-se
https://bit.ly/3baTfoK
Qualidade e testes de software | Unidade 8 - Outros aspectos do teste de software
114
2. TDD
O TDD (do inglês Test-Driven Development), desenvolvimento orientado a testes, é uma técnica para 
o desenvolvimento de software na qual você mescla a escrita de testes e a codificação do software em 
si. Basicamente, você escreve seu código de forma incremental (cada funcionalidade do software, por 
exemplo) ao mesmo tempo que escreve outro código que testa a funcionalidade codificada. Você não 
inicia a escrita da próxima funcionalidade até que o código escrito passe no teste (no código que testa a 
funcionalidade implementada) (SOMMERVILLE, 2011).
Essa técnica de desenvolvimento foi introduzida como parte de métodos ágeis de desenvolvimento como 
a Programação Extrema (Extreme Programming). Entretanto, pode ser utilizada com outros processos 
de desenvolvimento de software.
Acesse na plataforma o vídeo: O processo do TDD
Assista
Processo básico do TDD
O desenvolvimento orientado a testes é um processo que envolve a alternância da escrita de testes e a escrita do 
próprio código-fonte do software. Veja abaixo.
 Escreva um 
teste (automatizado) 
para essa
funcionalidade.
 Executa o teste. 
Como a funcionalidade 
ainda não foi codificada, 
o teste na primeira 
execução falhará.
 Você então implementa 
a funcionalidade e executa o 
teste novamente para 
verificar se as condições do 
teste foram satisfeitas. Se 
necessário, refatore o código 
e repete-se esse ciclo.
 Depois que todos 
os testes foram criados 
para a funcionalidade e 
executados com sucesso, 
você então estará apto 
para seguir com a 
implementação de novas
funcionalidades.
Identificar nova
funcionalidade
Implementar
funcionalidade
e refatorar
Escrever
teste
FalhaPassa
 Identifique a 
funcionalidade que se 
deseja implementar, de 
preferência que seja um 
incremento pequeno 
para seu software.
Executar
o teste
3 5421
Infográfico 1 - Como funciona o processo básico do TDD.
Fonte: adaptado de Sommerville (2011).
ED+ Content Hub © 2019
Qualidade e testes de software | Unidade 8 - Outros aspectos do teste de software
115
Um importante argumento sobre o TDD é que ele auxilia desenvolvedores a clarear suas ideias sobre o 
que um trecho de código deve fazer exatamente. Para escrever um teste, você deve entender para o que 
ele foi requisitado e esse entendimento torna mais fácil a escrita do código. Claro que se não existir a 
compreensão e o conhecimento a respeito dos requisitos, você será incapaz de escrever o código deman-
dado e a técnica de TDD não o ajudará. Por exemplo, se o seu software utiliza a operação matemática 
de divisão, é necessário checar se a divisão por zero não ocorre. Nesse caso, se a escrita de um teste for 
esquecida, então o código que checa dentro do programa a divisão por zero, nunca será implementado.
Segundo Sommerville (2011), além da melhor compreensão do problema a ser resolvido com o software, 
pode-se destacar os seguintes benefícios do TDD:
1. Cobertura de código: em princípio, todo segmento de código que você escreve deve 
ter pelo menos um teste associado. Portanto, você pode ter certeza de que todo o 
código no sistema foi realmente executado. Cada código é testado enquanto está sendo 
escrito; assim, os defeitos são descobertos no início do processo de desenvolvimento.
2. Teste de regressão: um conjunto de testes é desenvolvido de forma incremental 
enquanto um programa é desenvolvido. Você sempre pode executar testes de 
regressão para verificar se as mudanças no programa não introduziram novos bugs.
3. Depuração simplificada: quando um teste falha, a localização do problema deve ser 
óbvia. O código recém-escrito precisa ser verificado e modificado. Você não precisa 
usar as ferramentas de depuração para localizar o problema. Alguns relatos de uso 
de desenvolvimento dirigido a testes sugerem que quase nunca é necessário usar um 
sistema automatizado de depuração.
4. Documentação de sistema: os testes em si mesmos agem como uma forma de docu-
mentação que descreve o que o código deve fazer. Ler os testes pode tornar mais fácil 
a compreensão do código.
Título: TDD com Python
Acesso em: 21/12/2019.
Disponível em: https://youtu.be/M3zKKCJG71k
Aprofunde-se
Um dos benefícios mais importantes trazido pelo TDD é que ele reduz os custos dos testes de regressão. 
O teste de regressão envolve a execução de conjuntos de teste que tenham sidoexecutados com sucesso, 
após terem sido feitas alterações em um software. O teste de regressão verifica se essas mudanças não 
introduziram novos bugs no software e se o novo código interage com o código existente conforme o 
esperado. O teste de regressão é muito caro e geralmente impraticável quando um sistema é testado 
manualmente, pois os custos com o tempo e esforço são muito altos. Nessas situações, você precisa 
tentar escolher os testes mais relevantes para executar novamente – é fácil perder testes importantes. 
Vale ressaltar que testes automatizados reduzem drasticamente os custos com teste de regressão. Os 
testes existentes podem ser executados novamente de forma rápida e barata.
https://youtu.be/M3zKKCJG71k
Qualidade e testes de software | Unidade 8 - Outros aspectos do teste de software
116
TDD
Verde
Vermelho
Refatorar
1- Escreva
um teste
que falhe
2- Faça o
código funcionar3- Eliminarredundância
Por fim, outros aspectos podem ser observados em relação ao TDD:
• É útil para o desenvolvimento de software novos;
• Pode ser ineficaz para softwares que possuem multi-thread;
• Apesar da criação de teste, requer um processo para teste de sistemas;
• Tem-se mostrado como uma abordagem de sucesso para pequenas e médias empresas.
Título: Testes no NodeJS aplicando TDD com Jest
Acesso em: 21/12/2019.
Disponível em: https://youtu.be/2G_mWfG0DZE
Aprofunde-se
Figura 2 - O conceito do TDD: escreva um teste que 
falhe (vermelho), faça-o funcionar (verde) e o refatore, 
de modo que o teste sempre seja satisfatório.
Fonte: adaptado de http://bughuntinginbinary.com/?m=201404 
Acesso em: 14 jan. 2020.
ED+ Content Hub © 2019
https://youtu.be/2G_mWfG0DZE
http://bughuntinginbinary.com/?m=201404
Qualidade e testes de software | Unidade 8 - Outros aspectos do teste de software
117
3. AUTOMATIZAÇÃO
Neste tópico, você será apresentado a alguns exemplos de ferramentas e frameworks desenvolvidos 
que contribuem para a automatização da atividade de teste. A automatização da atividade de teste pode 
ser justificada pelas seguintes vantagens (CODE A TEST, 2016):
• Tarefas repetidas são possivelmente sujeitas a erro. É comum o testador ignorar 
ou esquecer parte do que precisa ser testado; isso não ocorre quando automatizamos, 
pois os passos descritos são seguidos à risca pelo computador.
• A capacidade de teste do ser humano é limitada. Se hoje um testador testa cinco 
funcionalidades por hora, é muito provável que amanhã ele continue testando a 
mesma quantidade nesse intervalo de tempo. Já a bateria de testes realizada por um 
computador (ou vários, pois você pode montar um cluster e paralelizar a execução) 
tem uma curva de crescimento muito mais acentuada.
• A regressão diminui com o uso de ferramentas automatizadas. A regressão ocorre 
quando novas funcionalidades de um sistema fazem com que funcionalidades preexis-
tentes deixem de funcionar. Nos testes manuais, principalmente em grandes sistemas, 
a regressão ocorre com alguma frequência, pois os testadores nem sempre conseguem 
testar todos os cenários possíveis. Já com os testes automatizados, isso diminui consi-
deravelmente já que ele executa sempre todos os testes: tanto os das novas funcio-
nalidades quanto os antigos. Assim, ele é capaz de pegar erros em testes antigos que 
podem ter sido gerados pela inclusão de novas funcionalidades.
Nos próximos tópicos, veja alguns exemplos de ferramentas utilizadas no dia a dia de muitas organiza-
ções que possuem o teste de software como prática no desenvolvimento de seus produtos.
Acesse na plataforma o vídeo: O processo do TDD
Assista
Qualidade e testes de software | Unidade 8 - Outros aspectos do teste de software
118
3.1 SELENIUM
O Selenium é um framework para a automatização de navegação web e utiliza as melhores técnicas dispo-
níveis para controlar remotamente navegadores e simular a interação do usuário com esse navegador.
Esse framework permite simular as atividades comuns executadas pelos usuários: digitação de textos 
nos campos de um formulário, seleção de valores em listas drop-down e checking boxes, e cliques do 
mouse em links de páginas web. Ainda fornece controles para o movimento do mouse e execução arbi-
trária de JavaScript, por exemplo (SELENIUM, 2019).
Quando o Selenium é usado para fazer testes automatizados, basicamente há três ferramentas para 
utilizar (CODE A TEST, 2016):
• Selenium IDE: é uma ferramenta que permite a rápida prototipagem de scripts de 
testes. É um plugin do Firefox que possibilita gravar o comportamento do usuário – 
página que ele acessou, textos escritos em formulários, cliques em links e botões etc. 
Depois de gravadas, essas ações podem ser exportadas para um script de teste em 
diversas linguagens de programação, como Java, Python, Perl, JavaScript etc.
• Selenium WebDriver: é uma ferramenta que oferece uma API que permite a escrita 
de forma mais produtiva e organizada de scripts de testes. Essa é a escolha natural 
quando você deseja escrever testes automatizados para aplicações web utilizando o 
Selenium.
• Selenium Grid: permite a criação de uma rede de máquinas de testes conectadas que 
é chamada de nós. Toda essa rede é controlada por hub. O papel do hub é distribuir os 
testes em diferentes nós conectados. Cada nó basicamente pode ser um computador 
com uma combinação de Sistema Operacional e navegadores.
O Selenium suporta praticamente todos os navegadores web existentes: Google Chrome, Firefox, 
Internet Explorer, Safari, Opera.
Título: Selenium (Testes automatizados)
Acesso em: 21/12/2019.
Disponível em: https://youtu.be/Fw9YW5_MZRs
Aprofunde-se
https://youtu.be/Fw9YW5_MZRs
Qualidade e testes de software | Unidade 8 - Outros aspectos do teste de software
119
3.2 JUNIT
JUnit (THE JUNIT TEAM, 2019) é um framework simples para escrever testes repetíveis automatizados 
com suporte na linguagem de programação Java. Com o JUnit é possível criar testes para verificar funcio-
nalidades de classes e seus métodos. Você pode automatizar também a execução de todos os testes de 
forma que, quando for criada uma nova versão estável do sistema, o framework execute todos os testes 
para garantir a integridade e estabilidade do sistema desenvolvido (DEXTRA, 2013).
Ressalta-se que o JUnit fornece apoio ao teste unitário, com foco na técnica caixa-branca, uma vez que 
o código do software a ser testado é conhecido. Além disso, o apoio desse framework é fundamental na 
utilização de técnicas com o TDD (Test-Driven Development).
Título: Java: usando JUnit para testes
Acesso em: 21/12/2019.
Disponível em: https://youtu.be/yn7PorbkZ18
Aprofunde-se
3.3 JMETER
Quando é necessário um teste de performance, sempre a primeira ferramenta que vem à cabeça é 
o JMeter (THE APACHE, 2019), isso porque é um software que está há um tempo no mercado e tem 
vários projetos de sucesso relatados na comunidade. Foi criado em 2007 pela Apache Software e é a 
ferramenta mais utilizada nesse segmento. Pelo fato de ser gratuito e ter o código aberto, é possível 
desenvolver melhorias para atender o projeto, como plugins para gerar outros relatórios além dos que 
a ferramenta já oferece.
A ferramenta tem muitos recursos para atender ao projeto, como componentes:
• Que auxiliam na gestão dos scripts de teste e no controle de cenários aplicados, facili-
tando a manutenção dos mesmos;
• Para configurações de ambientes de testes para execução em servidores e vários terminais;
• Para auxiliar nas avaliações das respostas recebidas para as requisições enviadas aos servidores.
https://youtu.be/yn7PorbkZ18
Qualidade e testes de software | Unidade 8 - Outros aspectos do teste de software
120
Esses são os principais recursos da ferramenta. Outras características existentes no JMeter são:
• Os controles de gravação são importantes no momento da gravação dos scripts, 
ajudando a economizar tempo no projeto;
• O extrator de expressão regular auxilia a coleta de dados dos resultados retornados 
para o JMeter, o que torna possível realizarvalidações durante o teste;
• Utilização de variáveis no script de teste para deixar o teste o mais próximo do 
cenário real do sistema.
O JMeter em geral é utilizado para o teste de performance, porém, também é possível criar e executar 
testes funcionais e em banco de dados, embora existam outras ferramentas no mercado com melhores 
recursos para executar esses tipos de avaliação (DEVMEDIA, 2016).
Na figura abaixo, você pode ver uma representação de uma possível configuração de ambiente onde o 
JMeter client gerencia todo o teste e, ao iniciar a execução, ele distribui todos os usuários nos quatro IPs 
que são os JMeter servers, que por sua vez enviam requisições acessando o alvo de teste.
Título: Teste de login com Jmeter
Acesso em: 21/12/2019.
Disponível em: https://youtu.be/a-HvpsfPS54
Aprofunde-se
ED
+ 
Co
nt
en
t H
ub
 ©
 2
01
9
Figura 3 - Exemplo de uma configuração 
de uso do JMeter.
Fonte: adaptado de DevMedia (2016).
https://youtu.be/a-HvpsfPS54
Qualidade e testes de software | Unidade 8 - Outros aspectos do teste de software
121
CONSIDERAÇÕES FINAIS
Nesta unidade você viu que o teste de software abrange, além da verificação do código em si da apli-
cação, a verificação da funcionalidade por meio da execução dos mesmos, checando seu desempenho 
frente à demanda de utilização.
Pôde ver também que desenvolver uma aplicação centrando esforços na construção em conjunto de 
testes traz benefícios para o ciclo de desenvolvimento.
Por fim, na busca por otimização e melhoria no processo de teste, a automatização da atividade, por 
meio de ferramentas que auxiliam essa tarefa, refina os processos já existentes.
Qualidade e testes de software | Unidade 8 - Outros aspectos do teste de software
122
GLOSSÁRIO
Framework: segundo alguns autores, um framework ou arcabouço, no desenvolvimento de software, 
é uma abstração que une códigos comuns entre vários projetos de software, provendo uma funcionali-
dade genérica. É uma espécie de caixa de ferramentas que você pode utilizar em seus projetos.
Qualidade e testes de software | Unidade 8 - Outros aspectos do teste de software
123
REFERÊNCIAS
CODE A TEST. Testes de aceitação automatizados com Selenium, 2016. Disponível em: http://www.
codeatest.com/testes-aceitacao-automatizados-selenium/ Acesso em: 08 dez. 2019.
DELAMARO, Márcio Eduardo; MALDONADO, José Carlos; JINO, Mário. Introdução ao Teste de Software. 
2. ed. Rio de Janeiro: Campus - Elsevier, 2016.
DEVMEDIA. Teste de performance com JMeter, 2016. Disponível em: https://www.devmedia.com.br/
teste-de-performance-com-jmeter/34621 Acesso em: 13 dez. 2019.
DEXTRA. Tutorial, ou melhor, um passo a passo explicando o funcionamento do JUnit, 2013. Disponível 
em: https://dextra.com.br/pt/tutorial-ou-melhor-um-passo-a-passo-explicando-o-funcionamento-do-junit-2/ 
Acesso em: 11 dez. 2019.
DRATOVSKY, M. Principais tipos de teste de software, 2017. Disponível em: https://www.linkedin.com/
pulse/principais-tipos-de-teste-software-marcus-dratovsky/ Acesso em: 07 dez. 2019.
PRIME CONTROL. Stress Test – Teste de carga. Disponível em: https://www.primecontrol.com.br/stress-
-test-teste-de-carga/ Acesso em: 07 dez. 2019.
SELENIUM. The Selenium project and tools. Disponível em: https://selenium.dev/documentation/en/
introduction/the_selenium_project_and_tools/ Acesso em: 08 dez. 2019.
SOMMERVILLE, I. Engenharia de Software. Tradução Ivan Bosnic e Kalinga G. de O. Gonçalves. 9. ed. São 
Paulo: Pearson Prentice Hall, 2011. 529 p.
THE APACHE. Apache JMeter. Disponível em: https://jmeter.apache.org/ Acesso em: 21 dez. 2019.
THE JUNIT TEAM. JUnit 5. Disponível em: https://junit.org/junit5/ Acesso em: 21 dez. 2019.
WITCZAK, A. B.; MAYER, D.; CHIARELLO, M. Guia Técnicas de Teste - Metodologia Celepar. Disponível 
em: http://www.documentador.pr.gov.br/documentador/pub.do?action=d&uuid=@gtf-escriba@d9bbb686-a-
5cd-432d-ad3f-ba77d6c427f2 Acesso em: 08 dez. 2019.
http://www.codeatest.com/testes-aceitacao-automatizados-selenium/
http://www.codeatest.com/testes-aceitacao-automatizados-selenium/
https://www.devmedia.com.br/teste-de-performance-com-jmeter/34621
https://www.devmedia.com.br/teste-de-performance-com-jmeter/34621
https://dextra.com.br/pt/tutorial-ou-melhor-um-passo-a-passo-explicando-o-funcionamento-do-junit-2/
https://www.linkedin.com/pulse/principais-tipos-de-teste-software-marcus-dratovsky/
https://www.linkedin.com/pulse/principais-tipos-de-teste-software-marcus-dratovsky/
https://www.primecontrol.com.br/stress-test-teste-de-carga/
https://www.primecontrol.com.br/stress-test-teste-de-carga/
https://selenium.dev/documentation/en/introduction/the_selenium_project_and_tools/
https://selenium.dev/documentation/en/introduction/the_selenium_project_and_tools/
https://jmeter.apache.org/
https://junit.org/junit5/
http://www.documentador.pr.gov.br/documentador/pub.do?action=d&uuid=@gtf-escriba@d9bbb686-a5cd-432d-ad3f-ba77d6c427f2
http://www.documentador.pr.gov.br/documentador/pub.do?action=d&uuid=@gtf-escriba@d9bbb686-a5cd-432d-ad3f-ba77d6c427f2