6a8fecc4-034c-4750-b598-53c2b12fac24

Prévia do material em texto

QUALIDADE DE 
SOFTWARE
Aline Zanin 
Garantias da qualidade 
de software
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:
  Definir as garantias da qualidade de software.
  Analisar as garantias da qualidade de software.
  Aplicar os métodos das garantias de software.
Introdução
A garantia da qualidade de software, do inglês quality assurance, pode ser 
definida como as atividades que dão suporte aos processos continua-
mente estabelecidos, visando a fornecer confiabilidade a esses processos. 
Para esse fim, os processos estão em contínua revisão, melhoria e adap-
tação, para produzir produtos que atendam aos requisitos estipulados 
pelo cliente e que sejam adequados para o uso pretendido.
A garantia de qualidade de software está associada com todas as 
atividades que formam o ciclo de desenvolvimento de um software, 
desde o primeiro contato com o cliente até a programação do software 
em si. Dessa forma, a área de garantia da qualidade se preocupa com a 
verificação e a validação do software, a verificação quanto aos processos 
e às definições (garantia da qualidade de processos) e a validação quanto 
ao produto (garantia da qualidade de produto). Para esse fim, diversas são 
as técnicas, os modelos e as atividades empregadas, conforme Campos 
([2019]). 
Neste capítulo, você vai estudar o conceito de garantia da qualidade e 
vai analisar algumas das técnicas que podem ser utilizadas para a garantia 
da qualidade. Por fim, algumas dessas técnicas serão demonstradas por 
meio de exemplos de aplicação.
Garantias da qualidade de software
A garantia da qualidade de software, ou os modelos de garantia da qualidade de 
software, como o próprio nome diz, tem como objetivo garantir que o software 
seja entregue ao cliente fi nal com qualidade e que o processo de verifi cação 
dessa qualidade seja conduzido de forma organizada.
Para que esse processo de garantia de qualidade de software tenha êxito 
em seu objetivo e possa ser executado pela equipe sem causar um consumo 
excessivo de tempo ou uma desmotivação do time, é necessário que esteja 
completamente integrado ao processo de desenvolvimento de software. Um 
bom processo de garantia de qualidade pode ser visto como uma relação de 
um para um com cada fase do processo de desenvolvimento de software; ou 
seja, realiza-se uma etapa de garantia da qualidade de software para cada etapa 
de desenvolvimento. Todo esse processo deve ser feito visando e reforçando 
a colaboração entre as áreas e a ciência por parte dos profissionais de um 
objetivo comum no time, segundo Bartié (2002).
Garantia de qualidade e controle de qualidade são áreas diferentes da engenharia de 
software. A área de controle de qualidade age diretamente sobre o produto e realiza 
a execução dos processos, enquanto a área de garantia da qualidade estrutura tanto 
o controle de processos quanto o controle de produtos e garante que estes estejam 
sendo executados.
Diversos são os modelos que podem ser utilizados para a garantia da 
qualidade. Esses processos incluem garantia da qualidade de processos e 
garantia da qualidade de produtos, verificação e validação. Um dos processos 
é o modelo de qualidade de software em U, que será descrito a seguir.
Modelo de qualidade de software em U
As fases do modelo de qualidade de software podem ser organizadas em um 
formato de U, sendo, nesse caso, o modelo de qualidade de software chamado 
de modelo U. Nesse modelo, as fases são executadas sequencialmente. O 
objetivo é garantir que durante o ciclo de desenvolvimento de software sejam 
Garantias da qualidade de software2
produzidos efetivamente todos os produtos previstos na metodologia empregada 
e que o software entregue esteja de acordo com o requisito esperado.
Esse modelo considera dois tipos de testes de software: testes de verificação 
e testes de validação. Os testes de verificação validam o processo de engenha-
ria de software, e os testes de validação garantem a qualidade do produto de 
software. Analisando a Figura 1, podemos verificar a divisão das etapas do 
modelo U conforme esses dois tipos de testes. As etapas que compreendem 
o modelo U são as seguintes:
Testes de verificação:
  Verificação do modelo de negócios — aqui, os testes verificam se 
foram levantadas informações suficientes sobre o modelo de negócios 
do cliente e como essas informações foram levantadas.
  Verificação da especificação de requisitos — aqui, os testes verificam 
se a partir do modelo de negócio do cliente foram definidos requisitos 
compatíveis, que vão agregar valor ao cliente por meio do produto de 
software.
  Verificação da análise e da modelagem — nessa etapa é verificado se 
a modelagem do sistema atende ao especificado nos requisitos e como 
essa modelagem é feita.
  Verificação da implementação — aqui se inicia a etapa de implemen-
tação; é verificada a estrutura para realização da implementação do 
sistema e o processo que será seguido para a implementação.
Testes de validação:
  Validação da unidade especificada ou modificada — nessa etapa é 
validada uma pequena unidade ou um componente de software que foi 
desenvolvido ou modificado.
  Validação da integração da unidade especificada ou modificada 
— nessa etapa é validada a integração dessa pequena unidade, ou 
componente de software, que foi desenvolvida ou modificada com o 
restante do sistema ou com sistemas externos, conforme a necessidade.
  Validação do sistema especificado ou modificado — aqui é realizada 
a validação do sistema como um todo, de suas funcionalidades imple-
mentadas e seus requisitos.
  Validação da disponibilização da solução — nessa etapa, o software 
já foi entregue ao cliente por meio de sua implementação; aqui é acom-
panhado se a implementação foi feita de forma correta e se o software 
3Garantias da qualidade de software
apresenta no cliente o mesmo comportamento que apresentou no am-
biente de testes.
Figura 1. Modelo de processo de qualidade de software em U.
Fonte: Adaptada de Bartie (2002).
5
Implementação
Verificação
da 
implementação
3
Análise e
modelagem
Verificação,
análise e
modelagem
5
Unidade
especificada ou
modificada
Validação
da
unidade
6
Integração
especificada
ou modificada
Validação
da
integração
7
Sistema
especificado ou
modificado
Validação
da
integração
8
Disponibilização
da
solução
Validação
do
aceite
1
Modelo
de
negócios
Verificação
de
negócios
2
Especificação
de
requisitos
Verificação
de
requisitos
TESTE DE VERIFICAÇÃO TESTES DE VALIDAÇÃO
Clientes
patrocinadores
usuários
Testes de verificação
O processo de desenvolvimento de software considera duas etapas principais, 
sendo elas: planejamento, em que são coletadas as informações e é planejada a 
arquitetura do software, e desenvolvimento, em que o sistema é de fato desen-
volvido. Os testes de verifi cação são realizados na etapa de planejamento e têm 
como objetivo avaliar se a documentação e o processo utilizado nessa etapa 
estão sendo feitos de forma correta. Nesse momento, não existem componentes 
tecnológicos, mas, sim, documentos que especifi cam o comportamento do 
software a ser construído. 
Os testes de verificação são aplicados de acordo com o estágio de desen-
volvimento. São realizados testes:
  na etapa de levantamento das necessidades do cliente e das caracterís-
ticas específicas para o software;
Garantias da qualidade de software4
  na etapa de identificação de requisitos funcionais e não funcionais do 
software;
  na etapa de definição do modelo de arquitetura e da solução tecnológica;
  na etapa de construção do software.
Testes de validação
Os testes de validação são um processo formal de avaliação de software e 
podem ser aplicados em componentes isolados, em módulos ou em funciona-
lidades já implementadas no sistema, ou mesmo no sistema como um todo. O 
objetivo desses testes é avaliar a conformidade do software com os requisitos 
especifi cados nas etapas iniciais doprojeto. A principal característica desses 
testes é a necessidade de o software já estar em execução para ser testado 
devidamente. Diversas são as categorias de testes que podem ser aplicados 
durante o processo de desenvolvimento de software, sendo que as atividades de 
planejamento, modelagem, execução e conferência dos testes deverão ocorrer 
em paralelo às atividades de construção do software.
As validações serão aplicadas respeitando-se os estágios de desenvolvi-
mento. São realizados:
  testes em componentes executáveis;
  testes de interface entre componentes;
  testes em sistemas ou módulos completos;
  aceite de um sistema ou módulo pelo cliente.
Testes de verificação e testes de validação fazem parte do modelo U de 
qualidade, sendo que cada um desses tipos de teste compreende diversas 
atividades que precisam ser executadas, visando a garantir a qualidade do 
software. Na próxima seção, vamos analisar algumas das técnicas de garantia 
de qualidade de software, tanto de verificação quanto de validação.
Análise das garantias de qualidade de software
O processo de garantia da qualidade considera um olhar detalhado para a qua-
lidade tanto do processo quanto do produto. No processo, podemos quantifi car 
a sua qualidade por meio de métricas e, nos produtos, por meio de técnicas de 
verifi cação e validação. Todo esse processo de garantia da qualidade pode ser 
5Garantias da qualidade de software
avaliado, por exemplo, pela normativa ISO 9000, por auditorias, por inspeções 
formais ou por testes de software, conforme Campos ([2019]).
A área de garantia da qualidade tem alguns papéis fundamentais, conforme 
aponta Bastos et al. (2007):
  ajuda a estabelecer processos;
  determina programas de medida para avaliar processos;
  identifica fraquezas de medida para avaliar processos;
  é uma responsabilidade de gerenciamento;
  está relacionada com todos os produtos que serão gerados por um 
processo;
  avalia se o controle de qualidade está funcionando.
Conforme citado, uma das principais formas de garantia da qualidade é 
por meio de auditorias. Vamos analisar algumas das principais auditorias que 
podem ser feitas em processos de desenvolvimento de software, considerando 
os cenários em que cada uma pode ser aplicada.
A normativa ISO 9000 é utilizada para a garantia da qualidade de processos 
nos mais diversos aspectos. Empresas de todos os segmentos utilizam a ISO 
9000, inclusive como estratégia de marketing para seus produtos. Essa norma 
teve origem na norma britânica BS 570, publicada em 1979 pelo SBI (British 
Standards Institute), baseada em padrões militares. Em 1987, a norma foi 
revisada, mudando seu foco de exclusivamente empresas de manufatura para 
outras empresas prestadoras de serviços. No ano seguinte, o documento foi 
aceito pela ISO como padrão mundial.
A ISO 9000 é um conjunto de normas genéricas que serve a qualquer 
organização, de qualquer ramo de atividade, que queira realizar o controle 
de qualidade de seus produtos e serviços. Essa norma é mais conhecida pela 
sua versão 9001. A ISO 9001 descreve exigências para o sistema de gerência 
de qualidade da empresa. A qualidade de produtos e serviços não é estabele-
cida pela norma, mas, sim, pela própria empresa e pelas exigências de seus 
clientes. A norma ISO 9001 define processos que descrevem como a empresa 
deve realizar determinadas atividades (ASSOCIAÇÃO BRASILEIRA DE 
NORMAS TÉCNICAS, 2015). Os documentos que definem os processos são 
chamados pela ISO 9000 de procedimentos.
Garantias da qualidade de software6
Uma empresa que tem ISO 9001 para os seus processos terá, por exemplo, um pro-
cedimento que define como a telefonista deve atender ao telefone, isto é, qual frase 
deve ser dita ao receber uma ligação.
Já o CMM e o CMMI são dois dos principais modelos para melhoria de 
processos especificamente para software, criados pelo Software Engineering 
Institute — SEI. CMM é o acrônimo de capability maturity model ou modelo 
de capacidade de maturidade. Por esse modelo ser focado especificamente em 
software, ele não avalia outras áreas da empresa, como recursos humanos ou 
setor financeiro, conforme lecionam Koscianski e Soares (2007).
O CMM busca que as empresas conheçam e melhorem os seus processos 
de desenvolvimento de software com a implementação de práticas bem de-
finidas. Ele define uma escala para a maturidade da empresa, que se divide 
em cinco passos. Cada nível do CMM define áreas-chave que identificam um 
conjunto de objetivos que a empresa precisa cumprir para atingir esse nível 
de maturidade. Os níveis são:
1. Inicial.
2. Gerenciado.
3. Definido.
4. Gerenciado quantitativamente.
5. Otimizado.
No nível 1, nenhum processo está definido, e, no nível 5, todos os processos 
estão definidos, são seguidos e estão apenas sendo otimizados constantemente, 
conforme lecionam Koscianski e Soares (2007).
Com a evolução do CMM, foram criados modelo semelhantes para diversas 
áreas das empresas, por exemplo: P-CMM para gestão de recursos humanos, 
SA-CMM para aquisição de software, SE-CMM para engenharia de sistemas. 
Para integrar todos esses modelos, surgiu o CMMI, ou capability maturity 
model integration. O CMMI mantém os mesmos cinco níveis do CMMI, 
contudo, amplia as áreas de foco de cada nível, exceto o nível 1, que não tem 
objetivos específicos, por ser a ausência de processos. As áreas definidas para 
cada nível do CMMI são mostradas nos Quadro 1.
7Garantias da qualidade de software
 Fonte: Adaptado de Koscianski e Soares (2007). 
Nível de maturidade 2 — gerenciado
  Gerência de requisitos
  Planejamento do projeto
  Gerência e controle do projeto
  Gerência e acordos com fornecedores
  Medição e análise
  Garantia da qualidade do processo e do produto
  Gerencia de configuração
Nível de maturidade 3 — definido
  Desenvolvimento de requisitos
  Solução técnica
  Integração do produto
  Verificação
  Validação
  Foco no processo organizacional
  Treinamento organizacional
  Gerência de projeto integrada
  Gerência de risco
  Análise de decisão e resolução
  Desempenho no processo organizacional
  Definição do processo organizacional
Nível de maturidade 4 — gerenciado quantitativamente
  Desempenho do processo organizacional
  Gerência quantitativa do projeto
Nível de maturidade 5 — otimizado
  Inovação e implementação na organização
  Análise e resolução de causas
 Quadro 1. Níveis de maturidade e processos do modelo MPS.BR 
Garantias da qualidade de software8
Por sua vez, o modelo MPS.BR, um acrônimo de “melhoria de processo de 
software brasileiro”, teve seu desenvolvimento iniciado no ano de 2003 pelas 
instituições SOFTEX, Riosoft, COPPE/UFRG, CESAR, CenPRA e CELE-
PAR. Esse modelo tem foco em empresas de micro, pequeno e médio porte e 
objetiva ser um modelo de qualidade com um custo inferior ao modelo CMMI. 
Esse modelo foi criado para adequar os processos de engenharia de software 
para a realidade brasileira, baseando-se nas abordagens internacionais para 
avaliação e melhoria de processos de software, conforme abordam Koscianski 
e Soares (2007). As bases do modelo MPS.BR são as normas ISO/IEC 12207, 
ISO/IEC 15504 e o CMMI. Esse modelo se divide em três componentes, sendo 
eles: modelo de referência (MR-MPS), método de avaliação (MA-MPS) e 
modelo de negócios (MN-MPS). Ele classifica as empresas de acordo com sete 
níveis de maturidade e, assim como o CMMI, também estabelece objetivos 
para cada nível. Os níveis estipulados para o MPS.BR são os seguintes:
a) Em otimização.
b) Gerenciado quantitativamente.
c) Definido.
d) Largamente definido.
e) Parcialmente definido.
f) Gerenciado.
g) Parcialmente gerenciado.
Nesse modelo, o nível A é o nível mais avançado, que considera os processos 
sendo executados e apenas em etapa de inovação e otimização, e o nível G 
é o início da organização dos processos da empresa, conforme Koscianski e 
Soares (2007). O Quadro 2 demonstra os níveis de maturidade e os processos 
gerenciadospor cada nível do modelo MPS.BR.
9Garantias da qualidade de software
 Fonte: Adaptado de Koscianski e Soares (2007). 
A
  Inovação e implantação na organização
  Análise de causas e resolução
B
  Desempenho do processo organizacional
  Gerência quantitativa do projeto
C
  Análise de decisão e resolução
  Gerência de riscos
D
  Desenvolvimento de requisitos
  Solução técnica
  Integração de produto
  Instalação de produto
  Liberação de produto
  Verificação
  Validação
E
  Treinamento
  Avaliação e melhoria do processo organizacional
  Definição do processo organizacional
  Adaptação do processo para gerência do projeto
F
  Medição
  Gerência de configuração
  Aquisição
  Garantia da qualidade
G
  Gerência de requisitos
  Gerência de projetos
 Quadro 2. Níveis de maturidade e processos do modelo MPS.BR 
Outra técnica de garantia de qualidade de software que tem sua utilização 
recomendada é a organização dos processos de testes de software. Os testes são 
Garantias da qualidade de software10
uma medida de controle de qualidade, e a organização e o acompanhamento 
do processo de testes são garantia da qualidade do software. O principal 
documento que norteia a organização do processo de testes e é utilizado para 
monitorar se os testes estão sendo realizados de acordo com o planejado é 
um documento chamado de plano de testes. De acordo com a International 
Software Testing Qualifications Board (ISTQB), em seu glossário de termos, 
o plano de testes é a “documentação descrevendo os objetivos do teste a serem 
alcançados, os meios para realizá-lo, e o cronograma para atingi-lo, organizados 
para coordenar as atividades de teste” (ISTQB, 2018, p. 22).
O plano de teste não é um documento estático; ele pode ser modificado 
durante todo o ciclo de vida do produto, caso novas necessidades sejam identi-
ficadas. O feedback de cada atividade do ciclo de vida pode ser utilizado como 
parâmetro para incluir ou remover itens do plano de testes. O planejamento 
dos testes de um projeto pode ser feito em um plano de teste principal e em 
planos de teste separados para cada nível de teste.
Por exemplo, cria-se um plano de testes para os testes de sistema, que serão feitos 
logo após a conclusão do desenvolvimento da primeira funcionalidade, e outro plano 
de testes para o teste de aceitação, que será feito juntamente com o cliente ou repre-
sentante dele, conforme exemplifica o ISTQB (2018).
O plano de testes é personalizável conforme as necessidades de cada em-
presa, mas, em geral, conforme aponta o ISTQB (2018), ele deve:
  determinar o escopo, os objetivos e os riscos do teste; 
  definir a abordagem geral do teste;
  integrar e coordenar as atividades de teste nas atividades do ciclo de 
vida do software;
  tomar decisões sobre o que testar, as pessoas e outros recursos necessá-
rios para realizar as várias atividades de teste e como essas atividades 
serão realizadas;
  programar as atividades de análise, projeto, implementação, execução e 
avaliação de testes, em datas específicas (p. ex., desenvolvimento sequen-
cial) ou no contexto de cada iteração (p. ex., desenvolvimento iterativo);
11Garantias da qualidade de software
  selecionar as métricas para monitoramento e controle de testes;
  orçar as atividades de teste;
  determinar o nível de detalhes e a estrutura da documentação de teste 
(p. ex., fornecendo modelos ou exemplos de documentos). 
O conteúdo dos planos de teste varia e pode se estender além dos tópicos 
identificados acima. Uma amostragem de planos de teste pode ser encontrada 
nos documentos do padrão ISO (ISO/IEC/IEEE 29119-3).
Métodos de garantia de qualidade de software
Diversas são as estratégias que podem ser utilizadas para a garantia da qua-
lidade de software; algumas foram descritas na seção anterior. Nesta seção, 
essas estratégias são apresentadas com uma abordagem mais aplicada. Como 
se preparar para uma auditoria? Como estruturar um plano de testes?
Auditoria ISO
A auditoria é o momento de verifi car se os processos que foram defi nidos 
para a empresa estão sendo cumpridos. É por meio da auditoria que as em-
presas recebem o almejado selo ISO 9001, e é também por meio dela que, 
periodicamente, as empresas renovam esse selo. Contudo, para obter êxito nas 
auditorias, é necessário saber como elas funcionam e executar alguns passos 
importantes, os quais serão descritos a seguir, com base em Oliveira (2018).
O primeiro passo para se preparar para uma auditoria ISO é estudar as 
normas, os padrões definidos pela sua empresa. Toda a empresa que almeja 
uma certificação ISO obrigatoriamente tem seus procedimentos definidos pelo 
SGQ — Sistema Gerenciador de Qualidade. O profissional que vai acompanhar 
a auditoria precisa conhecer esses processos.
Além do responsável pela qualidade da empresa, os demais colaboradores 
precisam também estar preparados para a auditoria. Dessa forma, é necessário 
preparar a equipe, apresentar a todos os procedimentos, uma vez que o auditor 
poderá conversar com qualquer pessoa para confirmar se os processos são 
executados conforme o determinado.
Além disso, a organização é fundamental para o processo de auditoria. O 
responsável pela qualidade da empresa, que acompanha a auditoria, precisa 
saber onde estão arquivados todos os documentos que são utilizados diaria-
mente e que constam nos procedimentos. É importante que todas as evidências 
Garantias da qualidade de software12
de que os processos definidos são cumpridos sejam apresentadas de forma 
organizada para o auditor.
Para garantir que nenhuma surpresa acontecerá quando a auditoria oficial 
com a certificadora da ISO acontecer, é aconselhável a realização de uma 
auditoria interna. Na auditoria interna, será possível para a empresa identifi-
car pontos fracos que podem ser melhorados para a auditoria externa. Além 
disso, a auditoria interna aumenta a confiança da equipe, o que faz com que, 
na auditoria externa, a equipe esteja tranquila e não cause transtornos apenas 
por nervosismo.
Segundo Oliveira (2018), uma auditoria ISO é constituída basicamente por:
  Reunião de abertura — em que o responsável pela qualidade da empresa 
e o auditor se reúnem pela primeira vez e é definido o cronograma da 
auditoria.
  Auditoria dos processos — nessa etapa, é feita a análise dos procedi-
mentos, dos documentos que comprovam a sua execução e, quando 
necessário, ocorre uma conversa com os profissionais da empresa, para 
garantir que o processo está sendo executado corretamente. 
  Reunião de conclusão — é o momento em que o auditor analisa a 
auditoria junto com todos os gestores da empresa envolvida e faz re-
comendações com base no resultado da auditoria.
Preparando seu plano de testes
Agora, vamos analisar cada parte do plano de testes e discutir como preencher 
esse plano e como identifi car as informações que devem constar em cada parte.
  Determinar o escopo, os objetivos e os riscos do teste: o escopo e os 
objetivos do teste dizem respeito a quais funcionalidades do sistema 
serão testadas. Os riscos dizem respeito a situações que podem impedir 
a realização dos testes. Por exemplo: para testar o sistema de uma ope-
radora telefônica, podem ser necessários dados de números de telefones 
válidos para entrada de dados no sistema; entretanto, a operadora pode 
atrasar a disponibilidade desses dados, e o teste pode atrasar; ou então 
a equipe pode ter um limite mínimo de colaboradores, e alguém pode 
pedir demissão durante o projeto, e, por isso, as demandas da equipe 
acabam atrasando.
  Definir a abordagem geral do teste: quais tipos e níveis de testes serão 
empregados no projeto? Os testes serão manuais ou automatizados? 
13Garantias da qualidade de software
Essas perguntas precisam ser definidas no plano de testes; é necessário 
especificar se a equipe vai realizar teste unitário, teste funcional, teste 
de performance, teste de segurança, entre outros. Essas definições são 
de extrema importânciapara a organização do ambiente de desenvol-
vimento e do cronograma.
  Integrar e coordenar as atividades de teste nas atividades do ciclo de 
vida do software: em que momento do ciclo de desenvolvimento os 
testes serão iniciados? Será possível iniciar a análise de testes junto 
com a análise do sistema? 
  Tomar decisões sobre o que testar, as pessoas e outros recursos neces-
sários para realizar as várias atividades de teste e como essas atividades 
serão realizadas: de acordo com o escopo que foi definido para o pro-
jeto, toda a funcionalidade será testada ou apenas a parte fundamental 
dela? O projeto dispõe de recursos humanos e financeiros para testar 
a funcionalidade por completo?
  Programar as atividades de análise, projeto, implementação, execução 
e avaliação de testes, em datas específicas (p. ex., em desenvolvimento 
sequencial) ou no contexto de cada iteração (p. ex., no desenvolvimento 
iterativo): nessa etapa, define-se como o projeto de testes será estrutu-
rado, em que momento será feita a análise de testes e de quanto tempo 
se dispõe para isso? Em que momento será feita a implementação dos 
testes e quanto tempo se dispõe para isso?
  Selecionar as métricas para monitoramento e controle de testes: qual é 
o parâmetro para que um projeto de testes seja considerado concluído 
com êxito? 
  Orçar as atividades de teste: qual será o custo do projeto para cumprir 
com o cronograma estabelecido e atingir todo o escopo de testes?
  Determinar o nível de detalhes e a estrutura da documentação de teste 
(p. ex., fornecendo modelos ou exemplos de documentos): serão criados 
casos de testes? As falhas serão reportadas em alguma ferramenta?
Cada uma dessas etapas é fundamental para o projeto e pode ser adaptada, 
dependendo das necessidades da equipe. Em síntese, um plano de testes 
precisa conter, obrigatoriamente, o escopo do projeto, os tipos de testes que 
serão executados, o cronograma, o orçamento disponível, as ferramentas que 
serão utilizadas e a definição dos documentos entregáveis que serão gerados 
ao final do projeto.
Garantias da qualidade de software14
ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS (ABNT). NBR ISO 9001: sistemas de 
gestão da qualidade: requisitos. Rio de Janeiro, 2015. 
BARTIE, A. Garantia da qualidade de software. Rio de Janeiro: Elsevier, 2002. 
BASTOS, A. et al. Base de conhecimento em testes de software. 2. ed. São Paulo: Martins 
Fontes, 2007. 
CAMPOS, F. M. Qualidade, qualidade de software e garantia da qualidade de software são 
mesma coisa? [2019]. Disponível em: . Acesso em: 23 jan. 2019. 
INTERNATIONAL SOFTWARE TESTING QUALIFICATIONS BOARD (ISTQB). Glossário de 
termos de teste: CTFL foundation level: versão 3.2br. 2018. Disponível em: . Acesso em: 23 jan. 2019.
KOSCIANSKI, A.; SOARES, M. S. Qualidade de software: aprenda as metodologias e técnicas 
mais modernas para desenvolvimento de software. 2. ed. São Paulo: Novatec, 2007.
OLIVEIRA, G. Como se preparar para uma auditoria ISO e o que esperar dela. 2018. Dispo-
nível em: . 
Acesso em: 23 jan. 2019.
Leitura recomendada
INTERNATIONAL SOFTWARE TESTING QUALIFICATIONS BOARD (ISTQB). Certified tester: 
CTFL foundation level syllabus: 3.2. 2018. Disponível em: . Acesso em: 23 jan. 2019.
15Garantias da qualidade de software
Conteúdo: