Centro Universitário Carioca

Roteiro de Testes segundo as Características de

Qualidade do Software

André Damasceno Dias

Rio de Janeiro
Fevereiro 2007
 Teste de Software

André Damasceno Dias

Monografia submetida ao corpo docente do Centro

Universitário Carioca – UniCarioca - como parte dos
requisitos necessários à obtenção do grau de
Tecnólogo em Sistemas de Informação.

Curso Superior de Tecnologia em Sistemas de Informação

Orientadora: Adele Malta Pontes

Mestre e m Informática

Rio de Janeiro
Fevereiro 2007
 Ficha Catalográfica

Damasceno Dias , André.

Roteiro de Testes segundo as Características de Qualidade do
Software / André Damasceno Dias. Rio de Janeiro: Unicarioca –
2006.

55p .il

Monografia (Graduação Tecnológica) Unicarioca, 2006

1 – Teste de Software 2 – Qualidade de Software I Título –
Roteiro de Teste segundo as Características de Qualidade de
Software.
UniCarioca - 2007

i
i
 Dedicatória

A minha família cujo amor, compreensão, solidariedade e apoio foram

decisivos para a existência desta dissertação. A minha noiva que me apoiou
desde o inicio da faculdade e nos grandes momentos da minha vida.

i
v
 Agradecimentos

Este projeto não teria sido escrito sem a colaboração da minha orientadora
Adele Malta e o auxílio de Emerson Rios um dos autores dos Livros de Teste
de Software e um dos fundadores da Alats (Associação Latino – Americana de
Teste de Software). Também faço um agradecimento especial à Dias e
Percília, meus pais por uma vida de inspiração.
Finalmente gostaria de agradecer a minha futura esposa Anna Paula por
aguardar o término da faculdade e crescer junto comigo na vida pessoal e na
carreira profissional.

v
 Resumo

Damasceno Dias, André ./ Roteiro de Testes segundo as Características de

Qualidade do Software / André Damasceno Dias. Rio de Janeiro: Unicarioca – 2007.
Orientadora Ad ele Malta Pontes - Rio de Janeiro : UniCarioca, 2007. Monografia
(Curso Superior de Tecnologia em Sistemas de Informação).

Com o avanço da tecnologia os problemas nos softwares atingiram um patamar

muito maior, com suas imagens ficando cada vez mais exposta. Testar software não é

uma tarefa simples e requer um conhecimento muito grande de técnicas muitas vezes

não disponíveis para desenvolvedores e usuários, que testavam seus softwares. Em

um modelo de garantia de qualidade isto é insuficiente. Os testes de software

precisam ser feitos e registrados em documentos específicos, tão logo o projeto se

inicia, pois quando chegar o momento dos testes de sistema, muitos defeitos já foram

detectados e corrigidos.

O Objetivo deste projeto é explicar de forma bem clara, para as pessoas que

trabalham com TI, como planejar e executar os testes de software, através de um

Roteiro de Teste. Este Roteiro foi baseado nas principais normas e padrões de

qualidade de software e sugere um documento padrão para cada etapa do teste.

v
i
 Glossário

Caso de Teste – Uma descrição especifica de um teste a ser executado.

CMM - Capability Maturity Model
CMMI (Capability Maturity Model Integration) – Consiste das melhores práticas e manutenção
de produtos e serviços cobrindo o ciclo de vida do produto desde a sua concepção até a sua
entrega ou manutenção.
Defeito – Resultado de um erro, encontrada num código ou num documento.
ISO - International Organization for Standardization
QAI - Quality Assurance Institute
TI – Tecnologia da Informação
RUP – Rational Unified Process

v
i
 Lista de Figuras

Figura 1 – Evolução do CMM para o CMMI 16

Figura 2 – Modelo 3P x 3E do Ciclo de Vida do processo de teste 22

Figura 3 – Exemplo de um Fluxo de Eventos em um Caso de Uso 26

Figura 4 – Pré-condição e Pós-condição 27

Figura 5 – Diagrama de Atividades do Processo e Teste de Software 30

v
i
 Lista de Tabelas

Tabela 1: Normas e padrões de software 5

Tabela 2 - Características de Qualidade da Norma ISO 9126 6

Tabela 3 – documentos da Norma ISO 14598 9

Tabela 4 – Itens da Norma ISO 12119 10

Tabela 5 – Lista de processos da Norma ISO 12207 13

Tabela 6 - Técnicas de Teste Estrutural 19

Tabela 7 – Técnica de Teste Funcional 21

Tabela 8 Exemplo de cenários e caminhos possíveis 26

i
x
 Lista de Templates

Template 1 – Guia Operacional de Teste 31

Template 2 – Relatório de Configuração 31

Template 3 – Plano de Teste 32

Template 4 – Estratégia de Testes 33

Template 5 – Caso de Teste 34

Template 6 – Registro de Defeito 36

x
 Lista de Roteiros

Roteiro 1 – Exemplo do Guia Operacional de Teste 38

Roteiro 2 – Exemplo do Relatório de Configuração 38

Roteiro 3 – Exemplo de um Plano de Teste 39

Roteiro 4 – Exemplo de uma Estratégia de Testes 39

Roteiro 5 – Exemplo de um Caso de Teste 40

Roteiro 6 - Exemplo de um Registro de Defeito 41

x
i
 Sumário

1 Introdução 1

2 Teste de Software 2

3 Qualidade de Software 4

3.1 – Norma ISO 9126 – Qualidade de Produtos de Software

3.1.1 – Métricas de software da norma ISO 9126

3.2 – Norma ISO 14598 – Guias para avaliação da Qualidade de software

3.3 – Norma ISO 12119 – Qualidade de Pacotes de Software

3.4 – Norma ISO 12207 – Processo de Vida do Ciclo de vida do Software

3.5 CMMI – Capability Maturity Model Integration

3.5.1 – Verificação e Validação

4 Técnicas de Teste 19

4.1 – Técnicas de Teste Estrutural (Caixa Branca)

4.2 – Técnicas de Teste Funcional (Caixa Preta)

5 Ciclo de Vida do processo de Teste de Software 22

5.1 – Procedimentos inicias

5.2 - Planejamento

5.3 – Preparação

5.4 – Especificação

5.4.1 Precondições e Pós-condições

5.5 – Execução

5.6 – Entrega

6 Roteiro de Teste Proposto 30

7 Exemplo de Uso do Roteiro de Teste Proposto 38

8 Considerações Finais 43

9 Referências Bibliográficas 44

x
i
1. Introdução

Até pouco tempo atrás os Testes de Software eram efetuados com um

nível de cobertura bastante reduzido, muitas vezes eram os próprios usuários
que descobriam os erros dos softwares, entretanto, para reduzir a quantidade
de erros no software e aumentar a qualidade destes produtos se faz necessário
que os testes sejam executados por testadores experientes.

O objetivo deste estudo é criar um roteiro de testes tendo como base as

características de qualidade de software dos padrões e normas mais utilizadas
do mercado. Este roteiro é voltado para estudantes de graduação e
profissionais de TI que queiram se iniciar na área de teste de software e
queiram uma referência simples e direta sobre o assunto.

O trabalho está organizado da seguinte maneira: no capitulo 2

apresentamos uma visão geral sobre o processo de teste de software; no
capitulo 3 são explicadas as principais normas e padrões de Qualidade de
Software, cada uma com suas características de qualidade; no 4 são
explicadas as Técnicas de Teste; no 5 são demonstrados os Tipos de Teste
presentes em cada Técnica; no 6 é demonstrado o Ciclo de Vida do processo
de Teste de Software; no 7 é proposto um Roteiro de Teste baseado neste
ciclo; no 8 é apresentado um exemplo de uso do Roteiro de Teste proposto; e
no capitulo 9 temos as considerações finais.

1
2. Teste de Software

Segundo o dicionário “Aurélio” a palavra teste significa: Exame,

verificação ou prova para determinar a qualidade, a natureza ou o
comportamento de alguma coisa, ou de um sistema sob certas condições.
Teste de Software por sua vez é o processo de executar um programa com a
intenção de encontrar e rros. (Glen Myers apud [1])

Outras definições para teste de software são:

• Qualquer atividade que a partir da avaliação de um atributo ou

capacidade de um programa ou sistema torne possível determinar se ele
alcança os resultados desejados, (Bill Hetzel apud [2]).
• Atividade que visa verificar se o software está fazendo o que deveria, de
acordo com os seus requisitos, e não está fazendo o que não deveria, [2].
• Teste de Software é um processo que visa executar o software de forma
controlada, com o objetivo de avaliar seu comportamento (resultado esperado),
baseado no que foi especificado, [2].

Até a década de 90 os testes eram efetuados pelos próprios

desenvolvedores do software com um nível de cobertura bastante reduzido e
não permitiam que todos os defeitos pudessem ser detectados. Muitas vezes,
os próprios usuários eram quem descobriam os erros quando o software já
estava em produção e onde sua correção era muito mais cara. Isso ainda
acontece hoje em dia e nestes casos, os testes, servem apenas para garantir
que as especificações e requisitos do negócio foram realmente implementados.
Em um modelo de garantia de qualidade de software isso é insuficiente.

Informações de mercado dizem que mais de 90% dos sistemas são

liberados com graves defeitos. Softwares com problemas de performance e
com defeitos na execução são extremamente custosos. O relatório “The
Economic Impact of Inadequate Infraestruture for Software Testing” (NIST apud

2
[2]) estima que o custo total dos softwares com defeitos para as organizações
nos EUA corresponde, aproximadamente, a um valor um pouco abaixo de 1%
do Produto Interno Bruto (PIB) daquele país.

Os problemas nos softwares atingiram um patamar muito maior quando

as empresas começaram a criar seus sites na internet, tornando sua imagem
cada vez mais exposta. Isso levou as organizações a procurarem caminhos
que melhorassem a qualidade de software, um deles foi incrementar a
atividade de teste. Para isso, se tornou cada vez mais necessário que essa
atividade fosse executada por especialistas e não mais por desenvolvedores,
cuja preocupação principal é mostrar que os sistemas funcionam, ou usuários,
que querem saber se o produto que pediram foi entregue da forma definida por
eles. A primeira grande mudança foi a criação de um processo de teste, que
podemos enquadrar dentro dos modelos, normas ou padrões que definem a
qualidade de software. Entre eles o CMMI (Capability Maturity Model
Integration [5]) e ISO (International Organization for Standardization [3]).

3
3. Qualidade de Software

Segundo o dicionário “Aurélio”, qualidade é o critério que permite avaliar

e aprovar, aceitar ou recusar, qualquer coisa. É possível dizer que a qualidade
do software é a garantia para o sucesso, como em qualquer outro negócio. Não
ter qualidade no produto, hoje em dia, é um risco para a sobrevivência e o
sucesso das fábricas de software, já que ela retém consumidores e aumenta o
lucro. Muitas razões para o investimento em qualidade de software devem ser
levadas em conta, a saber:

A) Qualidade é competitividade: uma das maneiras de diferenciar o produto do

competidor é pela qualidade do software. Como o mercado amadurece,
usuários não querem apenas que a empresa fale que tem qualidade, mas
que mostre a todos a sua qualidade através de uma certificação1, sendo
que sua ausência pode acarretar desvantagem competitiva.

B) Qualidade é essencial para o mercado internacional: O mercado de

software está, cada vez mais, se tornando global. A habilidade das
empresas de mostrarem qualidade, eventualmente as coloca no mercado
global.

C) Qualidade é custo/benefício: um sistema de qualidade leva ao aumento da

produtividade e reduz custos, habilitando o gerenciamento para reduzir a
correção de defeitos, dando ênfase à prevenção. Corrigir defeitos após o
desenvolvimento do software é muito mais caro do que corrigi-los no inicio.

Para que a qualidade possa ser avaliada devem ser seguidas regras,
normas ou padrões que levam a empresa a uma certificação de qualidade do
software desenvolvido. Embora uma empresa possa se auto-avaliar ou ser
avaliada por seus próprios clientes, o termo Certificação costuma ser aplicado
apenas quando efetuado por uma empresa independente e idônea,
normalmente especializada neste tipo de trabalho.

1
Certificação é a emissão de um documento oficial indicando a conformidade com uma
determinada norma ou padrão. Antes da emissão do certificado, é preciso realizar todo um
processo de avaliação e julgamento de acordo com uma determinada norma ou padrão.

4
Atualmente, muitas instituições se preocupam em criar normas para permitir a
correta avaliação de qualidade tanto do software quanto de seus processos de
desenvolvimento. Apenas para ter uma visão geral, observe o quadro a seguir,
na tabela 1, com as principais normas nacionais e internacionais nesta área:
Tabela 1: Normas e padrões de software. [7]

Norma / Padrão Comentário

ISO 9126 Avalia as características da qualidade de produtos de software.
Versão brasileira da ISO 9126. Características da qualidade e Diretrizes
NBR 13596
para o seu uso
Guias para a avaliação de produtos de software, baseados na utilização
ISO 14598
prática da norma ISO 9126
Características de qualidade de pacotes de software (Teste e requisito
ISO 12119
de qualidade)
IEEE P1061 Standard for Software Quality Metrics Methodology (produto de software)
Software Life Cycle Process. Norma para a qualidade do processo de
ISO 12207
desenvolvimento de software.
Sistemas de qualidade - Modelo para garantia de qualidade em Projeto,
NBR ISO 9001
Desenvolvimento, Instalação e Assistência Técnica (processo)
Gestão de qualidade e garantia de qualidade. Aplicação da norma ISO
NBR ISO 9000-3
9000 para o processo de desenvolvimento de software.
NBR ISO 10011 Auditoria de Sistemas de Qualidade (processo)
Capability Maturity Model. Modelo da SEI (Instituto de Engenharia de
Software do Departamento de Defesa dos EEUU) para avaliação da
CMM
qualidade do processo de desenvolvimento de software. Não é uma
norma ISO, mas é muito bem aceita no mercado.
Resumidamente e uma revolução do CMM. Evolui, agrega melhores
práticas de diversas organizações e experiências existentes no mercado
CMMI
de TI (tecnologia da informação), daí o “I” de Integration. Consistência
com a futura norma ISO 15504
Projeto da ISO para avaliação de processo de desenvolvimento de
SPICE
software. Ainda não é uma norma oficial ISO, mas o processo está em
ISO 15504
andamento.

A seguir faremos um breve comentário sobre cada norma ou padrão.

5
3.1 Norma ISO 9126 - Qualidade de Produtos de Software

Quando se pensa em qualidade de um "produto físico", é fácil imaginar

padrões de comparação, provavelmente ligado às dimensões do produto ou
alguma outra característica física. Entretanto quando se trata de software,
estes padrões se alteram.

A ISO (Organização Internacional de Padrões, em português) publicou

uma norma que representa a atual padronização mundial para a qualidade de
produtos de software. Esta norma chama-se ISO 9126 e foi publicada em 1991.
Ela é uma das mais antigas da área de qualidade de software e já possui sua
tradução para o Brasil, publicada em agosto de 1996 sob a denominação NBR
13596.

Esta norma lista o conjunto de características que devem ser verificadas

em um software para que ele seja considerado um "software de qualidade".
São seis grandes grupos de características, cada um reunindo algumas
subcaracterísticas.

Observe na tabela 2 abaixo a lista completa:

Tabela 2 - Características de Qualidade da Norma ISO 9126

Característica Subcaracterística Pergunta chave para subcaracterísticas

Funcionalidade
(satisfaz as necessidades?)
Confiabilidade
(é imune a falhas?)
Usabilidade
(é fácil de usar?)
Eficiência
(é rápido e "enxuto"?)
Adequação Propõe-se a fazer o que é apropriado?
Acurácia Faz o que foi proposto de forma correta?
Interoperbilidade Interage com os sistemas especificados?
Conformidade Está de acordo com as normas, leis, etc.?
Segurança de acesso Evita acesso não autorizado aos dados?
Maturidade Com que freqüência apresenta falhas?
Tolerância a falhas Ocorrendo falhas, como ele reage?
É capaz de recuperar dados em caso de
Recuperabilidade
falha?
Intelegibilidade É fácil entender o conceito e a aplicação?
Apreensibilidade É fácil aprender a usar?
Operacionalidade É fácil de operar e controlar?
Qual é o tempo de resposta, a velocidade
Tempo
de execução?
Quanto recurso usa? Durante quanto
Recursos
tempo?

6
 Analisabilidade
Modificabilidade
Manutenibilidade
Estabilidade
(é fácil de modificar?)
Testabilidade
Adaptabilidade
É fácil de encontrar uma falha, quando
É fácil modificar e adaptar?
Há grande risco quando se faz
É fácil testar quando se faz alterações?
É fácil adaptar a outros ambientes?

Capac. para ser instalado É fácil instalar em outros ambientes?

Portabilidade
(é facil de usar em Conformidade Está de acordo com padrões?

outro ambiente?) Capac. Para substituir É fácil usar para substituir outro?

3.1.1 Métricas de Software da norma ISO 9126

Embora a atual norma ISO 9126/NBR 13596 enumere as características

e subcaracterísticas a serem avaliadas em um software, ela ainda não define
como dar uma nota em cada um destes itens. Ficam, portanto, as questões:
como dar uma nota a uma determinada característica inteiramente subjetiva? O
que representa, por exemplo, uma "nota 10" em termos de "Segurança de
Acesso"? Quando se pode dizer que a "inteligibilidade" de um software pode
ser considerada satisfatória? Para responder essas questões criou-se, então,
uma área de estudo à parte dentro da Qualidade de Software, conhecida como
Métricas de Software.

Para avaliar um software segundo esta norma, deve-se tentar atribuir

valores (como se fossem notas ou conceitos) a cada uma das
subcaracterísticas.

Algumas características podem ser realmente medidas, como o tempo

de execução de um programa, número de li nhas de código, número de erros
encontrados em uma sessão de teste ou o tempo médio entre falhas. Nesses
casos é possível utilizar uma técnica, uma ferramenta ou um software para
realizar medições.

Para melhorar essa técnica deve-se garantir um número mínimo de

perguntas para cada característica. Além disso, algumas perguntas mais
importantes podem ter pesos maiores. É possível, ainda, criar perguntas do
tipo ABCDE, onde cada resposta indicaria um escore diferenciado. Alguns
estudiosos sugerem formas diferentes de medir uma característica, baseada

7
em conceitos do tipo "não satisfaz", "satisfaz parcialmente", "satisfaz
totalmente" e "excede os padrões". Estes conceitos, não deixam de ser uma
forma eficiente de medir uma característica.

Atualmente, a norma IS O 9126 está sendo revisada. A revisão, que

deverá estar pronta nos próximos anos [7], não deverá modificar nenhuma de
suas características básicas. A maior modificação será a inclusão de dois
documentos adicionais para descrever métricas externas (relativas ao uso do
produto) e métricas internas (relativas à arquitetura do produto). Veja algumas
das modificações previstas para esta revisão:

• Algumas novas subcaracterísticas: Conformidade fará parte de todas

as características. Atratividade será uma subcaracterística de
Usabilidade. Capacidade de coexistir será uma subcaracterística de
Portabilidade.

• A norma será dividida em três partes. A primeira (9126-1) incluirá

definições e características. As duas seguintes descreverão métricas
externas (9126-2) e internas (9126-3).

• A versão brasileira da revisão desta norma deverá ser chamada de NBR

9126-1, 9126-2 e 9126-3, segundo a numeração original da ISO.

3.2 Norma ISO 14598 – Guias para avaliação da Qualidade de

Software

A ISO está finalizando um conjunto de Guias para a Avaliação da

Qualidade segundo a norma ISO 9126. Esses guias descrevem,
detalhadamente, todos os passos para que se avalie um software. Embora o
trabalho nesta norma ainda não esteja totalmente pronto, já existem
informações detalhadas sobre o que será esta norma, quando for oficialmente
publicada.

8
 Ela trará muitos recursos interessantes aos avaliadores, já que trata o
processo de avaliação e define os três tipos básicos de certificação: Empresas
que desenvolvem software, Empresas que adquirem software, Empresas que
fazem certificação, com a finalidade de melhorar a qualidade de seus próprios
produtos, determinar a qualidade do produto que irão adquirir e emitir um
documento oficial sobre a qualidade de um software.

Esta norma, que se chamará ISO 14598, se constituirá, na verdade, de

seis documentos distintos relacionados entre si, como descritos na tabela 3
abaixo:

Tabela 3 – documentos da Norma ISO 14598

Norma Nome Finalidade

Visão Geral da estrutura dessa série de
14598-1 Visão Geral
normas e dos processos de avaliação.
Atividades de planejamento e gestão do
14598-2 Planejamento e Gerenciamento
processo de avaliação.
Atividades de avaliação durante o
14598-3 Guia para Desenvolvedores
processo de desenvolvimento de software.
Como avaliar sob o ponto de vista de
14598-4 Guia para Aquisição
quem vai adquirir.
Como avaliar sob o ponto de vista de
14598-5 Guia para Avaliação quem certifica. Com atividades entre
avaliador e cliente
Detalhes sobre como avaliar cada
característica. São pacotes estruturados
14598-6 Módulos de Avaliação
de métodos e ferramentas para apoio de
suas partes relacionadas

Em resumo, essa nova norma complementará a ISO 9126 e permitirá

uma avaliação padronizada das características de qualidade de um software. É
importante notar que, ao contrário da ISO 9126, a ISO14598 vai a detalhes
mínimos, incluindo modelos para relatórios de avaliação, técnicas para
medição das características, documentos necessários para avaliação e fases
da avaliação. O Processo de avaliação é descrito como um procedimento
passo-a-passo, de tal forma que os requisitos de avaliação possam ser
expressos em termos de características de qualidade.

9
3.3 Norma ISO 12119 - Qualidade de Pacotes de Software

Esta norma foi publicada em 1994 e trata da avaliação de pacotes de

software, também conhecidos como "softwares de prateleira". Além de
estabelecer os requisitos de qualidade para este tipo de software, ela também
destaca a necessidade de instruções para testes desses pacotes,
considerando estes requisitos. A norma divide-se em itens, da seguinte forma,
apresentados na tabela 4 a seguir:

Tabela 4 – Itens da Norma ISO 12119

Item Descrição
1. Escopo
2. Definições
3. Requisitos de qualidade
3.1. Descrição do Produto Descreve o produto, de forma a ajudar o comprador
em potencial, servindo como base para testes. Deve
incluir declarações sobre funcionalidade,
confiabilidade, usabilidade, eficiência,
manutenibilidade e portabilidade.
3.2. Documentação do Deve ser completa, correta, consistente, fácil de
usuário entender e capaz de dar uma visão geral do produto.
3.3. Programas e dados Descreve em detalhes cada uma das funções do
software, incluindo declarações sobre
funcionalidade, confiabilidade, usabilidade,
eficiência, manutenibilidade e portabilidade.
4. Instruções para teste
4.1. Pré-requisitos de Lista de itens necessários ao teste, incluindo
teste documentos incluídos no pacote, componentes do
sistema e material de treinamento.

10
4.2. Atividades de teste Instruções detalhadas sobre os procedimentos de
teste, inclusive instalação e execução de cada uma
das funções descritas.
4.3. Registro de teste Informações sobre como os testes foram realizados,
de tal forma a permitir uma reprodução destes
testes. Deve incluir parâmetros utilizados, resultados
associados, falhas ocorridas e até a identidade do
pessoal envolvido.
4.4. Relatório de teste Relatório incluindo: identificação do produto,
hardware e software utilizado, documentos
utilizados, resultados dos testes, lista de não
conformidade com os requisitos, lista de não
conformidade com as recomendações, datas, etc.

Um dos grandes méritos dessa norma está na profundidade com que

são descritas cada uma das características e subcaracterísticas mencionadas
na norma ISO 9126. A norma inclui detalhes que devem estar presentes no
produto, tais como:

• Documentação do usuário de fácil compreensão.

• Um sumário e um índice remissivo na documentação do usuário.
• Presença de um Manual de instalação com instruções detalhadas.
• Possibilidade de verificar se uma instalação foi bem sucedida.
• Especificação de valores limites para todos os dados de entrada, que
deverão ser testados.
• Operação normal mesmo quando os dados informados estão fora dos
limites especificados.
• Consistência de vocabulário entre as mensagens e a documentação
• Função de auxílio (help) com recursos de hipertexto .
• Mensagens de erro com informações necessárias para a solução da
situação de erro.
• Diferenciação dos tipos de mensagem: confirmação, consulta,
advertência e erro.

11
 • Clareza nos formatos das telas de entrada e relatórios.
• Capacidade de reverter funções de efeito drástico.
• Alertas claros para as conseqüências de uma determinada confirmação.
• Identificação dos arquivos utilizados pelo programa.
• Identificação da função do programa que está sendo executada no
momento.
• Capacidade de interromper um processamento demorado.

Outras características importantes são as ênfases nos testes e os

modelos de relatórios incluídos. Tudo isso facilita imensamente o trabalho do
avaliador.

3.4 Norma ISO 12207 - Processo do Ciclo de vida2 do Software

Esse padrão formaliza a arquitetura do ciclo de vida do software, que é

um assunto básico em Engenharia de Software e também em qualquer estudo
sobre Qualidade do Processo de Software. Esta norma possui mais de 60
páginas e detalha os diversos processos envolvidos no ciclo de vida. Os
processos da ISO 12207 são agrupados de acordo com sua natureza, ou seja,
o seu objetivo principal no ciclo de vida de software. Este agrupamento resultou
nas três classes de processos: Processos Fundamentais, Processos de Apoio
e Processos Organizacionais.
Veja a lista completa dos processos na tabela 5 a seguir:

2
Ciclo de Vida de Software são as fases (Atividades) que o software é desenvolvido

12
Tabela 5 – Lista de processos da Norma ISO 12207

Processos Fundamentais Início e execução do desenvolvimento,

operação ou manutenção do software durante
o seu ciclo de vida.
Aquisição Atividade de quem adquiriu um software. Inclui:
definição da necessidade de adquirir um software
(produto ou serviço), pedido de proposta, seleção
de fornecedor, gerência da aquisição e aceitação
do software.
Fornecimento Atividades do fornecedor do software. Inclui uma
proposta, assinatura de contrato, determinação
recursos necessários, planos de projeto e entrega
do software.
Desenvolvimento Atividades do desenvolvedor de software. Inclui:
análise de requisitos, projeto, codificação,
integração, testes, instalação e aceitação do
software.
Operação Atividades do operador do software. Inclui:
operação do software e suporte operacional aos
usuários.
Manutenção Atividades de quem faz a manutenção do
software.
Processos de Apoio Auxiliam um outro processo.
Documentação Registro de informações produzidas por um
processo ou atividade. Inclui planejamento,
projeto, desenvolvimento, produção, edição,
distribuição e manutenção dos documentos
necessários a gerentes, engenheiros e usuários
do software.
Gerência de Configuração Identificação e controle dos itens do software.
Inclui: controle de armazenamento, liberações,
manipulação, distribuição e modificação de cada
um dos itens que compõem o software.

13
Garantia da Qualidade Garante que os processos e produtos de software
estejam em conformidade com os requisitos e os
planos estabelecidos.
Verificação Determina se os produtos de software de uma
atividade atendem completamente aos requisitos
ou condições impostas a eles.
Validação Determina se os requisitos e o produto final
(sistema ou software) atendem ao uso específico
proposto.
Revisão Conjunta Define as atividades para avaliar a situação e
produtos de uma atividade de um projeto, se
apropriado.
Auditoria Determina adequação aos requisitos, planos e
contrato, quando apropriado.
Resolução de Problemas Análisa a resolução dos problemas de Qualquer
natureza ou fonte, descobertos durante a
execução do desenvolvimento, operação,
manutenção ou outros processos. .
Processos Implementa uma estrutura constituída de
Organizacionais processos de ciclo de vida e pessoal associados,
melhorando continuamente a estrutura e os
processos.
Gerência Gerenciamento de processos.
Infra-estrutura Fornece recursos para outros processos. Inclui:
hardware, software, ferramentas, técnicas,
padrões de desenvolvimento, operação ou
manutenção.
Melhoria Atividades para estabeler, avaliar, medir, controlar
e melhorar um processo de ciclo de vida de
software.
Treinamento Atividades para prover e manter pessoal treinado.

14
 A norma ISO 12207 detalha cada um dos processos acima. Ela define
ainda como eles podem ser usados de diferentes maneiras por diferentes
organizações (ou parte destas), representando diversos pontos de vista para
esta utilização. Cada uma dessas classes representa a forma como uma
organização emprega esses processos, agrupando-os de acordo com suas
necessidades e objetivos.

As classes de processos têm o objetivo de organizar melhor a estrutura

de uma empresa, para definir suas gerências e atividades alocadas às suas
equipes. Existem cinco visões diferentes: contrato, gerenciamento, operação,
engenharia e apoio.

A ISO 12207 é a primeira norma internacional que descreve em detalhes

os processos, atividades e tarefas que envolvem o fornecimento,
desenvolvimento, operação e manutenção de produtos de software. A principal
finalidade desta norma é servir de referência para os demais padrões que
venham a surgir.

Além das padronizações ISO, muitas outras organizações nacionais e

internacionais promovem padrões que descrevem fatores de qualidade para
serem aplicados em sistemas de desenvolvimento, a exemplificar o CMMI.

3.5 CMMI – Capability Maturity Model Integration

O CMMI é o atual modelo para avaliação e melhoria da maturidade dos

processos de uma organização. Ele foi criado pelo Software Engineering
Institute - SEI [4] da Carnegie Mellon University como uma integração e
evolução dos seguintes três modelos: SW-CMM – Capability Maturity Model for
Software; SECM-EIA 731 – System Engineering Capability Model, e IPD-CMM
– Integrated Product Development CMM. A versão 1.0 do CMMI foi lançada em
agosto de 2000, com plano do SEI de aposentar os três modelos precursores,
dentre eles o CMM. Então podemos dizer que o CMMI é a evolução do CMM
como mostra a figura 1 a seguir.

15
Figura 1 – Evolução do CMM para o CMMI [8]

O trecho abaixo foi retirado da versão 1.0 do CMMI e define bem o que é
proposto com os níveis de maturidade.

“A representação (níveis de maturidade) se concentra nas melhores práticas

que a sua organização pode utilizar para melhorar a qualidade nas áreas de
processos que pertencem ao nível de maturidade que se deseja atingir. Antes
de começar a utilizar um modelo CMMI para melhorar processos, você deve
mapear seus processos com as áreas de processos do CMMI. Este
mapeamento permite o controle da melhoria de processos na sua
organização, ajudando-o a rastrear o nível de conformidade da sua
organização com o modelo CMMI que está sendo utilizado. Não se pretende
que cada área de processo do CMMI se relacione com exatamente um
processo da sua organização”. [4]

Conforme vimos até aqui, a demanda por qualidade tem motivado a

comunidade de software para o desenvolvimento de padrões que levem a
qualidade de software. Esses padrões estão orientados por duas visões: visão
de processo e visão de produto. A primeira trata da avaliação e melhoria dos

16
processos utilizados no ciclo de vida do software. A segunda trata da avaliação
de um produto de software para a verificação de sua qualidade.

Estes padrões se relacionam, pois a qualidade de software é largamente

determinada pela qualidade dos processos utilizados para o desenvolvimento.
Deste modo, a melhoria da qualidade do produto do software é obtida pela
melhoria da qualidade dos processos. Esta visão orientou a elaboração de
modelos de definição, avaliação e melhoria de processos de software, tais
como o CMMI e ISO, que já comentamos anteriormente.

O modelo CMMI já vem sendo usado há alguns anos como padrão de

mercado para a melhoria do processo de desenvolvimento de aplicações. No
caso do Brasil, estatísticas do Ministério da Ciência e Tecnologia (MCT apud
[3]) mostram que cerca de 75% das organizações estão no nível 1, 20% no
nível 2 e aproximadamente 5% no nível 3.

O modelo CMM no seu nível 2 tem uma área de processo sobre garantia
de qualidade de software, onde um dos passos para a sua implantação é a
atividade de teste de software, que como vimos é uma das formas de garantir a
qualidade do produto. Já o modelo CMMI define duas áreas de processo no
seu nível 3 que se referem à atividade de teste de software e se chamam de
verificação e validação, e correspondem a tipos específicos de testes como
será explicado a seguir.

3.5.1 Verificação e Validação:

Se considerarmos as áreas de processo definidas pelo CMMI, vamos

encontrar a atividade de testar dentro da área de Validação. Segundo Emerson
Rios [2] é impossível uma empresa atingir o nível de maturidade número 3
(onde está a validação), se a atividade de teste não for executada por uma
equipe de teste independente e integrada à equipe de desenvolvimento, já na
área de verificação é onde estão definidos todos os trabalhos de revisão e
inspeção técnica.

17
 A atividade de verificação corresponde a realização de
inspeções/revisões sobre os produtos gerados pelas diversas etapas do
processo de teste [2]. Alguns autores costumam chamar esta atividade de
Teste de Verificação, já a atividade de validação avalia se o sistema atende
aos requisitos do projeto (usuário). Os testes unitários, de integração, de
sistema e de aceitação podem ser classificados como testes de validação.

18
4. Técnicas de Teste

As principais técnicas de teste são estrutural e funcional. A definição de

verificação e validação dada pelo CMMI [5] se aplica também à definição de
teste funcional e teste estrutural. Inspeções e revisões do software estão dentro
do conceito de Teste de Caixa Branca(estrutural), já o teste funcional é
executado através de técnicas de validação e também é conhecido como teste
caixa preta, ou seja, não é necessário abrir a documentação do software ou
seus códigos fontes para executar o teste [3 ].

4.1 Técnicas de Teste Estrutural (Caixa Branca)

O objetivo do Teste Caixa Branca é avaliar o código do programa ou

componente para verificar a sua consistência frente a determinados padrões ou
regras. Neste teste devem ser avaliados os desvios, ninhos de ifs e outros
comandos condicionais. O Teste estrutural foi criado para verificar se o sistema
desenvolvido e os programas que o compõe funcionam corretamente. A técnica
pretende determinar se os componentes funcionam como uma unidade coesa.
A Técnica do Teste Estrutural garante que a configuração implementada e o
relacionamento das partes funcionam e desempenham o papel esperado. Essa
técnica é composta por diferentes técnicas de teste, como explicado na tabela
6 a seguir:

Tabela 6 - Técnicas de Teste Estrutural

Tipo de Teste
Teste de Estresse
Teste de Execução
Descrição Exemplo
Verifica o desempenho do • Espaço alocado
sistema. suficiente em disco
• Comunicação de rede
adequada
Verifica se o sistema funciona • Transação rodando em
com proficiência tempo adequados
• Hardware e Software
otimizados

19
Teste de Contingência Verifica se o sistema retorna a
um status operacional depois
de um falha.
Teste de Operação Verifica se o sistema pode ser
executado em um status
operacional normal
Teste de Conformidade Verifica se o sistema foi
desenvolvido em
concordâncias com padrões e
procedimentos
Teste de Segurança Verifica se o sistema esta
protegido nos padrões de
segurança da empresa
• Induz um erro
• Avalia a adequação de
um Backup dos dados
• Manual de treinamento
dos operadores
• Verifica os
procedimentos
• Padrões seguidos
• Documentação
completa
• Acesso negado
• Procedimentos Locais

4.2 Técnicas de Teste Funcional (Caixa Preta)

O Teste Caixa Preta é executado tomando como base os requisitos e as

funcionalidades do software. A Técnica de Teste funcional é feita para
assegurar que os requisitos do software e as especificações foram atendidos.
O Processo normalmente envolve a criação de cenários de testes para o uso
na avaliação das funcionalidades da aplicação, validando se o que foi
especificado foi implementado corretamente. Os tipos de testes utilizados na
execução da técnica funcional são apresentados na tabela 7 a seguir:

20
Tabela 7 – Técnica de Teste Funcional
Tipo de Teste Descrição
Teste de Requisitos Determina se o Sistema é
executado conforme o
especificado.
Teste de Regressão Determina se alguma coisa que já
estava funcionando corretamente
parou de funcionar.
Erro no Manuseio Erros podem ser prevenidos ou
(Usabilidade) detectados e depois consertados
Manual do Suporte Preparação de dados para o uso
do sistema e no uso de dados
vindo do sistema
Teste de Integração Verifica que a interconexão entre
aplicações funciona corretamente
Controle Verifica que o que pode sair
errado foi adequadamente
corrigido. (Olhar negativo)
Paralelo Compara resultados do aplicativo
atual com a versão anterior
Exemplo
• Validação do
Especificado X
Implementado
• Verifica Políticas e
regulamentos
• Mudança nos segmentos
funcionais do sistema.
• Mudança manual de
procedimentos corretos
• Falha Introduzida no teste
• Erro reincidente
• Informar de Input
• Toma ações baseadas
nas informações contidas
nos relatórios
• Cenário de Teste de
Integração
• Seleciona transações e
verifica se o
processamento de cada
transação possa ser
reconstruído na base de
teste
• Compara os resultados
alcançados das versões:
nova e a antiga para
garantir a equivalência

Na prática é quase impossível testar todas as possibilidades de formas

alternativas de entrada de dados, bem como testar as diversas possibilidades e
condições criadas pela lógica do programador. Os testes de caixa preta cobrem
as funcionalidades, mas nem sempre cobrem todo o código do programa. Erros
de requisitos descobertos apenas quando o software já está em produção
estão entre aqueles defeitos mais caros de serem corrigidos. Dessa forma, as
técnicas mais modernas de teste de software sugerem que os defeitos sejam
buscados também nas fases iniciais de desenvolvimento do software e que os
testes se repitam por todo ciclo de vida do processo de desenvolvimento.

21
5. Ciclo de Vida do processo de Teste de Software

O ciclo de vida do processo de teste, conforme mostrado na Figura 2 é

composto por diversas etapas ou fases. Este ciclo, criado por Emerson Rios e
Trayahu Moreira é conhecido como modelo 3P x 3E [2].

Este nome espelha as atividades de Planejamento, Procedimentos

iniciais, Preparação (3P) e Especificação, Execução e Entrega (3E). Neste
modelo cada uma das etapas possui atividades, produtos e documentos
específicos e ocupa um percentual estimado no ciclo de vida do processo de
teste. Ilustramos o referido modelo na figura 2 abaixo.

Figura 2 – Modelo 3P x 3E do Ciclo de Vida do processo de teste

5.1 Procedimentos inicias

O primeiro P (Procedimentos iniciais) é uma fase pequena, na qual é

traçado um pequeno esboço do processo de teste. Nessa fase é assinado um
acordo entre as partes envolvidas do projeto de testes (usuários,
desenvolvimento, teste e produção). Este acordo tem o nome de Guia
Operacional de Teste (GOT). No Guia Operacional de Teste (GOT) são
definidas quais são as principais atividades que serão executadas: o objetivo
do projeto de testes, pessoal a ser envolvido, as responsabilidades de cada
um, o plano preliminar de trabalho, a avaliação dos riscos, os níveis de serviço

22
acordados e qualquer item considerado relevante pelo responsável das
atividades de testes para garantir o sucesso do projeto.

5.2 Planejamento

Nesta etapa de Planejamento é elaborada e revisada a Estratégia de

Testes e o Plano de Testes a serem utilizados de forma a minimizar os
principais riscos do negócio e fornecer os caminhos para as próximas etapas.

Para executamos um teste bem feito é preciso planejá-lo. Para fazermos

um bom planejamento é necessário usar um documento padronizado, no
ambiente da empresa, guiado por regras e normas internacionais de qualidade,
como exemplo CMMI ou IS O, já citadas anteriormente. O documento que
permite fazer esse planejamento é conhecido como Plano de Teste, é nele que
definimos os níveis de cobertura e a abordagem dos testes. O manual da QAI
(Quality Assurance Institute [9 ]) cita um outro documento chamado Estrutura
do Teste, que seria o documento onde estaria a definição do que vai ser
selecionado para teste e descreve os resultados dos testes. Embora este
mesmo manual cite que ambos os documentos podem estar juntos no Plano de
Teste. Desse modo, o Plano de Teste identifica as informações existentes no
projeto e o escopo do software a ser testado como explicado abaixo:

• Lista os Requisitos recomendados para teste.

• Recomenda e descreve as estratégias de teste a serem empregadas.

• Identifica os recursos necessários.

• Fornece uma estimativa para o trabalho de teste.

Sistemas complexos podem ter mais de um Plano de Teste.

Posteriormente, se o software precisar de algum tipo de manutenção, ou de ser
testado novamente, este documento orientará o trabalho dos testadores para
preparar novos testes e serve como base para executar os testes de
regressão. Este será o documento que orientará o trabalho dos testadores para
preparar novos testes.

23
 Como na maioria das vezes é impossível garantir que todo o sistema foi
testado e que nenhum erro mais existe, se faz necessário planejar o nível de
cobertura dos testes. Desta forma os responsáveis poderão verificar no Plano
de Testes o que está sendo coberto e como está o andamento.
A Estratégia de Testes deve ser elaborada antes do Plano de Teste,
porém é mais comum o Plano de Testes ser o principal e único documento de
planejamento de testes. O objetivo maior deles é reduzir a probabilidade da
ocorrência de defeitos quando o sistema ou software estiver em produção.
Essas falhas ou defeitos estão associados ao risco. Uma forma de se fazer
uma análise de risco é associá-lo a uma característica de qualidade do
software.

5.3 Preparação

O objetivo básico desta etapa é preparar o ambiente de teste

(equipamentos, pessoal, ferramentas de automação, hardware e software).
Trata-se de uma fase que vai ocorrer em paralelo com outras etapas conforme
mostrado na Figura 2. Nesta etapa será elaborado um relatório com o ambiente
de teste proposto. Lembrando que este documento e o GOT não são
documentos obrigatórios.

5.4 Especificação

Os objetivos básicos desta etapa são elaborar e revisar os Casos de

Testes e os Roteiros de Testes. Eles devem ser elaborados à medida que a
equipe de desenvolvimento libera algum módulo ou parte do sistema para
testes. Os Casos de Testes e os Roteiros de Testes devem estar conforme
previstos na Estratégia e nos Planos de Testes.

A fase de elaboração tem como papel principal a atividade de

24
elaboração do cenário de teste, que será executado (testado). Um cenário é
uma história hipotética usada para ajudar as pessoas a solucionar um
problema, recriando ou visualizando um caminho a ser seguido. O cenário em
que o teste é baseado é aquele descrito em uma especificação do sistema, por
exemplo, do caso de uso. O Caso de teste é o cenário a ser executado, para
verificar se o que foi especificado foi devidamente implementado.

Segundo o RUP (Rational Unified Process [6]) um Caso de teste é um

conjunto de entradas de teste, condições de execução e resultados esperados
desenvolvidos para um objetivo específico como, por exemplo, testar o
caminho de determinado programa ou verificar o cumprimento de um requisito
específico. Os Casos de Teste são inicialmente construídos na fase de
levantamento de requisitos do software. Neste momento são criados casos de
teste voltados ao Teste funcional. Nada proporciona satisfação maior ao
usuário final, com relação ao software, do que uma visão clara de suas
expectativas, Os casos de teste refletem os requisitos que devem ser
verificados e validados.

Os casos de teste para a técnica do teste funcional, são derivados de

uma especificação formal (caso de uso, dicionário de dados, etc..) É necessário
desenvolver os casos de teste para cada cenário de caso de uso. Os cenários
de caso de uso são identificados através da descrição dos caminhos que
percorrem os fluxos básico e alternativo. No diagrama de Caso de Uso do RUP
[6], os vários caminhos através do caso de uso refletem o fluxo de Eventos
(figura 3), que é composto por duas partes que são o fluxo básico (linha reta) e
os fluxos alternativos (desvios), apresentados com as setas. O fluxo de eventos
básico deve abordar o que "geralmente" ocorre quando o caso de teste é
executado. Os fluxos de eventos alternativos abordam o comportamento de
caráter opcional ou excepcional em relação ao comportamento normal e
também as variações do comportamento normal. Os fluxos de eventos
alternativos são como "desvios" do fluxo de eventos básico, alguns dos quais
voltarão ao fluxo de eventos básico e alguns finalizarão a execução do caso de
uso.

25
Figura 3 – Exemplo de um Fluxo de Eventos em um Caso de Uso [6]

Após percorrer cada caminho possível através do caso de uso mostrado

no diagrama é possível identificar os diversos cenários de caso de teste.
Começando pelo fluxo básico e depois combinando esse fluxo com os fluxos
alternativos, é possível identificar os seguintes cenários de caso de teste [6], na
tabela 8 a seguir:
Tabela 8 Exemplo de cenários e caminhos possíveis [6]

Cenário 1 Fluxo Básico

Cenário 2 Fluxo Básico Fluxo Alternativo 1
Cenário 3 Fluxo Básico Fluxo Alternativo 1 Fluxo Alternativo 2
Cenário 4 Fluxo Básico Fluxo Alternativo 3
Cenário 5 Fluxo Básico Fluxo Alternativo 3 Fluxo Alternativo 1
Cenário 6 Fluxo Básico Fluxo Alternativo 3 Fluxo Alternativo 1 Fluxo Alternativo 2
Cenário 7 Fluxo Básico Fluxo Alternativo 4
Cenário 8 Fluxo Básico Fluxo Alternativo 3 Fluxo Alternativo 4

26
5.4.1 Precondições e Pós-condições

Por isso é útil usar a noção de precondição e pós-condição para

esclarecer como o fluxo de eventos começa e termina. Entretanto, só use isso
se for agregar valor ao público do caso de teste. [6]

Figura 4 – Pré-condição e Pós -condição [6]

Uma pré-condição é o estado do sistema que é exigido antes do início do caso

de uso. Uma pós-condição é o estado que o sistema pode apresentar após o
término do caso de teste.

Considere o seguinte:

• Os estados descritos pelas pré-condições e pós-condições devem ser

estados que o usuário pode observar. "O usuário fez login no sistema" ou
"O usuário abriu o documento" são exemplos de estados observáveis.

• Uma pré-condição é uma restrição sobre quando um caso de teste pode

começar. Não é o evento que inicia o caso de teste.

27
 • A pré-condição de um caso de teste não é apenas para um subfluxo,
apesar de ser possível definir pré-condições e pós-condições no nível do
subfluxo.

• A pós-condição de um caso de teste deve ser verdadeira

independentemente dos fluxos alternativos que foram executados; não
deve ser verdadeira apenas para o fluxo principal. Se houver
possibilidade de falha, você abordará isso na pós-condição informando
que "A ação está concluída. E se ocorrer alguma falha, a ação não será
realizada", em vez de apenas "A ação está concluída".

• Pós-condições podem ser ferramentas poderosas para descrever casos

de teste. Você define primeiro o caso de teste que pretende alcançar a
pós-condição. É possível descrever como alcançar essa condição (o
fluxo de eventos necessário).

5.5 Execução

Os testes são executados conforme os Casos de testes e Roteiros de

Testes, criados em etapa anterior, com os correspondentes registros dos
resultados obtidos. A Execução dos testes é considerada um tipo de validação.
Os casos de teste criados anteriormente são executados nesta etapa, o ideal é
que os casos de testes não sejam executados pela mesma pessoa que criou
os casos. Como explicado anteriormente, os casos de teste devem conter
algumas características (Efetivo, Econômico, Reutilizável, Rastreável,
Autoexplicativo), com estas características o caso de teste poderá ser
executado por qualquer testador e ao mesmo tempo estão sendo revisados por
quem executa.

28
5.6 Entrega

Nesta etapa é concluído o projeto de teste, quando é concluída e

arquivada toda a sua documentação e serão relatadas todas as ocorrências
deste projeto que forem consideradas relevantes à melhoria do processo.

6. Roteiro de Teste Proposto

Baseando-se no modelo 3P x 3E, apresentado no capitulo 5, abaixo

veremos um modelo que sugere templates necessários para executar cada
etapa do teste de software. Na verdade todos os modelos de teste de software
mantêm certa semelhança e esse não foge desse contexto. A diferença, neste
caso, é que o modelo se mostrará simples, representado por meio de um
diagrama de atividades (que tem uma notação reconhecida por todos na área
de TI). No diagrama de atividades, que explica o processo de Teste de
Software e quais documentos fazem parte de cada etapa, foi sugerido um
template para cada atividade (Figura 5). Dentro desse contexto, este diagrama
de atividades foi feito com o objetivo de ajudar o profissional de Informática
para que ele consiga executar um teste seguindo os passos representados
neste roteiro:

29
Figura 5 – Diagrama de Atividades do Processo e Teste de Software

30
Atividade: Procedimentos Iniciais
Artefato: Guia Operacional de Teste (GOT)

Como explicado anteriormente o GOT é um acordo entre as partes

envolvidas no projeto de testes e define quais são as principais atividades que
serão executadas, objetivos do projeto de testes e as responsabilidades de
cada pessoa envolvida.
Template 1 – Guia Operacional de Teste.

Guia Operacional de Teste

Atividades que serão executadas:
Objetivo do projeto de testes:
Responsabilidades (por pessoa):
<Tipos de Testes que serão executados>
<Descrição do Objetivo do Projeto de
Teste>
< Papéis dos envolvidos em todas as
etapas do Teste de Software>

Atividade: Preparação
Artefato: Relatório de Configuração

Um dos documentos que não existiam no modelo 3px3e e que estamos

propondo é o Relatório de Configuração. Neste artefato é preciso especificar
qual será a configuração do ambiente de teste, para assegurar que todos os
componentes necessários (Pessoal envolvido, hardware, software, etc.)
tenham sido implementados e estejam prontos e no estado correto para
permitir a condução dos testes.
Template 2 – Relatório de Configuração.

Relatório de Configuração
Pessoal: < Papéis dos envolvidos no processo de Teste >
Hardware: < Configuração do computador utilizado na execução dos testes >
Software: < Softwares utilizados para execução dos testes >
Massa: < Nome do Servidor e banco de dados utilizados no Teste >

31
Atividade: Planejamento
Artefato: Plano de Teste

Nesta etapa será criado o Plano de teste que deve ser revisado e
alterado sempre que houver necessidade. Toda modificação importante como
alterações na estratégia de teste utilizada ou pessoal envolvido,
responsabilidades de cada um, deve ser alterada também no Plano de Teste.
Template 3 – Plano de Teste.

Plano de Teste
Código do Plano de Teste: <O código que serve para referência
para identificar o plano de teste>
Nome do Plano de Teste: <O nome para identificar o Plano de
Teste>
Introdução: <Breve descrição do Plano de Teste>
Funcionalidades a serem testadas: <Quais são as funcionalidades 3 a
serem testadas>
Código da Estratégia de Testes: <Inserir o código do documento de
Estratégia de Teste relacionado>
Pessoal: <Papéis das Pessoas envolvidas na
atividade de Teste>
Data da modificação: <Anotar a data, hora e pessoa que
fizer alteração no Plano de Teste>

3
Funcionalidades são os módulos que serão testados.

32
Atividade: Planejamento
Artefato: Estratégia de Testes

Por ser tratar de uma Estratégia, o documento proposto associa o risco a

cada característica de qualidade de software. A importância relativa define
qual característica de qualidade é a mais importante a ser testada.
Template 4 – Estratégia de Testes

Estratégia de Testes
Código da Estratégia de Teste: <O código que serve para
referência para identificar a
Estratégia de Teste>
Nome da Estratégia de Teste: <O nome para identificar a
Estratégia de Teste. >
Característica Risco 1 Risco (n+1) Importância
de Qualidade relativa
<Nome das 7 < Pontuação entre 1 a 3 <Quantidade <Pontuação entre
características dada para cada risco em de riscos 0 a 6. Cada
de qualidade> relação à característica definidas na característica tem
de qualidade do estratégia> uma pontuação
software > única em cada
estratégia>

Atividade: Especificação
Artefato: Caso de Teste – Especificação

O caso de teste estabelece quais informações serão empregadas

durante os testes dos cenários e quais serão os resultados esperados. Para
isso acontecer é necessário ter uma massa 4 a ser utilizada no teste de forma a
validar todos os requisitos do software. Neste modelo foram acrescentadas as
seguintes informações nos casos de teste Tempo Gasto, Característica de
Qualidade, Técnica de Teste. Estas informações são muito importantes porque
ao final dos testes será possível identificar todas as características de
qualidade testadas, que técnicas foram utilizadas e o tempo total gasto.

Os casos de teste em geral devem conter as características abaixo para

4
Massa são os nomes do servidor e do banco de dados utilizados no teste de software

33
que possam atender as expectativas de validação da qualidade:

• Efetivo – Testar o que se planejou testar.

• Econômico – Sem passos desnecessários.
• Reutilizável – Possa ser repetido.
• Rastreável – Possa identificar o requisito a ser testado.
• Autoexplicativo – Possa ser testado por qualquer testador.
Template 5 – Caso de Teste
Caso de Teste
Código do Caso de Teste: <O Código do Caso de Teste deve ser
seqüencial. >
Nome do Caso de Teste: <Um nome curto do Caso de Teste, este nome
pode ser, por exemplo, o nome do Caso de
Uso (mostrado no capitulo 5.4), se a pessoa
que for escrever o caso de testes tiver acesso
a ele.>
Pré – Condições: <A pré – Condição pode ser o Código do Caso
de Teste Executado anteriormente (Figura 4).
Como exemplo um Caso de Teste com nome
“Cadastrar Produto” deverá ser executado
antes de um Caso de Teste para usar o
produto. 5>
Pós – Condições: <Como explicado na Figura 4 uma pós
condição é o estado que o sistema pode
apresentar após o término do caso de Teste.
6
>
Detalhamento: <Escrever um passo a passo, ou seja, os
caminhos que o testador deve seguir para
executar o caso de teste. O detalhamento deve
ser escrito segundo as características descritas
anteriormente (efetivo, econômico,
autoexplicativo, etc...) para que qualquer
testador possa executar o caso. >
Cronograma: < Definir em que fase este teste será
executado >

5
Caso não haja escrever “não há”.

34
Tempo gasto: < Os casos de testes podem ter tamanhos
diferentes e tempos de execução diferentes,
mesmo que este tempo varie este campo daria
um tempo médio que este caso de teste leva
para ser executado. >

Característica de Qualidade <Informar a característica de qualidade que

está sendo executada neste Caso de Teste.>
Técnica de Teste <Escrever a Técnica de Teste utilizada (tabela
6 e 7 neste Caso de Teste)>
Data da modificação: <Anotar a data, hora e pessoa que fizer
alteração no Plano de Teste.>
Fluxo <Fluxo Básico (FB) ou Fluxo Alternativo (FA)>.

Atividade: Execução
Artefato: Casos de Teste – Execução

A execução dos testes é realizada nos casos de testes criados. Quando

mais detalhado for este caso de teste, mais fácil será o trabalho dos testadores
responsáveis pela execução dos testes.

Para isso é preciso que todos os artefatos necessários tenham sido

implementados, estejam prontos no ambiente de teste e no estado correto para
permitir a condução dos testes.

35
Atividade: Resultado
Artefato: Registro de Defeito

Os defeitos também devem ser registrados em um documento

padronizado. O defeito relatado pode ser um erro (Baixo Impacto, Médio
Impacto e Alto Impacto) ou melhoria. Os erros relatados deverão ser marcados
como Baixo Impacto quando não atrapalham a execução dos testes, os erros
de médio impacto são os que atrapalham, mas não impossibilitam a execução
da tarefa solicitada, e o de Alto Impacto são os erros que não permitem a
execução do software. As melhorias não são erros e sim correções solicitadas
para melhor visualização. Como exemplo um erro de Português ou texto não
alinhado.

Este documento deve estar muito bem explicado, para que o

desenvolvedor, que for corrigir o problema, possa simular o defeito em seu
próprio computador. Algumas vezes, quando isso não é possível, o
desenvolvedor solicita a ajuda do testador que achou o erro, para fazer
novamente a simulação e identificar o problema. Outro ponto importante seria a
situação em que o defeito se encontra. Após a execução do caso de teste é
achado um defeito, que é cadastrado está com o status de novo. Quando o
desenvolvedor fizer a Correção do defeito (Figura 5) ele deve alterar o status
para resolvido. O testador vai executar novamente o caso de teste alterando o
status para testado, para conferir se o problema foi mesmo resolvido. Quando o
defeito foi corrigido e testado o mesmo pode ser alterado para liberado assim
que o gerente do produto quiser.
Template 6 – Registro de Defeito

Registro de Defeito
Código da Pendência: <O código seqüencial que serve para referência
para identificar a Pendência>
Status: <O erro identificado pode ser classificado em 4
tipos: Melhoria, Baixo Impacto, Médio Impacto,
Alto Impacto. >
Situação: <Novo, Resolvido, Testado, Retorno, Liberado>.
Desenvolvedor: <Nome do desenvolvedor responsável pela
correção do defeito>

36
Descrição: <Informar a descrição do problema de forma
mais detalhada possível. >
Parâmetros: <Se necessário informar os registros necessários
para chegar ao erro. Ex: Código: 01, Nome:
Teste.>
Passo a Passo: <Informar cada passo para a execução do
problema, pode ser separado por números. Os
parâmetros Informados no passo anterior devem
ser informados novamente. Exemplo: 1-Digitar
Código: 01, 2-Digitar Nome: Teste, 3-Clicar em
OK.>
Código do Plano de Teste: <Código do Plano de Teste. >
Código do Caso de Teste: <Código do Caso de Teste Executado para
achar o erro. >
Versão: <Versão do Software que foi localizado o
problema. >
Anexos: <Se necessário incluir uma figura com o erro
ocorrido na execução do caso de teste. >

Atividade: Resultado
Artefato: Relatório de Defeitos

Com o relatório de defeitos é possível identificar a quantidade de

pendências cadastradas. Os erros impactam principalmente na entrega do
produto testado, ou seja, os erros não precisam ser corrigidos para o software
ser entregue, mas devem ser analisados para identificar qual impacto causaria
a entrega do produto. Para isso é preciso solicitar o relatório, para ver a
quantidade de defeitos cadastrados. Os únicos erros que obrigatoriamente
impactam na entrega são os identificados como Alto Impacto.

37
7. Exemplo de Uso do Roteiro de Teste Proposto

Para demonstrar a aplicação prática do modelo proposto, em um

sistema de uma editora que vende livros pela internet, podemos citar alguns
itens importantes a serem avaliados quando testamos um sistema deste tipo.
• Facilidade de uso do site, pois se a navegação não for bastante
amigável pode ser que o cliente desista de fazer o negócio;
• Tempo de resposta, pois caso demore muito para a página abrir o
cliente também pode desistir do negócio.
• Conectividade com o sistema em produção que efetua o estoque de
livros.
Roteiro 1 – Exemplo do Guia Operacional de Teste

Guia Operacional de Teste

Atividades que serão executadas: Teste de Estresse, Teste de Execução,
Teste de Requisitos, Erro no Manuseio
(Usabilidade)
Objetivo do projeto de testes: O Objetivo deste projeto e garantir a
qualidade de atendimento no sistema on
line com o máximo de rapidez e
segurança.
Responsabilidades (por pessoa): Gerente de Teste = Gerenciar Testes
Testador1 = Conectividade
Testador2 = Usabilidade

Roteiro 2 – Exemplo do Relatório de Configuração

Relatório de Configuração
Pessoal: Líder do Teste: André;
Testador1: Waldir;
Testador2: Anderson.
Hardware: PC 256, PC 257
Software: Internet Explorer 7
Massa: (Servidor + Banco de dados) S050_Livraria

38
Roteiro 3 – Exemplo de um Plano de Teste

Plano de Teste
Código do Plano de Teste: 01
Nome do Plano de Teste: Livraria_Virtual
Introdução: Este plano de teste tem como objetivo
testar para editora que vende livros
pela Internet, os itens com importância
relativa maior, de acordo com a
estratégia de teste.
Funcionalidades a serem testadas: Login, Cadastro de Produtos, Carrinho
de Compras, Finalizar Compra.
Código da Estratégia de Testes: 01
Pessoal: Líder de Teste e Analista de Teste.
Data da modificação: <Anotar a data, hora e pessoa que
fizer alteração no Plano de Teste>

Roteiro 4 – Exemplo de uma Estratégia de Testes

Estratégia de Testes
Código da Estratégia de Teste: 01
Nome da Estratégia de Teste: Livraria_Virtual
Característica Facilidade Tempo de Conectividade Importância
de Qualidade resposta relativa
Conectividade 1 2 3 6
Continuidade 1 1 2
Segurança 1 1
Eficiência 1 1 2
Funcionalidade 0
Usabilidade 3 2 5
Performance 3 3

A tabela acima apresenta uma pontuação entre 1 a 3 que foi dada para
cada risco em relação à característica de qualidade do software. As
características de qualidade de performance estão muito relacionadas com o
tempo de resposta. A continuidade também pode afetar a performance, pois

39
caso os componentes não se integrem com eficiência, a performance do
software pode ser afetada.

A regra de Pareto diz que 20% do software é responsável por 80% de

suas funcionalidades [10]. Ao concentrar os testes nessa área do software os
riscos de defeitos diminuem com um esforço menor.

A seguir um exemplo de um caso de Teste de Campo Obrigatório. Este

caso de teste foi criado para testar uma tela (funcionalidade) do sistema.
Vamos supor que esta funcionalidade de Entrada do sistema, comum em
muitos softwares, possui dois campos: login e senha. Esta funcionalidade
também teria 2 botões: OK e Cancelar.

Roteiro 5 – Exemplo de um Caso de Teste

Caso de Teste
Código do Caso de Teste: CT01
Nome do Caso de Teste: Teste Campo Obrigatório
Pré – Condições: Não se aplica.
Pós – Condições: Mensagem de Erro do Sistema.
Detalhamento: *PA: O Ator não informa o login e a
senha.
PA: O Ator seleciona a opção OK.
**PS:: O sistema verifica se os
campos obrigatórios foram
informados
PS: O sistema apresenta a
mensagem “Os campos obrigatórios”

Cronograma: 1º Fase
Tempo gasto (média): 4 min
Característica de Qualidade Segurança
Técnica de Teste Segurança
Data da modificação:
Fluxo ***FA Exceção

40
 • * PA – Passo do Ator.
• ** PS – Passo do Sistema.
• *** Nome do Fluxo Fluxo Básico (FB), Fluxo Alternativo (FA);

Esse é apenas um dos muitos casos de teste que podem ser criados
para está funcionalidade. Mesmo tendo apenas dois campos e dois botões,
deveria ser verificado (testado) também:
Fluxo Básico – Digitar um login e senha válidos e clicar no botão OK.
Fluxo Alternativo – Seriam vários, como exemplo o caso de teste CT01 acima,
login válido e senha inválida, login inválido e senha válida, etc.
Botão cancelar – Em alguns softwares o botão cancelar poderia, por exemplo,
limpar o que já foi escrito nos campos login e senha, em outros softwares o
botão cancelar poderia talvez sair do sistema. Como saber o que está certo?
Para isto devem ser verificados os requisitos do sistema.
Um Analista de Teste deve verificar se os requisitos do projeto e as
características de qualidade estão sendo validados na criação dos casos de
teste.
Roteiro 6 - Exemplo de um Registro de Defeito

Registro de Defeito
Código da Pendência: 01
Status: Melhoria.
Situação: Novo.
Desenvolvedor: Igor
Descrição: O sistema não está informando a
mensagem de campo obrigatório de
acordo com os requisitos do sistema.
Parâmetros: Código: Não informar
Nome: Não informar
Passo a Passo: 1-Não informar o Código;
2-Não informar o Nome.
Código do Plano de Teste: 01
Código do Caso de Teste: CT01
Versão: V 3.01
Anexos:

41
8. Considerações Finais

Como podemos ver neste documento, os testes são extremamente

necessários para que as empresas possam garantir a qualidade nos softwares
desenvolvidos. É importante ressaltar que os testes não garantem que o
software não terá defeitos, mas diminuem consideravelmente a quantidade de
erros. A garantia de zero defeito seria necessária apenas em casos
específicos, através de testes exaustivos, que prolongam o prazo de entrega
do software para limites acima do aceitável, como por exemplo, no caso de um
software colocar a vida de uma pessoa em risco, como em um software
médico, por exemplo.

Devido à importância dos testes e com a experiência adquirida

profissionalmente para o levantamento das informações, foi elaborado o
Roteiro de Teste aqui apresentado. É esperado que por meio deste roteiro o
profissional de TI possa elaborar os testes de acordo com as principais normas
e padrões de qualidade de software apresentadas no capitulo 3, tornando-se
assim, uma ferramenta útil no trabalho diário para as empresas criadoras de
softwares e para estudantes de informática que queiram iniciar nas questões
relativas à testes de software.

42
9. Referências Bibliográficas

[1] Roger Pressman - Engenharia de Software - Makron Books, 1995

[2] Rios, Emerson Et. Al. Teste de Software, 2006.

[3] Bastos, Anderson Et. Al Base de Conhecimento em Teste de Software,

2006.

[4] http://www.iso.ch/

[5] http://www.sei.cmu.edu/cmm/cmm.html

[6] http://www-306.ibm.com/software/br/rational/rup.shtml

[7] http://www.abnt.org.br/

[8] http://www.asrconsultoria.com.br

[9] http://www.qaiworldwide.org

[10] http://en.wikipedia.org/wiki/Pareto_principle

43