AVALIAÇÃO

DE SOFTWARE

autor
MAYB FIATS

1ª edição
SESES
rio de janeiro  2016
Conselho editorial  regiane burger; roberto paes; gladis linhares; karen bortoloti;
helcimara affonso de souza

Autor do original  mayb fiats

Projeto editorial  roberto paes

Coordenação de produção  gladis linhares

Coordenação de produção EaD  karen fernanda bortoloti

Projeto gráfico  paulo vitor bastos

Diagramação  bfs media

Revisão linguística  amanda carla duarte aguiar

Imagem de capa  saniphoto | dreamstime.com

Todos os direitos reservados. Nenhuma parte desta obra pode ser reproduzida ou transmitida
por quaisquer meios (eletrônico ou mecânico, incluindo fotocópia e gravação) ou arquivada em
qualquer sistema ou banco de dados sem permissão escrita da Editora. Copyright seses, 2016.

Dados Internacionais de Catalogação na Publicação (cip)

F442a Fiats, Mayb

Avaliação de software / Mayb Fiats
Rio de Janeiro : SESES, 2016.
144 p. : il.

isbn: 978-85-5548-185-7

1. Avaliação de software. 2. Qualidade de software. 3. Testes.

4. Verificação e validação. I. SESES. II. Estácio.
cdd 005.1

Diretoria de Ensino — Fábrica de Conhecimento

Rua do Bispo, 83, bloco F, Campus João Uchôa
Rio Comprido — Rio de Janeiro — rj — cep 20261-063
Sumário

Prefácio 7

1. Conceitos de Qualidade Software 9

1.1  Definição de qualidade 11
1.2  Qualidade de produto x qualidade de processo de software 13
1.2.1  Produto de software 13
1.2.2  Processo de Software 14
1.3  Fatores de qualidade de software 16
1.4  Pilares da qualidade de software’ 18
1.5  Cenário atual do desenvolvimento de software 19
1.6  Custo da qualidade 22
1.7  Fatores de insucesso do processo da qualidade 23
1.8  Conceito de testes 26

2. Testes de Verificação 33

2.1  Conceitos de testes de verificação 35

2.2  Métodos estruturados de verificação 36
2.2.1 Revisões 36
2.2.2 Auditorias 42
2.2.3  Reunião de acompanhamento 46
2.3  Aplicação e checklist na verificação 47
2.4  Diferentes verificações 48
2.5  Fases dos testes de verificação 49

3. Testes de Validação 55

3.1  Teste de validação 57

3.1.1  Testes de caixa branca 59
 3.1.2  Testes de caixa preta 59
3.2  Abordagens dos testes 61
3.2.1  Testes baseados na estrutura interna 61
3.2.2  Testes baseados nos requisitos 62
3.3  Testes progressivos e regressivos 62
3.4  Categorias dos testes de validação 62
3.5  Norma ISO/IEC 9126-1 65
3.6  Métodos estruturados de validação 70
3.6.1  Casos de testes 70
3.6.2  Métodos de caixa preta para
obtenção de casos de testes 71
3.6.3  Métodos de caixa branca para
obtenção de casos de testes 73
3.7  Fases da validação 74
3.7.1  Validação da unidade 74
3.7.2  Validação da integração 75
3.7.3  Validação do sistema 75
3.7.4  Validação do aceite 76

4. Gerenciamento do Testware e
Gestão das Ferramentas de Apoio a Testes 79

4.1  Conceitos de testware 81

4.2  Ambientes de teste 82
4.2.1  Ambiente de desenvolvimento 86
4.2.2  Ambiente de teste e homologação 86
4.2.3  Ambiente de produção 87
4.3  Ferramentas de apoio a testes 88
4.3.1  Ferramentas para planejamento dos testes 92
4.3.2  Ferramentas de revisões e inspeções 95
4.3.3  Ferramentas de modelagem e automação 96
4.3.4  Ferramentas de execução e conferência 97
4.3.5  Ferramentas de suporte aos testes 98
5. Documentação do Planejamento e
Relatóros das Verificações e Validações 101

5.1  Plano de garantia da qualidade de software 103

5.1.1  Pessoas relacionadas à garantia de qualidade de software 106
5.2  Plano de testes 107
5.3  Plano mestre de verificação 112
5.4  Plano mestre de validação 114
5.5  Casos de teste 115
5.6  Suíte de testes 116
5.7  Norma IEEE 829 116
Prefácio
Prezados(as) alunos(as),

Avaliação é uma palavra que tem sido muito utilizada ultimamente na área
da tecnologia de informação. E se pensarmos com cuidado isso faz todo o sen-
tido, uma vez que a cada dia que passa nós somos bombardeamos com novida-
des tecnológicas.
Com tanta novidade nos sendo apresentada e com tanta rapidez, não é de
espantar a necessidade de avaliação desses novos produtos. Vamos pensar, se
temos tantas tecnologias e produtos a disposição nós vamos querer escolher
sempre o MELHOR, e para isso se faz necessário escolhermos entre elas, deci-
dirmos o que é melhor para mim, para meu departamento, para minha empre-
sa, considerando muitos fatores.
Mas baseado em que eu posso realizar essa escolha?
Bom, aí entra essa nossa disciplina!!! Para poder escolher da melhor manei-
ra, para poder escolher com clareza e certeza eu preciso conhecer e, para adqui-
rir esse conhecimento se faz necessário estudar e AVALIAR seja um produto ou
processo de software!
Sejam muito bem vindos a esse assunto atual, interessante e que com certe-
za vai lhe ajudar a entender como funciona as técnicas de avaliação de softwa-
re, uma área que além de muito interessante é também bastante lucrativa para
seus profissionais.

Bons estudos!

7
 1
Conceitos de
Qualidade Software
Neste capítulo estaremos definindo qualidade de software e vendo como se en-
contra o cenário atual do desenvolvimento de software, como é a realidade dos
projetos de software, além de diferenciar as dimensões da qualidade do proces-
so e do produto de software.
Comentaremos também sobre os custos relacionados à qualidade e a im-
plantação de um processo de qualidade. Aqui serão apresentados alguns fato-
res de insucesso do processo de qualidade.
Finalizaremos esse capítulo conceitualizando a atividade de testes.

OBJETIVOS
•  Definir qualidade de software (produto e processo);
•  Compreender a realidade dos projetos de software;
•  Compreender os custos relacionados a qualidade;
•  Entender o que são testes.

10 • capítulo 1
1.1  Definição de qualidade
A exigência por qualidade pode ser considerada o centro das atenções para o
desenvolvimento de software. Por exemplo, do ponto de vista dos fornecedores
de software, qualidade não é mais um fator de vantagem no mercado, mas uma
condição necessária e pode-se dizer indispensável para que seja possível com-
petir com sucesso.
Qualidade é um termo que pode ter diferentes interpretações e para se estu-
dar a qualidade de software de maneira efetiva é necessário, inicialmente, obter
um consenso em relação à definição de qualidade de software que está sendo
abordada. Existem muitas definições de qualidade de software propostas na
literatura, sob diferentes pontos de vistas, vejamos alguns:
•  Qualidade de software é a conformidade a requisitos funcionais e de de-
sempenho que foram explicitamente declarados, a padrões de desenvolvimen-
to claramente documentados, e a características implícitas que são esperadas
de todo software desenvolvido por profissionais” [Pressman,2002].
•  “Um produto de software apresenta qualidade dependendo do grau de sa-
tisfação das necessidades dos clientes sob todos os aspectos do produto”.
•  Qualidade é a totalidade de características e critérios de um produto ou
serviço que exercem suas habilidades para satisfazer as necessidades declara-
das ou envolvidas “[ISO9126 1994].
•  Qualidade é a totalidade das características de uma entidade, que lhe con-
fere a capacidade de satisfazer necessidades explícitas e implícitas [NBR ISO
8402, 1994].

Existe, ainda, uma visão de qualidade de software do ponto de vista gerencial, que diz
que o software que possa ser desenvolvido dentro do prazo e do orçamento especi-
ficados pode ser um software de alta qualidade. Isso demonstra que, ainda dentro da
qualidade de software, pode-se definir várias visões diferentes, como tem sido para a
definição da qualidade como um termo geral.

capítulo 1 • 11
 De um modo geral, qualidade de software pode ser definida como:
Um conjunto de atributos de software que devem ser satisfeitos de modo
que o software atenda às necessidades do usuário (seja ele um usuário final,
um desenvolvedor ou uma organização), onde a determinação dos atributos re-
levantes para cada software varia em função:

•  do domínio da aplicação
•  das tecnologias utilizadas
•  das características específicas do projeto
•  das necessidades do usuário e da organização

Podemos dizer ainda que a qualidade depende também do ponto de vista de

quem a avalia, onde usuários, desenvolvedores e organizações podem ter pon-
tos de necessidades diferentes:

Avalia o software sem conhecer seus aspectos inter-

nos, está apenas interessado na facilidade do uso, no
USUÁRIO desempenho, na confiabilidade dos resultados e no
preço.

Avaliam aspectos de conformidade em relação aos

DESENVOLVEDORES requisitos dos clientes e também aspectos internos
do software.

Avalia aspectos de conformidade em relação aos

ORGANIZAÇÃO requisitos dos clientes e desenvolvedores e também
aspectos de custo e cronograma.

A qualidade de um software está diretamente relacionada com a qualida-

de de um processo de software. Devido a importância desse assunto dentro do
contexto do nosso estudo, vamos entender um pouco mais sobre o produto e o
processo de software? Vamos lá!

12 • capítulo 1
1.2  Qualidade de produto x qualidade de
processo de software

Qualidade de Software pode ser vista como um conjunto de características que

devem ser alcançadas em um determinado grau para que o produto atenda as
necessidades de seus usuários [Rocha et al.,2001]. A qualidade do produto final
é profundamente afetada pela qualidade do processo de desenvolvimento, por-
tanto a qualidade deve ser uma meta a ser alcançada e aprimorada ao longo do
processo de software.
Aqui se faz importante definirmos o que vem a ser um produto de softwa-
re, assim como esclarecermos alguns pontos de um processo de software, va-
mos lá?

1.2.1  Produto de software

Um produto de software compreende os programas e procedimentos de com-

putador e a documentação e dados associados, que foram projetados para se-
rem liberados para o usuário [ISO/IEC 12207-1, 1995].
Da mesma forma como existem diversas interpretações para qualidade de
um modo geral, também existem diversas interpretações para qualidade de um
produto de software, tais como:

•  Boa fabricação.
•  Deve durar muito.
•  Bom desempenho.
•  Adaptável às minhas necessidades específicas
•  Fácil de usar.
•  Sem defeitos, entre outros.

A especificação de Qualidade de Produto de Software deve ser mais precisa

e detalhada. A formalização de Qualidade de Produto de Software pode ser feita
usando-se um Modelo de Qualidade de Produto de Software.

capítulo 1 • 13
 CONEXÃO
Para compreender um pouco mais sobre nosso assunto, veja o link http://cbsoft2013.unb.
br/wp-content/uploads/2013/10/ST1-2.pdf, um excelente artigo para aumentar nossos
conhecimentos. Boa leitura!

Como mesmo as proposições bem sucedidas trazem dificuldades de aplica-

ção, por causa dos muitos aspectos de qualidade oferecidos, surgiu a necessi-
dade de um modelo padronizado. Por essa razão o comitê técnico da ISO/IEC
começou a trabalhar para desenvolver o consenso requerido e encorajar a pa-
dronização em nível mundial. As primeiras tentativas de padronização surgi-
ram em 1978. Em 1985 foi iniciado o desenvolvimento da Norma Internacional
ISO/IEC 9126 – “Information Technology – Software product evaluation –
Quality characteristics and guidelines for thei use” - publicada em 1991.
A Norma NBR 13596 é uma tradução da Norma ISO/IEC 9126. Foi elaborada
pela comissão de Estudos de Qualidade de Software do Subcomitê de Software
do Comitê de Informática da ABNT – Associação Brasileira de Normas Técnicas
e publicada em agosto de 1996. A norma avalia a qualidade de um produto de
software através de um conjunto de características. Essas características são di-
vididas em seis grandes grupos, os quais serão apresentados detalhadamente
no capítulo 2.

1.2.2  Processo de Software

Vejamos algumas definições da palavra processo:

•  Um processo é “a maneira pela qual se realiza uma operação, segundo
determinadas normas” (dicionário Aurélio).
•  Um processo é uma seqüência de passos realizados para um dado propó-
sito” (IEEE).
•  O processo integra pessoas, ferramentas e procedimentos.
•  Processo é o que as pessoas fazem, usando procedimentos, métodos, fer-
ramentas e equipamentos, para transformar matéria prima (entrada) em um
produto (saída) que tem valor para o cliente.

14 • capítulo 1
 Um processo de software pode ser definido como um conjunto de ativida-
des, métodos, práticas e transformações que as pessoas usam para desenvolver
e manter o software e os produtos associados (por exemplo: planos de projeto,
documentos, código, casos de teste e manuais de usuário) [IEEE-STD-610].
Um processo de software envolve um grande conjunto de elementos, tais
como objetivos organizacionais, políticas, pessoas, comprometimentos, ferra-
mentas, métodos, atividades de apoio e as tarefas da engenharia de software.
Para que o processo de software seja eficiente ele precisa ser constantemente
avaliado, medido e controlado. Quando as empresas não possuem conheci-
mento suficiente de todos os elementos do processo, essas atividades de ava-
liar, medir e controlar ficam difíceis de serem realizadas, nesse caso o processo
de software passa a ser descontrolado, sem gerência e até mesmo caótico.
Algumas características de processos de software caóticos são
[Pressman,2002].
•  o processo é improvisado (profissionais e gerentes).
•  o processo não é rigorosamente seguido e o cumprimento do mesmo não
é controlado.
•  o processo é altamente dependente dos profissionais atuais.
•  a visão do progresso e da qualidade do processo é baixa.
•  a qualidade do produto decorrente do processo é comprometida em fun-
ção de prazos.
•  Quando são impostas datas urgentes para entrega dos produtos, freqüen-
temente, a funcionalidade e a qualidade dos mesmos são comprometidas para
atender o cronograma.
•  Não existe nenhuma base objetiva para julgar a qualidade do produto ou
para resolver problemas de processo ou de produto, portanto, a qualidade do
produto é difícil de ser prevista.
•  As atividades ligadas à melhoria da qualidade, tais como revisões e testes,
freqüentemente são encurtadas ou eliminadas quando os projetos ultrapas-
sam o cronograma previsto.

Já quando as coisas caminham bem e o processo é controlado e gerenciado

com eficiência o processo passa a ser bom, passa a ser maduro e eficiente, ge-
rando resultados positivos, tais como:
•  O processo continua a despeito de problemas inesperados (Robustez).
•  Rapidez na produção do sistema (Velocidade).

capítulo 1 • 15
 •  O processo é aceito por todos os envolvidos nele (Aceitabilidade).
•  Os erros do processo são descobertos antes que resultem em erros no pro-
duto (Confiabilidade).
•  O processo evolui para atender alterações de necessidades organizacio-
nais (Manutenibilidade).
•  O processo é compreendido (usualmente através de documentação e de
treinamento), utilizado, vivo e ativo.
•  O processo é bem controlado – a fidelidade ao processo é objeto de audi-
toria e de controle.
•  Medidas do produto e do processo são utilizadas.
•  Os papéis e responsabilidades no processo estão claros ao longo de todo o
projeto e por toda a organização.

A produtividade e a qualidade dos produtos de software resultantes podem

ser melhoradas com o tempo através de ganhos consistentes na disciplina obti-
da pelo uso do processo de software.

•  Os gerentes monitoram a qualidade dos produtos de software e a satisfa-

ção do cliente.
•  Existe uma base quantitativa, objetiva para julgar a qualidade dos produ-
tos e analisar problemas com o produto e o processo.
•  As organizações com processo de software de alta qualidade tem
esse processo institucionalizado através de políticas, padrões e estrutu-
ras organizacionais.

Bom pessoal, acredito que tenha ficado claro que para se alcançar os objeti-
vos de produtividade e qualidade é necessário que o processo de software seja
eficiente, definido, gerenciado, medido e controlado.

1.3  Fatores de qualidade de software

Existem dois tipos de qualidade de software: um
tipo
de
qualidade
com
a
qual
o usuário
do
programa interage – essa é
a
qualidade externa.
 E um tipo de
qualidade
com
a
qual outros desenvolvedores interagem – essa é
a
qualidade
interna, sendo assim podemos dizer te temos os fatores de qualidade interno e
os fatores de qualidade externo (Pressman 2002).

16 • capítulo 1
Fatores externos- ponto de vista do usuário:

Característica do software que realiza as tarefas como

CORREÇÃO foram definidas em sua especificação de requisitos.

Um software é robusto se realiza as suas tarefas de

ROBUSTEZ forma correta mesmo quando submetido a condições
anormais.

Característica de um software poder ser facilmente

EXTENSIBILIDADE adaptado a inclusões e alterações de requisitos.

Característica de um software que pode ser reutilizado

REUSABILIDADE ao todo ou em parte por outros softwares.

Facilidade de se combinar o software com outros

softwares. Essa característica é importante porque
COMPATIBILIDADE raramente um software é construído sem interação
com outros softwares.

Refere-se ao bom uso que o software faz dos recursos

EFICIÊNCIA de hardware, tais como memória e processadores.

É a facilidade de se utilizar o software em diferentes

PORTABILIDADE ambientes de hardware e software.

É a facilidade de se preparar rotinas para se verificar a

VERIFICABILIDADE conformidade do software com os seus requisitos.

capítulo 1 • 17
 É uma característica relacionada à segurança de
dados, programas e documentos. Integridade é a ha-
INTEGRIDADE bilidade de proteger tais componentes contra acessos
não autorizados.

Também denominada usabilidade, é a facilidade com

FACILIDADE DE USO que o software pode ser aprendido e utilizado.

Fatores internos: ponto de vista estrutural do software. Permitem atingir os

fatores externos:
•  Modularidade: característica de um software que é constituído por unida-
des denominadas módulos.
•  Legibilidade.
•  Manutenibilidade: facilidade de realizar manutenção em um software.

A forma com um software é construído permite atingir os fatores internos

de qualidade. Os fatores internos de qualidade permitem atingir os fatores ex-
ternos de qualidade.

1.4  Pilares da qualidade de software’

Os pilares da qualidade de software são:

Destinado a identificar quais os padrões de qualidade

são importantes para o projeto e determinar como
PLANEJAMENTO DA satisfazê-los. Tem como produto o Plano da Garantia da
QUALIDADE Qualidade de Software (SQA PLAN – Software Quality
Assurance Plan).

GARANTIA DA Aqui estão os testes de verificação (estáticos) e os

QUALIDADE testes de validação (testes dinâmicos).

18 • capítulo 1
 Monitoramento e desempenho dos resultados do proje-
CONTROLE DA to para determinar se ele está atendendo aos padrões
QUALIDADE de qualidade no processo de desenvolvimento .

É um processo contínuo.

1.5  Cenário atual do desenvolvimento de

software

Como observamos no item anterior a qualidade é um fator extremamente im-

portante dentro do dentro do desenvolvimento de software, porém não é uma
tarefa assim tão fácil de se realizar.
Tendo visto a sua importância e, sabendo da crescente demanda e necessi-
dade por software, fica claro que nenhuma empresa deveria abrir mão de esfor-
ços para alcançar a qualidade, porém na prática, não é exatamente assim que
acontece e, um dos motivos é a grande dificuldade de se implementar essa tão
necessária qualidade.
A boa notícia é que muitas empresas estão se movimentando no sentido de
definirem detalhadamente seus processos para apoiarem suas atividades de
desenvolvimento. As mpresas nacionais estão se preocupando com a qualidade
dos serviços que oferecem, conseguindo, dessa forma, uma inserção maior no
mercado internacional de desenvolvimento de software.
Entretanto, o cenário de desenvolvimento de software atual e o cenário
idealizado junto à engenharia de software ainda estão distantes. Vários fato-
res contribuem para isso, podemos citar dois

•  O não uso dos fundamentos da engenharia de software para apoiar as ati-

vidades do desenvolvimento;
•  O mau uso dos fundamentos da engenharia de software para apoiar as
atividades do desenvolvimento.

capítulo 1 • 19
 Vamos dar uma olhada na realidade e dificuldade do cenário de desenvolvi-
mento dos software observando a tabela 1.1 (Cenário atual de desenvolvimen-
to) e a seguir a figura 1.1 (Distribuição da conclusão dos projetos de software):

% DO CUSTO DE % DOS ERROS % DOS ERROS CUSTO RELATIVO DE

DESENVOLVIMENTO INTRODUZIDOS ENCONTRADOS CORREÇÃO
ANALISE DE 5 55 18 1
REQUITOS
PROJETO 25 30 10 1 – 1.5

CÓDIFICAÇÃO E 50
TESTE DE UNIDADE
TESTE 10 10 50 1–5

VALIDAÇÃO E 10
DOCUMENTAÇÃO
MANUTENÇÃO 5 22 10 – 100

Tabela 1.1  –  Cenário atual de desenvolvimento.

Sucesso Problemático
Fracasso

Figura 1.1  –  Distribuição da conclusão dos projetos de software

Na tabela 1.2, podemos perceber que são vários os fatores que podem preju-
dicar o sucesso de um projeto de software.

FATORES CRÍTICOS %

1. REQUISITOS INCOMPLETOS 13.1%

20 • capítulo 1
 FATORES CRÍTICOS %

2. FALTA DE ENVOLVIMENTO DO USUÁRIO 12.4%

3. FALTA DE RECURSOS 10,6%

4. EXPECTATIVAS IRREAIS 9,9%

5. FALTA DE APOIO EXECUTIVO 9,3%

6. MUDANÇA DE REQUISITOS E ESPECIFICAÇÕES 8,7%

7. FALTA DE PLANEJAMENTO 8,1%

8. SISTEMA NÃO MAIS NECESSÁRIO 7,5%

Tabela 1.2  –  Fatores críticos do sucesso.

Pudemos perceber que apesar de sabermos da grande necessidade de se ob-

ter a qualidade em um projeto de software, a mesma nem sempre é obtida e,
as tabelas acima nos deixa claro vários fatores que prejudicam o sucesso dessa
obtenção da qualidade.
Um dos grandes desafios da implantação de um processo de software de
qualidade é não tolerar erros, inibir e impedir falhas, por isso é importante, ga-
rantir a qualidade de cada etapa do processo de desenvolvimento de software.

capítulo 1 • 21
1.6  Custo da qualidade
Como alguns costumam dizer: “Você pode fazer direito ou fazer novamente”
Se uma equipe de software enfatiza a qualidade em todas as atividades de
engenharia de software, reduz a quantidade de trabalho a ser refeito, resultan-
do em menores custos, e melhores prazos para colocação no mercado.
Os custos vão aumentando conforme os defeitos vão se propagando dentro
do processo de software.
Podemos dividir os custos da qualidade em dois:

Objetivo é a detecção e prevenção de erros. Tudo que

CUSTOS DA é realizado com a intenção de melhorar e garantir o
CONFORMIDADE processo de desenvolvimento (Revisões, inspeções e
testes).

Esforço para reparar falhas originadas no decorrer do

CUSTOS DA processo de desenvolvimento (Re-revisões, re-testes,
NÃO-CONFORMIDADE re-estruturação, etc).

Como seria utópico alcançar a perfeição em um sistema de computação, en-

tão o mais importante passa a ser definir qual nível de checagem (de qualidade)
seria suficiente para o sistema em questão e os custos associados.
O custo de qualidade inclui todos os gastos financeiros relacionados às ati-
vidades de qualidade, os quais podem ser divididos em: custos de prevenção,
custos de avaliação e custos de falhas.
Os custos de prevenção incluem:
•  planejamento da qualidade;
•  revisões técnicas formais;
•  teste de equipamentos;
•  treinamento.

Os custos de avaliação incluem:

•  inspeções dos processos e relações entre eles;
•  manutenção dos equipamentos;
•  testes.

22 • capítulo 1
 Os custos de falhas poderiam desaparecer se nenhum defeito ocorresse an-
tes da entrega do produto para o cliente. Os custos de falhas podem ser dividi-
dos em: custos de falhas internas e custos de falhas externas.
Os custos de falhas internas incluem:
•  retrabalho;
•  conserto de bugs;
•  análise de falhas.

Os custos de falhas externas incluem:

•  resolução de queixas;
•  troca/devolução do produto;
•  suporte em help on-line;
•  trabalhos de segurança.

Os custos relacionados a encontrar e consertar um defeito aumentam dras-

ticamente quando vamos da prevenção de falhas internas para a prevenção de
falhas externas.

1.7  Fatores de insucesso do processo da

qualidade

Atualmente, gerentes de projetos estão constantemente procurando maneiras

de entregar produtos de qualidade o mais rápido possível. De maneira geral,
projetos de desenvolvimento de software são como quaisquer outros tipos de
projetos, de modo que existem cronogramas a serem cumpridos, recursos a
serem gerenciados e objetivos a serem conquistados. Entretanto, a grande di-
ferença vem do fato de que cada projeto de software é único. De modo que um
projeto obtenha sucesso, é preciso que o mesmo crie um produto que atenda
as expectativas do cliente, sendo entregue em um prazo adequado. Diante dos
recursos limitados e da quantidade ilimitada de trabalho, a produtividade do
time responsável pelo projeto se torna um fator crítico para seu sucesso, visto
que a eficiência com que os recursos são empregados no desenvolvimento de
software é um fator primordial para o sucesso do projeto.

capítulo 1 • 23
 Vários estudos ao longo da história analisaram projetos de desenvolvimen-
to de software e apontaram os fatores que afetam a qualidade e produtividade
em projetos de software. Cada um dos estudos produziu resultados de grande
relevância, mas que podem ser combinados de modo a permitir uma análise
da sistêmica e correlação entre os fatores. Desse modo, se torna importante ter
uma definição clara dos fatores que afetam a produtividade, bem como uma
categorização de modo a permitir uma melhor identificação dos mesmos.

Fatores relacionados ao processo:

Organizações que têm focado explicitamente na melhoria dos seus processos

de software, ao longo do tempo, têm diminuído o time-to-market pela metade,
bem como reduzido os custos e defeitos em fatores de 3 a 10.

Fatores relacionados com a tecnologia:

A tecnologia associada ao projeto também possui uma grande influência na

produtividade geral do projeto. O uso de ferramentas pode melhorar a produti-
vidade em projetos de software, facilitando a execução de atividades não prati-
cadas até então. No entanto, a introdução de ferramentas pode também dimi-
nuir a produtividade, que pode ocorrer quando o uso da ferramenta aumenta o
esforço necessário para desempenhar determinadas atividades ou até mesmo
introduz novas atividades ao processo utilizado. Com isso, dependendo das ca-
racterísticas do projeto, a mesma ferramenta pode ocasionar diferentes efeitos
na produtividade.

Fatores relacionados com as pessoas:

De forma a aumentar a produtividade em projetos atrasados em seus cronogra-

mas, muitos gerentes adicionam pessoas aos mesmos. No entanto, de acordo
com (Brooks 1995), adicionar pessoas a um projeto com cronograma atrasa-
do, apenas o tornará ainda mais atrasado, uma vez que aumentará o esforço
total de três maneiras: o reparticionamento do trabalho como um todo, o trei-
namento das novas pessoas e o aumento da necessidade de comunicação. os
fatores relacionados com pessoas que afetam a produtividade em projetos de
software são: tamanho da equipe; experiência da equipe de desenvolvimento;
existência de especialistas; experiência da gerência e turnover.

24 • capítulo 1
Fatores relacionados com a cultura organizacional:

Medir a produtividade é importante para que se busque sua constante melho-

ria. Geralmente, uma vez que o funcionário não tem ideia de sua produtividade,
não importa a notícia sobre sua produtividade, seja ela boa ou ruim, ele sempre
ficará surpreso. Gerentes de projeto têm comprometido a qualidade do projeto
estipulando deadlines impossíveis, embora saibam que existe uma tendência
por parte dos desenvolvedores de se vincular a auto-estima à qualidade do tra-
balho, e não à quantidade. No Japão, a qualidade está intrinsecamente relacio-
nada com a produtividade. Na maioria dos casos, a decisão de pressionar as
pessoas para entregar o projeto que não satisfaça com sua qualidade é quase
sempre um erro (DeMarco 1999). Apesar disso, (Jones 1999) afirma que a exis-
tência de uma pressão moderada por parte da gerência pode ocasionar um
aumento na produtividade em torno de 11%. Caso tal pressão seja excessiva,
a produtividade pode ter uma diminuição de até 30%. (DeMarco 1999) afirma
que as organizações devem incentivar o surgimento de grupos de pessoas, nos
quais a força do grupo seja mais forte do que a soma das forças dos integrantes
do grupo.

Fatores relacionados com o produto:

Além das características intrínsecas do produto, a complexidade do produto

contribui satisfatoriamente para a produtividade com que o mesmo é desenvol-
vido. Segundo (Jones 1999), a complexidade pode prover um aumento na pro-
dutividade de 13%, nos casos de produtos pouco complexos, e uma diminuição
de 35% na produtividade, nos casos de produtos muito complexos.

Podemos ainda, citar alguns outros fatores, tão importantes quantos, que
são: a ausência de gerência de qualidade independente (muitas empresas não
criam uma área de qualidade de software), ausência de procedimentos de tes-
tes automatizados (é importante investir na automatização dos processos de
testes, uma vez que as interferências humanas fragilizam o modelo, sendo
considerada também extenuante, devido ao grande esforço de repetição que
muitos testes exigem, muitas vezes tornando a atividade inviável), qualidade
aplicada tardiamente no projeto (infelizmente, muitas empresas, insistem
em realizar os testes somente após a produção do software ou quando está

capítulo 1 • 25
parcialmente pronto), ausência de profissionais capacitados em qualidade (os
profissionais ligados as atividades de qualidade de software devem possuir a
metodologia totalmente desenhada para atender seu objetivo, que é encontrar
falhas em todos o ciclo de desenvolvimento do projeto de software de forma
a avaliar a solidez do produto desenvolvido), falta de um modelo corporativo
de qualidade (normalmente, a falta de uma gerência de qualidade de software
nas organizações faz com que cada projeto adote uma forma de estruturar o
processo de qualidade de software), deficiência no planejamento dos testes (o
correto planejamento dos testes é um exercício mental que produz uma visão
de como resolver um conjunto de situações, antecipando os passos de realiza-
ção dos testes. Através do estudo do problema analisamos as soluções, opera-
cionalizamos uma sequencia de atividades e prevemos eventuais riscos e insu-
cessos), sob pressão, os testes são sacrificados (é muito comum que os prazos
de entrega de um software sejam maiores do que o prazo planejado e os custos
ultrapassarem o orçado. Nestes casos, normalmente algumas etapas são sacri-
ficadas e, normalmente essas etapas são a modelagem, estruturação da solução
e testes. As fases não são totalmente sacrificadas, mas reduzidas), ausência de
uma ambiente isolado de testes (o processo de validação de um software exige
um ambiente exclusivo de testes, isolado de qualquer interferência dos demais
ambientes de desenvolvimento e produção. A interferência pode comprometer
a qualidade dos testes, bem como a confiabilidade das informações e proces-
sos executados. Este isolamento garante que nenhuma atividade externa preju-
dicará a execução dos procedimentos de testes, aumentando o nível de eficiên-
cia dos trabalhos), transferir o planejamento ao analista de sistemas (somente
o analista de testes tem a percepção

1.8  Conceito de testes

O processo de desenvolvimento de software envolve uma série de atividades
nas quais, apesar das técnicas, métodos e ferramentas empregados, erros no
produto ainda podem ocorrer. Atividades agregadas sob o nome de Garantia de
Qualidade de Software têm sido introduzidasao longo de todo o processo de de-
senvolvimento, entre elas atividades de VV&T – Verificação, Validação e Teste,
com o objetivo de minimizar a ocorrência de erros e riscos associados.
Dentre as técnicas de verificação e validação, a atividade de teste é uma das
mais utilizadas, constituindo-se em um dos elementos para fornecer evidências

26 • capítulo 1
da confiabilidade do software em complemento 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.
A atividade de teste consiste de uma análise dinâmica do produto e é uma
atividade relevante para a identificação e eliminação de erros que persistem.
Do ponto de vista de qualidade do processo, o teste sistemático é uma ativi-
dade fundamental para a ascensão ao Nível 3 do Modelo CMM do Software
Engineering Institute — SEI. Ainda, o conjunto de informação oriundo da
atividade de teste é significativo para as atividades de depuração, manuten-
ção e estimativa de confiabilidade de software. Salienta-se que a atividade de
teste tem sido apontada como uma das mais onerosas no desenvolvimento de
software. Apesar deste fato, Myers observa que aparentemente conhece-se mui-
to menos sobre teste de software do que sobre outros aspectos e/ou atividades
do desenvolvimento de software.
Antes de iniciarmos uma discussão mais aprofundada sobre testes de
software precisamos esclarecer alguns conceitos relacionados a essa ativi-
dade. Inicialmente, precisamos conhecer a diferença entre Defeitos, Erros
e Falhas. As definições que iremos usar aqui seguem a terminologia padrão
para Engenharia de Software do IEEE – Institute of Electrical and Electronics
Engineers – (IEEE 610, 1990).

É um ato inconsistente cometido por um indivíduo ao tentar

entender uma determinada informação, resolver um proble-
DEFEITOS ma ou utilizar um método ou uma ferramenta. Por exemplo,
uma instrução ou comando incorreto.

É uma manifestação concreta de um defeito num artefato de

software. Diferença entre o valor obtido e o valor esperado,
ERROS ou seja, qualquer estado intermediário incorreto ou resultado
inesperado na execução de um programa constitui um erro.

É o comportamento operacional do software diferente do

FALHAS esperado pelo usuário. Uma falha pode ter sido causada por
diversos erros e alguns erros podem nunca causar uma falha.

capítulo 1 • 27
 A figura 1.2 expressa a diferença entre esses conceitos. Defeitos fazem parte
do universo físico (a aplicação propriamente dita) e são causados por pessoas,
por exemplo, através do mal uso de uma tecnologia. Defeitos podem ocasionar
a manifestação de erros em um produto, ou seja, a construção de um software
de forma diferente ao que foi especificado (universo de informação). 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) e pode
inviabilizar a utilização de um software.

Instrução ou comando Desvio da Processamento incorreto e

incorreto especificação comportamento inconsistente

Falha
Defeito Erro
Universo físico
Universo da informação
Universo do usuário

Figura 1.2  –  Defeito x erro x falha.

O tamanho do projeto a ser desenvolvido e a quantidade de pessoas envolvi-

das no processo são dois possíveis fatores que aumentam a complexidade des-
sa tarefa, e consequentemente aumentam a probabilidade de defeitos. Assim,
a ocorrência de falhas é inevitável. Mas o que significa dizer que um programa
falhou? Basicamente significa que o funcionamento do programa não está de
acordo com o esperado pelo usuário. Por exemplo, quando um usuário da li-
nha de produção efetua consultas no sistema das quais só a gerência deveria ter
acesso. Esse tipo de falha pode ser originado por diversos motivos:
•  A especificação pode estar errada ou incompleta;
•  A especificação pode conter requisitos impossíveis de serem implemen-
tados devido a limitações de hardware ou software;
•  A base de dados pode estar organizada de forma que não seja permitido
distinguir os tipos de usuário;
•  Pode ser que haja um defeito no algoritmo de controle dos usuários.

Os defeitos normalmente são introduzidos na transformação de infor-

mações entre as diferentes fases do ciclo de desenvolvimento de um softwa-
re. Vamos seguir um exemplo simples de ciclo de vida de desenvolvimento de

28 • capítulo 1
software: os requisitos expressos pelo cliente são relatados textualmente em um
documento de especificação de requisitos. Esse documento é então transforma-
do em casos de uso, que por sua vez foi o artefato de entrada para o projeto do soft-
ware e definição de sua arquitetura utilizando diagramas de classes da UML. Em
seguida, esses modelos de projetos foram usados para a construção do software
em uma linguagem que não segue o paradigma orientado a objetos. Observe que
durante esse período uma série de transformações foi realizada até chegarmos
ao produto final. Nesse meio tempo, defeitos podem ter sido inseridos.
A figura 1.3 expressa exatamente a metáfora discutida nesse parágrafo.

Como o Sistema Como Como

foi descrito no foi foi
Levantamento definido especificado
inical pela no projeto
Análise

Como Como foi

corrigido O que o
foi usuário
implementado pela
Manutenção queria

Figura 1.3  –  Diferentes Interpretações ao longo do ciclo de desenvolvimento de um software.

Essa série de transformações resultou na necessidade de realizar testes em

diferentes níveis, visando avaliar o software em diferentes perspectivas de acor-
do com o produto gerado em cada fase do ciclo de vida de desenvolvimento.
Princípios para um bom Teste:

Para que a etapa de testes aconteça de forma correta é necessário tomar al-
guns cuidados, tais como:
•  Planejar o tipo de teste a ser realizado,
•  Planejar detalhes de cada atividade,
•  Definir todo o procedimento de testes,
•  Definir quais são os resultados esperados,

capítulo 1 • 29
 •  Avaliar resultados obtidos (Obtido x Esperado),
•  Melhoramento Contínuo do Processo, redefinindo técnicas e a confiabi-
lidade prevista, através de melhoria em normas, políticas, procedimentos e fer-
ramentas de testagem.

Podemos perceber a importância de um plano de testes para que tudo ocor-

ra como o esperado. Um plano de teste deve possuir as seguintes etapas:

Processo de Teste:
•  Descrição de cada fase do Teste (Estratégia).

Rastreabilidade de Requisitos:
•  Planejamento de teste para cada requisito.

Itens que serão Testados:

•  Descrição detalhadas de cada Item que será “testado” (Modelo, Manual,
Programa etc).

Cronograma:
•  Além do Tempo, Matriz de Alocação de Recursos x Atividades-Fases
Engenharia de Software .

Procedimentos de Registro:
•  Definição das Métricas e Padronização dos mecanismos de registro de re-
sultados, para que o processo de teste possa ser medido.

Requisitos de Hardware, Software e Rede:

•  Lista de recursos necessários para o teste.

Descrição das Restrições:

•  Restrições que afetarão o processo de teste (Ex: Deficiência de Pessoal,
Treinamento de Pessoal, Aquisição de Software etc).

Para fixarmos os conhecimentos apresentados nesse capítulo, a seguir se-

guem algumas questões a serem respondidas.

30 • capítulo 1
 ATIVIDADES
01. Defina qualidade de software.

02. Defina processo de software e comente as características de um bom processo

de software.

03. Explique o que significa a atividade de teste dentro do ciclo de desenvolvimento

de software.

04. Diferencie defeito, erro e falha.

05. Quais etapas fazem parte de um plano de testes?

REFLEXÃO
Neste capítulo pudemos conhecer um pouco mais sobre o assunto qualidade de software,
entendendo a sua importância.
Com a grande demanda para softwares em todas as áreas e, com a pessoas cada vez mais
exigentes, a qualidade é fator crucial para que empresas de desenvolvimento de software não
fechem suas portas e possam continuar competindo nesse mercado cada vez mais acelerado.
A qualidade de software pode ser subdividida em qualidade de produto e qualidade de
processo, sendo as duas extremamente importantes e relacionadas. A qualidade de produto
está diretamente relacionada ao produto final e a qualidade de processo está relacionada a
maturidade do processo de software. Costumamos dizer que quanto mais maduro é o pro-
cesso melhor qualidade ele possui e, que quanto mais imaturo é o processo maior é o caos
do mesmo. O essencial em uma empresa de desenvolvimento de software é que esses dois
conceitos andem de mãos dadas, um completando o outro.
Analisamos nesse capítulo também que a qualidade tem um custo para as empresas e,
que, no cenário atual de software muitas empresas que buscam pela qualidade encontram
várias dificuldades, mas que no final elas compensam e acabam agregando muito valor aos
produtos, processos e também para a empresa.
Finalizamos nosso capítulo dando destaque a atividade de teste de software, uma ativi-
dade que consiste de uma análise dinâmica do produto e que é uma atividade relevante para
a identificação e eliminação de erros que persistem. Vimos a importância de se diferenciar

capítulo 1 • 31
erros, defeitos e falhas e que, quanto mais demoramos para identificá-los mais prejudicamos
e aumentamos os custos do software.

LEITURA
Uma experiência na implantação de processo de software em uma fábrica de
software livre. Disponível em: <http://www.cin.ufpe.br/~in953/publications/papers/
UmaExperienciaNaImplantacaoDeProcessoEmUmaFabricaDeSoftwareLivre.pdf>.
Introdução a Qualidade de Software. Disponível em: <http://www.ufpa.br/srbo/
Disciplinas/TecnologiaProcessosSoftware/Aulas/Qualidade.pdf>.
Qualidade de software: visão geral. Disponível em: <file:///C:/Users/Mayb/
Downloads/Aula03_QualidadeSoftware.pdf>.

REFERÊNCIAS BIBLIOGRÁFICAS
NBR ISO/IEC 9126-1: Engenharia de Software – Qualidade de produto – Parte 1: Modelo de
qualidade. Rio de Janeiro: ABNT, 2003.
PRESSMAN, Roger S. Engenharia de Software. Rio de Janeiro: MacGraw Hill, 2006.
ROCHA, ANA REGINA CAVALCANTI; MALDONADO, JOSÉ CARLOS; WEBER, KIVAL CHAVES.
Qualidade de Software – Teoria e Prática. 1 ed. São Paulo: Prentice Hall, 2001.
SANCHES, ROSELY. Material Didático: Qualidade de Software. ICMC-USP, 2003.
SANCHES, ROSELY; FABBRI, SANDRA PINTO; MALDONADO, JOSÉ CARLOS. Qualidade de
Software: da engenharia de software aos modelos de qualidade. VI Escola Regional de Informática,
SBC, 2003.
SOMERVILLE, IAN. Engenharia de Software. 6 ed. São Paulo: Addison Wesley, 2003.

32 • capítulo 1
 2
Testes de
Verificação
No capítulo anterior vimos os conceitos de qualidade de software e percebemos
que o mesmo é extremamente importante, visto que, com a grande demanda
de software, os clientes encontram-se cada vez mais exigentes e o mercado cada
dia mais competitivo.
Apesar da necessidade da qualidade nos softwares, garantir isso nem sem-
pre é uma tarefa fácil para as empresas desenvolvedoras de software, uma vez
que envolve muitas atividades, dentre elas a atividade de testes.
A atividade de teste constitui uma anomalia interessante para o engenhei-
ro de software. Durante as fases de definição e desenvolvimento anteriores, o
engenheiro tenta construir o software, partindo de um conceito abstrato para
uma implementação tangível. Agora, surge a fase de testes. O engenheiro cria
uma série de casos de teste que tem a intenção de “demolir”o software que
ele construiu.
A atividade de teste deve promover culpa?
A atividade de testes é realmente destrutiva?
A reposta a essas perguntas é “Não!”.
Vamos, agora, nesse capítulo aprender um pouco mais sobre os conceitos
de testes de verificação.

OBJETIVOS
•  Compreender os conceitos de testes de verificação;
•  Compreender e analisar os métodos estruturados de verificação;
•  revisões isoladas;
•  revisões técnicas formais;
•  auditorias;
•  Aprender quais são as funções de um auditor;
•  Descrever as diferentes verificações: verificações de negócios, de requisitos, de análise e
modelagem e a verificação na implementação.

34 • capítulo 2
2.1  Conceitos de testes de verificação
Muitos software possuem restrições de qualidade e confiabilidade, lembrando
que a qualidade do software pode ser definida pela satisfação dos requisitos
funcionais, de desempenho e normas explicitamente declarados.
Estima-se que 40% a 50% do esforço de desenvolvimento de sistemas são
empregados em atividades de verificação e validação.
Embora verificação e validação de software, em primeiro momento pareça
ser a mesma coisa, não são. De acordo com a (IEEE 1012), a validação está re-
lacionado ao fato de estarmos construindo o produto certo. Se o software faz o
que o usuário requisitou. Já a verificação está relacionada ao fato de estarmos
construindo o produto corretamente. Se o software está de acordo com sua es-
pecificação'' Verificação e Validação (V&V) é o nome dado aos processos de veri-
ficação e análise que asseguram que o software cumpra com as suas especifica-
ções e atenda às necessidades dos clientes que estão pagando por ele.
É um processo do ciclo de vida. Inclui:
•  Revisões dos requisitos
•  Revisões de projeto
•  Inspeções de código
•  Testes do produto

Para se realizar a verificação e a validação existem duas técnicas distintas:

inspeção de software e teste de software.
As inspeções de software analisam e verificam as representações do siste-
ma, tais como:
•  Documento de requisitos
•  Diagramas de projeto
•  Código-fonte do programa

As inspeções são aplicadas em todos os estágios do processo e podem ser

complementadas por alguma análise automática de texto dos documentos
do sistema.
Os testes de software envolvem executar uma implementação do softwa-
re com os dados de teste e examinar as saídas do teste e seu comportamen-
to operacional.

capítulo 2 • 35
 É importante lembrar que enquanto as inspeções são empregadas em todos
os estágios do processo de software, os testes são utilizados somente quando
um protótipo ou um programa estiver disponível.

2.2  Métodos estruturados de verificação

Os testes de verificação devem garantir a qualidade de todas as etapas do desen-
volvimento de sistemas. Os testes de verificação devem se concentrar em dois as-
pectos bem distintos: revisões e auditorias, os quais serão apresentados a seguir.

2.2.1  Revisões

De acordo com SEI CMM (3-1.5, 1988) "um processo de revisão pode ser defini-
do como uma avaliação crítica de um objeto[...] assim walkthroughs, inspeções
e auditorias podem ser visualizados como formas de processos de revisão."
As revisões são métodos de validação de qualidade de um processo ou pro-
duto amplamente usado pela equipe técnica do projeto. São consideradas
como verdadeiros “filtros” de erros e inconsistências no processo de desenvol-
vimento de software.
A atividade de revisão começou como uma ferramenta de controle gerencial
– Revisão de progresso, onde o progresso não pode ser avaliado simplesmente
contando-se o número de tarefas finalizadas.
Era preciso estabelecer um meio de avaliar também a qualidade do tra-
balho executado, surgiram então as revisões que avaliam aspectos técnicos
do produto.
Qualquer produto pode ser submetido a uma revisão aplicada desde as pri-
meiras fases do ciclo de vida. As revisões devem ser fomais e também informais.
Deve sempre ser realizado um planejamento para a realização das revisões
de software.Cabe ao engenheiro de software planejar:
•  o que deve ser revisado
•  quais os resultados esperados
•  quem deve fazer a revisão
•  determinar “checkpoints” dentro do ciclo de vida onde a revisão deve
ser aplicada
•  determinar resultados esperados.

36 • capítulo 2
 Algumas informações importantes no planejamento das revisões são:
•  quem participa?
•  qual informação é requerida antes da revisão?
•  quais pré-condições que devem ser satisfeitas antes que a revisão possa
ser conduzida?
•  Como Organizar?
•  Gerar checklists ou outra indicação do que deve ser coberto na revisão;
•  Determinar as condições de término ou critérios que devem ser satisfei-
tos para que a revisão termine;
•  Gerar registros e documentos que devem ser produzidos.

As revisões são o principal mecanismo para avaliar o progresso do desenvol-

vimento de maneira confiável, trazendo vários benefícios para o bom desenvol-
vimento do software, tais como:
•  As revisões trazem à luz as capacidades de cada indivíduo envolvido
no desenvolvimento,
•  revisões são capazes de revelar lotes ou classes de erros de uma só vez;
•  revisões proporcionam retorno já nas primeiras fases, prevenindo que er-
ros mais sérios surjam;
•  revisões treinam e educam os participantes e
•  têm significante efeito positivo na competência dos desenvolvedores.

Quando se realiza revisões e correções desde o início do ciclo de desenvolvi-

mento de software, um dos grandes ganhos é com relação aos custos.
As revisões minimizam o tempo de desenvolvimento do software devido
aredução do número de reformulações que serão necessárias ao longo do pro-
jeto. Um erro insignificante, se não for descoberto e tratado no início do pro-
cesso de software, pode se transformar em um conjunto de erros graves para a
sequencia do projeto.
Para cada fase do processo de criação de documentos, pode ser aplicado um
tipo diferente de revisão, a saber:
•  na fase de criação de documentos, a revisão normalmente envolve o autor
e o revisor e, aqui, utiliza-se normalmente as revisões isoladas.
•  na fase de validação dos documentos, a revisão normalmente engloba um
número maior de pessoas, entre elas o moderador, o grupo de revisores e o au-
tor e, aqui, normalmente utiliza-se as revisões técnicas formais.

capítulo 2 • 37
 •  na fase de divulgação dos documentos, a revisão normalmente envolve o
autor e o grupo de acompanhamento e, aqui, normalmente utiliza-se a reunião
de acompanhamento.

A seguir vamos analisar com mais detalhes as revisões isoladas, as revisões

técnicas formais e a reunião de acompanhamento.

a) Revisões isoladas:
Apesar de pouco explorado, esse método de verificação é muito eficiente na
detecção prematura de erros de definições e soluções registradas.
O principal objetivo das revisões isoladas é poder antecipar a revisão de do-
cumentos, entregando versões de documentos ainda não acabados, para que
possam ser analisados os tópicos já abordados. São realizadas validações par-
ciais do documento em questão. Desta forma possibilita correções nos docu-
mentos durante ainda a sua fase de concepção.
Como o próprio nome diz, nesse caso, a ação dos revisores é isolada , sen-
do normalmente utilizado um único revisor, o qual irá propor as modifica-
ções necessárias.
Porém, nem tudo são flores, e essa técnica possui um grande problema!
Você é capaz de imaginar qual é?
Se você pensou na possível diferença de visão do autor e do revisor você acer-
tou em cheio!
O autor pode ter uma visão de conjunto mais apurada que o revisor, já que a
utilização de um único revisor poderá propor mudanças que prejudiquem uma
visão integrada do problema!

b) Revisões técnicas formais:

Segundo (Pressman, 2010), uma Revisão Técnica Formal (FTR) é uma ati-
vidade de Garantia da Qualidade de Software realizada por engenheiros de
software (e outros). A FTR é o filtro mais efetivo do ponto de vista de Garantia
da Qualidade.

Os objetivos da FTR são:

•  descobrir erros na função, na lógica ou na implementação, para qualquer
representação do software;
•  verificar se o software sob revisão satisfaz seus requisitos;

38 • capítulo 2
 •  garantir que o software tenha sido representado de acordo com pa-
drões predefinidos;
•  conseguir software que seja desenvolvido de modo uniforme;
•  tornar os projetos mais administráveis.

Além disso, a FTR serve como uma oportunidade de treinamento, permitin-

do a jovens engenheiros observar abordagens diferentes para a análise, projeto
e implementação de software.
A FTR é na realidade uma classe de revisões que inclui walkthoughs, inspe-
ções, revisões circulares e outras avaliações técnicas de software.

A Reunião de Revisão

Independentemente do formato de FTR escolhido, normalmente em um pro-

cesso de revisão é importante ter as seguintes etapas:

Faz parte do planejamento a seleção da equipe,

PLANEJAMENTO a definição de critérios e a seleção de partes dos
documentos a serem vistos.

Nessa etapa deve ser feita a distribuição dos docu-

KICK-OFF mentos e explicado os objetivos aos participantes.

É importante que antes de cada reunião, cada

PREPARAÇÃO participantes tome nota dos defeitos em potencias,
INDIVIDUAL questões e comentários a serem discutidos.

Essa atividade é realizada pelo autor e consiste em

RE-TRABALHO resolver os defeitos encontrados.

Nessa etapa deve ser checado se os defeitos foram

ACOMPANHAMENTO encaminhados , obtendo métricas e checando o
critério de saída .

capítulo 2 • 39
 Cada reunião de revisão deve atender às seguintes restrições:
•  entre três e cinco pessoas (em geral) devem ser envolvidas na revisão.
Preparativos devem ser feitos, os quais não devem exigir mais de duas horas de
trabalho de cada pessoa;
•  a duração da reunião de revisão deve ser inferior a duas horas;
•  à vista dessas restrições, fica óbvio que uma FTR focaliza uma parte espe-
cífica (e pequena) de todo o software.

O foco de uma FTR é um produto de trabalho (por exemplo, uma parte da

especificação de requisitos, o projeto detalhado de um componente, uma lis-
tagem do código-fonte de um componente). O indivíduo que desenvolveu o
produto de trabalho (produtor) informa ao líder do projeto que o produto do
trabalho foi completado e que é necessária uma revisão. O líder do projeto con-
tata um líder de revisão, que avalia se o produto está efetivamente pronto, gera
cópias dos materiais do produto e as distribui a dois ou três revisores para pre-
parativos antecipados. Concomitantemente, o líder de revisão também revisa o
produto e estabelece uma agenda para a reunião de revisão, que é usualmente
marcada para o dia seguinte.
A reunião de revisão tem a participação do líder de revisão, de todos os re-
visores e do produtor Um dos revisores assume o papel de registrador, isto é, o
indivíduo que registra (por escrito) todas as questões importantes levantadas
durante a revisão. A FTR começa com a introdução da agenda e uma breve in-
trodução pelo produtor. O produtor então prossegue, percorrendo o produto
de trabalho e explicando o material, enquanto os revisores levantam questões
baseadas na sua preparação antecipada. Quando problemas ou erros válidos
são descobertos, o registrador os anota.
No fim da revisão, todos os participantes da FTR devem decidir se:
•  aceitam o produto sem maiores modificações;
•  rejeitam o produto devido a erros graves;
•  aceitam o produto condicionalmente.

A figura 2.1 apresenta as etapas da reunião da revisão de software.

40 • capítulo 2
 A Reunião da Revisão de Software

produto produto cópia do

produto

desenvolvedor líder de projeto líder de revisão

revisores
Reunião de Revisão

líder
Aceita o
de
Discussão Geral Produto sem
revisão
modificação
Breve Introdução
de produto Rejeita o produto
desenvolvedor Explicação do devido a erros
material graves
Comentários
Problemas
Registrados aceita o produto
provisoriamente
revisores secretária

Figura 2.1  –  A reunião da revisão de software.

Tomada a decisão, todos os participantes da FTR assinam uma lista na qual

indicam sua participação na revisão e sua concordância com os resultados da
equipe de revisão.
As diretrizes para a realização de revisões técnicas formais devem ser esta-
belecidas antecipadamente, distribuídas à todos os revisores, ter a concordân-
cia de todos e então encaminhada. Uma revisão descontrolada muitas vezes
pode ser pior do que nenhuma revisão.
Os seguintes dados representam um conjunto mínimo de diretrizes para as
revisões técnicas formais:
•  revise o produto, não o produtor: uma FTR envolve pessoas e egos. Se
conduzida adequadamente, deve deixar em todos os participantes um senti-
mento de realização. Se realizada inadequadamente pode assumir a áurea de
uma inquisição.
•  fixe e mantenha uma agenda: uma FTR deve ser mantida nos triulhos e
em seu cronograma. Ao líder de revisão é dada a responsabilidade de manter o
cronograma da reunião, ele não deve ter medo de chamar a atenção de pessoas
quando a divagação instalar-se.

capítulo 2 • 41
 •  limite o debate e a refutação: quando uma questão é levantada por um
revisor, talvez não uma haja uma concordância universal sobre o seu impacto.
Em vez de perder tempo debatendo a questão, o assunto deve ser registrado
para posterior discussão off-line.
•  enuncie as áreas problemáticas, mas não tende resolver cada problema
anotado: a revisão não é uma sessão de resolução de problemas. A resolução
dos problemas deve ser postergada para depois do encontro da revisão.
•  faça anotações por escrito: as vezes é uma boa idéia que o secretário faça
anotações numa lousa, de forma que a redação e a determinação de prioridades
possam ser avaliadas por outros revisores quando a informação for registrada.
•  limite o número de participantes e insista numa preparação antecipa-
da: mantenha o número de pessoas envolvidas ao mínimo necessário. Todos
os membros da equipe de revisão devem preparar-se antecipadamente.
Comentários escritos devem ser solicitados pelo líder de revisão.
•  desenvolva uma lista de conferência (cheklist) para cada produto que pro-
vavelmente será revisto: uma lista de conferência ajuda o líder de revisão a estru-
turar o encontro e ajuda cada revisor a se concentrar em questões importantes.
•  atribua recursos e uma programação de tempo para as TFRs: para que
as revisões sejam efetivas, elas devem ser programadas como tarefas durante
o processo de engenharia de software. Além disso, deve-se programar tempo
para as inevitáveis modificações que ocorrerão como resultado de uma FTR.
•  realize um treinamento significativo para todos os revisores: o treinamen-
to deve destacar tanto as questões relacionadas a processos como o lado psico-
lógico humano das revisões.
•  reveja suas antigas revisões: o produto prioritário a ser revisado poderiam
ser as próprias diretrizes da revisão.

2.2.2  Auditorias

A auditoria é um processo sistemático, documentado e independente para

obter evidências de auditoria e avaliá-las objetivamente para determinar a ex-
tensão na qual os critérios de auditoria são atendidos. O objetivo da auditoria
da qualidade é avaliar se um determinado projeto e as diversas equipes estão
respeitando o processo de desenvolvimento e se estão registrando os defei-
tos encontrados.

42 • capítulo 2
 Na auditoria, a pessoa ou organização que passará pelo processo de audito-
ria denomina-se auditado. Para a realização da auditoria é necessário um Plano
da Auditoria, o qual descreve as atividades e arranjos para uma auditoria.
A auditoria é caracterizada pela confiança em princípios como:
•  Conduta ética: O fundamento do profissionalismo (Confiança, integrida-
de, descrição e confidencialidade são essenciais para auditar).
•  Apresentação Justa: a obrigação de reportar com veracidade e exatidão. A
conclusão de uma auditoria reflete verdadeiramente e com precisão as ativida-
des da auditoria.
•  Devido cuidado profissional: Cuidado necessário considerando a impor-
tância da atividade e a confiança depositada.
•  Independência: Auditores devem ser independentes da atividade a ser au-
ditada e são livres de conflito de interesse e tendência.
•  Abordagem baseada em evidência: Evidência de Auditoria é Verificável.

Vamos conhecer os diferentes tipos de auditoria:

•  Primeira parte: realizada por uma organização sobre si mesma.
•  Segunda parte: conduzida por uma organização sobre uma outra para fins
da organização condutora da auditoria.
•  Terceira parte: realizadas por uma terceira independente sem interesses
nos resultados da auditoria.

O processo de auditoria é de extrema importância, podendo variar de or-

ganização para organização, porém não deve deixar de alcançar o objetivo da
auditoria. Um processo de auditoria exerce uma ação preventiva, reparadora e
moralizadora. As etapas do processo de auditoria são: planejamento, auditoria
e finalização.

Planejamento: nessa etapa são realizadas as seguintes atividades:

•  Identificação do objetivo de cada auditoria.
•  Identificação do escopo da auditoria, ou seja, onde se quer verificar a exis-
tência de não-conformidades.
•  Auditoria no produto ou no processo.
•  Definição da estratégia da auditoria, ou seja, como ela será realizada.
•  Definição de um cronograma de auditoria.

capítulo 2 • 43
 •  As auditorias devem ter um cronograma atualizado e sendo executadas
com frequência. Ex: mensal: Cada mês focar em uma área especifica. A fre-
qüência pode variar por projeto ou organização.
•  Utilizar uma análise de risco para poder atualizar o cronograma.
•  Um cronograma de auditoria é conhecido pelos membros do projeto.

Auditoria: a etapa de auditoria propriamente dita pode ser conduzida por

um ou mias auditores, onde:
•  O auditor identifica os critérios de auditoria (processo, templates e infor-
mações pertinentes).
•  Realiza uma preparação no material.
•  Cria ou seleciona um checklist para que sirva de guia durante a execução
da auditoria.
•  Identifica possíveis auditados (Verificar com o líder da equipe)
•  Apresenta-se formalmente ao auditados, descrevendo os objetivos
da auditoria.
•  Pode ser realizada em grupo ou individualmente.
•  Na reunião de auditoria:
– O auditor deve apresentar qual o objetivo da auditoria, qual o papel
dos auditados e como será realizada a auditoria.
– Deve esclarecer que todas as informações são confidencias.
– O auditor usa o checklist para guiar na identificação das informa-
ções necessárias.
– O auditor deve questionar o entrevistado com base no que foi estu-
dado e no checklist .
– O auditor anota todas as informações pertinentes à auditoria que
posteriormente vai utilizar para identificar não-conformidades.
– Além das não-conformidades, o auditor deve ser capaz de identificar
oportunidades de melhoria, bem como boas práticas.
– Solicitar evidências das informações que estão sendo afirmadas
(Podem ser apresentadas na hora ou é dado um limite para que sejam
entregues ao auditor).
– Pedir sugestões aos auditados.

44 • capítulo 2
 Finalização:
•  Com base nas informações coletadas na auditoria, bem como evidências
coletadas, o auditor deve verificar junto aos processos, procedimentos e pa-
drões da organização, se são caracterizadas não-conformidades.
•  Diferenciar FATO de INFERÊNCIA.
•  As oportunidades de melhoria são identificadas.
•  As boas práticas são identificadas.
•  Tendo relacionado as não-conformidades, oportunidades de melhoria e
boas práticas, o auditor deve verificar sua coerência com os auditados.
•  O auditor deve criar um relatório contendo as informações da auditoria e
para cada não-conformidade deve ser apresentada: uma ação de correção, data
para conclusão e o responsável pela ação.
•  Após o relatório finalizado, o mesmo deve ser apresentado, para que to-
dos fiquem cientes do resultado da auditoria.
•  As não-conformidades devem ser acompanhadas até o seu fechamento.
•  Caso as datas não sejam cumpridas, deve ser um utilizado um critério de
escalação, até que a não-conformidade seja finalizada.
•  O relatório de auditoria deve estar em um repositório com controle
de versão.

O auditor é uma peça chave dentro do processo de auditoria, fazendo parte

das suas funções as seguintes atividades:
Compreensão do ambiente,
•  Análise do ambiente e determinação dasπ situações mais sensíveis,
•  Elaboração de uma massa de testes,
•  Aplicação da massa de testes,
•  Análise das simulações,
•  Emissão da opinião quanto ao ambiente auditado,
•  Debate com os profissionais da área auditada para discussão das alterna-
tivas recomendadas,
•  Acompanhamento da implantação da solução proposta,
•  Auditoria da solução implantada,
•  Novas auditorias no ambiente,

capítulo 2 • 45
 •  O auditor deve utilizar palavras de questionamentos como: Como?, O
que?, Quando?, Quem?, Onde?, Por que? e Mostre-me (Evidência),
•  Estar bem preparado para realizar a auditoria,
•  Tentar prever o máximo de situações possíveis,
•  Evitar surpresas ao auditado,
•  Esclarecer todas as dúvidas sobre uma nãoconformidade,
•  Buscar objetividade e fatos concretos (Evidências),
•  Não atacar pessoas e sim fatos concretos,
•  Motivar a identificação de melhorias,
•  Persuadir, não impor,
•  O auditor não deve relacionar pessoas à não-conformidades
ou deficiências,
•  Ser flexível quando necessário e,
•  Ser imparcial e objetivo para obtenção dos fatos.

2.2.3  Reunião de acompanhamento

A reunião de acompanhamento é uma forma de verificação, porém ela é menos

formal do que as reuniões da revisão (vista no tópico anterior), uma vez que não
há a necessidade de preparação dos participantes.
Na reunião de acompanhamento, o apresentador, que na maioria das vezes
é o autor do documento deve preparar-se para a reunião, porém os outros par-
ticipantes não.
O principal objetivo dessa reunião não é detectar erros, mas sim distribuir
as informações a todos os participantes, o que permite envolver um núme-
ro maior de pessoas que podem colaborar no processo de desenvolvimento
de software.
A dinâmica normalmente utilizada é a distribuição de material a todos os
participantes para que possam realizar a análise antecipada dos documentos
e que posteriormente, em uma reunião pré-agendada todos poderão debater
as dúvidas.

46 • capítulo 2
2.3  Aplicação e checklist na verificação
Durante o desenvolvimento de software muitos documentos são gerados. Rea-
lizarmos verificações para analisarmos esses documentos em cada uma das
etapas do desenvolvimento de software é extremamente importante, para ga-
rantirmos que problemas não sejam migrados para fases seguintes.
Você se lembra do que comentamos anteriormente?
Dentro do desenvolvimento de software, quanto antes descobrirmos os pro-
blemas melhor! Um probleminha não descoberto no início pode ser um pro-
blemão lá no final!
Durante a verificação um checklist pode ser útil. Um checklist contem um
roteiro de possíveis erros:

Defeitos nos dados:

•  Todas as variáveis foram inicializadas?
•  As constantes foram nomeadas?
•  Tamanho máximo de um vetor?
•  Pode haver overflow de buffer?

Defeitos de controle
•  As condições estão corretas?
•  Todos os loops estão certos de terminar?
•  Os parênteses estão corretos nas condições compostas?
•  Num case todas as alternativas estão declaradas?

Defeitos de Entrada/saída
•  Todas as variáveis de entrada são utilizadas?
•  Todas as variáveis de saída têm um valor designado antes de saírem?
•  Entradas inesperadas podem corromper os dados?

Defeitos de interface
•  Todas as chamadas de funções e métodos têm o número correto
de parâmetros?
•  Os tipos de parâmetros combinam?
•  Os parâmetros estão na ordem certa?

capítulo 2 • 47
 •  Se componentes acessam memória compartilhada, eles têm a mesma es-
trutura de memória compartilhada?

Defeitos de gerenciamento de armazenamento

•  Se uma estrutura linkada é modificada, todos os links foram corretamen-
te redesignados?
•  Se o armazenamento dinâmico é utilizado, o espaço foi aloca-
do corretamente?
•  O espaço é explicitamente liberado, depois que não é mais necessário?

Defeitos de gerenciamento de exceções

•  Todas as possíveis condições de erro foram levadas em conta?

2.4  Diferentes verificações

Os estes de verificação são aplicados respeitando os estágios do desenvolvi-
mento de software:

O objetivo dessa fase é garantir que os diversos docu-

VERIFICAÇÃO DOS mentos produzidos tenham total aderência às necessi-
NEGÓCIOS dades apontadas pelos clientes.

O objetivo dessa fase é a verificação das especifica-

VERIFICAÇÃO DOS ções do levantamento dos requisitos funcionais e não
REQUISITOS funcionais do software a ser desenvolvido.

O objetivo dessa fase não está somente na avaliação

VERIFICAÇÃO da aderência da solução tecnológica aos requisitos
DE ANÁLISE E funcionais e não funcionais estabelecidos pelo cliente
MODELAGEM mas também em avaliar a modelagem da solução como
um todo.

48 • capítulo 2
 O objetivo dessa fase é garantir a qualidade do código-
fonte gerado pela equipe de desenvolvimento. Essa
VERIFICAÇÃO NA qualidade é atribuída pela prática das regras da boa
IMPLEMENTAÇÃO programação. É um processo formal de verificação do
código produzido.

2.5  Fases dos testes de verificação

Em todas as etapas do processo de desenvolvimento de software são gerados
vários documentos.
Para que, chegando no final do desenvolvimento de software tenhamos pro-
duzido em produto com qualidade é importante que, durante cada etapa do
ciclo os documentos sejam verificados e, após a verificação sejam corrigidos.
Imagine que você vai desenvolver um software e, em cada fase, vai gerando
os documentos necessários, porém não verifica se os documentos estão cor-
retos, se o documento necessário a próxima fase foi desenvolvido totalmente.
Você simplesmente vai gerando os documentos necessários e guardando-os.
Aí, lá no final do ciclo, você vai realizar as verificações e descobre que alguns
documentos gerados na primeira fase, na fase inicial do negócio está incorreto,
incompleto ou inconsistente?
Melhor nem imaginar não acha?
Pensa no tanto de retrabalho a ser feito, o custo extra que isso geraria, na
demora que isso acarretaria.
Bom, o correto é que as atividades de verificação sejam feitas em cada eta-
pa do processo de desenvolvimento do software. Vamos, a seguir, verificar
como proceder as verificações em cada fase do processo de desenvolvimento
de software:
-Fase de negócios: no primeiro contato identificamos as necessidades do
cliente, o que ele espera do software, quais são as suas expectativas e também
quais são as suas principais exigências (ou seja, as coisas que o cliente não abre
mão de jeito nenhum que o software realize).
Antes de pensarmos no software que será desenvolvido, precisamos enten-
der o domínio do negócio que esse software fará parte. É extremamente im-
portante entender o negócio da organização, suas necessidades e principais

capítulo 2 • 49
problemas atuais, buscar alternativas para minimizar ou resolver esses proble-
mas e, de forma geral, otimizar os processos de negócios para elicitação de bons
requisitos de software, atendendo ou até mesmo superando as expectativas.
O modelo de negócios, como o próprio nome diz, modela as atividades e
estabelece uma macrovisão, identifica as expectativas e exigência dos clientes,
estima os prazos e custos.
Nessa fase, a verificação de negócios é realizada com o objetivo de verificar
a aderência do modelo de negócios com a macrovisão, verificar as expectati-
vas e exigências do projeto e também para verificar se projeções foram realiza-
das criteriosamente.
O principal objetivo dessa fase é garantir que os documentos produzidos
tenham aderência às necessidades apontadas pelos clientes. É extremamen-
te importante realizar a revisão destes documentos juntamente com o pró-
prio cliente.
A tabela 2.1 apresenta os principais produtos e as principais atividades des-
sa fase:

FASE DE PRINCIPAIS PRINCIPAIS

VERIFICAÇÃO PRODUTOS ATIVIDADES

Revisar contextos do
Modelo de negócios mercado e necessidade
do cliente.

Análise de riscos Revisar riscos do projeto.

MODELO DE
NEGÓCIOS
Auditar alternativas de
Árvore de decisão
execução do projeto.

Revisar o estudo de
Estudo de viabilidade
viabilidade do projeto.

Tabela 2.1  –  Principais produtos e atividades da fase de verificação de negócios.

50 • capítulo 2
 Como já vimos anteriormente, um checklist é um instrumento importante
para auxiliar os revisores e auditores no processo de verificação. A tabela 2.2
apresenta um exemplo de checklist do modelo de negócios:

CHECKLIST DO MODELO DE NEGÓCIOS

LEVANTAMENTO DAS NECESSIDADES DO CLIENTE

Todas as necessidades foram devidamente registradas? ( ) sim ( ) não

Toda necessidade apontada possui uma descrição ( ) sim ( ) não

LEVANTAMENTO DAS CARACTERÍSTICAS DE SOFTWARE

Cada característica atende ao menos a uma necesidade

( ) sim ( ) não
identificada?

Cada característica possui uma descrição clara? ( ) sim ( ) não

Cada característica possui exemplos que auxiliam no seu

( ) sim ( ) nao
entendimento?

Tabela 2.2  –  Checklist de modelo de negócios . Fonte: (Bartié, 2002).

No processo de desenvolvimento de software, na fase

de especificação de requisitos, é necessário definir e
FASE DE detalhar todos os requisitos funcionais e os requisi-
REQUISITOS tos não-funcionais (ou requisitos de qualidade) do
software.

capítulo 2 • 51
 Nessa fase deve-se lidar com diferentes pontos de vista e usar uma combina-
ção de métodos, ferramentas e pessoas.
O produto desta fase é um modelo do qual se produz um documento cha-
mado documento de requisitos. O Documento de Requisitos de um software
contém todos os requisitos funcionais e de qualidade do software, incluindo
as capacidades do produto, os recursos disponíveis, os benefícios e os critérios
de aceitação. Esse documento serve como um meio de comunicação entre o
engenheiro de software e o usuário, a fim de estabelecer um “acordo” acerca do
software pretendido. Deve-se evitar que durante o desenvolvimento do
Documento de Requisitos decisões de projeto sejam tomadas.

CONEXÃO
Os requisitos funcionais do documento de requisitos são definidos pelo cliente, será ele
quem definirá esses requisitos e discutirá os mesmo com a equipe de desenvolvimento.
Já os requisitos não funcionais (ou requisitos de qualidade) são normalmente definidos
utilizando uma norma de qualidade de software, tal como a NORMA ISO 9126 (que apresen-
taremos no capítulo3).
Veja as características dessa norma acessando o artigo:
Guia para utilização das normas sobre avaliação de qualidade de produto de software-
ISO/IEC 9126 e ISO/IEC 14598
Disponível em: <http://www2.dem.inpe.br/ijar/GuiaUtilNormTec.pdf>.

Na fase de especificação de requisitos, a verificação de requisitos consis-

te em:
•  verificar a consistência dos requisitos funcionais e não funcionais,
•  verificar a rastreabilidade entre requisitos e necessidades

Nessa etapa, o objetivo é definir uma solução

tecnológica que suporte os requisitos funcionais
FASE DE ANÁLISE E e os requisitos não funcionais. Como o próprio
MODELAGEM nome diz, esses requisitos devem ser modelados
utilizando alguma técnica para isso.

52 • capítulo 2
 A verificação na fase de análise e modelagem tem como principais objetivos:
•  verificar a consistência da arquitetura da solução,
•  verificar a aderência dos requisitos funcionais e não funcionais com
a solução.

Nessa fase, toda a documentação produzida nas

FASE DE fases anteriores serão transformadas em código
IMPLEMENTAÇÃO de uma determinada linguagem.

A verificação na fase de implementação tem como principais objetivos:

•  garantir que os códigos-fonte estejam compatíveis com os modelos,
•  garantir normas e padrões de desenvolvimento,
•  garantir reduzido nível de complexidade de fonte.

Para fixarmos melhor os conhecimentos adquiridos até aqui, seguem abai-

xo algumas questões para serem refletidas.

ATIVIDADES
01. O que vem a ser auditoria de software? Quais são as suas etapas?

02. Quais são os objetivos da revisões técnicas formais?

03. Explique quais são as diretrizes mínimas para as FTRs.

04. Comente as principais funções do auditor.

REFLEXÃO
Nesse capítulo pudemos observar mais detalhadamente a atividade de teste de verificação.
Vimos que embora muitos considerem os testes uma atividade destrutiva, ela não deve
ser encarada dessa maneira e sim, como uma atividade a mais na busca pela qualidade
do software.

capítulo 2 • 53
 Pudemos ver a grande importância de realizarmos adequadamente as tarefas de revi-
sões e de auditoria nos testes de verificação e, finalizamos vendo os principais objetivos das
verificações nas etapas de negócio, de requisitos, de análise, modelagem e na verificação do
processo de desenvolvimento de software.

LEITURA
Introdução ao teste de software. Disponível em: <http://www.icmc.usp.br/CMS/Arqui-
vos/arquivos_enviados/BIBLIOTECA_113_ND_65.pdf>.
Ferramentas para auditoria de sistemas e suas vantagens. Disponível em: <http://
www.cnasi.com.br/ferramentas-para-auditoria-de-sistemas-e-suas-vantagens/>.

REFERÊNCIAS BIBLIOGRÁFICAS
PRESSMAN, Roger S. Engenharia de Software, 6 ed. Editora MCGrawHill: Porto Alegre, 2010.
SOMERVILLE, IAN. Engenharia de Software. 6 ed. São Paulo: Addison Wesley, 2003.
NBR ISO/IEC 9126-1: Engenharia de Software – Qualidade de produto – Parte 1: Modelo de
qualidade. Rio de Janeiro: ABNT, 2003.
ISO/IEC 9126. International Standard. Information Technology. Software Product
Evaluation. Quality characteristics and guidelines for their use. Geneve, 1991.
BARTIÉ, Alexandre. Garantia da qualidade de software. Rio de Janeiro: Campus, 2002.

54 • capítulo 2
 3
Testes de
Validação
O processo de qualidade de software está decomposto em fases. Cada fase tem
uma sequência de execução dos testes a serem aplicados. Os testes de verifica-
ção visam garantir o processo de engenharia de software, enquanto os testes
de validação estão focados na garantia da qualidade do produto de software.
Testes de verificação e validação são complementares. Em hipótese alguma,
estes deverão ser encarados como atividades redundantes. Tanto um quanto
o outro possui naturezas e objetivos distintos, fortalecendo o processo de de-
tecção de erros e aumentando a qualidade final do produto. Um bom processo
de qualidade de software deverá potencializar essas duas formas de testes de
modo que os esforços sejam minimizados e os resultados sejam os mais posi-
tivos possíveis.

OBJETIVOS
•  Compreender o conceito de teste de validação;
•  Compreender as estratégias de testes (testes de caixa branca e testes de caixa preta)
além das abordagens dos testes ( testes baseados na estrutura interna e testes baseados
nos requisitos);
•  Estudar as categorias dos testes de validação;
•  Compreender cada um dos métodos estruturados de testes e;
•  Analisar as Fases da Validação para um melhor entendimento do tema.

56 • capítulo 3
3.1  Teste de validação
É muito complicado inspecionar um sistema inteiro, composto por vários sub-
sistemas. Os testes são a única técnica viável no nível de sistema.
Os testes, além de localizar erros, também são necessários para determinar
a confiabilidade, o desempenho e para validar a interface com o usuário.
O teste de validação tem o seu foco na aplicação, uma vez que já existe um
produto computacional. Seu principal objetivo é identificar o maior número
possível de erros. O sucesso desse teste está apoiada no forte planejamento de
todas as atividades de teste.
É um processo formal de avaliação de produtos tecnológicos que podem ser
aplicados em componentes isolados, em módulos existentes ou mesmo à tota-
lidade do sistema.
O seu principal objetivo é avaliar a conformidade do software com os requi-
sitos e especificações analisadas e revisadas nas etapas iniciais do projeto.

Estratégias de teste

Uma estratégia para o teste de um projeto descreve a abordagem geral e os obje-

tivos das atividades de teste. Ela inclui os estágios de teste (unidade, integração
e sistema) que devem ser abordados e os tipos de teste (de função, desempe-
nho, carga, stress, etc.) que devem ser executados.

A estratégia define:

•  As ferramentas e técnicas de teste a serem empregadas.

•  Os critérios de conclusão e êxito do teste a serem usados. Por exemplo, os
critérios podem permitir que o software evolua para o teste de aceitação quan-
do 95% dos casos de teste tiverem sido executados com êxito. Outro critério
consiste na cobertura de código. Em um sistema no qual a segurança seja vital,
esse critério pode significar que 100% do código devem ser cobertos por testes.
•  Algumas considerações especiais afetam os requisitos de recurso ou têm
implicações na programação, como:
•  O teste de interfaces para sistemas externos.
•  Simulação de danos físicos ou de ameaças à segurança.

capítulo 3 • 57
 Algumas organizações possuem estratégias de teste corporativas definidas.
Nesse caso, é necessário essas estratégias especificamente ao projeto.
É necessário planejar as atividades de teste com base nas seguin-
tes dimensões:

•  Em que iteração você se encontra e quais são as metas dessa iteração.

•  Que estágio de teste (teste unitário, de integração ou de sistema) você está
executando.

Agora, observe como as características das atividades de teste podem ser

alteradas dependendo de onde você esteja nas "dimensões de teste" menciona-
das acima. É claro que há várias características a observar (como recursos ne-
cessários e tempo gasto), mas, nesse ponto, concentre-se no que é importante
para definir a estratégia de teste:

•  Tipos de teste (de função, stress, volume, desempenho, usabilidade, dis-

tribuição, etc.).
•  Critérios de avaliação usados (cobertura de teste baseada em código, co-
bertura de teste baseada em requisitos, número de defeitos, intervalo entre fa-
lhas, etc.).
•  Técnicas de teste usadas (manuais e automatizadas).

Não há nenhum padrão geral referente à maneira como os tipos de testes

são distribuídos nos ciclos de teste. Dependendo do número de iterações, do
tamanho da iteração e do tipo de projeto, é necessário enfatizar diferentes tipos
de testes.
O foco do estágio de teste do sistema é garantir que se esteja cobrindo to-
dos os requisitos testáveis expressos em um conjunto de casos de teste. Isso
significa que os critérios de conclusão se concentrarão na cobertura de teste
baseada em requisitos. Nos estágios de teste unitário e de integração, é possível
perceber que a cobertura de teste baseada em código é um critério de conclusão
mais apropriado.
Existem basicamente duas estratégias utilizadas para conduzir o processo
de validação de software: testes de caixa branca e testes de caixa preta.

58 • capítulo 3
3.1.1  Testes de caixa branca

Também conhecido como teste estrutural. É aquele em que o analista tem

total acesso à estrutura interna da entidade sendo analisada e permite, por
exemplo, que o analista escolha partes específicas de um componente para se-
rem testadas.
O fato de conhecer o código do programa permite que o avaliador projete
testes mais precisos. Por exemplo, se a definição de uma função g(), para um
determinado programa, afirma que ela não aceita valores negativos, um avalia-
dor poderia provocar uma chamada fun(-1) e descobrir que um tratamento de
exceções não está corretamente implementado.
Esses testes são projetados em função da estrutura do componente e podem
permitir verificação mais precisa de comportamento do produto. Ele permite
ao avaliador concentrar a atenção nos pontos mais importantes ou “perigosos”
do código, de uma maneira mais precisa do que no caso do teste caixa-preta.
Tais pontos podem até ser identificados durante o desenvolvimento e cobertos
com o uso de assertivas e testes.
Há, entretanto, um elemento comum entre os testes caixa-preta e caixa
-branca: em ambos os casos, o avaliador não sabe qual será o comportamento
produto em uma determinada situação.
A versão de testes resultante deve ser executada e os resultados, observa-
dos. Naturalmente, é preciso um cuidado especial com o controle de versões de
software: a versão de teste, bem como o executável resultante, não deve jamais
ser confundida com a versão correta que será entregue ao cliente.

3.1.2  Testes de caixa preta

O Teste de Caixa-Preta ou Teste Funcional, também é usado na engenharia, no

problema de identificação de sistemas, e advém do fato de que ao analisar o
comportamento de um objeto, ignora-se totalmente sua construção interna.
O teste de caixa-preta é baseado nos requisitos funcionais do software.
Como não há conhecimento sobre a operação interna do programa, o avaliador
se concentra nas funções que o software deve desempenhar. A partir da especi-
ficação são determinadas as saídas esperadas para certos conjuntos de entrada
de dados.

capítulo 3 • 59
 Esse tipo de teste reflete, de certa forma, a óptica do usuário, que está inte-
ressado em se servir do programa sem considerar os detalhes de sua constru-
ção. Comparando a outros tipos de teste, este é relativamente mais simples.

O teste é particularmente útil para revelar problemas, tais como:

•  funções incorretas ou omitidas;
•  erros de interface;
•  erros de comportamento ou desempenho;
•  erros de iniciação e término.

Um exemplo simples de aplicação é verificar a consistência de dados de in-

terface. Um exemplo de aplicação do teste é fazer entradas erradas de dados e
observar o comportamento do programa.
Ao realizar o teste, o avaliador deve buscar simular erros que um usuário
pode cometer e que fogem da especificação do programa:
•  usar como data de nascimento a data atual ou uma data futura;
•  preencher campos com um número insuficiente de caracteres (por exem-
plo, digitar apenas “123” para CPF ou telefone);
•  códigos de CPF ou de CEP errados;
•  preencher campos como nome com valores muito grandes (por exemplo,
copiar- colar um texto de 10 Kbytes num campo);
•  deixar campos de entrada vazios ou preenchê-los com espaços brancos ou
zeros(sobretudo campos de preenchimento obrigatório);
•  usar valores negativos para números, como valor a pagar;
•  não respeitar tipos de dados (por exemplo, digitar letras ou símbolos em
um campo “idade”.

Além da interface, pode-se verificar a execução de funções ou tarefas intei-

ras. Alguns exemplos de testes são:

•  duplicar informações (por exemplo, tentar cadastrar duas vezes exata-

mente os mesmos dados);
•  imprimir relatórios para bases de dados vazias;
•  procurar registros inexistentes.
Continuando nosso estudo sobre os testes de validação, vamos a seguir ana-
lisar algumas abordagens de testes.

60 • capítulo 3
3.2  Abordagens dos testes
Abordagens de teste dizem respeito à profundidade da análise a ser realizada.
Em outras palavras, a abordagem de um teste define se o que interessa são ape-
nas as respostas geradas pelo item em teste ou se o seu comportamento interno
também deve ser levado em conta.
Segundo Bartié (2002), o direcionamento dos testes baseia-se exclusiva-
mente em requisitos da solução tecnológica a ser desenvolvida (teste de caixa
preta) ou na estrutura interna do código-fonte a ser desenvolvido (teste de cai-
xa branca).
A figura 3.1 mostra essas abordagens dos testes.

Caixa Branca Caixa Preta

Testes Baseados na Estrutura Interna Testes Baseados nos Requisitos

Figura 3.1  –  Abordagens fundamentais dos testes. Fonte Bartié, 2002.

3.2.1  Testes baseados na estrutura interna

Testes baseados na estrutura interna requerem um profundo conhecimento da

tecnologia e do projeto de desenvolvimento, de modo a validar todos os algorit-
mos empregados pelo software. Por exigir conhecimento da estrutura interna
do software, a estratégia da caixa branca será utilizada para aborda-los.

capítulo 3 • 61
3.2.2  Testes baseados nos requisitos

Testes baseados em requisitos: são baseados em documentos de requisitos e

modelados por meio de especificações funcionais e suplementares. Os casos
de testes devem avaliar todos os cenários existentes e validar todas as variações
(fluxos de processamento alternativos e de exceção) que uma solução tecno-
lógica deve suportar. São testes que devem ser empregados pela estratégia da
caixa preta.

3.3  Testes progressivos e regressivos

Os testes progressivos são testes elaborados de acordo com a criação de novas
funcionalidades do software. Nesta abordagem é necessário testar somente as
inovações do software, assumindo que nenhum erro foi introduzido após seu
processo de desenvolvimento. Nesta categoria, as funcionalidades já existentes
não são testadas e considera-se que as novas alterações no código não impacta-
ram na estrutura existente anteriormente.
Já os testes regressivos é uma abordagem que reexecuta um subconjunto
(total ou parcial) de testes previamente executados. Seu objetivo é garantir que
uma alteração ou criação de nova funcionalidade não causou impactos nas
estruturas já existentes. Toda nova versão do produto deveria ser submetida a
uma nova sessão de testes, a fim de assegurar que estes novos segmentos não
afetaram outras partes do produto.

3.4  Categorias dos testes de validação

Sabe-se que o objetivo de todo teste é detectar os erros existentes no produto de
software, porém a realização de todas as categorias de testes descrita a seguir
não reflete a realidade vivenciada pelas equipes de teste. A realização de todas
estas categorias demandaria um esforço muito grande, então se faz necessário
selecionar as categorias a utilizar conforme o perfil do produto (BARTIÉ, 2002).
a) Testes de Funcionalidade. Para Bartié (2002), o direcionamento dos
testes funcionais deve ser realizado com base nos documentos de especifica-
ção funcional. Este documento descreve o comportamento da aplicação nos

62 • capítulo 3
diversos cenários existentes para cada requisito de negócio. A principal caracte-
rística desta categoria de testes é o grande foco nos negócios, com isso, garante-
se que não exista diferença entre os requisitos funcionais e o comportamento
do software construído. Esta categoria cobre as seguintes situações: pré-condi-
ções de uma transação; o fluxo de dados de uma transação de negócios; o 32 ce-
nário primário de uma transação de negócios; os cenários alternativos de uma
transação de negócios; os cenários de exceção de uma transação de negócios; e
as póscondições de uma transação de negócios.
b) Testes de Usabilidade. Para Rios e Moreira (2003), os testes de usabi-
lidade têm como meta simular as condições de uso da aplicação sob a pers-
pectiva do usuário. Sendo assim, este tipo de teste tem como foco verificar a
facilidade de navegação entre as telas da aplicação, a clareza dos textos e das
mensagens apresentadas ao usuário, o volume reduzido de interações para rea-
lizar uma determinada função, o padrão visual e etc. Esta categoria de testes
pode ser realizada da seguinte forma: avaliar a facilidade de navegação entre as
telas da aplicação; realizar operações e desfazê-las; realizar operações inválidas
e avaliar as mensagens de alerta; avaliar quantos passos são necessários para
executar as principais operações; verificar a existência de ajuda em todas as te-
las; e verificar se as informações presentes nos manuais de ajuda são coerentes.
c) Testes de Carga. Conforme Bastos (2006), os testes de carga servem ba-
sicamente para avaliar como uma aplicação e toda sua infraestrutura se com-
portam quando se aplica um volume de transações superiores aos volumes
máximos previstos para esta aplicação e quando se aplica variações bruscas de
transações. Este tipo de teste pode ser executado da seguinte forma: aumentan-
do e diminuindo sucessivamente a quantidade de transações simultâneas; au-
mentando e diminuindo o tráfego de rede; aumentando a quantidade de usuá-
rios simultâneos; e realizando uma combinação de todos estes itens anteriores.
d) Testes de Volume. Segundo Bartié (2002), os testes de volume são carac-
terizados por determinar os limites de processamento e a carga da aplicação e
de toda a sua infra-estrutura. Este tipo de teste é conduzido de forma contínua,
aumentando o volume das operações realizadas com a aplicação, até que se
atinja o limite máximo. O objetivo deste teste é conhecer os limites da solução
e avaliar se estão de acordo com as especificações. Para a realização deste teste
pode-se: aumentar constantemente o volume de transações; aumentar 33 cons-
tantemente o volume de consultas; e aumentar constantemente o tamanho dos
arquivos a serem processados.

capítulo 3 • 63
 e) Testes de Configuração. Para Molinari (2006), esta categoria de tes-
tes tem por finalidade executar o software sobre inúmeras configurações de
software e de hardware. A meta deste teste é garantir que a solução funcione
corretamente sobre os diversos ambientes previstos nas fases de levantamento
de requisitos. A execução deste teste pode ser da seguinte forma: variando os
sistemas operacionais; variando os hardwares; e combinando as variações cita-
das anteriormente.
f) Testes de Compatibilidade. A respeito dos testes de compatibilidade,
Bartié (2002) afirma que esta categoria tem por finalidade executar a aplicação
interagindo com as versões anteriores de outras aplicações ou dispositivos físi-
cos. O objetivo deste teste é garantir que as novas versões de um software estão
suportando antigas versões. Pode ser testado do seguinte modo: realizando a
importação de dados gerados pela versão anterior; e realizando a comunicação
com todas as versões de layout.
g) Testes de Segurança. Segundo Rios e Moreira Filho (2003), este tipo de
teste tem como objetivo encontrar as falhas de segurança que podem compro-
meter a confidencialidade e a integridade das informações, provocar perdas de
dados ou interrupções de processamento. Este tipo de teste pode ser executa-
do da seguinte maneira: validar todos os requisitos de segurança identificados;
tentar acessar funcionalidades que requerem determinados perfis; tentar inva-
dir/derrubar o servidor de dados; e tentar extrair backups de informações e etc.
h) Testes de Desempenho. Conforme Bastos et al (2006), esta categoria de
testes tem por finalidade determinar se o desempenho da aplicação está coe-
rente com os requisitos definidos, quando se obtém situações em que o pico
máximo de acesso e concorrência é atingido. Para se executar este tipo de teste,
pode-se: validar todos os requisitos de desempenho 34 identificados; simular
vários usuários acessando a mesma informação de forma simultânea; simular
vários usuários processando a mesma transação de forma simultânea; simu-
lar percentagem de tráfego de rede; e combinar todos os itens apresentados
anteriormente.
i) Testes de Confiabilidade e Disponibilidade. Para Rios e Moreira Filho
(2003), a principal característica deste teste é monitorar uma aplicação por um
determinado tempo e avaliar o nível de confiabilidade da arquitetura da solu-
ção. Este tipo de teste pode ser executado da seguinte maneira: monitorando
a execução da aplicação; identificando todas as interrupções do ambiente; e
identificando o tempo de interrupção do ambiente.

64 • capítulo 3
 j) Testes de Recuperação. Os testes de recuperação, segundo Bartié
(2002), tem por finalidade avaliar o comportamento da aplicação após a ocor-
rência de um erro e verificar sua recuperação. Esses testes podem ser realizados
da seguinte forma: interrompendo o acesso à rede por alguns instantes e por
um longo período; interrompendo o processamento, desligando o micro e o
servidor; e gerando arquivos e posteriormente cancelando o processamento.
k) Testes de Instalação. O teste de instalação tem como objetivo validar o
procedimento de instalação da aplicação, de forma que esta atenda a todas as
necessidades apresentadas nos requisitos. É recomendado que este teste seja
realizado pelo próprio usuário (BASTOS et al, 2006).
l) Teste de Regressão. Conforme BSTQB (2007), o teste de regressão é o
teste repetido de um programa que sofreu alguma mudança após uma etapa de
testes, tem como objetivo descobrir a existência de algum defeito introduzido
ou não identificado originalmente como resultado da mudança, sendo realiza-
do quando o software ou o ambiente são modificados. BSTQB (2007) ainda defi-
ne que este tipo de teste pode ser realizado em todos os níveis de teste, podendo
ser aplicado aos testes funcionais, não funcionais e estruturais. Os testes de
regressão são executados muitas vezes, por esta razão deve ser automatizado.
35 De acordo com Pressman (2006), o teste de regressão é uma atividade que
ajuda a garantir que as modificações no produto de software não introduzam
um comportamento indesejável ou erros.
Você consegue imaginar por que existe a necessidade de categorizamos
os testes?
Para aumentar a eficiência da detecção do maior número possível de cená-
rios de testes!
Existem diversas versões sobre a categorização dos testes de software, den-
tre elas podem citar o modelo FURPS, que representa as categorias que podem
ser usadas na definição de requisitos e testes de validação de software, assim
como os atributos de qualidade. Podemos citar também a Norma ISO/IEC9126-
1, a qual é apresentada no próximo tópico.

3.5  Norma ISO/IEC 9126-1

Como já comentamos anteriormente, a qualidade é um conceito muito im-
portante para o software. Durante muito tempo, foram propostos modelos de

capítulo 3 • 65
qualidade, mas a confiabilidade era o único meio de se avaliar a qualidade de
um software. Surgiu então a necessidade de um modelo padronizado. Por essa
razão, o comitê técnico da ISO (International Organization for Standardization)
e IEC (International Electrotechnical Comission), iniciaram em 1985 o desen-
volvimento da Norma Internacional ISO/IEC 9126, que estabelece característi-
cas baseadas no conceito de qualidade para um produto de software.
A Norma ISO/IEC 9126:1991 ou NBR 13596:1996 apresenta a padroniza-
ção mundial do Software como Produto considerado como um “Software de
Qualidade”.
Esta norma fornece um modelo de propósito geral o qual define 6 catego-
rias de características de qualidade de software que são, por sua vez, divididas
em subcaracterísticas. As subcaracterísticas podem ser avaliadas por um con-
junto de métricas.
A ISO/IEC 9126 e foi publicada em 1991, sendo uma das mais antigas da
área de qualidade de software e já possui sua tradução para o Brasil, publicada
em agosto de 1996 como NBR 13596. Estas normas listam o conjunto de carac-
terísticas que devem ser verificadas em um software para que ele seja conside-
rado um "software de qualidade". São seis grandes grupos de características,
cada um dividido em algumas subcaracterísticas, os quais são descritos abaixo:

Qualidade
de produto
de software

Funcionalidade Confiabilidade Usabilidade Eficiência Manutenibilidade Portabilidade

Adequação Maturidade Inteligibilidade Comportamento Analisabilidade Adaptabilidade

Acurácia Tolerância Apreensibilidade emrelação Modificabilidade Capacidade
Interopera- a Falhas Operacionalidade ao tempo Estabilidade para ser
bilidade Recuperabilidade Atratividade Comportamento Testabilidade instalado
Segurança de Conformidade Conformidade em relação Conformidade Co-existência
acesso aos recursos Capacidade para
Conformidade Conformidade substituir
Conformidade

Figura 3.2  –  Norma ISO/IEC 9126

Segundo a ISO/IEC 9126-1, as definições das características e subcaracterís-

ticas de qualidade interna e externa são:

66 • capítulo 3
 Capacidade do produto de software de prover
funções que atendam às necessidades explícitas e
FUNCIONALIDADE implícitas, quando o software estiver sendo utilizado
sob condições específicas.

•  Adequação: capacidade do produto de software de prover um conjunto

apropriado de funções para tarefas e objetivos do usuário especificados.
•  Acurácia: capacidade do produto de software de prover, com o grau de
precisão necessário, resultados ou efeitos corretos ou conforme acordados.
•  Interoperabilidade: capacidade do produto de software de interagir com
um ou mais sistemas especificados.
•  Segurança de Acesso: capacidade do produto de software de proteger
informações e dados, de forma que pessoas ou sistemas não autorizados não
possam lê-los nem modificá-los e que não seja negado o acesso às pessoas ou
sistemas autorizados.
•  Conformidade: capacidade do produto de software de estar de acordo
com normas, convenções ou regulamentações previstas em leis e prescrições
similares relacionadas à funcionalidade.

Capacidade do produto de software de manter um

CONFIABILIDADE nível de desempenho especificado, quando usado
em condições específicas.

•  Maturidade: capacidade do produto de software de evitar falhas decorren-

tes de defeitos no software.
•  Tolerância a Falhas: capacidade do produto de manter um nível de de-
sempenho especificado em casos de defeitos no software ou de violação de sua
interface especificada.
•  Recuperabilidade: capacidade do produto de software de restabelecer seu
nível de desempenho especificado e recuperar os dados diretamente afetados
no caso de uma falha.
•  Conformidade: capacidade do produto de software de estar de acordo
com normas, convenções ou regulamentações relacionadas à confiabilidade.

capítulo 3 • 67
 Capacidade do produto de software de ser com-
USABILIDADE preendido, aprendido, operado e atraente ao usuá-
rio, quando usado sob condições específicas.

•  Inteligibilidade: capacidade do produto de software de possibilitar ao

usuário compreender se o software é apropriado e como ele pode ser usado
para tarefas e condições de uso específicas.
•  Apreensibilidade: capacidade do produto de software de possibilitar ao
usuário aprender sua aplicação.
•  Operacionalidade: capacidade do produto de software de possibilitar ao
usuário operá-lo e controlá-lo.
•  Atratividade: capacidade do produto de software de ser atraente ao usuário.
•  Conformidade: capacidade do produto de software de estar de acordo
com normas, convenções, guias de estilo ou regulamentações relacionadas
à usabilidade.

Capacidade do produto de software de apresentar

EFICIÊNCIA desempenho apropriado, relativo à quantidade de
recursos usados, sob condições específicas.

•  Comportamento em relação ao tempo: capacidade do produto de

software de fornecer tempos de resposta e de processamento, além de taxas de
transferência, apropriados, quando o software executa suas funções, sob con-
dições estabelecidas.
•  Comportamento em relação aos recursos: capacidade do produto de soft-
ware usar tipos e quantidades apropriados de recursos, quando o software exe-
cuta suas funções, sob condições estabelecidas.
•  Conformidade: capacidade do produto de software de estar de acordo
com normas e convenções relacionadas à eficiência.
•  Manutenibilidade: capacidade do produto de software ser modifica-
do. As modificações podem incluir correções, melhorias ou adaptações do
software devido a mudanças no ambiente e nos seus requisitos ou especifica-
ções funcionais.

68 • capítulo 3
 •  Analisabilidade: capacidade do produto de software de permitir o diag-
nóstico de deficiências ou causas de falhas no software, ou a identificação de
partes a serem modificadas.
•  Modificabilidade: capacidade do produto de software que uma modifica-
ção especifica seja implementada.
•  Estabilidade: capacidade do produto de software de evitar efeitos inespe-
rados decorrentes de modificações no software.
•  Testabilidade: capacidade do produto de software de permitir que o soft-
ware, quando modificado, seja validado.
•  Conformidade: capacidade do produto de software de estar de acordo
com normas ou convenções relacionadas à manutenibilidade.

Capacidade do produto de software de ser transfe-

PORTABILIDADE rido de um ambiente para outro.

•  Adaptabilidade: capacidade do produto de software de ser adaptado para

diferentes ambientes especificados, sem necessidade de aplicação de outras
ações ou meios além daqueles fornecidos para essa finalidade pelo softwa-
re considerado.
•  Capacidade de ser instalado: capacidade do produto de software ser insta-
lado em um ambiente especificado.
•  Coexistência: capacidade do produto de software de coexistir com outros
produtos de software independentes, em um ambiente comum, compartilhan-
do recursos comuns.
•  Capacidade para substituir: capacidade do produto de software de ser
usado em substituição a outro produto de software especificado, com o mesmo
propósito e no mesmo ambiente.
•  Conformidade: capacidade do produto de software de estar de acordo
com normas ou convenções relacionadas à portabilidade.

Na norma cada característica é refinada em um conjunto de subcaracterís-

ticas e cada subcaracterística é avaliada por um conjunto de métricas. A norma
não fornece métricas e nem métodos para medição, pontuação ou julgamento.
Cada organização pode estabelecer seus próprios modelos de processo de
avaliação e métodos para a criação e validação de métricas relacionadas com as
características.

capítulo 3 • 69
 Também é necessário estabelecer níveis de pontuação e critérios específi-
cos para a organização ou para a aplicação.

3.6  Métodos estruturados de validação

Vamos conhecer alguns métodos estruturados de validação.

3.6.1  Casos de testes

Casos de teste são elementos essenciais para o sucesso das atividades de teste
em um projeto de software. São eles que definem as entradas a serem informa-
das pelo testador (manualmente ou com apoio ferramental) e os resultados es-
perados a partir desta ação. Assim, eles nos permitem medir o quanto o software
está sendo testado. Já um procedimento de teste define os passos/sequência
necessários para executar os casos.
Estes visam apoiar na customização do esforço de teste em um projeto.
Neste artigo, serão discutidas estratégias para melhor especificação de casos
e procedimentos de teste em projetos de software. Para isso, será utilizado um
exemplo simples e comum de ser encontrado em sistemas de informação, um
formulário de cadastro de venda de produtos on-line com diversas regras de ne-
gócio para validação dos dados preenchidos, e realizaremos a especificação dos
casos e procedimentos de teste de forma a torná-la mais completa e objetiva,
apoiando assim testes manuais e automáticos.
Qualquer profissional da área de teste de software possivelmente conhece
e/ou já precisou especificar casos e/ou procedimentos de teste.
Segundo Craig e Jaskiel (2002), estes artefatos do processo de teste de
software podem ser definidos da seguinte forma:

Descreve uma condição particular a ser testada e

é composto por valores de entrada, restrições para
CASO DE TESTE a sua execução e um resultado ou comportamento
esperado.

70 • capítulo 3
 PROCEDIMENTO DE É uma descrição dos passos necessários para exe-
TESTE cutar um caso (ou um grupo de casos) de teste.

Aqueles com um pouco mais de experiência profissional devem perceber

que uma das dificuldades enfrentadas na atividade de teste é a especificação
dos casos e procedimentos de testes, não apenas pela dificuldade natural exigi-
da pela tarefa, mas pelas variações de formato de descrição destes artefatos em
diferentes locais.
Apesar de existir um padrão internacional para a especificação de casos e
procedimentos de teste publicado no padrão IEEE-Std-829 (roteiro de docu-
mentos para a atividade de teste em geral, não apenas casos e procedimentos
de teste, cuja versão mais atual foi publicado em 2008), este padrão em geral
serve apenas como um roteiro e normalmente é customizado pelas empresas,
em certas ocasiões de forma correta, porém em outras, de forma indevida.
Na verdade, o padrão IEEE-Std-829 foi proposto exatamente com o intuito
de servir como base para que empresas de software pudessem definir o seu ro-
teiro de documentos para as atividades de teste de software. Cada organização
possui suas especificidades e isso precisa ser refletido no roteiro utilizado para
documentar suas atividades de teste.
Assim, se um determinado formato funciona adequadamente para a empre-
sa X, é por que ele contém o conjunto de informações necessárias para que os
demais membros da equipe de teste desempenhem de forma satisfatória suas
atividades. Contudo, não há garantia de que mesmo este formato funcionando
adequadamente em uma empresa, ele possa ser utilizado de forma satisfatória
por outra com características ou perfil diferentes. Maiores ou menores níveis
de detalhamento na descrição podem ser necessários.

3.6.2  Métodos de caixa preta para obtenção de casos de testes

No início desse capítulo vimos sobre os testes de caixa preta e testes de caixa
branca, você se lembra?
Caso não se lembre, pára por um instante, volte e releia os tópicos 3.1.1 e
3.1.2.

capítulo 3 • 71
 Os testes de caixa preta são uma abordagem complementar aos testes de
caixa branca e, possuem a finalidade de identificar um conjunto de situações
que serão empregadas em forma de testes para a identificação de erros.
Quanto maior a variedade de cenários maior será o conjunto de soluções
que serão avaliadas e comparadas com os requisitos. Os principais métodos de
testes de caixa-preta para a obtenção de casos de teste são: Métodos de decom-
posição de requisitos e Métodos de análise de documentos.

Métodos de decomposição de requisitos:

Os requisitos são extremamente importantes no processo de teste de software.

A decomposição de um requisito em cenário é fundamental para obtermos to-
das as possibilidade envolvidas na dinâmica do software. É importante explo-
rar todos os cenários possíveis para cada requisito especificado.
Destacam-se os três tipos de cenários que podem estar contidos nos requi-
sitos: primário, exceção e alternativo.

É a situação mais básica de compreensão de um

CENÁRIO requisito de software. Trata-se da representação de um
PRIMÁRIO cenário perfeito que será usada como linha mestra para
o entendimento de outros cenários existentes.

São variações possíveis dentro do cenário primário, isto

CENÁRIO é, os caminhos alternativos ou situações equivalentes
ALTERNATIVO que conduzirão ao mesmo objetivo.

Trata-se de possíveis problemas e inconsistências que

CENÁRIO DE impedem a finalização de determinado requisito. São
EXCEÇÃO todas as condições impeditivas que podem ocorrer a
qualquer requisito.

72 • capítulo 3
Métodos de análise de documentos:

Todo documento gerado durante o processo de desenvolvimento de software

pode conter elementos importantes para auxiliar na localização de novos casos
de testes e na melhoria do planejamento de testes.
Por exemplo, se durante a modelagem estiver sendo utilizada a UML para
elaboração dos modelos, os diagramas de estados e o digrama de atividades
deverão revelar conjunto de casos de testes que deverão ser inseridos no plane-
jamento de testes.

3.6.3  Métodos de caixa branca para obtenção de casos de testes

Esses métodos baseiam-se em um estudo detalhado das linhas de código. Os

principais métodos de caixa branca para obtenção dos casos de teste são:

É o método mais tradicional utilizado para cobertura

de testes de caixa branca, realizando a medição de
COBERTURA DE linhas que foram executadas dentro de um caso de
LINHAS DE CÓDIGO teste. Por exemplo, se um código fonte possui 100
linhas e 87 delas foram executadas, a cobertura de
código foi de 87% nos testes.

Complementa a visão simplificada da cobertura por

COBERTURA DE linhas de código, exercitando todos os possíveis ca-
CAMINHOS minhos de execução que podem encontrar erros de
inicialização de variáveis, fluxos não previstos, etc.

COBERTURA Tem como objetivo executar todas as condições lógi-

DE DESVIOS cas de um código fonte, como, por exemplo, estrutu-
CONDICIONAIS ras de if, then, else, while, for, entre outros.

capítulo 3 • 73
3.7  Fases da validação
Nos testes de validação, os mecanismos de testes são divididos em dois grupos:
•  Baixo nível: que envolve os testes de unidade e de integração e,
•  Alto nível: que envolve os testes de sistema e de aceitação.

Vamos a seguir, analisar cada uma das fases de validação: da unidade, de

integração, de sistemas e de aceitação.

3.7.1  Validação da unidade

Essa é a primeira etapa do processo de validação e, tem por objetivo testar com-
ponentes individuais de uma aplicação.
Segundo Pressman (2011, pag. 407), esse estágio de teste, também chamado
de testes unitários é definido como: O teste de unidade focaliza o esforço da ve-
rificação na menor unidade de projeto do software – o componente ou módulo
do software. Usando como guia a descrição de projeto nível de componente,
caminhos de controle importantes são testados para descobrir erros dentro dos
limites do módulo.
Molinari (2003, pag. 160) resume esse conceito como “[...] Teste em nível e
componente ou classe. É o teste cujo objetivo é um ‘pedaço de código’.”. Para
Sommerville (2011, pag. 148), os testes unitários devem ser projetados visan-
do à cobertura de código nos objetos, realizando testes em todas as operações
do mesmo, além de verificar seus atributos e simular os mais diversos eventos
que causem alguma mudança nesse objeto, utilizando diferentes entradas para
atingir tal objetivo. Apesar de que os testes unitários possam ser executados de
forma manual, Sommerville (2011, pag. 149) recomenda que: Sempre que pos-
sível, você deve automatizar os testes unitários. Em testes unitários automati-
zados, pode-se utilizar um framework de automação de teste (como JUnit) para
escrever e executar os testes de seu programa. Frameworks de testes unitários
fornecem classes de teste genéricas que você pode estender para criar casos de
teste específicos. Eles podem, então executar todos os testes que você imple-
mentou e informar, muitas vezes por meio de alguma interface gráfica, sobre o
sucesso ou o fracasso dos testes.

74 • capítulo 3
3.7.2  Validação da integração

A validação de integração é uma continuação natural dos testes unitários. O

principal objetivo é validar a compatibilidade entre os diversos componentes
do software.
Testes de integração ou também chamados de testes de componentes, “[...]
é uma técnica sistemática para construir a arquitetura de software ao mesmo
tempo que conduz testes para descobrir erros associados com as interfaces.”
(PRESSMAN, 2011, pag. 409). Além dessa definição, Molinari (2003, pag. 160)
cita que o teste de integração “Garante que um ou mais componentes combina-
dos (ou unidades) funcionam corretamente.”. Para 42 Delamaro, Maldonado e
Jino (2007, pag. 129), os testes de integração são importantes pelo fato de que:
[...] deve-se ressaltar que os tipos de erro em geral revelados com o teste de inte-
gração elevam em muito o custo da atividade de teste se forem detectados nos
estágios mais avançados, em especial se a correção do erro forçar modificações
em unidades previamente testadas. Desse modo, a realização de testes de inte-
gração é de fundamental importância para assegurar uma melhor qualidade
do software que está sendo construído e reduzir os custos associados. Dentro
do contexto de aplicações que usam o paradigma de OO (Orientado a Objeto),
Pressman (2011, pag. 415-416) diz que os testes de integração possuem duas
abordagens: sequência de execução e baseado no uso. A primeira utiliza todas
as classes que respondem a uma entrada ou evento do software, sendo que cada
uma dessas classes precisam ser integradas e testadas de forma individual.
Após isso, testes de regressão são executados para verificar se não ocorreram
problemas. Já, os testes baseados em uso começam pelas classes que podem
possuir poucas classes dependentes ou nenhuma, sendo que ao final desses
testes, as classes que as utilizam irão sendo testadas até que todo o sistema es-
teja construído, sendo isso realizado de forma incremental. O próximo passo,
após que os testes de integração forem realizados é a execução dos testes de
sistema, sendo este estágio definido a seguir.

3.7.3  Validação do sistema

Aqui, o principal objetivo passa a ser a validação do sistema como um todo.

Quando se chega nessa fase é necessário que a maior parte das falhas de funcio-
nalidade tenham sido detectadas pelos testes unitários e os testes de integração.

capítulo 3 • 75
 Segundo Pressman (2011, pag. 421), os testes de sistema caracterizam-se
em “[...] uma série de diferentes testes cuja finalidade primária é exercitar to-
talmente o sistema.”. Pezzè e Young (2008, pag. 443) complementam essa afir-
mação, sendo que “[...] Da mesma forma que o teste unitário e o de integração,
o teste de sistema é focado principalmente na descoberta de falhas, mas ao
contrário das atividades de teste de nível de granularidade mais fino, se con-
centra nas propriedades do nível do sistema.”. Alguns dos tipos de testes que
são realizados nesse estágio foram definidos anteriormente, como, por exem-
plo, os testes de funcionalidade (2.6.1), os testes de recuperação (2.6.11), testes
de segurança (2.6.7), testes de desempenho (2.6.8) e testes de disponibilidade
(2.6.10). 43 Apesar dos diversos tipos de testes que são executados no sistema,
Sommerville (2011, pag. 154) cita que: Para a maioria dos sistemas, é difícil sa-
ber o quanto o teste de sistema é essencial e quando você deve parar de testar. É
impossível fazer testes exaustivos, em que cada sequência possível de execução
do programa seja testada. Assim, os testes precisam ser baseados em um sub-
conjunto possível de casos de teste. [...] Como alternativa, podem basear-se na
experiência de uso do sistema e em testes de características do sistema opera-
cional. Ainda, conforme Sommerville (2011, pag. 155), os testes de sistema são
mais difíceis de automatizar do que testes de unidade e integração, uma vez
que a verificação pode ser dificultada pela necessidade da geração de grandes
volumes de dados ou de dados que não possuam certa precisão, dificultando
os casos de teste que precisam comparar a saída do sistema com a saída ideal
do teste. A seguir, é apresentado o último estágio dos testes, que são os testes
de aceitação.

3.7.4  Validação do aceite

Chegamos no último estágio do processo de validação, sendo o último proces-

so de detecção de erros no sistema, antes que o mesmo seja disponibilizado.
Nessa etapa, o software ;e disponibilizado para os clientes e usuários para que
estes validem todas as funcionalidades requisitadas no início do projeto.
Neste último estágio, Sommerville (2011, pag. 159) define que os testes de
aceitação têm como objetivo: [...] que os usuários ou clientes fornecem entra-
das e conselhos sobre o teste de sistema. Isso pode envolver o teste formal de

76 • capítulo 3
um sistema que foi aprovado por um fornecedor externo ou processo informal
em que os usuários experimentam um produto de software novo para ver se
gostam e verificar se faz o que eles precisam. Para Molinari (2003, pag. 161),
esse estágio de testes se caracteriza por um “[...] teste exploratório voltado para
validar aquilo que o usuário deseja, tendo um objetivo claro: dar o aceite ou
não.”. Dentro dos testes de aceitação, os mesmos podem ser divididos em dois
estágios, sendo estes o teste alfa e o teste beta. (BARTIÉ, 2002, pag. 158-159):
Teste alfa: É caracterizado pelos testes realizados pelos usuários em um am-
biente simulado, podendo este estar localizado dentro da empresa criadora do
software. Esse estágio de teste tem como objetivo observar a naturalidade com
que o sistema é utilizado pelos usuários finais, não sendo muito rigoroso em
relação aos 44 procedimentos mais críticos a serem validados. Apesar disso, ele
deve ter um conjunto reduzido desses procedimentos, garantindo, assim, um
mínimo de cobertura dos testes de aceitação. Teste beta: Tem como caracterís-
tica a execução do sistema na própria infraestrutura da empresa que vai utilizar
o software e, assim, será utilizado nas mesmas proporções que são utilizadas
diariamente. Esse estágio de teste serve para que os usuários possam ter segu-
rança em utilizar essa versão em produção, contando com o apoio da equipe de
desenvolvimento para correção de qualquer problema que possa prejudicar o
seu o uso.
Após a finalização das fases da validação no próximo tópico seguem algu-
mas atividades sugeridas.

ATIVIDADES
01. Comente o que é teste de validação e qual o seu principal objetivo.

02. Diferencie teste de caixa preta de teste de caixa branca.

03. Comente duas abordagens de testes.

04. O que são casos de testes?

capítulo 3 • 77
 REFLEXÃO
O desenvolvimento de software envolve várias fases. Dentre elas podemos destacar a fase
de TESTES de software. É muito complicado inspecionar um sistema inteiro, composto por
vários subsistemas. Os testes são a única técnica viável no nível de sistema.
Vimos nesse capítulo que para podermos realizar os testes de validação de maneira
correta é necessário a definição de estratégias e abordagens.
Aprendemos também sobre a estrutura da Norma ISO 9126, um documento bastante
importante, que apresenta em suas características, requisitos importantes de qualidade que
devem ser testados e verificados.

LEITURA
Casos de Teste: Aprimore seus casos e procedimentos de teste. Disponível em: <http://
www.devmedia.com.br/casos-de-teste-aprimore-seus-casos-e-procedimentos-de-tes-
te/30526#ixzz3gxLIgYqg>.
Um Método para Elicitação e Modemagem de Requisitos Baseado em Objetivos.
Disponível em: <http://www.inf.puc-rio.br/wer01/Eli-Req-5.pdf>.

REFERÊNCIAS BIBLIOGRÁFICAS
PRESSMAN, Roger S. Engenharia de Software, 6 ed. Editora MCGrawHill: Porto Alegre, 2010.
REITZ, Lindomar P. Qualidade de Software com Testes Automatizados: Um Estudo de Caso sobre
Testes de Unidade, Integração e de Sistema, Trabalho de Conclusão de Curso, Florianópolis, 2014.
SOMERVILLE, IAN. Engenharia de Software. 6 ed. São Paulo: Addison Wesley, 2003.
NBR ISO/IEC 9126-1: Engenharia de Software – Qualidade de produto – Parte 1: Modelo de
qualidade. Rio de Janeiro: ABNT, 2003.
BARTIÉ, A. Garantia da Qualidade de Software: Adquirindo Maturidade Organizacional. 1ed. ed. Rio
de Janeiro: Campus, v. I, 2002.
BASTOS, A. et al. Base de Conhecimento em Teste de Software. 1 ed. São Paulo: Martins Editora,
v. I, 2007.
DELAMARO, M. E.; MALDONADO, J. C.; JINO, M. Introdução ao Teste de Software. 2 ed. ed. Rio de
Janeiro: Elsevier, 2007.
MOLINARI, L. Testes de Software: Produzindo Sistemas melhores e mais confiáveis. 1 ed. São Paulo:
Érica, 2003.

78 • capítulo 3
 4
Gerenciamento do
Testware e Gestão
das Ferramentas de
Apoio a Testes
Já cometamos anteriormente que durante o desenvolvimento do software é ge-
rado uma quantidade grande de documentos.
Todos os produtos gerados pelo teste, ou seja, os planos de teste, casos e
teste são considerados testware. Por tanto testware é tudo que os engenheiros
de teste produzem.
Os produtos gerados pelo engenheiros de software não são poucos e, o con-
trole e a organização desses documentos é muito importante para que a etapa
de teste seja realizada corretamente e com qualidade.
Cada ciclo do processo de desenvolvimento de software necessita de uma
ambiente distinto. Os ambientes de processo de software podem ser organi-
zados em ambiente de desenvolvimento, ambiente de testes e homologação e
ambiente de produção.
Para apoiar cada uma fase dos testes de software existem ferramentas espe-
cíficas, estaremos apresentado nesse capítulo as seguintes ferramentas:
•  Ferramentas para Planejamento de Testes.
•  Ferramentas para Revisões e Inspeções.
•  Ferramentas de Modelagem e Automação.
•  Ferramentas de execução e conferência.

OBJETIVOS
•  Compreender o conceito de testware;
•  Definir os ambientes de teste (do desenvolvimento, de testes e homologação e de produção);
•  Compreender as ferramentas para planejamento, revisões e inspeções de testes;
•  Estudar as ferramentas de modelagem e automação;
•  Compreender as ferramentas de suporte aos testes.

80 • capítulo 4
4.1  Conceitos de testware
Segundo Bartié, testware são todos os produtos gerados nas fases de verificação
e validação , incluindo todas as formas de documentação, automação e relató-
rios produzidos.
Outra definição de testware, diz que são artefatos, produzidos durante o
processo do teste, que são necessários para planejar, projetar e para executar
testes, tais como documentação, scripts de teste, entradas, resultados espera-
dos, procedimentos de instalação e limpeza, arquivos, bases de dados, ambien-
tes e qualquer outro software ou utilidades adicionais usados no teste. (IBQTS,
2007)
Assim como os engenheiros de software constroem o software, o produto
do trabalho dos engenheiros de teste é o teste.
Outro fator importante para a correta realização da etapa de testes é o am-
biente onde o mesmo é realizado, o qual deve ser isolado e organizado, para que
a equipe de testes possa trabalhar adequadamente.
Seguindo a definição de Bartié de testware, concluímos que fazem parte
do testware:
•  o checklist,
•  o planejamento e especificação de testes,
•  as rotinas automatizadas de execução de testes,
•  os casos de testes,
•  as massas de testes,
•  relatório finais de validação de testes.

ATENÇÃO
Pessoal, já comentamos vários vezes sobre os checklists das fases de verificação e validação,
vocês estão lembrados?
Se não lembram, voltem ao capítulo 2 e relembrem a tabela 2.2, onde vimos um exemplo
de checklist de modelo de negócios!

O teste contribui para a produtividade, confiabilidade e qualidade do

software. Desta forma todos os cuidados existentes no desenvolvimento de
um software também devem existir no processo de desenvolvimento dos

capítulo 4 • 81
componentes que se referem à automação dos procedimentos de testes.
Devemos considerar que apesar do testware ser um subproduto do processo de
desenvolvimento de software e estão ligados um no outro.
Assim, torna-se necessário uma série de ações com o objetivo de tornar o
processo de teste confiável e produtivo, conforme figura 4.1

Controle do ambiente Utilização de Criação de Equipe capacitada

Criação e de software através rotinas de padrões de a utilizar
manutenção de um sistema de backups elaboração de ferramentas
de ambientes gerenciamento de (armazenamento documentos e e metodologias
de teste configurações periódico) relatórios de testes

Figura 4.1  –  Ações de teste.

4.2  Ambientes de teste

“Ambiente é um local físico onde existe uma infra-estrutura de hardware e
software adequada a uma determinada missão."
O ambiente de testes deve ser definido pelo nível de testes a ser executado,
ou seja, quanto maior o nível, mas, o ambiente de teste deverá ser capaz de re-
produzir as características do ambiente de produção.
O ambiente de testes deve ser isolado, com processamento independente
e características similares ao ambiente de desenvolvimento e produção e deve
ser restrito à equipe de testes para garantir a integridade dos testes realizados.
O Ambiente de testes é o "local" que o sistema será testado.
Ele deve incorporar tudo que envolve o software e seu funcionamento.
Segundo Bastos 2007 a definição do ambiente envolve: ambiente físico, pes-
soas, hardware, documentação, software, suprimentos, rede e interface.
O ambiente de testes deve ser planejado na definição da estratégia de testes
ou no plano de testes. Quanto maior o nível do testes a serem aplicados, mais o
ambiente de testes deverá ser capaz de reproduzir as características do ambien-
te de produção.
A criação, pela equipe de testes, de um ambiente isolado, organizado, re-
presentativo e mensurável garante a descoberta de erros reais, ou seja, aqueles
que realmente ocorreriam na produção e que não foram descobertos em tempo
de desenvolvimento e o mais importante, oferece a garantia de que não houve
influência externa.

82 • capítulo 4
 Outra vantagem é que a preparação desse ambiente isolado, libera a equipe
de desenvolvimento para continuar produzindo novos códigos, sem prejuízo à
integridade do ambiente, mesmo durante a execução dos testes e possibilita a
realização dos de iteração e sistema, de modo a permitir a integração das dife-
rentes camadas e ou ambientes.
As principais características: ambiente isolado, com processamento inde-
pendente e com componentes similares ao ambiente de desenvolvimento e
produção. O ambiente restrito à equipe de testes;
Dentro do processo de testes, as fases são correspondentes a todas as ativi-
dades, produtos e documentos gerados. (BASTOS et al., 2007, pag. 44).
Dentro de cada fase existem diversas atividades, cada uma delas será breve-
mente descrita a seguir.

Nesta fase é “[...] aprofundado um estudo dos requisitos

do negócio que dará origem ao sistema de informação
a ser desenvolvido, de modo que o mesmo esteja com-
pleto e sem nenhuma ambiguidade.” (BASTOS et al.,
PROCEDIMENTOS 2007, pag. 45). Para Rios e Moreira (2006, pag. 57),
INICIAIS opcionalmente poderá ser gerado um Guia Operacional
de Testes (GOT), sendo que o mesmo trata de “[...] um
acordo entre as partes envolvidas (desenvolvedores,
usuários e testadores) visando formalizar o inicio do
projeto de testes.”.

Dentro dessa fase, o objetivo é de “[...] elaborar a

Estratégia de Teste e o Plano de Teste a ser utilizados
de modo a minimizar os principais riscos do negócio
e fornecer os caminhos para as próximas etapas.”
(BASTOS et al., 2007, pag. 46). Ainda, segundo Bastos
PLANEJAMENTO et al. (2007, pag. 46), “A atividade de planejamento tem
de permanecer ativa até que o projeto seja concluído,
visto que se fará necessário avaliar constantemente se
os rumos do projeto estão dentro do que foi previsto e
planejado.”.

capítulo 4 • 83
 Na fase de preparação, o principal objetivo é de “[...]
preparar o ambiente de teste (equipamentos, pessoal,
ferramentas de automação, hardware e software)” para
que os testes sejam executados corretamente. Cada
PREPARAÇÃO ambiente de teste (desenvolvimento, teste e produção)
terá seus tipos de teste, de tal forma que na sua execu-
ção se atinja os melhores resultados. (RIOS; MOREIRA,
2006, pag. 117).

Na fase de especificação, os objetivos básicos serão

de tanto elaborar quanto revisar todos os casos de
teste e roteiro de teste, uma vez que os mesmos serão
ESPECIFICAÇÃO elaborados de forma dinâmica durante todo o projeto,
na medida em que os módulos ou partes dos sistemas
desenvolvidos sejam liberados para tais atividades.
(BASTOS et al., 2007, pag. 47).

A fase de execução tem como principal objetivo a

execução de testes, que devem estar de acordo com os
casos/roteiros de teste, e caso sejam testes automa-
tizados, também devem ser usados os scripts de teste.
(BASTOS et al., 2007, pag. 47). Além disso, Bastos et
EXECUÇÃO al. (2007, pag. 47) citam que: Os testes deverão ser
executados integralmente, por regressão ou parcial-
mente, sempre que surgir alguma mudança de versão
dos programas em teste e nos ambientes preparados
(desenvolvimento, testes, homologação, produção),
conforme previsto na Estratégia e nos Planos de Teste.

Nesta última fase, tudo o que foi realizado durante

o processo será documentado/arquivado, relatando
ENTREGA também todas as ocorrências de conformidades e não
conformidades encontradas no software testado. (BAS-
TOS et al., 2007, pag. 47-48).

84 • capítulo 4
 Para se obter resultados positivos nos projetos de testes é necessário que
o mesmo inicie desde a especificação dos requisitos do sistema a ser imple-
mentado, ou seja, tão logo comece o projeto de desenvolvimento do software
inicia-se também em conjunto o projeto de testes de software.

Os principais participantes no processo de testes são:

•  Gerente de Teste: tem como papel defender a qualidade dos testes, plane-
jar e gerenciar os recursos e resolver os problemas que representam obstáculos
ao esforço de teste.
•  Líder de Teste: pessoa responsável pela liderança de um projeto de teste
específico, normalmente relacionado a um projeto de desenvolvimento, seja
um projeto novo ou uma manutenção.
•  Analista de Teste: elabora e modela os casos e roteiros de testes. Deve fo-
car seu trabalho nas técnicas de teste adequadas à fase de teste trabalhada.
•  Arquiteto de Teste: é responsável por montar a infra-estrutura de testes
como: ambiente, ferramentas, capacitação da equipe, entre outros.
•  Testador: executa os testes, o mesmo deve observar as condições de teste
e respectivos passos de teste documentados pelo analista de teste e evidenciar
os resultados de execução.
•  Automatizador: tem como papel automatizar as situações de teste em fer-
ramentas observando as condições de teste documentadas pelo analista de teste
e automatizar a execução desses testes na ferramenta utilizada. Normalmente
são gerados scripts de teste que permitam a execução de ciclos de teste sempre
que se julgar necessário.

Uma pessoa pode assumir mais de um dos papéis citados acima como,
por exemplo, um testador pode exercer o papel de um automatizador de tes-
tes também.
Cada ciclo do processo de desenvolvimento de software necessita de uma
ambiente distinto.
A seguir vamos comentar cada um desses ambiente: ambiente de desenvol-
vimento, ambiente de testes e homologação e ambiente de produção (figura 4.2)

capítulo 4 • 85
 Ambiente Ambiente Ambiente
de Teste e de
Desenvolvimento Homologação Produção

Ciclo de Vida do Software

Em Em Em Em
Desenvolvimento Teste Homologação Produção

Figura 4.2  –  Ambientes de Teste de Software. Fonte (Bartié, 2002).

4.2.1  Ambiente de desenvolvimento

Este ambiente deverá fornecer toda a infra-estrutura necessária de hardware e

software para o desenvolvimento de um novo software.
Ele deverá ser dividido em duas partes:

•  Uma para atender as necessidades da equipe de desenvolvimento.

•  Outra para atender as necessidades de teste da própria equipe
de desenvolvimento.

Aqui devem ser realizados os testes de unidade e integração e avaliadas as

categorias de funcionalidade e usabilidade.

4.2.2  Ambiente de teste e homologação

Nesse ambiente de teste e homologação devem ser realizados o teste de sistema

e o teste de integração.
No ambiente de testes é realizado o teste de sistema e são verificadas as ca-
tegoria de carga, performance, volume, instalação e segurança.
No ambiente de homologação é realizado o aceitação e são verificadas as
categorias de aceite formal e o alpha-teste.

86 • capítulo 4
 A figura 4.3 apresenta o ambiente de teste e homologação.

Ambiente de Desenvolvimento Ambiente de Teste de Homologação

Teste: Teste: Teste:
Unidade Sistema Aceitação
Desenvolvimento Integração Categoria:
Fontes Carga
Categoria: Performance Categoria:
Estrutura Interna Funcional Aceite Formal
Volume
Usabilidade Instalação Alpha - Teste
Segurança

Em Desenvolvimento Em Teste Em Homologação

Figura 4.3  –  Ambiente de desenvolvimento e ambiente de teste e homologação. Fonte Bar-

tié, 2002.

4.2.3  Ambiente de produção

Segundo Bartié, esse ambiente fornece toda a infraestrutura necessário de

hardware e software para a o produto desempenhe totalmente as funciona-
lidades paras quais foi projetado. Neste ambiente é garantido o controle do
ambiente e segurança contra invasões. É através dos erros identificados neste
ambiente é que pode-se mensurar o quanto o trabalho da equipe de qualidade
de software está sendo efetivo.

Equipe de testes

Os profissionais que atuam na área de teste devem possuir cultura no processo

de teste de software, nas metodologias empregas e nas ferramentas de automa-
ção que são bastante diferenciadas do processo de desenvolvimento.
O papel de um grupo independente de teste é remover os problemas asso-
ciados ao fato de deixar o desenvolvedor testar o software que ele mesmo criou.
O teste independente remove o conflito de interesses que, de outra forma, po-
deria estar presente.
A equipe independente de teste faz parte da equipe de desenvolvimento
de software no sentido de que ela se envolve durante a análise, e o projeto e

capítulo 4 • 87
permanece envolvido (planejando e especificando procedimentos de teste) du-
rante o projeto inteiro.
É comum em muitos casos a equipe de teste responder a organização de
garantia de qualidade de software para, desta forma, obter um grau de inde-
pendência que poderia não ser possível se fizesse parte da organização de en-
genharia de software.

4.3  Ferramentas de apoio a testes

As ferramentas de apoio às atividades de testes são tão importantes quanto as
ferramentas que auxiliam no processo de desenvolvimento de software.
Durante as etapas de testes, muitos documentos são gerados e, o uso de fer-
ramentas par ajudar a gerenciá-los é muito válido.
Essas ferramentas podem auxiliar na elaboração dos checklist, na gestão
dos documentos, no controle de versões e em várias outras atividades desenvol-
vidas nessa etapa.
Segundo Bartié (2002, pag. 196), os testes automatizados são definidos
como “[...] a utilização de ferramentas de testes que possibilitem simular usuá-
rios ou atividades humanas de forma a não requerer procedimentos manuais
no processo de execução dos testes.”. Segundo Molinari (2003, pag. 104), a
aplicação de testes automatizados “[...] permitirá aumentar a profundidade e
abrangência dos casos de testes envolvidos.”. A automação de testes é impor-
tante pelo fato de que podem ser executados de forma frequente, além de se
executarem mais rapidamente do que os testes manuais. Ainda, serão executa-
dos testes de regressão que irão confirmar se novos bugs foram introduzidos no
sistema. (SOMMERVILLE, 2011, pag. 147)
Além dos benefícios da automação de testes de software, a necessidade sur-
giu também pela alta necessidade de utilizar ferramentas que facilitassem os tes-
tes em situações que, de forma manual, seriam muito difíceis ou impossíveis de
serem aplicadas, como testes de performance e estresse em sistemas cliente/ser-
vidor ou sistemas web. (RIOS; MOREIRA, 2006, pag. 153). Conforme Bartié (2002,
pag. 188), “As ferramentas de automação dos testes possibilitam o desenvolvi-
mento de scripts automatizados, de forma a viabilizar um processo de teste com
as atividades de entrada e conferência de valores totalmente automatizados.”.
Outro motivo para sua utilização é que “A automação exige um esforço inicial de

88 • capítulo 4
criação, porém possibilita uma incomparável eficiência e confiabilidade, impos-
sível de ser atingida com procedimentos manuais.” (BARTIÉ, 2002)

Pilares da automação de testes

Rios e Moreira (2006, pag. 156) esclarecem que a automação de testes está fun-
damentada em três pilares que são as ferramentas, a metodologia e a infraes-
trutura. A representação desses pilares da automação de testes é mostrada na
figura 4.4.

Projeto de
automação de testes
Infraestrutura

Metodologia

Ferramenta

Recursos

Figura 4.4  –  Pilares da automação de testes Fonte: RIOS; MOREIRA (2006, pag. 156)..

Seleção da ferramenta certa, adequada à tecnologia

FERRAMENTA usada e que possa integrar com as metodologias de
desenvolvimento e teste.

Existência de metodologias de desenvolvimento e

METODOLOGIA testes consolidadas e usadas, que possam se integrar
com a ferramenta escolhida.

Disponibilidade de máquina e seus recursos , um pro-

INFRAESTRUTURA jeto em desenvolvimento (em fase de testes) dedicado
para o projeto de automação de testes.

capítulo 4 • 89
 Mas, será que todos os casos de testes especificados devem ser automatizados?
Quais casos de testes são candidatos a automatização?
A cada nova versão de um software torna-se necessário realizar um novo
conjunto de teste, visando ampliar as melhorias implementadas. Desta forma
também é necessário reexecutar um conjunto de casos de testes (todos ou par-
tes) de forma a avaliar se as mudanças realizadas danificaram outras partes do
software que já funcionava.
Os custos relativos à execução dos testes de progressão não são importan-
tes. Porém são importantes os custos de execução dos testes de regressão, pois
estes devem ser reexecutados ao longo do ciclo de vida do software.
Desta forma devemos considerar que os testes automatizados visam a oti-
mização da execução dos testes, mas deve ser feito, preventivamente, um es-
tudo de viabilidade técnica e um estudo de custo beneficio para sua utilização
ou não.
Os testes automatizados não substituem os testes manuais, eles são com-
plementares e para isso devemos levar em consideração que todo caso de teste
é naturalmente candidato à automação, mas naturalmente nem todos são reco-
mendáveis para automação:
•  Se o caso de teste for algo pontual e específico de alguma versão do soft-
ware e não se espera que seja testado em versões futuras, não é candidato
à automação.
•  Se o caso de teste tiver características de uso de uma grande massa
de dados, indica ser um data-driventest que precisará provavelmente ser
automatizado.
•  Não existe tempo hábil para automatizar o teste desejado devido ao cro-
nograma, então ele não será momentaneamente um teste a ser automatizado.

Ainda conforme Rios e Moreira (2006, pag. 156), a automação de testes

acaba sendo um processo de longo prazo e alto custo, então existe uma alta
expectativa sobre os seus resultados e benefícios pelas pessoas que dirigem a
organização.
Segundo Bastos et al. (2007, pag. 87): A escolha da ferramenta apropriada
é um aspecto importante do processo de teste. As técnicas são poucas e muito
abrangentes, ao passo que as ferramentas são numerosas e mais restritas. Cada
uma delas oferece diferentes opções, projetada para alcançar um objetivo de
teste específico.

90 • capítulo 4
 Segundo Molinari (2003, pag. 109-111), as escolhas das ferramentas passam
por alguns critérios de escolha, tais como:

•  a compatibilidade da ferramenta com o sistema operacional, ambiente

da aplicação e sistemas de terceiros que são utilizados na empresa;
•  a investigação da ferramenta, ou seja, devem-se verificar quais funcionali-
dades são oferecidas pela ferramenta,
•  quem irá utilizá-la no dia a dia,
•  quanto tempo será destinado a treinamentos,
•  além da questão de facilidade de uso da mesma;
•  os custos que essa ferramenta pode trazer à organização, verificando o
quanto e quando o retorno do investimento será alcançado;
•  e os fornecedores atendem os requisitos de negócio, utilizando isso como
peso para a avaliação e consequente escolha da ferramenta, desqualificando os
fornecedores que menos atendem esses requisitos de forma antecipada.

Pessoal, nós iniciamos nosso estudo falando de Qualidade, lembram?!

Qualidade de sofware, de produto e de processo de software.
Vimos que controlando e gerenciando todas as etapas e tarefas do processo de software
temos uma chance muito grande de obtermos um produto de software com qualidade,
pois a qualidade do produto está diretamente ligada à qualidade do processo.
Pois, bem, para conseguirmos gerenciar e controlar todas as tarefas e documentos do
processo de software nós temos a nosso favor várias ferramentas para nos auxiliar.
Dentre essas ferramentas algumas estão relacionadas a atividade de testes!

Existem várias ferramentas de apoio às atividades de testes, para um bom

desempenho do processo de automatização estas ferramentas devem estar in-
tegradas entre si.

capítulo 4 • 91
 As integrações entre as diversas categorias

Planejamento Modelagem e
de testes Automação

Suporte aos
testes

Revisões e Execução e
Inspeções Conferência

Figura 4.5  –  Categorias das ferramentas de testes. Fonte: Bartié, 2002.

4.3.1  Ferramentas para planejamento dos testes

Estas ferramentas auxiliam a fase de planejamento dos testes definindo es-

copos, abordagens, recursos e programando atividades. As ferramentas de
planejamento de teste auxiliam também no processo de documentação,
possibilitando:

•  Gerar planejamentos padronizados.

•  Elaborar estimativas de tempo e custos.
•  Dimensionar as equipes de acordo com o tempo disponível.

Análise de
Criticidade
Planejamento
de testes
Gerador de
Documentos

Figura 4.6  –  Características das ferramentas de planejamento de testes. Fonte: Bartié,

2002.

92 • capítulo 4
 Cada vez mais, ferramentas de automação de teste estão sendo lançadas no
mercado para automatizar as atividades de teste. Mas antes de pensar em uma
ferramenta é preciso definir os processos. Veja alguns fatores que leva a auto-
mação de testes:
•  Existem fortes pressões para melhorar a qualidade;
•  O projeto tem situações que não possam ser testadas adequadamente pe-
los métodos tradicionais,
•  O perfil dos softwares desenvolvidos for complexo e com impacto
no negócio,
•  Estudos de custo X benefício justificar o investimento,
•  O tamanho do projeto ou do ambiente de teste justificar.

A maioria das empresas sempre avaliam a possibilidade do uso de ferra-

mentas abertas e livres.
Existem basicamente três categorias de ferramentas de automação de tes-
tes, a saber:

Ferramentas de gerenciamento

As ferramentas de gerenciamento são as ferramentas gerenciais, normalmente

utilizadas para fazer a gestão de testes e defeitos. Por exemplo, uma ferramenta
que permite que sejam cadastrados os defeitos encontrados no software duran-
tes os testes.
São ferramentas muito importantes, pois auxiliam o processo de teste como
um todo.
Estão divididas em:
•  Ferramentas de gerenciamento de defeitos (rastreamento e correção dos
defeitos): Jira, Mantis (Free), BugZilla (Free);
•  Ferramentas de controle de versionamento (documenta as versões dos
testes): SubVersion, SourceSafe (Free);
•  Ferramenta de gerenciamento dos testes (gerenciam quais módulos deve
ser testado, em qual data, dar suporte ao gerenciamento de testes e suas ati-
vidades. Faz a interface entre as ferramentas de execução, gerenciamento de
defeito e gerenciamento de requisitos, gerar os resultados e os relatórios de
progresso de teste): RTH, TestLink, Mantis

capítulo 4 • 93
Ferramentas de verificação de código-fonte

Estas ferramentas são utilizadas para:

•  Verificar se o trabalho foi produzido dentro dos padrões de codificação;
•  Identificar pedaços de códigos não executados;
•  Identificar erros mais comuns, como problemas com inicialização de va-
riáveis, estouro de memória, etc.

Estes tipos de ferramentas não têm a obrigação de verificar se o código rea-

liza o que deveria realizar, ou seja, não têm a responsabilidade de testar as fun-
cionalidades. Esse tipo de ferramenta é muito utilizado nos testes unitários.

Ferramentas de automatização na execução dos testes.

São ferramentas que auxiliam diretamente na execução dos testes. Veja al-
guns exemplos:
Unitários - JUnit
Sistema – TestComplet (Teste Funcionais), JUnitPerf
Aceitação – Jmeter (Teste Estresse), JUnitPerf (Teste de Performance).

Objetivos da automação

Veja alguns dos objetivos na utilização da automação de teste:

•  Apoiar o processo de testes;
•  Reduzir falhas introduzidas pela intervenção humana;
•  Aumentar a produtividade (a médio/longo prazo);
•  Tratar a automação dos testes como um projeto.

A automatização deve acontecer quando:

•  Existirem fortes pressões para melhorar a qualidade;

•  O projeto tiver situações que não possam ser testadas adequadamente pe-
los métodos tradicionais;
•  O perfil dos softwares desenvolvidos for complexo e com impacto
no negócio;
•  Estudos de custo X benefício justificar o investimento;
•  O tamanho do projeto ou do ambiente de teste justificar.

94 • capítulo 4
 Como já comentamos, é fundamental o desenvolvimento de ferramentas
de teste para o suporte à atividade de teste propriamente dita, uma vez que essa
atividade é muito propensa a erros, além de improdutiva, se aplicada manual-
mente, bem como para dar apoio a estudos empíricos que visem a avaliar e a
comparar os diversos critérios de teste. Assim, a disponibilidade de ferramen-
tas de teste propicia maior qualidade e produtividade para as atividades de tes-
te. Observam-se na literatura esforços da comunidade científica nessa direção.
Resultados desses estudos fornecem evidências de que esses critérios, hoje
investigados fundamentalmente no meio acadêmico, às vezes em cooperação
com a indústria, podem, em médio prazo, constituir o estado da prática em am-
bientes de produção de software.

4.3.2  Ferramentas de revisões e inspeções

Essas ferramentas apóiam o processo de verificação do software, auxiliam nas

tarefas de revisão dos documentos e nas inspeções técnicas.
As principais características dessas ferramentas são:

•  Análise da complexidade: auxilia a identificar onde estão as áreas mais

complexas e quais possuem maior risco de introduzir novos erros, além de
quantificar o esforço e os custos dos testes a serem empregados.
•  Compreensão do código: Auxilia a inspecionar os códigos-fontes, possibi-
litando avaliar a aderência a padrões de programação estabelecidos pela orga-
nização, como por exemplo:

• Padrão de nome,
• Utilização de rotinas corporativas,
• Variáveis não utilizadas,
• Sub-rotinas internas não acionadas,
• APIs incompatíveis com determinados sistemas operacionais.

•  Análise sintática da semântica: Localiza erros na sintaxe e na semântica

dos comandos empregados no código, os quais o compilador não acusaria, sen-
do possível detectar defeitos antes de os testes formais serem iniciados.

capítulo 4 • 95
 Análise de
Complexidade

Revisões e Compreensão do
Inspeções Código

Análise Sintática
da Semântica

Figura 4.7  –  Ferramentas de revisões e inspeções. Fonte: Bartié, 2002.

4.3.3  Ferramentas de modelagem e automação

As ferramentas de modelagem auxiliam no processo de construção e documen-

tação de como serão testados todos os requisitos de negócio, possibilitando re-
gistrar todos os procedimentos de teste a cada cenário estabelecido e ainda o
processo de conferência dos dados.
Estas ferramentas possibilitam o desenvolvimento de scripts automatiza-
dos. As principais características destas ferramentas são:

Modelagem de
Testes

Modelagem e Gerador de Massa

Automação de Dados

Automatizador
de Scripts

Figura 4.8  –  Ferramentas de Modelagem e Automação. Fonte: Bartié, 2002.

Modelagem de testes: Auxilia nos processos de planejamento e construção

dos testes, identificado os diversos cenários estabelecidos para cada requisito

96 • capítulo 4
a ser testado. Determina as informações que devem ser empregadas em cada
procedimento de teste, atingindo o menor nível de detalhamento.
Vale ressaltar que a modelagem dos testes é um processo mental, assim ne-
nhuma ferramenta substituirá a experiência e abstração de um bom analista de
testes, porém estas ferramentas auxiliam na estruturação das ideias.
Gerador de massa de dados: Possibilita a geração automática de massa de
dados baseada no planejamento dos testes e critérios estabelecidos de forma a
garantir uma massa diferenciada e nas circunstâncias desejadas.
Automatizador de scripts: Possibilita a interação entre as rotinas automa-
tizadas e os softwares a serem testados através da captura de valores em telas,
arquivos, relatórios ou mesmo em banco de dados. Permitem automatizar não
somente as atividades de entrada de informações, como o processo de confe-
rência (análise da saída das informações).

4.3.4  Ferramentas de execução e conferência

As ferramentas de execução e conferência possibilitam o gerenciamento e o

controle do processo de execução, reexecução e medição dos testes planejados.
Possibilitam integração entre as demais fases, de forma a executar os testes se-
lecionados no planejamento.
As principais características destas ferramentas são:
Executor de scripts: Possibilita a interação entre as rotinas automatizadas e
os softwares a serem testados através da captura de valores em telas, arquivos,
relatórios ou mesmo em banco de dados. Permitem automatizar não somente
as atividades de entrada de informações, como o processo de conferência (aná-
lise da saída das informações).
Análise de cobertura: Possibilita estabelecer uma métrica de cobertura do
teste através do monitoramento das linhas de código executadas. Os testes de
caixa branca requerem esse tipo de ferramenta, pois possibilita visualizar áreas
do código não cobertas pelos testes em execução.
Simuladores e medidores de performance: Estão diretamente ligadas aos
testes de sistema, como os testes de carga, volume e performance, já que nessa
categoria é impossível conceber a ideia de realizar testes sem empregar ferra-
mentas específicas.
Testadores de memória : Auxiliam no processo de detecção de problemas
em relação ao uso e alocação de memória pela aplicação. Sendo assim devem
ser específicas para cada linguagem e ambiente.

capítulo 4 • 97
 Executor de
Scripts

Execução e Análise de
Conferência Corbetura

Simuladores de
Performance

Testadores
de Memórias

Figura 4.9  –  Características das Ferramentas de Execução e Conferência. Fonte: Bartié,

2002.

Como as ferramentas de execução e conferência são normalmente integra-

das aos softwares de planejamento de testes e desenvolvimento de scripts, o
executor de scripts permite executar os procedimentos na ordem e frequências
preestabelecidas. Permite também a gestão do ciclo de testes como um todo,
com o controle de execução de cada caso de testes, o controle da reexecução dos
testes e os desvios de testes provocados por erros inesperados.

4.3.5  Ferramentas de suporte aos testes

Estas ferramentas apoiam atividades que não estão diretamente ligadas

ao processo de testes, porém garantem que determinados itens fundamentais
desse processo estão sendo bem gerenciados.
As principais características destas ferramentas são: Gerenciamento de de-
feitos e gerenciamento de configurações.
Gerenciamento de defeitos : Tem como objetivo acompanhar e controlar os
defeitos identificados durante o ciclo de vida do software e monitorá-los até a
sua solução final, através da produção de um grande número de indicadores de

98 • capítulo 4
qualidade. Permite parametrizações de forma a customizar um workflow de re-
solução de problemas, para melhor adapta-se a estrutura da empresa. Também
é conhecido por: gerenciamento de erros, gerenciamento de problemas, regis-
tro de ocorrências, controle de incidências.
Gerenciamento de configurações: Permite controlar e coordenar as mu-
danças efetuadas em documentações, fontes e ambientes físicos. Estabelece a
relação entre os artefatos de software e identifica-los através de um único con-
trole de versão enquanto ocorre modificações de fontes de uma versão anterior.

Gerenciamento
de Defeitos
Suporte aos
testes
Gerenciamento de
Configurações

Figura 4.10  –  Ferramentas de Suporte aos Testes. Fonte: Bartié, 2002.

ATIVIDADES
Vamos agora nos esforçar para responder as atividades abaixo!
Lembrem-se que essas atividades possuem o objetivo de lhes ajudar a relembrar e fixar
os conceitos vistos no capítulo.

01. Defina testware e comente o que faz parte do mesmo.

02. Comente sobre o ambiente de teste e homologação

03. Quais são os objetivos da automação e quando a mesma deve acontecer?

04. Quais são as principais características das ferramentas de suporte aos testes?

capítulo 4 • 99
 REFLEXÃO
Nesse capítulo aprendemos que os produtos gerados pelo teste são denominados testware,
que eles não são poucos e, que é muito importante que sejam organizados e controlados.
Aprendemos também que para produzir os documentos dos testes existem ferramentas
Para apoiar cada uma fase dos testes de software e, finalizamos analisando cada uma des-
sas ferramentas, que são:
•  Ferramentas para Planejamento de Testes.
•  Ferramentas para Revisões e Inspeções.
•  Ferramentas de Modelagem e Automação.
•  Ferramentas de execução e conferência.

LEITURA
Criação e Geração de Planos de Teste de Software. Disponível em: <http://www.ibm.
com/developerworks/br/local/rational/criacao_geracao_planos_testes_software/>.
Testes de software – papéis e oportunidades. Disponível em: <http://pt.slideshare.net/
camiloribeiro/papis-em-teste-e-qualidade-de-software>.

REFERÊNCIAS BIBLIOGRÁFICAS
Base de Conhecimento em Teste de Software. 2 ed. Rios, Emerson; Cristalli, Ricardo; Moreira,
Trayahú & Bastos, Aderson. – S. Paulo, Martins Fontes, 2007.
PRESSMAN, Roger S. Engenharia de Software – Uma Abordagem Profissional. 7 ed. Porto Alegre:
AMGH Editora, 2011.
BARTIÉ, Alexandre. Garantia da qualidade de software: adquirindo maturidade organizacional. Rio
de Janeiro: Campus, 2002.
BASTOS, Aderson; RIOS, Emerson; CRISTALLI, Ricardo;
MOREIRA, Trayahú. Base de conhecimento de teste de software. 2 ed. São Paulo: Martins, 2007.
MOLINARI, Leonardo. Testes de Software: Produzindo Sistemas Melhores e Mais Confiáveis. São
Paulo: Érica, 2003.
SOMMERVILLE, Ian. Engenharia de software. 9 ed. São Paulo: Pearson Prentice Hall, 2011.
PAULA FILHO, W. D. P. Engenharia de Software: Fundamentos, Métodos e Padrões. 2 ed. ed. Rio de
Janeiro: LTC, 2003.
IBQTS- Glossário de termos utilizados mundialmente em testes de software, 2007. Disponível
em: <http://ibqts.com.br/downloads/Glossario_ATC-NF-IBQTS.pdf>.

100 • capítulo 4
 5
Documentação
do Planejamento
e Relatóros das
Verificações e
Validações
A garantia da qualidade de software é uma atividade abrangente aplicada a
cada passo do processo de engenharia de software. Ela envolve procedimentos
pra a efetiva aplicação de métodos e ferramentas, revisões técnicas formais, es-
tratégias e técnicas de teste, procedimentos para controle de mudanças, proce-
dimentos para assegurar o cumprimento de padrões e mecanismos de medição
e reportagem.
Logo que a organização tenha resolvido instituir a garantia da qualidade de
software, deve ser desenvolvido um plano.
Nesse último capítulo vamos distinguir os diferentes planos e documenta-
ção existente para apoiar os processos de qualidade de software.

OBJETIVOS
•  Compreender o plano de garantia da qualidade de software;
•  Compreender o plano mestre de verificação e o plano mestre de validação;
•  Compreender a Norma IEE 829.

102 • capítulo 5
5.1  Plano de garantia da qualidade de
software

Documentar é fundamental para formalizar o processo de qualidade, o conteú-

do da documentação deve ser claro e bem definido, constando todos os itens
que devem ser abordados, possibilitando que todos os envolvidos no processo
de avaliação da qualidade possam:
•  Acompanhar a evolução do trabalho.
•  Rastrear como as atividades foram planejadas
•  Verificar em que condições foram executadas e quais defeitos foram iden-
tificados. A garantia de qualidade de software não é algo com o qual se começa
a pensar depois que o código é gerado.

É muito importante perceber a importância da documentação no processo

de software, uma vez que:
•  O software existe inicialmente na forma de documentos.
•  A qualidade do produto final depende da qualidade da documentação.
•  Os documentos são meios de comunicação entre os diferentes grupos en-
volvidos na elaboração do produto.

Desta forma torna-se necessário a construção de documentos compatíveis

com cada fase do processo de teste de software.
A Garantia de Qualidade de software ou SQA (Software Quality Assurance)
é uma atividade que é aplicada ao longo de todo o processo de engenharia de
software. Ela abrange:
•  métodos e ferramentas de análise, projeto, codificação e teste;
•  revisões técnicas formais que são aplicadas durante cada fase da enge-
nharia de software;
•  uma estratégia de teste de múltiplas fases;
•  controle da documentação do software e das mudanças feitas nela;
•  um procedimento para garantir a adequação aos padrões de desenvolvi-
mento de software, se eles forem aplicados;
•  mecanismos de medição e divulgação.

capítulo 5 • 103
 Geralmente, a garantia de qualidade consiste daqueles procedimentos, técnicas e
ferramentas aplicadas por profissionais para assegurar que um produto atinge ou
excede padrões pré-especificados durante o ciclo de desenvolvimento do produto;
se tais padrões não são aplicados, a garantia de qualidade assegura que um produto
atinge ou excede um nível de excelência (industrial ou comercial) mínimo aceitável.

A finalidade do Plano de Garantia de Qualidade é fornecer um ponto de refe-

rência único sobre qualidade para o projeto. Trata-se de um artefato orientado
a processo que destaca os elementos que contribuem para a obtenção dos ob-
jetivos de qualidade.
O Plano de Garantia de Qualidade não conterá detalhes sobre as técnicas,
os critérios, as métricas e outros itens das revisões e avaliações de colegas cujo
enfoque seja o produto.
É responsabilidade do Gerente de Projeto garantir que o Plano de Garantia
de Qualidade seja criado, apropriado e aceitável para o projeto.
O Plano de Garantia de Qualidade contém informações que podem ser
abordadas com mais ou menos detalhes por outros planos. As abordagens a
seguir podem ser usadas para lidar com essa possível sobreposição:

•  Fazer referência ao conteúdo em outro plano.

•  Fornecer a visão geral em outro plano e mais detalhes neste plano. As
referências provenientes desses outros planos para o Plano de Garantia de
Qualidade também podem ser úteis. Isso geralmente funciona bem em proje-
tos grandes, que tenham uma organização separada responsável pela garantia
de qualidade.
•  Adaptar as seções de documento para cobrir somente as áreas que ainda
não foram abordadas em nenhum outro lugar.

Cada projeto de desenvolvimento e manutenção deveria ter um Plano de

Controle de Qualidade (SQAP) que especifica seus objetivos, as tarefas de SQA
a serem realizadas, os padrões contra os quais o trabalho de desenvolvimento
é para ser medido e os procedimentos e a estrutura organizacional. O Plano de
SQA constitui um mapa rodoviário para a instituição da garantia de qualidade
de software.

104 • capítulo 5
 O padrão IEEE (Padrão ANSI/IEEE 730-1984 e 983-1986) para a preparação
do SQAP contém os seguintes tópicos [Humphrey89]:
I. Propósito do plano
II. Documentos de referência
III. Administração
A. Organização
B. Tarefas
C. Responsabilidades
IV. Documentação
A. Propósito
B. Documentos de engenharia de software exigidos
C. Outros documentos
V. Padrões, práticas e convenções
A. Propósito
B. Convenções
VI. Revisões auditoriais
A. Propósito
B. Requisitos de revisão
1. Revisão dos requisitos de software
2. Revisões de projeto
3. Verificação de software e revisões de validação
4. Auditoria funcional
5. Auditoria física
6. Auditorias in-process
7. Revisões administrativas
VII. Gerenciamento de configuração de software
VIII. Reportagem de problemas e ações corretivas
IX. Ferramentas, técnicas e metodologias
X. Controle de código
XI. Controle de mídia
XII. Controle de fornecedores
XIII. Coleta, manutenção e retenção de registros

A seção de documentação deveria descrever a documentação a ser produ-

zida e como é para ela ser revisada. Os documentos de engenharia de software
exigidos podem ser: Especificação de Requisitos, Descrição de Projeto, Plano de

capítulo 5 • 105
Verificação e Validação, Relatório de Verificação e Validação e Documentação
do Usuário.
O Plano de Verificação e Validação é uma descrição dos métodos usados
para verificar se os requisitos são implementados no projeto, se o projeto é im-
plementado no código e se o código atinge os requisitos. Outros documentos
podem ser:
•  Plano de Desenvolvimento de Software.
•  Plano de Gerência de Configuração de Software.
•  Manual de Padrões e Procedimentos.

A seção de padrões, práticas e convenções especifica um conteúdo míni-

mo de:
•  padrões de documentação;
•  padrões de estrutura lógica;
•  padrões de codificação;
•  padrões de comentários.

A auditoria funcional é uma auditoria feita antes da entrega do sistema para

verificar se os requisitos foram encontrados. A auditoria física também é fei-
ta antes da entrega do sistema para verificar se o software e a documentação
estão consistentes com o projeto e prontos para serem entregues. A auditoria
in-process é uma amostra estatística do processo de desenvolvimento que é
feita para verificar a consistência do o código versus as especificações de pro-
jeto e interface, do projeto versus os requisitos e os planos de testes versus
os requisitos.
As revisões administrativas são revisões independentes, conduzidas para a
verificação da execução do plano de qualidade.
Muitos dos padrões são requeridos para definir apropriadamente a opera-
ção de uma organização de software.

5.1.1  Pessoas relacionadas à garantia de qualidade de software

Alocar pessoas para trabalhar com SQA é uma tarefa difícil dos gerentes de
software.
A prática de iniciar novas contratações em SQA é uma solução parcial que
pode ser efetiva apenas se existem pessoas experientes no mercado. Recrutar

106 • capítulo 5
pessoas para trabalhar em SQA é difícil também porque os profissionais de
software geralmente preferem atribuições de desenvolvimento e a gerência cer-
tamente quer atribuir aos melhores projetistas o trabalho de projeto.
O esquema de rotatividade também pode ser efetivo, mas infelizmente, o
desenvolvimento de software geralmente é adepto a transferir pessoas para tra-
balhar em SQA e não “pegá-las” de volta.
Uma solução efetiva é requerer que todos os novos gerentes de desenvol-
vimento sejam promovidos para trabalharem em SQA. Isso poderia significar
que potenciais gerentes poderiam passar entre seis meses e um ano em SQA,
antes de serem promovidos à gerência. Essa é uma medida extrema, mas pode
ser efetiva [Humphrey89].
Para o trabalho de SQA possa ser efetivo, deve haver bons profissionais na
equipe e um completo apoio da gerência, no sentido de investimento mesmo.

Perceberam no último tópico uma ótima oportunidade de trabalho?

Pois bem, o mercado é carente de bons profissionais na área de Garantia
de Qualidade!
Agora que vocês já sabem disso, já conhecem a atividade de garantia de qualidade e
já estudaram vários assuntos relacionados, quem sabe alguém se decida por seguir
nessa área! É um desafio é tanto, mas que vale a pena!

5.2  Plano de testes

O plano de testes é o documento principal dos testes de software. Nele estão
contidas informações importantes sobre as partes envolvidas no teste, os obje-
tivos do teste, as partes do software a serem testadas, os critérios de aceitação e
os passos necessários para executar os testes.
Cada plano de testes possui descrição de um ou mais casos de teste. Um
caso de teste compreende no mínimo um conjunto de ações a serem executa-
das e um critério de aceitação, que diz se o teste foi bem sucedido ou não. Na
maioria das vezes os casos de teste possuem também critérios de entrada ou
requisitos, e vem acompanhados de uma breve descrição do item a ser testado
e dos objetivos que ele busca atingir.

capítulo 5 • 107
 À medida que a disciplina de testes de software foi se profissionalizando
nos últimos anos, novas seções foram adicionadas aos planos de teste, como
sumário de alto nível e lições aprendidas. Estas seções tem o intuito de situar o
plano de testes e a equipe de testes com relação a outras equipes e ao planeja-
mento do projeto como um todo.
O International Software Testing Qualifications Board (ISTQB) é uma das
instituições mais respeitadas da área de teste de software, pois propõe uma uni-
formização dos conceitos e nomenclatura da disciplina. Grandes corporações,
inclusive a IBM, têm boa parte de seus profissionais certificados pelos exames
da ISTQB e processos de desenvolvimento que utilizam o modelo ISTQB em
seus artefatos e relatórios de testes de software. O ISTQB possui ramificações
no Brasil (BSTQB), Estados Unidos (ASTQB) e Inglaterra (ISEB).
Portanto, para que os testes suportem todos esses aspectos do desenvolvi-
mento de softwares, é preciso que eles sejam projetados e realizados de acordo
com o tipo de software e as necessidades que ele irá atender. A figura 5.1 mostra
o plano de teste e a sua ligação entre o desenvolvimento e os testes.

Especificação Especificação Projeto de Projeto

de requisitos de sistema sistema detalhado

Plano de teste Plano de teste Código unitário

Plano de teste
de integração de integração e de módulo,
de aceitação
do sistema de subsistemas e teste

Teste de Teste de integração Teste de integração

Serviço
aceitação de sistemas de subsistemas

Figura 5.1  –  Plano de teste como ligação entre o desenvolvimento e os testes. Fonte
(Sommerville, 2006).

A seguir vamos analisar os componentes de um plano de testes:

1 Introdução

Na Introdução os objetivos gerais do Plano de Teste são apresentados de forma

clara e não detalhada.

108 • capítulo 5
1.1 Sumário de alto nível

O sumário de alto nível define o escopo dos testes descritos no Plano em rela-
ção ao projeto de desenvolvimento do software como um todo. Ele não contém
aspectos técnicos, pois é uma descrição que deve ser entendida por todos os
envolvidos no projeto, como executivos e gestores de projeto.
Pode incluir restrições de recursos relacionados aos testes, escopo do es-
forço de teste, relacionamento dos testes com outros métodos de avaliação do
software (análises e revisões) e os processos de controle, comunicação e coor-
denação das atividades-chave.

1.2 Terminologia

Essa sessão é útil para identificar termos técnicos, comerciais ou próprios da

empresa que são utilizados ao longo do documento, como nomes de produtos
que são refereciados e processos próprios da empresa.

2 Ambiente e Configuração dos Testes

Nesta sessão são descritos o ambiente de testes e as configurações necessárias

para a execução deles.

2.1 Plataformas

Os testes devem ser executados em todas as plataformas suportadas pelo

software, pois é necessária uma documentação que sustente essa garantia de
suporte dada pelo fabricante do software. Cada uma das platoformas a serem
usadas nos testes deve ser descrita com detalhe, com foco nas características
mais relavantes ao sotware a ser testado: tipo de máquina, capacidade de pro-
cessamento, sistema operacional, quantidade de memória disponível.

2.2 Configurações

Assim como as plataformas, as configurações usadas em cada ambiente de tes-

tes devem ser descritas detalhadamente: softwares relacionados àquele a ser
testado, drivers necessários ao seu uso, entre outras.

capítulo 5 • 109
3 Análise e Estratégia de Teste

A análise e a estratégia de teste são descritas minuciosamente nesta sessão,

que abrange os objetivos, as dependências, a preparação e finalmente os casos
de teste.

3.1 Objetivos dos testes

Os objetivos dos testes são pautados pelas características finais desejadas do

software: segurança, integração com outros processos ou softwares e geração
de determinados dados são alguns exemplos.

3.1.1 Obj 1 - <Definição do objetivo. Exemplo: Segurança>

•  Condição do teste: <Condição que deve ser atendida para que o objetivo
seja satisfeito. Exemplo: Somente usuários autorizados devem ter acesso às
funcionalidades do software.>
•  Abordagem: <De que forma esse objetivo pode ser avaliado? Exemplo:
Devem ser usadas combinações corretas e incorretas/inválidas de usuário e se-
nha na tela de autenticação do usuário.>
•  Critério de aceitação: <Critério que define se o obejtivo foi atendido.
Exemplo: O processo de autenticação para uso do software deve negar aces-
so em caso de combinações incorretas de usuário e senha e permitir o acesso
quando a combinação fornecida for correta.>

3.2 Dependências dos casos de teste

Nessa sessão são descritos os requisitos que devem ser atendidos para a realiza-
ção dos testes. Pode ser necessária a preparação de dados de entrada para que
o software os reconheça, por exemplo.

3.3 Preparação para os casos de teste

Tudo o que deve ser preparado antes de se iniciar a execução dos testes é des-
crito nessa sessão, como por exemplo a preparação de ambiente, upgrade/do-

110 • capítulo 5
wngrade das dependências, ou qualquer outro passo que necessita estar previa-
mente configurado antes do teste.

3.4 Casos de teste

Os casos de teste definem com detalhe os procedimentos a serem seguidos du-

rante a execução dos testes.

3.4.1 CT 1 - <Nome>

•  Descrição: <Em que consiste esse caso de teste? Exemplo: Verificar se um

usuário não autorizado consegue acessar as funcionalidades do software.>
•  Tempo estimado: <Qual é a duração estimada desse teste? Exemplo: A ve-
rificação para autenticação deve ser feita em até 3 segundos.>
•  Critério de saída: <Quais ações ou dados de saída são esperados? Exemplo:
O acesso deve ser negado e uma mensagem exibida ao usuário.>
•  Requisitos do ambiente: <Quais os requisitos do ambiente para a reali-
zação desse teste? Exemplo: O software a ser testado deve estar instalado no
ambiente de testes.>
•  Objetivos mapeados: <Quais objetivos são mapeados com esse teste?
Exemplo: Obj 1 - Segurança>

4 Execução dos Testes

4.1 Cobertura

Essa sessão lista as funcionalidades do software que são cobertas pelos testes
do Plano, além de outros aspectos, como usabilidade, performance e seguran-
ça. Ela não deve ter um caráter técnico, e sim deve ser feita sob o ponto de vista
do usuário, abordando o que interessará a ele e refletindo o que será testado
através dos casos de teste.

4.2 Resultados

A importância de se registrar os resultados dos testes é muito grande: eles são a

base para a criação de itens de trabalho para reparo e replanejamento durante o

capítulo 5 • 111
desenvolvimento. E, ao final do desenvolvimento, a compilação dos resultados
dos testes bem-sucedidos são um indicativo relevante da confiabilidade daque-
le software.

5 Lições aprendidas

O registro das lições aprendidas durante os testes realizados é um material de

consulta muito útil para a criação de novos Planos de Teste, especialmente para
pessoas que não participaram dos testes definidos nesse Plano, e para testado-
res com menos experiência na área. Essa é uma sessão que resume o que pode
ser feito de forma melhor em novos testes, especialmente em Planos de Teste
de Software semelhantes ao testado.

5.3  Plano mestre de verificação

Vocês se lembram o que estudamos no capítulo 2?
Vamos relembrar:
A atividade de teste de software é um elemento de um tema mais amplo que
frequentemente é chamado de verificação e validação (V&V).
A verificação refere-se ao conjunto de atividades que garante que o software
implemente corretamente uma função específica.
Boehm (BOE81), define essa questão da seguinte maneira:

Verificação: “Estamos construindo certo o produto?”

O plano mestre de verificação é um documento de alto nível elaborado

no processo de verificação do software, subordinado ao Plano de Garantia de
Qualidade do Software, com o objetivo de:
•  Definir e estruturar o processo de verificação.
•  Estabelecer a visão da equipe de verificação.
•  Uniformizar os conhecimentos, experiências e expectativas dos diversos
grupos que integram o processo de desenvolvimento de software.

O plano mestre de verificação aborda os seguintes itens:

112 • capítulo 5
 •  Propósito do documento.
•  Detalhes do ciclo de do processo de verificação.
•  Principais atividades de verificação.
•  Definição de papeis e responsabilidades da equipe de verificação.
•  Principais documentos a serem empregados.
•  Principais documentos a serem gerados.
•  Referências a técnica, métodos e ferramentas a serem empregadas.
•  Referências a padrões, políticas, formatos a serem adotados.
•  Contratação de treinamentos e mentoring.
•  Cronograma das etapas da verificação.
•  Riscos e contingências.

Subordinado ao Plano Mestre de Verificação estão as Estratégias de

Verificação. Para cada fase da verificação deve haver uma estratégia de verifica-
ção definida e documentada.
As estratégias de documentação tem por objetivos:
Estabelecer o escopo definido de trabalho
•  Organizar as atividades de levantamento.
•  Definir os riscos e suas contingências.

As estratégias de verificação devem estar divididas em estratégia de verifica-

ção de modelagem de negócios, de requisitos, de análise e design e de imple-
mentação. Cada uma delas devem abordar os seguinte itens:
•  Propósito do documento.
•  Detalhes das atividades de verificação.
•  Definição dos grupos de revisão e auditoria.
•  Definição de papeis e responsabilidades.
•  Documentos a serem verificados.
•  Principais documentos a serem gerados.
•  Documentos que não serão verificados.
•  Lista de documentos a serem produzidos.
•  Critério de finalização dos testes.
•  Checklists que serão empregados.
•  Técnicas, ferramentas e padrões a serem empregadas.
•  Cronograma detalhado.
•  Lista de aprovação.

capítulo 5 • 113
5.4  Plano mestre de validação
A validação refere-se a um conjunto diferente de atividades que garante que o
software que foi contruído é rastreável às exigências do cliente.
Da mesma forma que na verificação, Boehm (BOE81), define essa questão
da seguinte maneira:

Validação: “Estamos construindo o produto certo?”

O Plano mestre de validação é um documento de alto nível elaborado no

processo de verificação do software.
Este plano é subordinado ao Plano de Garantia de Qualidade do Software, e
tem como objetivos:
•  Definir e estruturar o processo de validação;
•  Estabelecer a visão da equipe de validação do software;
•  Uniformizar os conhecimentos, experiências e expectativas dos diversos
grupos que integram o processo de desenvolvimento de software.

As estratégias de Validação utilizadas são: Unidade; Integração, Sistema

e Aceite.
O Plano mestre de validação deve os seguinte itens:
•  Propósito do documento.
•  Detalhes das atividades de validação.
•  Definição dos grupos de validação.
•  Definição de papeis e responsabilidades.
•  Áreas do software que serão verificados.
•  Áreas do software que não serão verificados.
•  Lista de componentes de testes a serem criados (controladores
e simuladores).
•  Lista de documentos a serem produzidos.
•  Técnicas, ferramentas e padrões a serem empregadas.
•  Cronograma detalhado.
•  Lista de aprovação.

114 • capítulo 5
 As estratégias de validação são documentos de alto nível, elaboradas em
cada fase da validação do software. São subordinadas ao Plano de Garantia de
Qualidade e possuem os seguintes objetivos:
•  Estabelecer a visão clara de como será operacionalizado o processo;
•  Estabelecer o escopo definido de trabalho;
•  Nivelar as expectativas em relação aos testes de software;
•  Identificar quais os assuntos serão futuramente levantados e detalhados
nas fases posteriores;
•  Apontar riscos e contingências do processo;
•  Definir os próximos passos a serem executados.

5.5  Casos de teste

É o documento de registro de todo o planejamento dos testes de estabelecendo
o que será testado. Sua finalidade é identificar o maior número de cenários e
variações de determinado requisito de software.
Os casos de testes determinam as informações empregadas durante os tes-
tes dos cenários e os resultados esperados, estabelecendo a massa critica de
testes para validar os requisitos do software.
O documento de casos de teste deve abordar os seguintes itens:
Abordar os seguinte itens:
•  Identificação das condições de testes.
•  Identificação dos casos de testes.
•  Definição de cada caso de teste identificado.
•  Detalhamento da massa de entrada.
•  Detalhamento da massa resultante.
•  Arquitetura do ambiente de teste.
•  Critérios especiais para geração da massa de testes (d + O, d – 30, m + 1,
a + 18).
•  Responsáveis pelo levantamento.
•  Cronograma detalhado.
•  Definir agenda de levantamentos (como testar).

capítulo 5 • 115
5.6  Suíte de testes
Finaliza o processo de detalhamento dos testes de validação. A suíte de tes-
tes estabelece:
•  Como será testado um determinado conjunto de casos de uso.
•  Define quais procedimentos e em que ordem serão executados.
•  Possibilita validar o comportamento dos vários cenários de determinados
requisitos de software.

Esse documento deve abordar os seguintes itens:

•  Identificação das suítes de testes.
•  Definição das suítes de teste.
•  Pré-requisitos de cada suíte.
•  Definir os procedimentos de iniciação dos teste (setup-up).
•  Definir os procedimentos de execução dos testes.
•  Definir os procedimentos de conferência dos testes.
•  Definir os procedimentos de limpeza e finalização dos testes (clean-up).
•  Definir agenda de levantamentos para detalhamentos.
•  Cronograma detalhado.

5.7  Norma IEEE 829

IEEE 829,1 também conhecido como o Padrão 829 para Documentação de Tes-
te de Software, é um padrão IEEE que especifica a forma de uso de um conjunto
de documentos em oito estágios definidos de teste de software, cada estágio
potencialmente produzindo seu próprio tipo de documento. O padrão especi-
fica o formato desses documentos mas não estipula se todos eles devem ser
produzidos, nem inclui qualquer critério de conteúdo para esses documentos.
A primeira versão do padrão foi publicada em 1983, tendo sido revisada em
1998 e 2008. Por este motivo são referidas como IEEE 829-1983, IEEE 829-1998
e IEEE 829-2008, respectivamente (Wikipédia, 2015).
Esse padrão também é conhecido com Norma e descreve um conjunto de 8
documentos definidos, que cobrem as tarefas de planejamento, especificação
e relado de testes. São eles:

116 • capítulo 5
 •  Plano de Teste que apresenta o planejamento para a execução do teste
identifica os itens e as funcionalidades a serem testados, as tarefas além dos
riscos associados com a atividade de teste.
•  Há também a tarefa de especificação de testes que é composta por 3 do-
cumentos (Especificação de Projeto de teste, Especificação de caso de Teste,
Especificação de Procedimento de teste) que principalmente identifica os ca-
sos e os procedimento de teste, critérios de aprovação, define dados de estrada
e resultados esperado, além de especificar os passos para a execução dos testes.
•  Já os relatórios são cobertos por 4 documentos (Diário de teste, Relatório de
Incidente de Teste, Relatório-Resumo de teste, Relatório de Encaminhamento
de Item de Teste) que visam registrar detalhes relevantes, eventos que ocorrem
durante os testes e resultados das atividades.

Um detalhe importante é que esta norma separa as atividades de teste em

três etapas: preparação do teste, execução do teste e registro do teste. Mais do
que apresentar um conjunto de documentos, esta norma apresenta um conjun-
to de informações necessárias para teste de produtos, independentemente do
tamanho ou complexibilidade do software. Se bem utilizado, servirá de auxilio
para gerencia.

Suporte à Interpretação do Processo de Teste de Software

Como normalmente as normas de engenharia de software são genéricas, a me-

todologia de teste da norma IEEE-829 propões um método para implantação
do processo de teste de software, para isso possui alguns documentos descre-
vendo isso. São eles:

•  Guia para Elaboração de Documentos de Teste de Software: tem o propó-

sito de servir como referencia para criação de documentos de teste.
•  Processos para a Elaboração de Documentos de Teste de Software: apre-
senta os processo que abrangem a preparação, a execução e o registro dos resul-
tado do teste para estabelecerem uma orientação geral.

Independente da forma em que os documentos serão adaptados para os

testes, é importante que incluam o planejamento, projeto, os casos de teste
e os procedimentos de teste. Além disso, os resultados/incidentes ocorridos

capítulo 5 • 117
durante o teste devem ser adequadamente registrados e condensados num re-
latório final.
A seguir apresentamos algumas atividades a serem resolvidas com o intuito
de fixar os conhecimentos aprendidos nesse capítulo.

ATIVIDADES
01. Quais são os tópicos de um plano de garantia de qualidade de software?

02. Quais são os componentes do Plano de Testes?

03. Quais itens são abordados pelo Plano Mestre de Verificação?

04. O que é descrito na Norma IEEE 829?

REFLEXÃO
De acordo com Pressman (2011), a principal finalidade de se aplicar a abordagem e os
fundamentos da Engenharia de Software é a criação de softwares dentro de prazos e custos
planejados e, sobretudo, que se obtenha como resultado um produto que apresente alta
qualidade. A qualidade de software é definida pela norma ISO/IEC 9126 (2003), como sen-
do a capacidade de um produto ou serviço apresentar funcionalidades e características que
atendem totalmente as necessidades específicas ou implícitas dos usuários. Segundo Som-
merville (2007), a garantia da qualidade reúne processos que definem como alcançar a qua-
lidade do software e como a equipe de desenvolvimento deverá se comportar para satisfazer
o nível de qualidade exigido.
O processo de Verificação e Validação (V&V) é um dos processos de garantia de qua-
lidade do software que abrange várias atividades, dentre elas o Teste de Software, que tem
uma importante função neste aspecto. Conforme Jenkins (2008), a Verificação deve garantir
a consistência interna do produto, ou seja, certificar que suas especificações estão sendo
atendidas, enquanto a Validação utiliza as referências externas do usuário final, para assegu-
rar que o produto construído satisfaz suas necessidades e expectativas.

118 • capítulo 5
 Os Testes de Software são conjuntos de funções e atividades que são executadas com
o objetivo de encontrar erros cometidos na construção de um software. Sommerville (2007)
aponta outra meta dos testes além de descobrir falhas no software, que é comprovar aos
desenvolvedores e ao usuário final que o programa atende aos requisitos e está em confor-
midade com suas especificações.
A garantia da qualidade tem uma forte relação com os testes de software no sentido de
que a execução dos testes é motivada pela confirmação da qualidade do programa, através
de procedimentos que podem ser aplicados a todos os sistemas.
Apesar dos testes colaborarem significativamente, eles não podem assegurar a qualida-
de do produto. Ainda de acordo com Sommerville (2007), a atividade de teste é um processo
que tem o objetivo de contribuir para a confiabilidade do software, porém não garante que
seu comportamento será o esperado em qualquer circunstância ou que estará totalmente
livre de falhas durante sua utilização.

Para que os testes de software sejam executados é preciso que seja definida uma Es-
tratégia de Teste que, conforme Pressman (2011), deve fornecer um roteiro que indica o
caminho a ser seguido, definindo como e quando os passos referentes aos testes serão
planejados e executados, além do tempo, esforço e recursos necessários. Ainda segundo o
autor, uma Estratégia de Teste de Software reúne alguns elementos que são o planejamento
dos testes, o projeto dos casos de teste, a execução dos testes e, por fim, a coleta e avaliação
de resultados.
Jenkins (2008) afirma que o planejamento dos testes deve ser feito para garantir que
se obtenham os resultados esperados, decidindo onde os erros podem ser encontrados e
projetando os testes mais eficientes para localizá-los. Uma das maneiras de se criar um plano
de teste é baseá-lo em riscos, ou seja, em uma parte do código em que a probabilidade de
ocorrência de uma falha seja maior ou em um módulo específico onde o impacto do erro
poderia comprometer o funcionamento do produto.
Espero que tenha apreciado o assunto e que o mesmo lhe seja útil na sua vida profissional!
Continue se atualizando, a avaliação de software ainda é uma área recente e sem-
pre podemos contar com mais informações e estudos de caso para nossa aprimorar nos-
sa formação.
Finalizando nosso estudo, após esse último capítulo apresenta-se no Anexo 1, um exem-
plo de Plano de Garantia de Qualidade de Software.

capítulo 5 • 119
 LEITURA
Testador de software é uma profissão em alta. Disponível em: <http://eduardo-prola.
blogspot.com.br/2015/04/testador-de-software-e-uma-profissao-em.html>.
Documentação de teste baseado na Norma IEEE 829 – estudo de caso: “siste-
ma de apoio a tomada de decisão”. Disponível em: < file:///C:/Users/Mayb/Down-
loads/18-74-2-PB.pdf>.
Garantia da qualidade dos processos de software baseados no MPS.BR – UM
ESTUDO DE CASO. Dipsonível em: <http://www.uel.br/cce/dc/wp-content/uploads/Ver-
saoPreliminarTCC-RafaellaCarvalho.pdf>.

REFERÊNCIAS BIBLIOGRÁFICAS
(BOE81) Boehm, B., Software Engineering Economics, Prentice-Hall, 1981, p.37
WEBER, K.C.; ROCHA, A.R.C e NASCIMENTO, C.J. Qualidade e produtividade em software, 4 ed
renovada. São Paulo, SP, Makron Books, 2001.
PRESSMAN, Roger S. Engenharia de Software. Rio de Janeiro: MacGraw Hill, 2006
PÁDUA, Wilson de Pádua Paula. Engenharia de software: fundamentos, métodos e padrões. 3 ed.
Rio de Janeiro: LTC, 2005.
ISO, 2014) – International Organization for Standardization. Disponível em: http://www.iso.
org

GABARITO
Capítulo 1

01. Qualidade de software possui várias definições, vejamos algumas:

•  Qualidade de software é a conformidade a requisitos funcionais e de desempenho que fo-
ram explicitamente declarados, a padrões de desenvolvimento claramente documentados, e a
características implícitas que são esperadas de todo software desenvolvido por profissionais.
•  Um produto de software apresenta qualidade dependendo do grau de satisfação das ne-
cessidades dos clientes sob todos os aspectos do produto.
•  Qualidade é a totalidade de características e critérios de um produto ou serviço que exer-
cem suas habilidades para satisfazer as necessidades declaradas ou envolvidas .

120 • capítulo 5
•  Qualidade é a totalidade das características de uma entidade, que lhe confere a capacida-
de de satisfazer necessidades explícitas e implícitas.
02. Um processo de software pode ser definido como um conjunto de atividades, métodos,
práticas e transformações que as pessoas usam para desenvolver e manter o software e os
produtos associados (por exemplo: planos de projeto, documentos, código, casos de teste e
manuais de usuário).
Um processo de software envolve um grande conjunto de elementos, tais como objetivos
organizacionais, políticas, pessoas, comprometimentos, ferramentas, métodos, atividades de
apoio e as tarefas da engenharia de software. Para que o processo de software seja eficiente
ele precisa ser constantemente avaliado, medido e controlado. Quando o processo é eficien-
te ele possui as seguintes características:
•  O processo continua a despeito de problemas inesperados (Robustez).
•  Rapidez na produção do sistema (Velocidade).
•  O processo é aceito por todos os envolvidos nele (Aceitabilidade)
•  Os erros do processo são descobertos antes que resultem em erros no produto
(Confiabilidade)
•  O processo evolui para atender alterações de necessidades organizacionais
(Manutenibilidade)
•  O processo é compreendido (usualmente através de documentação e de treinamento),
utilizado, vivo e ativo.
•  O processo é bem controlado – a fidelidade ao processo é objeto de auditoria e de controle.
•  Medidas do produto e do processo são utilizadas,
•  Os papéis e responsabilidades no processo estão claros ao longo de todo o projeto e por
toda a organização
03. A atividade de teste consiste de uma análise dinâmica do produto e é uma atividade re-
levante para a identificação e eliminação de erros que persistem. Do ponto de vista de quali-
dade do processo, o teste sistemático é uma atividade fundamental para a ascensão ao Nível
3 do Modelo CMM do Software Engineering Institute — SEI. Ainda, o conjunto de informação
oriundo da atividade de teste é significativo para as atividades de depuração, manutenção e
estimativa de confiabilidade de software.
04. Defeito é um ato inconsistente cometido por um indivíduo ao tentar entender uma de-
terminada informação, resolver um problema ou utilizar um método ou uma ferramenta. Por
exemplo, uma instrução ou comando incorreto.
Erro é uma manifestação concreta de um defeito num artefato de software. Diferença
entre o valor obtido e o valor esperado, ou seja, qualquer estado intermediário incorreto ou
resultado inesperado na execução de um programa constitui um erro.

capítulo 5 • 121
 Falha é o comportamento operacional do software diferente do esperado pelo usuário.
Uma falha pode ter sido causada por diversos erros e alguns erros podem nunca causar
uma falha.
05. Um plano de teste deve possuir as seguintes etapas:
- Processo de Teste:
• Descrição de cada fase do Teste (Estratégia),
- Rastreabilidade de Requisitos
• Planejamento de teste para cada requisito
- Itens que serão Testados
• Descrição detalhadas de cada Item que será “testado” (Modelo, Manual, Programa,
etc..)
- Cronograma
• Além do Tempo, Matriz de Alocação de Recursos x Atividades-Fases Engenharia de
Software
- Procedimentos de Registro
• Definição das Métricas e Padronização dos mecanismos de registro de resultados,
para que o processo de teste possa ser medido
- Requisitos de Hardware, Software e Rede
• Lista de recursos necessários para o teste
- Descrição das Restrições
• Restrições que afetarão o processo de teste (Ex: Deficiência de Pessoal, Treina-
mento de Pessoal, Aquisição de Software, etc)

Capítulo 2

01. O processo de auditoria é de extrema importância, podendo variar de organização para

organização, porém não deve deixar de alcançar o objetivo da auditoria. Um processo de
auditoria exerce uma ação preventiva, reparadora e moralizadora. As etapas do processo de
auditoria são: planejamento, auditoria e finalização
02. Os objetivos da FTR são:
•  descobrir erros na função, na lógica ou na implementação, para qualquer representação
do software;
•  verificar se o software sob revisão satisfaz seus requisitos;
•  garantir que o software tenha sido representado de acordo com padrões predefinidos;
•  conseguir software que seja desenvolvido de modo uniforme;
•  tornar os projetos mais administráveis.

122 • capítulo 5
 Além disso, a FTR serve como uma oportunidade de treinamento, permitindo a jovens
engenheiros observar abordagens diferentes para a análise, projeto e implementação
de software.
03. Os seguintes dados representam um conjunto mínimo de diretrizes para as revisões
técnicas formais:
•  revise o produto, não o produtor: uma FTR envolve pessoas e egos. Se conduzida adequa-
damente, deve deixar em todos os participantes um sentimento de realização. Se realizada
inadequadamente pode assumir a áurea de uma inquisição.
•  fixe e mantenha uma agenda: uma FTR deve ser mantida nos triulhos e em seu cronogra-
ma. Ao líder de revisão é dada a responsabilidade de manter o cronograma da reunião, ele
não deve ter medo de chamar a atenção de pessoas quando a divagação instalar-se.
•  limite o debate e a refutação: quando uma questão é levantada por um revisor, talvez não
uma haja uma concordância universal sobre o seu impacto. Em vez de perder tempo debaten-
do a questão, o assunto deve ser registrado para posterior discussão off-line.
•  enuncie as áreas problemáticas, mas não tende resolver cada problema anotado: a revisão
não é uma sessão de resolução de problemas. A resolução dos problemas deve ser poster-
gada para depois do encontro da revisão.
•  faça anotações por escrito: as vezes é uma boa idéia que o secretário faça anotações numa
lousa, de forma que a redação e a determinação de prioridades possam ser avaliadas por
outros revisores quando a informação for registrada.
•  limite o número de participantes e insista numa preparação antecipada: mantenha o nú-
mero de pessoas envolvidas ao mínimo necessário. Todos os membros da equipe de revisão
devem preparar-se antecipadamente. Comentários escritos devem ser solicitados pelo líder
de revisão.
•  desenvolva uma lista de conferência (cheklist) para cada produto que provavelmente será
revisto: uma lista de conferência ajuda o líder de revisão a estruturar o encontro e ajuda cada
revisor a se concentrar em questões importantes.
•  atribua recursos e uma programação de tempo para as TFRs: para que as revisões sejam
efetivas, elas devem ser programadas como tarefas durante o processo de engenharia de
software. Além disso, deve-se programar tempo para as inevitáveis modificações que ocorre-
rão como resultado de uma FTR.
•  realize um treinamento significativo para todos os revisores: o treinamento deve destacar
tanto as questões relacionadas a processos como o lado psicológico humano das revisões.
•  reveja suas antigas revisões: o produto prioritário a ser revisado poderiam ser as próprias
diretrizes da revisão.
04.

capítulo 5 • 123
•  Compreensão do ambiente,
•  Análise do ambiente e determinação dasπ situações mais sensíveis,
•  Elaboração de uma massa de testes,
•  Aplicação da massa de testes,
•  Análise das simulações,
•  Emissão da opinião quanto ao ambiente auditado,
•  Debate com os profissionais da área auditada para discussão das alternativas
recomendadas,
•  Acompanhamento da implantação da solução proposta,
•  Auditoria da solução implantada,
•  Novas auditorias no ambiente,
•  O auditor deve utilizar palavras de questionamentos como: Como?, O que?, Quando?,
Quem?, Onde?, Por que? e Mostre-me (Evidência),
•  Estar bem preparado para realizar a auditoria,
•  Tentar prever o máximo de situações possíveis,
•  Evitar surpresas ao auditado,
•  Esclarecer todas as dúvidas sobre uma nãoconformidade,
•  Buscar objetividade e fatos concretos (Evidências),
•  Não atacar pessoas e sim fatos concretos,
•  Motivar a identificação de melhorias,
•  Persuadir, não impor,
•  O auditor não deve relacionar pessoas à não-conformidades ou deficiências,
•  Ser flexível quando necessário e,
•  Ser imparcial e objetivo para obtenção dos fatos

Capítulo 3

01. O teste de validação tem o seu foco na aplicação, uma vez que já existe um produto com-
putacional. Seu principal objetivo é identificar o maior número possível de erros. O sucesso
desse teste está apoiada no forte planejamento de todas as atividades de teste.
É um processo formal de avaliação de produtos tecnológicos que podem ser aplicados
em componentes isolados, em módulos existentes ou mesmo à totalidade do sistema.
O seu principal objetivo é avaliar a conformidade do software com os requisitos e especi-
ficações analisadas e revisadas nas etapas iniciais do projeto.

124 • capítulo 5
02. Teste de caixa branca: Também conhecido como teste estrutural. É aquele em que o
analista tem total acesso à estrutura interna da entidade sendo analisada e permite, por
exemplo, que o analista escolha partes específicas de um componente para serem testadas.
Esses testes são projetados em função da estrutura do componente e podem permitir
verificação mais precisa de comportamento do produto. Ele permite ao avaliador concentrar
a atenção nos pontos mais importantes ou “perigosos” do código, de uma maneira mais pre-
cisa do que no caso do teste caixa-preta. Tais pontos podem até ser identificados durante o
desenvolvimento e cobertos com o uso de assertivas e testes.
A versão de testes resultante deve ser executada e os resultados, observados. Natu-
ralmente, é preciso um cuidado especial com o controle de versões de software: a versão
de teste, bem como o executável resultante, não deve jamais ser confundida com a versão
correta que será entregue ao cliente.
Testes de caixa preta: O Teste de Caixa-Preta ou Teste Funcional, também é usado na
engenharia, no problema de identificação de sistemas, e advém do fato de que ao analisar o
comportamento de um objeto, ignora-se totalmente sua construção interna.
O teste de caixa-preta é baseado nos requisitos funcionais do software. Como não há
conhecimento sobre a operação interna do programa, o avaliador se concentra nas funções
que o software deve desempenhar. A partir da especificação são determinadas as saídas
esperadas para certos conjuntos de entrada de dados.
Esse tipo de teste reflete, de certa forma, a óptica do usuário, que está interessado em
se servir do programa sem considerar os detalhes de sua construção. Comparando a outros
tipos de teste, este é relativamente mais simples.
03. Testes baseados na estrutura interna requerem um profundo conhecimento da tecno-
logia e do projeto de desenvolvimento, de modo a validar todos os algoritmos empregados
pelo software. Por exigir conhecimento da estrutura interna do software, a estratégia da caixa
branca será utilizada para aborda-los.
Testes baseados em requisitos são baseados em documentos de requisitos e modelados
por meio de especificações funcionais e suplementares. Os casos de testes devem avaliar
todos os cenários existentes e validar todas as variações (fluxos de processamento alterna-
tivos e de exceção) que uma solução tecnológica deve suportar. São testes que devem ser
empregados pela estratégia da caixa preta.
04. Casos de teste são elementos essenciais para o sucesso das atividades de teste em
um projeto de software. São eles que definem as entradas a serem informadas pelo testador
(manualmente ou com apoio ferramental) e os resultados esperados a partir desta ação. As-
sim, eles nos permitem medir o quanto o software está sendo testado. Já um procedimento
de teste define os passos/sequência necessários para executar os casos.

capítulo 5 • 125
 Estes visam apoiar na customização do esforço de teste em um projeto. Neste artigo,
serão discutidas estratégias para melhor especificação de casos e procedimentos de tes-
te em projetos de software. Para isso, será utilizado um exemplo simples e comum de ser
encontrado em sistemas de informação, um formulário de cadastro de venda de produtos
on-line com diversas regras de negócio para validação dos dados preenchidos, e realizare-
mos a especificação dos casos e procedimentos de teste de forma a torná-la mais completa
e objetiva, apoiando assim testes manuais e automáticos.
Qualquer profissional da área de teste de software possivelmente conhece e/ou já preci-
sou especificar casos e/ou procedimentos de teste.

Capítulo 4

01. Testware são todos os produtos gerados nas fases de verificação e validação , incluindo
todas as formas de documentação, automação e relatórios produzidos.
Assim como os engenheiros de software constroem o software, o produto do trabalhos
dos engenheiros de teste é o teste.
Seguindo a definição de Bartié de testware, concluímos que fazem parte do testware:
•  o checklist,
•  o planejamento e especificação de testes,
•  as rotinas automatizadas de execução de testes,
•  os casos de testes,
•  as massas de testes,
•  relatório finais de validação de testes.
02. Nesse ambiente de teste e homologação devem ser realizados o teste de sistema e o
teste de integração.
No ambiente de testes é realizado o teste de sistema e são verificadas as categoria de
carga, performance, volume, instalação e segurança.
No ambiente de homologação é realizado o aceitação e são verificadas as categorias de
aceite formal e o alpha-teste.
03. Os objetivos são:
Apoiar o processo de testes;
Reduzir falhas introduzidas pela intervenção humana;
Aumentar a produtividade (a médio/longo prazo);
Tratar a automação dos testes como um projeto.

A automatização deve acontecer quando:

126 • capítulo 5
 Existirem fortes pressões para melhorar a qualidade;
O projeto tiver situações que não possam ser testadas adequadamente pelos méto-
dos tradicionais;
O perfil dos softwares desenvolvidos for complexo e com impacto no negócio;
Estudos de custo X benefício justificar o investimento;
O tamanho do projeto ou do ambiente de teste justificar.
04. As principais características destas ferramentas são: Gerenciamento de defeitos e ge-
renciamento de configurações.
Gerenciamento de defeitos : Tem como objetivo acompanhar e controlar os defeitos
identificados durante o ciclo de vida do software e monitorá-los até a sua solução final, atra-
vés da produção de um grande número de indicadores de qualidade. Permite parametriza-
ções de forma a customizar um workflow de resolução de problemas, para melhor adapta-se
a estrutura da empresa. Também é conhecido por: gerenciamento de erros, gerenciamento
de problemas, registro de ocorrências, controle de incidências.
Gerenciamento de configurações: Permite controlar e coordenar as mudanças efetuadas
em documentações, fontes e ambientes físicos. Estabelece a relação entre os artefatos de
software e identifica-los através de um único controle de versão enquanto ocorre modifica-
ções de fontes de uma versão anterior.

Capítulo 5

01.
I. Propósito do plano
II. Documentos de referência
III. Administração
A. Organização
B. Tarefas
C. Responsabilidades
IV. Documentação
A. Propósito
B. Documentos de engenharia de software exigidos
C. Outros documentos
V. Padrões, práticas e convenções
A. Propósito

capítulo 5 • 127
 B. Convenções
VI. Revisões auditoriais
A. Propósito
B. Requisitos de revisão
1. Revisão dos requisitos de software
2. Revisões de projeto
3. Verificação de software e revisões de validação
4. Auditoria funcional
5. Auditoria física
6. Auditorias in-process
7. Revisões administrativas
VII. Gerenciamento de configuração de software
VIII. Reportagem de problemas e ações corretivas
IX. Ferramentas, técnicas e metodologias
X. Controle de código
XI. Controle de mídia
XII. Controle de fornecedores
XIII. Coleta, manutenção e retenção de registros
02.
1 Introdução
Na Introdução os objetivos gerais do Plano de Teste são apresentados de forma clara e
não detalhada.

1.1 Sumário de alto nível

O sumário de alto nível define o escopo dos testes descritos no Plano em relação ao pro-
jeto de desenvolvimento do software como um todo. Ele não contém aspectos técnicos, pois
é uma descrição que deve ser entendida por todos os envolvidos no projeto, como executivos
e gestores de projeto.
Pode incluir restrições de recursos relacionados aos testes, escopo do esforço de teste,
relacionamento dos testes com outros métodos de avaliação do software (análises e revi-
sões) e os processos de controle, comunicação e coordenação das atividades-chave.

1.2 Terminologia

128 • capítulo 5
 Essa sessão é útil para identificar termos técnicos, comerciais ou próprios da empresa
que são utilizados ao longo do documento, como nomes de produtos que são refereciados e
processos próprios da empresa.

2 Ambiente e Configuração dos Testes

Nesta sessão são descritos o ambiente de testes e as configurações necessárias para
a execução deles.

2.1 Plataformas
Os testes devem ser executados em todas as plataformas suportadas pelo software, pois
é necessária uma documentação que sustente essa garantia de suporte dada pelo fabricante
do software. Cada uma das platoformas a serem usadas nos testes deve ser descrita com de-
talhe, com foco nas características mais relavantes ao software a ser testado: tipo de máqui-
na, capacidade de processamento, sistema operacional, quantidade de memória disponível...

2.2 Configurações
Assim como as plataformas, as configurações usadas em cada ambiente de testes de-
vem ser descritas detalhadamente: softwares relacionados àquele a ser testado, drivers ne-
cessários ao seu uso, entre outras.

3 Análise e Estratégia de Teste

A análise e a estratégia de teste são descritas minuciosamente nesta sessão, que abran-
ge os objetivos, as dependências, a preparação e finalmente os casos de teste.

3.1 Objetivos dos testes

Os objetivos dos testes são pautados pelas características finais desejadas do software:
segurança, integração com outros processos ou softwares e geração de determinados da-
dos são alguns exemplos.

3.1.1 Obj 1 - <Definição do objetivo. Exemplo: Segurança>

•  Condição do teste: <Condição que deve ser atendida para que o objetivo seja satisfeito.
Exemplo: Somente usuários autorizados devem ter acesso às funcionalidades do software.>

capítulo 5 • 129
•  Abordagem: <De que forma esse objetivo pode ser avaliado? Exemplo: Devem ser usadas
combinações corretas e incorretas/inválidas de usuário e senha na tela de autenticação do
usuário.>
•  Critério de aceitação: <Critério que define se o obejtivo foi atendido. Exemplo: O processo
de autenticação para uso do software deve negar acesso em caso de combinações incor-
retas de usuário e senha e permitir o acesso quando a combinação fornecida for correta.>

3.2 Dependências dos casos de teste

Nessa sessão são descritos os requisitos que devem ser atendidos para a realização
dos testes. Pode ser necessária a preparação de dados de entrada para que o software os
reconheça, por exemplo.

3.3 Preparação para os casos de teste

Tudo o que deve ser preparado antes de se iniciar a execução dos testes é descrito
nessa sessão, como por exemplo a preparação de ambiente, upgrade/downgrade das de-
pendências, ou qualquer outro passo que necessita estar previamente configurado antes
do teste.

3.4 Casos de teste

Os casos de teste definem com detalhe os procedimentos a serem seguidos durante a
execução dos testes.

3.4.1 CT 1 - <Nome>
•  Descrição: <Em que consiste esse caso de teste? Exemplo: Verificar se um usuário não
autorizado consegue acessar as funcionalidades do software.>
•  Tempo estimado: <Qual é a duração estimada desse teste? Exemplo: A verificação para
autenticação deve ser feita em até 3 segundos.>
•  Critério de saída: <Quais ações ou dados de saída são esperados? Exemplo: O acesso
deve ser negado e uma mensagem exibida ao usuário.>
•  Requisitos do ambiente: <Quais os requisitos do ambiente para a realização desse teste?
Exemplo: O software a ser testado deve estar instalado no ambiente de testes.>
•  Objetivos mapeados: <Quais objetivos são mapeados com esse teste? Exemplo: Obj 1 -
Segurança>

130 • capítulo 5
 4 Execução dos Testes
4.1 Cobertura
Essa sessão lista as funcionalidades do software que são cobertas pelos testes do Plano,
além de outros aspectos, como usabilidade, performance e segurança. Ela não deve ter um
caráter técnico, e sim deve ser feita sob o ponto de vista do usuário, abordando o que inte-
ressará a ele e refletindo o que será testado através dos casos de teste.

4.2 Resultados
A importância de se registrar os resultados dos testes é muito grande: eles são a base
para a criação de itens de trabalho para reparo e replanejamento durante o desenvolvimento.
E, ao final do desenvolvimento, a compilação dos resultados dos testes bem-sucedidos são
um indicativo relevante da confiabilidade daquele software.

5 Lições aprendidas
O registro das lições aprendidas durante os testes realizados é um material de consulta
muito útil para a criação de novos Planos de Teste, especialmente para pessoas que não
participaram dos testes definidos nesse Plano, e para testadores com menos experiência na
área. Essa é uma sessão que resume o que pode ser feito de forma melhor em novos testes,
especialmente em Planos de Teste de Software semelhantes ao testado.

03. O plano mestre de verificação aborda os seguintes itens:

•  Propósito do documento.
•  Detalhes do ciclo de do processo de verificação.
•  Principais atividades de verificação.
•  Definição de papeis e responsabilidades da equipe de verificação.
•  Principais documentos a serem empregados.
•  Principais documentos a serem gerados.
•  Referências a técnica, métodos e ferramentas a serem empregadas.
•  Referências a padrões, políticas, formatos a serem adotados.
•  Contratação de treinamentos e mentoring.
•  Cronograma das etapas da verificação.
•  Riscos e contingências.
04. Esse padrão também é conhecido com Norma e descreve um conjunto de 8 docu-
mentos definidos, que cobrem as tarefas de planejamento, especificação e relado de testes.
São eles:

capítulo 5 • 131
•  Plano de Teste que apresenta o planejamento para a execução do teste identifica os itens
e as funcionalidades a serem testados, as tarefas além dos riscos associados com a atividade
de teste.
•  Há também a tarefa de especificação de testes que é composta por 3 documentos ( Es-
pecificação de Projeto de teste, Especificação de caso de Teste, Especificação de Procedi-
mento de teste) que principalmente identifica os casos e os procedimento de teste, critérios
de aprovação, define dados de estrada e resultados esperado, além de especificar os passos
para a execução dos testes.
•  Já os relatórios são cobertos por 4 documentos (Diário de teste, Relatório de Incidente
de Teste, Relatório-Resumo de teste, Relatório de Encaminhamento de Item de Teste) que
visam registrar detalhes relevantes, eventos que ocorrem durante os testes e resultados
das atividades.

Anexo 1

Projeto VANT-EC-SAME
Plano de Garantia de Qualidade - V-CNS
(VANT - Comunicação, Navegação, Vigilância)
Plano de Garantia de Qualidade

Introdução

Esse documento tem o propósito delinear um Plano de Garantia de Qualidade

para o Protótipo do Componente de Software de Computador CSC Comuni-
cação, Navegação e Vigilância – V-CNS. O Projeto VANT-EC-SAME se propõe a
desenvolver um Sistema, de cunho acadêmico, que poderá no futuro servir ao
Ministério da Defesa e usuários civis. Este documento refere-se apenas ao Pla-

132 • capítulo 5
no de Garantia de Qualidade para Unidade de Software de Componente (USC)
necessários para implementar as funcionalidades do Sistema de Navegação,
Controle e Vigilância (CNS) a ser utilizado pelo Sistema, .
As definições, acrônimos e abreviaturas encontram-se definidos no docu-
mento V-CNS – Glossário. Para facilitar a leitura o significado de alguns acrôni-
mos, definições, e abreviaturas importantes serão colocados entre parênteses
após sua primeira aparição neste documento. As referências encontram-se na
seção 1.4 deste documento

Propósito

Esse plano de Garantia de Qualidade tem o propósito de garantir que o software

gerado estará de acordo com as Normas e requisitos do usuário.

Escopo

A Garantia de Qualidade é um conjunto de atividades planejadas e sistemáti-

cas, implementadas no sistema da qualidade e demonstradas como necessá-
rias, para prover confiança adequada de que uma entidade atenderá os requisi-
tos para a qualidade. Nesse documento será abordada a Garantia de Qualidade
para o Componente de Sofwtare de Componente V-CNS, que fará parte do Sis-
tema VANT-EC-SAME.
A garantia da qualidade visa, simultaneamente, aos objetivos internos
e externos:
a) Garantia da qualidade interna: dentro de uma organização, a garantia
da qualidade provê confiança à administração;
b) Garantia da qualidade externa: em situações contratuais ou outras, a
garantia da qualidade provê confiança aos clientes ou a outros.

Algumas ações do controle da qualidade e da garantia da qualidade são in-

ter-relacionadas. Se os requisitos para a qualidade não refletirem inteiramente
as necessidades do usuário, a garantia da qualidade pode não prover a confian-
ça adequada.

Definições, Acrônimos e Abreviações

capítulo 5 • 133
As definições de todos os termos, acrônimos e abreviações necessárias para a
interpretação desse plano encontram-se no documento V-CNS – Glossário.

Referências

A seguir se encontra uma lista completa de todos os documentos referen-

ciados ao longo desse documento. Cada documento está identificado pela refe-
rência, título, data e o local onde ele pode ser obtido.
1. Plano de Desenvolvimento de Software (V-CNS);
2. Caso de Desenvolvimento (V-CNS);
3. Visão (V-CNS);
4. Funções do Sistema Acauã;
5. Documento de Referência VANT-EC-SAME;
6. Associação Brasileira de Normas Técnicas – ABNT – Norma: NBR ISO
8402:1994, 3.5;
7. Associação Brasileira de Normas Técnicas – ABNT – Norma: NBR ISO/
IEC 12207 .

Visão Geral

Essa sub-seção mostra como o restante desse documento está organizado. Após
a Introdução acima a seção 2 apresenta os Objetivos de Qualidade. A seguir, na
seção 3, o Gerenciamento da Garantia de Qualidade é descrito. As seções 4 e 5
apresentam respectivamente a Documentação e as Métricas utilizadas. O Plano
de Revisão e Auditoria é apresentado na seção 6.
Os Testes de Validação e o Gerenciamento de Configuração são apresen-
tados nas seções 7 e 8, respectivamente. A seção 9 cuida do Treinamento.
Finalmente a seção 10 descreve como será feito o Gerenciamento de Riscos.

Objetivos de Qualidade

Os objetivos de um Plano de Garantia da Qualidade é o reconhecimento da

importância de:

•  Satisfação do cliente. Entendimento, avaliação, definição e gerenciamen-

to de expectativas de forma a atender às necessidades do cliente. Isso exige uma

134 • capítulo 5
combinação de conformidade com os requisitos (o projeto deve produzir o que
afirmou que produziria) e adaptação ao uso (o produto ou serviço deve satisfa-
zer as necessidades reais).
•  Prevenção sobre inspeção. O custo de prevenção de erros em geral é muito
menor que o custo de corrigi-los, conforme revelado pela inspeção.
•  Responsabilidade da gerência. O sucesso exige a participação de todos os
membros da equipe, mas é sempre responsabilidade da gerência fornecer os
recursos necessários para que exista sucesso.
•  Melhoria contínua. O ciclo PDCA (ver [1] seção 1.3) é à base da melhoria
da qualidade (conforme definido por Shewhart e modificado por Deming, no
ASQ Handbook, páginas 13 e 14, American Society for Quality, 1999). Além dis-
so, as iniciativas de melhoria da qualidade realizadas pela organização executo-
ra, como GQT (ver [3] seção 1.3) e Seis Sigma, podem melhorar a qualidade do
gerenciamento do projeto e também a qualidade do produto do projeto. Os mo-
delos de melhoria de processos incluem Malcolm Baldrige, CMM® e CMMiSM.

Gerenciamento

Organização

O Gerenciamento da Qualidade do software será executado em três fases:

•  Planejamento da qualidade – identificação dos padrões de qualidade rele-

vantes para o projeto e determinação de como satisfazê-los.
•  Realizar a garantia da qualidade – aplicação das atividades de qualidade
planejadas e sistemáticas para garantir que o projeto emprega todos os proces-
sos necessários para atender aos requisitos.
•  Realizar o controle da qualidade – monitoramento de resultados especí-
ficos do projeto a fim de determinar se eles estão de acordo com os padrões
relevantes de qualidade e identificação de maneiras de eliminar as causas de
um desempenho insatisfatório.

Tarefas e Responsabilidades

capítulo 5 • 135
A garantia da qualidade pode utilizar os resultados de outros processos de
apoio tais como: verificação, validação, revisões conjuntas, auditorias e resolu-
ção do problema.
O processo consiste nas seguintes nas seguintes nas seguintes atividades:

•  Implementação do processo;
•  Garantia do produto;
•  Garantia do processo;
•  Sistema de Garantia e Qualidade.

Cada Componente de Software de Computador escolhido ficará responsá-

vel pela supervisão do processo de auditoria do seu referido CSC que está res-
ponsável. É desejável desenvolver e efetuar testes que irão gerar códigos.

Documentação

A documentação mínima que servirá de base para esse plano:

•  Plano de Desenvolvimento de Software;

•  Plano de Testes;
•  Documento de Requisitos;
•  Documento de Arquitetura;
•  Plano de Gerência de Configuração.

Métricas

As métricas de produto, projeto e processo, que serão utilizadas, deverão ser

coletadas ao longo do ciclo de desenvolvimento. Tipicamente serão as métri-
cas que estão disponíveis no IBM-Rational Test RealTime e no IBM – Rational
Quality Architect.

Plano de Revisão e Auditoria

•  Atividades de Revisão e Auditoria

136 • capítulo 5
 Os artefatos que serão revisados são: Plano de Desenvolvimento de Software,
Caso de Desenvolvimento, Visão, Solicitação de Requisitos, Plano de Teste.
As revisões de auditoria serão escritas de acordo com a Norma ECSS-E-50
Comunicações e com o andamento do projeto.

•  Cronograma

O detalhamento do cronograma para as revisões e auditorias para os princi-

pais marcos do projeto devem conter:

PROJETO DE EXPERIMENTOS X

ANÁLISE DO EXPERIMENTO x

TESTES x x

AÇÕES CORRETIVAS x x

REPARO DO DEFEITO x x

AÇÕES PREVENTIVAS x x

LISTA DE VERIFICAÇÃO DE QUALIDADE X x x

SOLICITAÇÕES DE MUDANÇAS x
APROVADAS

ENTREGAS x

capítulo 5 • 137
 •  Organização e Responsabilidades

A tabela a seguir lista os indivíduos do CSC V-CNS que estarão envolvidos

com as atividades de revisão e auditoria.

Gerência a Comunica-
ção para qualidade da
Auditor, Revisor de
Comunicação transmissão de dados
Processo
via Protocolo e via Rádio
e Freqüência.

Gerenciar a qualidade
Auditor, Revisor de
Navegação do Nível de Vôo, Rota e
Processo
Direção.

Gerenciar os recursos
Auditor, Revisor de qualidade do Proces-
Vigilância
Processo samento e Captura das
Imagens.

•  Resolução de Problemas e Ações corretivas

Essa sub-seção descreve os procedimentos para reportar e gerenciar proble-

mas identificados durante as revisões e auditorias.

•  Ferramentas, Técnicas e Metodologias

Dentre as ferramentas, técnicas e metodologias a serem utilizadas no de-
senvolvimento de Software do CSC V-CNS, poderão serem utilizadas as lista-
das abaixo:

•  Diagramas de Causa e Efeito;

•  Gráficos de controle;

138 • capítulo 5
 •  Fluxogramas;
•  Histogramas;
•  Diagrama de Pareto;
•  Gráfico de Execução;
•  Diagrama de Dispersão;
•  Amostragem Estatística;
•  Inspeção;
•  Revisão de Reparo de Defeito.

A Ferramenta, técnica ou metodologia utilizada durante a revisão ou audi-

toria será o RUP (de onde o UniProcess foi instanciado) sugere um conjunto
mínimo de revisões:
1. Revisão de Requsitos;
2. Revisão da Arquitetura; e
3. Revisão do Projeto.

Testes e Validação

Os testes estão referenciados no artefato RUP – Plano de Testes e as estimativas

de validações foram realizadas no software EEDS – Estimativas de esforço de
pontos de Caso de Uso.

Gerenciamento de Configuração

O Gerenciamento de Configuração são tratados no artefato RUP – Plano de Ge-

rência de Configuração.

Treinamento

Devido à dificuldade de se encontrar no país atualmente equipes experientes no

uso da metodologia RUP e das ferramentas automatizadas de Gerenciamento
de Versões, Gerenciamento de Requisitos, Desenvolvimento e Geração Automa-
tizada de Código e Testes Automatizados foi efetuado um treinamento inicial
com todos os desenvolvedores e alguns gerentes do Projeto VANT-EC-SAME.

capítulo 5 • 139
 Entretanto, devido à complexidade do software necessário, treinamentos
mais aprofundados devem ser oferecidos às equipes de desenvolvedores para
garantir a qualidade do produto, processo e projeto.

Gerenciamento de Riscos

O Gerenciamento de Riscos deve seguir as recomendações dos artefatos: Plano

de Desenvolvimento de Software e Lista de Riscos.

140 • capítulo 5
ANOTAÇÕES

capítulo 5 • 141
 ANOTAÇÕES

142 • capítulo 5
ANOTAÇÕES

capítulo 5 • 143
 ANOTAÇÕES

144 • capítulo 5