Teste deTítulo

Inserir Software
Aqui
Inserir Título Aqui
Verificação e Validação de Software

Responsável pelo Conteúdo:

Prof. Me. Wilson Vendramel

Revisão Textual:
Prof.ª Me Natalia Conti
 Verificação e Validação de Software

Nesta unidade, trabalharemos os seguintes tópicos:

• Verificação e Validação de Software;
• Modelo “V” de Desenvolvimento;
• Inspeção de Software;

Fonte: iStock/Getty Images

• Teste de Software.

Objetivos
• Compreender a importância da qualidade no desenvolvimento de sistemas de software;
• Entender os conceitos de qualidade de software e as técnicas de verificação e validação
de software.

Caro Aluno(a)!

Normalmente, com a correria do dia a dia, não nos organizamos e deixamos para o úl-
timo momento o acesso ao estudo, o que implicará o não aprofundamento no material
trabalhado ou, ainda, a perda dos prazos para o lançamento das atividades solicitadas.

Assim, organize seus estudos de maneira que entrem na sua rotina. Por exemplo, você
poderá escolher um dia ao longo da semana ou um determinado horário todos ou alguns
dias e determinar como o seu “momento do estudo”.

No material de cada Unidade, há videoaulas e leituras indicadas, assim como sugestões

de materiais complementares, elementos didáticos que ampliarão sua interpretação e
auxiliarão o pleno entendimento dos temas abordados.

Após o contato com o conteúdo proposto, participe dos debates mediados em fóruns de
discussão, pois estes ajudarão a verificar o quanto você absorveu do conteúdo, além de
propiciar o contato com seus colegas e tutores, o que se apresenta como rico espaço de
troca de ideias e aprendizagem.

Bons Estudos!
UNIDADE
Verificação e Validação de Software

Contextualização
Diversas organizações compromissadas com a busca pela qualidade vêm aplicando
técnicas de Verificação e Validação (V&V) em seus produtos de software, tais como ins-
peção e teste, o que tem aumentado a qualidade dos sistemas de software, contribuindo
para redução de defeitos e diminuição de custos, além de aumentar a confiabilidade do
produto e a satisfação dos usuários que utilizam produtos de software verificados e va-
lidados. No que tange à execução de testes, há quem ainda acredita que essa atividade
pode ser realizada por qualquer pessoa com baixo ou nenhum nível de preparo, não
requerendo conhecimentos específicos sobre tal atividade. Para que o teste de software
alcance seus objetivos e assegure a garantia da qualidade, é necessário planejamento,
conhecimento do domínio de negócio no qual este está inserido; utilização de metodolo-
gias, técnicas e ferramentas de teste, além de características pessoais como criatividade,
dedicação, paciência e potencial investigativo por parte dos profissionais envolvidos com
as atividades de teste de software.

6
Verificação e Validação de Software
Este material teórico apresenta a importância dos processos de Verificação e Vali-
dação (V&V) no desenvolvimento de sistemas de software, enfatizando conceitos de
qualidade e técnicas de verificação e validação, especificamente inspeção e teste.

Qualidade de Software
Ao estudar teste de software, você está tentando assegurar a qualidade de um sistema
(ou produto) de software.

Mas o que é qualidade de software?

“Qualidade de software é um processo sistemático que focaliza todas
as etapas e artefatos produzidos com o objetivo de garantir a confor-
midade de processos e produtos, prevenindo e eliminando defeitos”.
(BARTIÉ, 2002, p.16).

De forma mais simples, qualidade de software significa que um produto (sistema de

software) deve atender as suas especificações.

A qualidade de software não pode ser comparada diretamente à qualidade na ma-

nufatura. Algumas razões impossibilitam concluir de forma objetiva se um sistema de
software atende ou não suas especificações, por exemplo:
• Há conflitos entre os requisitos de qualidade do cliente (eficiência, confiabilidade) e
os requisitos de qualidade do desenvolvedor (reuso, manutenibilidade);
• Determinados requisitos de qualidade são difíceis de serem especificados com clareza;
• Muitas vezes as especificações de software são incompletas e/ou inconsistentes
(SOMMERVILLE, 2011).

Além do sistema de software funcionar, ele precisa atender diversos atributos de qualidade
(requisitos funcionais), tais como segurança, portabilidade, usabilidade, desempenho,
confiabilidade, manutenibilidade, robustez. É possível garantir que o software contemple
todos esses atributos?

Não é possível qualquer sistema de software ser desenvolvido para atender todos
esses atributos de qualidade, pois existem requisitos não funcionais que são conflitantes,
por exemplo, a melhoria da robustez pode levar à perda de desempenho. Portanto, um
plano de qualidade deve priorizar os atributos de qualidade mais importantes para o
software que está sendo desenvolvido. Além disso, um plano de qualidade deve incluir
uma definição do processo de avaliação de qualidade, uma forma acordada de avaliar
se algum atributo de qualidade, como a de manutenção ou robustez, estão presentes no
sistema de software (SOMMERVILLE, 2011).

7
7
UNIDADE
Verificação e Validação de Software

A qualidade de um produto desenvolvido é influenciada pela qualidade do processo de

desenvolvimento. Isso é importante porque alguns atributos de qualidade são difíceis de
serem avaliados. Em contrapartida, existe uma relação complicada e mal compreendida
entre os processos de software e a qualidade de produto. As habilidades e a experiência
individual são bastante importantes no desenvolvimento de software; mas os fatores
externos, como a novidade de uma aplicação ou a necessidade de um cronograma de
desenvolvimento mais rápido pode afetar a qualidade do sistema de software. A figura 1
mostra a qualidade baseada em processo para alcançar a qualidade de produto.

Desenvolver Avaliar qualidade

Definir processo
produto de produto

Não Qualidade Sim Padronizar

Melhorar Processo
OK processo

Figura 1 – Qualidade baseada em processo

A garantia da qualidade de software possui uma ampla gama de elementos e ativi-

dades que se concentram na gestão da qualidade de software, podendo ser resumidas
em padrões, revisões e auditorias, testes, gestão de mudanças, gestão de riscos, dentre
outros (PRESSMAN e MAXIM, 2016).

A gestão da qualidade de software está preocupada com a garantia de que o software

tenha um baixo número de defeitos e que alcance os padrões exigidos de manutenção,
confiabilidade, portabilidade e, assim por diante (SOMMERVILLE, 2011).

Diversas informações sobre gestão da qualidade de software podem ser encontradas em

https://goo.gl/F1n1SU

Sobre padrões, existem os que definem os atributos necessários de um produto ou

processo, contribuindo positivamente no gerenciamento de qualidade.

Os padrões podem ser internacionais, nacionais, padrões organizacionais ou de pro-

jeto. Os padrões de produto de software e os padrões de processo, quando bem ge-
renciados, podem garantir a qualidade do sistema de software. Enquanto os padrões de
produto definem características que todos os componentes de software devem exibir,
por exemplo, um estilo de programação comum, os padrões de processo definem como
o processo de software deve ser seguido. Os padrões são importantes porque contem-
plam um resumo das melhores práticas, evitando a repetição de erros cometidos no

8
passado. Os padrões são um framework que define o significado da visão de qualidade
de uma organização, já que fornece a continuidade, possibilitando assim que pessoas
novas possam compreender a organização por meio dos padrões adotados (SOMMER-
VILLE, 2011). A tabela 1 apresenta exemplos de padrões de produto e de processo.

Tabela 1 – Padrões de produto e de processo

Padrões de Produto Padrões de Processo
Formulário de revisão de projeto Condução de revisão de projeto
Estrutura de documento de requisitos Apresentação do novo código para a construção de sistema
Formato de cabeçalho de método Processo de versão e release
Estilo de programação Java Processo de aprovação de plano de projeto
Formato de plano de projeto Processo de controle de mudança
Formulário de solicitação de mudança Processo de registro de teste
Fonte: Adaptado de Sommerville (2011, p.460)

IEEE, ISO e outras organizações de padronizações criaram uma ampla relação de pa-
drões para engenharia de software e documentos relacionados. O papel da garantia da
qualidade de software é assegurar que os padrões adotados por uma organização sejam
seguidos e que todos os produtos resultantes estejam em conformidade com os referidos
padrões (PRESSMAN e MAXIM, 2016).

ISO/IEC 9126 é uma norma para qualidade de produto de software que define um conjunto
de parâmetros com o objetivo de padronizar a avaliação da qualidade de software. Ela se
enquadra no modelo de qualidade das normas da família 9000. Maiores informações sobre
essa norma podem ser encontradas em https://goo.gl/FJJxnM

Modelo “V” de Desenvolvimento

As atividades relacionadas com a garantia da qualidade de software podem ser orga-
nizadas em processos de Verificação e Validação (V&V). Esses processos são realizados
em paralelo ao processo de desenvolvimento de software.

Para Sommerville (2011), a Verificação estabelece se o software está de acordo com as

especificações e a Validação estabelece se o software faz o que o usuário realmente precisa.

“Verificação: estamos construindo o produto de maneira correta? Validação: estamos

construindo o produto certo?” (BOEHM, 1979 apud SOMMERVILLE, 2011, p.145).]

9
9
UNIDADE
Verificação e Validação de Software

O modelo “V” de desenvolvimento é um modelo conceitual que pode ser represen-

tado de diversas formas.

A figura 2 mostra o ciclo de vida de testes. Observe que o desenvolvimento e o

teste se iniciam simultaneamente. Isso significa que a equipe que desenvolve o sistema
começa o processo de desenvolvimento do software e a equipe de teste inicia o pla-
nejamento do processo de teste. Ambas as equipes começam no mesmo ponto, utili-
zando as mesmas informações. Enquanto a equipe de desenvolvimento se preocupa
em coletar os requisitos com o objetivo de desenvolver o software, a equipe de teste
se baseia nos mesmos requisitos com o objetivo de testar o sistema. Nos momentos
apropriados do processo de desenvolvimento, a equipe de teste aplica as técnicas de
teste para avaliar os produtos resultantes do processo de desenvolvimento com o pro-
pósito de descobrir defeitos.

Inicio da Inicio dos

Implementação Testes

Verificação
Ciclo de vida de Ciclo de vida de
DS (FAZ) Validação testes (Confere)

Correções
Completadas

Figura 2 – Conceito “V” de teste de software

Com base no conceito “V” de teste, as atividades de FAZER e CONFERIR convergem

do início até o final do projeto. A equipe que “faz” trabalha com o propósito de imple-
mentar o software e a equipe que “confere” executa, em paralelo, as atividades de teste
buscando minimizar os riscos. Dessa forma, se as equipes trabalharem conjuntamente e
de forma integrada, o nível de riscos do desenvolvimento de um sistema de software ten-
de a ser reduzido para um grau aceitável, possibilitando assim uma entrega bem-sucedida
do software. A figura 3 mostra um processo de teste de software que segue o conceito
“V” já apresentado na figura 2. Enquanto o lado esquerdo do “V” representa o ciclo de
desenvolvimento de software, o lado direito representa os passos do processo de teste.
Observe os primeiros cinco passos utilizando a técnica de verificação como a principal
maneira de avaliar a correção dos produtos resultantes do desenvolvimento de software.
Por outro lado, a técnica de validação é utilizada para testar o software durante as ativi-
dades de construção até a implantação (BASTOS et al., 2012).

10
 Definição dos requisitos Passo 1
do sotfware Acesso ao plano de
desenvolvimento e situação

Passo 2
Desenvolvimento
do planode testes

Passo 3
Testes dos requisitos
Construção do sotfware do sotfware

Passo 4
Testes do desenho
do sotfware

Instalação do sotfware

Passo 5
Teste da construção
do sotfware

Passo 6
Execução e registro
dos testes

Passo 7
Teste de aceitação
Operação e
Manutenção do
sotfware

Passo 8
Informação dos
resultados dos testes

Passo 9
Teste das mudanças
no sotfware

Passo 10
Avaliação da eficácia
dos testes

Figura 3 – Processo de teste de software

A figura 4 apresenta outra forma de visualizar o modelo “V” de desenvolvimento.

Cada fase tem uma numeração que indica a sequência de execução dos testes a serem
executados. O objetivo desse modelo é garantir que ao longo do processo de desenvol-
vimento, o sistema de software desenvolvido esteja de acordo com os requisitos especi-

11
11
UNIDADE
Verificação e Validação de Software

ficados. Os testes de verificação e validação são complementares e não devem ser vistos
como atividades redundantes, pois têm naturezas e objetivos diferentes, fortalecendo
o processo de identificação de defeitos e aumentando a qualidade final do produto de
software (BARTIÉ, 2002).

Observe na figura 4 que os clientes, patrocinadores e usuários podem participar da

maioria dos testes de verificação e de validação; somente a verificação da implemen-
tação e a validação da unidade não têm a participação dos referidos stakeholders, pois
são testes de caráter mais técnico e que necessitam de conhecimento de linguagem de
programação, por exemplo.

Modelo de
Negócios
1 Disponibilização
de Solução
8
Verificação Verificação
de Negócios do Aceite

Especificação
de Requisitos
2 Sistema
Especificado ou
Modificado
7
Verificação Clientes Verificação
de Requisitos Patrocinadores de Sistema
Usuários

Análise e
Montagem
3 Implementação 4 Unidade
Especificada ou
Modificada
5 Integração
Especificada ou
Modificada
6
Verificação
Análise e Verificação da Verificação Verificação
Montagem Implementação da U nidade da Integração

Figura 4 – Visão do modelo “V” de desenvolvimento

Sobre a figura 4, os testes de verificação são aplicados de acordo com as fases de

desenvolvimento:
• Verificação de negócios: os testes são aplicados na fase de definição das necessi-
dades e atributos de negócio a serem atendidos pelo sistema de software;
• Verificação de requisitos: os testes são aplicados na fase de identificação dos re-
quisitos funcionais e não-funcionais que o software deve atender;
• Verificação da análise e modelagem: os testes são aplicados na fase de definição
do projeto arquitetural do sistema de software;
• Verificação da implementação: os testes são aplicados na implementação do
software, visando atender a arquitetura de software estabelecida (BARTIÉ, 2002).

12
 A figura 4 ainda mostra que os testes de validação também são aplicados de acordo
com as fases de desenvolvimento:
• Validação da unidade: os testes são aplicados em componentes executáveis isolados;
• Validação da integração: os testes são aplicados entre componentes, conforme
eles vão sendo integrados;
• Validação do sistema: os testes são aplicados em sistemas ou módulos completos;
• Validação do aceite: aceitação de um sistema ou módulos por parte dos clientes
e/ou da comunidade usuária (BARTIÉ, 2002).

Qual deve ser o nível de confiança exigido de um sistema de software?

Para Sommerville (2011), o objetivo dos processos de V&V é estabelecer a confiança

de que o software está pronto para seu propósito. O nível de confiança exigido de um
sistema de software depende de alguns fatores:
• Finalidade do software: o nível de confiança depende do quanto o software é
crítico para a organização;
• Expectativas do usuário: os usuários podem ter expectativas baixas em determi-
nados tipos de software;
• Ambiente de marketing: um produto de software disponibilizado rapidamente
no mercado pode ser mais importante do que encontrar defeitos no software.

Segundo Koscianski e Soares (2007), a confiabilidade de um sistema de software

pode ser definida como a probabilidade de o software operar sem apresentar falhas, em
um determinado contexto de uso e intervalo de tempo determinado. Os testes devem
ser mais rigorosos à medida que a confiabilidade se torne uma característica com maior
peso em um modelo de qualidade. Para garantir maior confiabilidade, é preciso maior
investimento de tempo e de recursos, além da realização de testes mais detalhados.

Quais atividades podem ser contempladas pelos processos de Verificação e Validação?

Para Pressman e Maxim (2016), os processos de V&V contemplam revisões técni-

cas formais, auditoria de qualidade e configuração, monitoramento de desempenho,
simulação, estudo de viabilidade, revisão da documentação, revisão da base de dados,
análise de algoritmos e diversos tipos de teste como teste de desenvolvimento, teste de
usabilidade, teste de instalação, dentre outros.

Para Sommerville (2011), existem duas abordagens complementares nos processos

de V&V: inspeção de software, que é uma técnica estática que verifica artefatos do pro-
duto de software, como documento de requisitos, diagramas e código-fonte; e o teste
de software, que é uma técnica dinâmica que envolve executar uma implementação do
software, analisando as saídas para verificar o comportamento operacional do produto.

Vale ressaltar que este material teórico contempla as atividades de inspeção e de teste
de software.

13
13
UNIDADE
Verificação e Validação de Software

Inspeção de Software
A inspeção de software está interessada na análise da representação estática do
sistema de software, visando a identificação de problemas, podendo ser apoiada por
ferramentas baseadas em documentos e análise de código. Essa técnica envolve pessoas
examinando principalmente a representação do código-fonte com o objetivo de desco-
brir anomalias e defeitos, não exigindo a execução do sistema e podendo ser aplicada
antes da implementação. As inspeções podem ser aplicadas em qualquer representação
do sistema, tais como requisitos, dados de projeto (design), configuração, dados de teste,
e assim por diante. Essa técnica tem se mostrado bastante eficaz para descobrir defeitos
em um sistema de software (SOMMERVILLE, 2011).

A figura 5 mostra os artefatos, os quais as técnicas de inspeção e de teste podem

ser aplicadas. Observe que a inspeção pode ser aplicada ao longo do processo de de-
senvolvimento, desde a especificação de requisitos, passando pelos modelos de projeto
(design) em UML até a implementação do código (programa). Já o teste pode ser apli-
cado especificamente no protótipo do sistema e no código implementado, já que essa
técnica requer a execução do software.

Inspeções

Especificação Arquitetura Modelos de Esquemas de

de requisitos de sotfware projetos em UML banco de dados Programas

Protótipo
de sistema Teste

Figura 5 – Inspeção e Teste

É importante enfatizar que um checklist de inspeção de defeitos comuns deve ser

utilizado para conduzir a inspeção. Os checklists de inspeção de defeitos são dependen-
tes da linguagem de programação e refletem os erros característicos daquela linguagem.

A aplicação da técnica de inspeção de software oferece algumas vantagens:

• Durante o teste, erros podem esconder outros erros. Já a inspeção é um processo
estático, no qual não é preciso se preocupar com as interações entre os erros;
• Versões incompletas de um sistema de software já podem ser inspecionadas, sem
custos adicionais;
• Além de procurar por defeitos no software, uma inspeção também pode considerar
atributos mais amplos de qualidade, como o cumprimento de normas, portabilidade
e manutenibilidade (SOMMERVILLE, 2011).

Nós podemos afirmar que as atividades de inspeção e teste são técnicas concorrentes?

Não, muito pelo contrário, essas técnicas são complementares. Ambas devem ser apli-
cadas durante os processos de V&V. De qualquer forma, é importante ressaltar que as

14
inspeções podem verificar a conformidade com uma especificação, mas não a conformi-
dade com os requisitos reais do cliente. As inspeções não podem verificar características
não-funcionais, como desempenho, usabilidade, dentre outras (SOMMERVILLE, 2011).

A técnica de inspeção de software é utilizada pelos métodos ágeis?

Métodos ágeis dificilmente utilizam inspeção de software. Ao invés disso, os mem-

bros do time colaboram entre si para controlar o código uns dos outros, além das orien-
tações informais que sugerem que os programadores devem verificar o seu próprio
código. Os adeptos do eXtreme Programming (XP) entendem que a programação em
pares é um substituto eficaz para a inspeção, pois é um processo de inspeção contínua,
onde duas pessoas olham para cada linha de código e verificam se a mesma deve ou não
ser aceita (SOMMERVILLE, 2011).

Teste de Software
O teste está interessado na análise dinâmica do sistema, visando executar o software
com dados de teste a fim de observar o comportamento operacional do produto. Um
bom teste deve revelar a presença de erros, não a sua ausência.

Segundo Koscianski e Soares (2007), o objetivo do teste é encontrar defeitos, re-

velando que o funcionamento do software em uma determinada situação não está de
acordo com o esperado. Um teste bem-sucedido identifica defeitos que ainda não foram
revelados e que podem ser corrigidos pelo programador.

Os testes são destinados a mostrar o que um software faz, o que pretende fazer e
para descobrir os defeitos antes do produto ser colocado em uso. Ao testar o software,
você executa um programa usando dados de teste, permitindo verificar os resultados
para erros, anomalias ou mesmo informações sobre os requisitos não funcionais do
sistema de software. O teste é uma atividade de verificação e validação de software
(SOMMERVILLE, 2011).

De acordo com Sommerville (2011), a atividade de teste tem dois objetivos distintos:
• Demonstrar para o desenvolvedor e o cliente que o software atende aos seus requi-
sitos, configurando testes de validação, pois é esperado que o software seja execu-
tado corretamente usando um determinado conjunto de casos de teste que refletem
o uso esperado do sistema;
• Revelar situações em que o comportamento operacional do software está incor-
reto, indesejável ou em desacordo com sua especificação, configurando testes de
defeito, pois os casos de teste são elaborados para revelarem defeitos; os casos de
teste visando testes de defeito podem ser propositadamente obscuros, não sendo
necessário representar como o sistema de software é usado normalmente.

E quais são os estágios (ou níveis) do teste de software? Há alguma classificação?

15
15
UNIDADE
Verificação e Validação de Software

Sommerville (2011) classifica os testes de software em três estágios:

• Teste de desenvolvimento: o software é testado durante seu desenvolvimento para
descobrir defeitos;
• Teste de release: uma equipe de teste separada testa uma versão completa do
sistema antes que ele seja liberado para a comunidade usuária;
• Teste de usuário: os usuários testam o sistema de software em seu próprio ambiente.

Não há uma classificação universal quanto aos estágios (ou níveis de teste). Os livros
classificam os estágios de teste utilizando terminologias distintas, apesar dos significados
serem semelhantes.

Bastos et al. (2012) consideram que o estágio (ou nível) representa o “quando”, ou
melhor, a fase de desenvolvimento na qual um determinado tipo de teste deve ser apli-
cado. Esses estágios de teste são:
• Teste de unidade: estágio mais baixo da escala de teste, aplicado aos menores ele-
mentos de código desenvolvidos, visando garantir que eles atendam as especifica-
ções funcionais e arquiteturais. Esse teste costuma ser realizado pelo programador
que testa as unidades individuais: funções (ou métodos), classes e componentes;
• Teste de integração: teste do sistema ao término de cada iteração (ciclo de desen-
volvimento ou sprint), a fim de validar a integração dos componentes. Esse teste cos-
tuma ser realizado pelo analista de sistemas que testa um módulo ou conjunto destes;
• Teste de sistema: teste da execução do sistema de software como um todo, para
validar a execução de suas funções a partir de cenários oriundos de casos de uso
ou estórias de usuário. Esse teste costuma ser realizado pelo analista em ambiente
de teste;
• Teste de aceitação: último teste antes da implantação do sistema de software, sendo
sua execução de responsabilidade do cliente. Este visa verificar se o software está pron-
to para ser utilizado pelos usuários para executar as funções para as quais o produto foi
construído. Costuma ser realizado pelo usuário em ambiente de homologação.

O teste de unidade é planejado a partir da fase de construção do software, sendo que esse
estágio geralmente é feito pelo desenvolvedor (programador). Um teste de método de
classe é um teste de unidade.
O teste de integração é planejado a partir da fase de projeto (design) arquitetural, sendo
que esse estágio geralmente é realizado pelo analista de sistemas, arquiteto ou desenvol-
vedor. Um teste de integração de subsistemas é um teste de integração.
O teste de sistema é planejado a partir da fase de especificação (requisitos, casos de uso,
estórias de usuário), sendo que esse estágio de teste geralmente é feito pelo analista de
teste (testador). Um teste de requisito é um teste de sistema.
O teste de aceitação é planejado a partir dos requisitos levantados no domínio de negócio,
sendo que esse estágio geralmente é feito pelo analista (testador) e pelo usuário. Um teste
de liberação do software para ser implantado no ambiente do cliente é um teste de aceitação.

16
 Este material teórico apresentou a importância dos processos de Verificação e Va-
lidação (V&V) no desenvolvimento de sistemas de software, enfatizando conceitos de
qualidade de software e as técnicas de verificação e validação de software, especifica-
mente inspeção de software e teste de software. O teste de software será abordado em
maiores detalhes nas próximas unidades desta disciplina.

O  Guide to the Software Engineering Body of Knowledge, (SWEBOK) é um documen-

to criado sob o patrocínio da IEEE com o propósito de servir de referência em assuntos
considerados, de forma generalizada pela comunidade, como pertinentes à área de En-
genharia de Software, inclusive conteúdos de Qualidade de Software. Maiores informa-
ções sobre o SWEBOK podem ser encontradas em https://goo.gl/351bQA e também em
https://goo.gl/c5ZkLt

17
17
UNIDADE
Verificação e Validação de Software

Material Complementar
Indicações para saber mais sobre os assuntos abordados nesta Unidade:

Sites
ASQ - The Global Voice of Quality
https://goo.gl/F1n1SU
SWEBOK
https://goo.gl/c5ZkLt

Leitura
ISO/IEC 9126
https://goo.gl/FJJxnM
Software Engineering Body of Knowledge
https://goo.gl/351bQA

18
Referências
BARTIE, A. Garantia da qualidade de software. 1.ed. Rio de Janeiro: Campus
Elsevier, 2002.

BASTOS, A.; CRISTALLI, R.; MOREIRA, T.; RIOS, E. Base de conhecimento em

teste de software. 3.ed. São Paulo: Martins Fontes, 2012.

KOSCIANSKI, A.; SOARES, M. S. Qualidade de software. 2.ed. São Paulo:

Novatec, 2007.

PRESSMAN, R. S.; MAXIM. B. R. Engenharia de software. 8.ed. Porto Alegre:

AMGH, 2016.

SOMMERVILLE, I. Engenharia de software. 9.ed. São Paulo: Pearson, 2011.

19
19