Modelo de um plano de testes

Modelo de um plano de testes

Traduzido do link:
http://members.tripod.com/~bazman/frame.html

1. INTRODUCO
1.1. Viso geral do sistema X
O objetivo desta fase do projeto implantar uma nova plataforma do sistema X que ir possibilitar:

Remoo de sistemas legados de escritrio

Introduo de ABC
Processamento de transaes especiais
Ausncia de restries no local de captura
Captura de transaes para outros sistemas de processamento
Novo processo de reconciliao
Posicionamento para moeda da Unio Europia e iniciativas futuras

Este programa vai resultar em mudanas significativas nos atuais processos departamentais e interescritrio. A funcionalidade ser entregue em fases.
A fase 1 vai incorporar as seguintes caractersticas:

Substituio do sistema legado A

Novo sistema de reconciliao
Sistema de terceirizao para departamentos em diferentes pases europeus
Caractersticas novas/revisadas de auditoria e pesquisa
[Incluses detalhadas esto listadas mais adiante neste documento]

1.2. Propsito deste documento

Este documento deve servir como o Rascunho da Abordagem (estratgia) de Teste para o Projeto de
Desenvolvimento de Sistemas de Negcio.
A preparao para este teste consiste de trs estgios principais:

A Abordagem (estratgia) de Teste define o escopo do teste do sistema, a estratgia geral a ser
adotada, as atividades a serem completadas, os recursos gerais necessrios e os mtodos e
processos a serem usados para testar a verso. Ela tambm detalha as atividades, dependncias e
esforos requeridos para conduzir o teste de sistema.
O Planejamento de Teste detalha as atividades, dependncias e esforos requeridos para conduzir
o teste de sistema.
As Condies/Casos de Teste documentam os testes a serem aplicados, os dados a serem
processados, a cobertura automatizada de teste e os resultados esperados .

Qualidade e Teste de Software

Pgina 1

Modelo de um plano de testes

1.3. Reviso formal
H vrios pontos formais de reviso antes e durante o teste de sistema. Este um elemento vital para
alcanar um produto de qualidade.
1.3.1. Pontos formais de reviso ocorrem ao final da elaborao de:
1. Documentao de Desenho
2. Abordagem de teste
3. Planos de Teste Unitrio
4. Condies e Resultados do Teste Unitrio
5. Condies do Teste de Sistema
6. Progresso do teste de sistema
7. Reviso aps o teste de sistema

1.4. Objetivos do Teste de Sistema

Em um nvel elevado, o teste de sistema tem o objetivo de provar que:

A funcionalidade, entregue pela equipe de desenvolvimento, est de acordo com as especificaes

do negcio no documento de especificaes de desenho do negcio e da documentao de
requisitos.

O software de alta qualidade; o software vai substituir as/dar suporte s funes de negcio
desejadas e alcanar os padres requisitados pela companhia para o desenvolvimento de novos
sistemas.

O software entregue faz a interface correta com os sistemas existentes, inclusive o Windows 98.
[Objetivos detalhados esto listados mais adiante neste documento]

1.4.1. Envolvimento da Garantia de Qualidade de Software

O modelo V acima mostra o processo de teste ideal, onde a preparao de teste comea assim que a
definio de requisitos produzido. O planejamento de teste de sistema comeou em um estgio inicial, e

Qualidade e Teste de Software

Pgina 2

Modelo de um plano de testes

por esta razo o teste de sistema vai se beneficiar de iniciativas de qualidade atravs do ciclo de vida do
projeto.
As responsabilidades entre o departamento de Garantia de Qualidade de Software (SQA) e o departamento
do Projeto so as seguintes:

Testes Unitrios so de responsabilidade da equipe de desenvolvimento

Testes de sistemas so de responsabilidade da Garantia de Qualidade de Software
Testes de aceitao de usurio so de responsabilidade da equipe de representao do usurio
Testes de conformidade tecnolgica so de responsabilidade da equipe de instalao & suporte de
sistemas

2. ESCOPO E OBJETIVOS
2.1. Escopo da abordagem de teste Funes do sistema
2.1.1. INCLUSES (ESCOPO)
O contedo desta verso :
Entregveis da fase 1
o
o
o
o
o
o
o
o
o

Processo de transao novo e revisado, com suporte automatizado

Novos processos de dvidas do cliente e sistemas
Processo revisado de auditoria inter-escritrios
Re-alocao de excees para o escritrio central
Novo sistema centralizado de gerenciamento de agncia
Processo revisado de gerenciamento de dvidas
Processo revisado de recuperaes
Novo processo de reconciliao internacional
Novo processo de reconciliao contbil

2.1.2. EXCLUSES (NO ESCOPO)

Quando o escopo de cada fase tiver sido acordado e terminado, incluses no sero mais consideradas na
verso, exceto:
(1) Onde houver permisso e concordncia expressas do analista de negcio e do Analista de Teste;
(2) Onde as mudanas/incluses no requerem esforo significativo da equipe de teste (como preparao
extra, novas condies de teste, etc) e no afetem o cronograma de teste.
[Veja a seo 9.1.]
2.1.3. EXCLUSES ESPECFICAS

Gerenciamento de caixa no est includo nesta fase

Funes de incio/trmino esto excludas elas sero tratadas por processos existentes
A funo de Pedido Especial j existente no ser substituda
Transaes com moeda estrangeira
Dados de cmbio internacional
Contabilidade ou relatrios de transaes em Euros

Documentao de referncia & fontes:

Qualidade e Teste de Software

Pgina 3

Modelo de um plano de testes

1. Documento de desenho de processo de negcio - Referncia: BPD-1011
2. Requisitos de transao para a fase 1 - Referncia: TR_PHASE1-4032
3. Problemas & riscos do projeto T:\Data\Project\PROJECT.MDB
4. Padres de desenvolvimento de sistema - Referncia: DEVSTD-1098-2
5. Ciclo de vida do desenvolvimento de sistema - Referncia: SDLC-301

2.2. Processo de teste

b. Desenhar o
Teste de
Sistema

a. Planejar o
projeto

c.
Desenhar/Constru
ir procedimentos
de testes

e. Executar o
teste de Sistema

f. Executar o
teste de Aceite

g. TERMINO

d. Construir
ambiente de
teste
O diagrama acima explica a abordagem do processo de teste que ser seguida.
a.
b.

c.

d.
e.
f.
g.

ORGANIZAR O PROJETO - envolve a criao de um plano de teste de sistema, abordagem de cronograma &
teste, e requisitar/delegar recursos.
DESENHAR/CONSTRUIR TESTE DE SISTEMA - envolve identificar ciclos de teste, casos de teste, critrios
de entrada e de sada, resultados esperados, etc. Em geral, as condies de teste e os resultados esperados
sero identificados pela equipe de teste em conjunto com o analista de negcio do projeto ou com o
especialista do negcio. A equipe de teste vai ento identificar os casos de teste e os dados requeridos. As
condies de teste so derivadas do desenho do negcio e dos documentos de requisitos de transao.
DESENHAR/CONSTRUIR PROCEDIMENTOS DE TESTE - inclui preparar procedimentos como sistemas de
gerenciamento de erro e relatrio de status, e preparar as tabelas de dados para a ferramenta automatizada de
teste.
CONSTRUIR O AMBIENTE DE TESTE - inclui requisitar/construir hardware e software e preparar dados.
EXECUTAR TESTE DE INTEGRAO DE PROJETO - veja seo 3 Ciclos e fases de teste.
EXECUTAR TESTE DE ACEITAO DE OPERAES - veja seo 3 Ciclos e fases de teste.
TRMINO - o trmino acontece quando todos os critrios de sada pr-definidos foram alcanados. Veja a
seo 2.4.
2.2.1. Excluses
A garantia da qualidade do sistema no vai lidar diretamente com o desenho do negcio em relao a
qualquer questo de desenho e assuntos funcionais.
A equipe de desenvolvimento o fornecedor da garantia da qualidade do sistema. Se aparecerem questes
funcionais ou relativas ao desenho, elas devem ser resolvidas pela equipe de desenvolvimento e seus
fornecedores.

2.3. Escopo de teste

Qualidade e Teste de Software

Pgina 4

Modelo de um plano de testes

Abaixo esto os principais tipos de testes que sero feitos para esta verso. Todos os planos e condies
de testes de sistema sero desenvolvidos a partir de especificaes funcionais e do documento de
requisitos.

2.3.1. Teste Funcional

O objetivo deste teste garantir que cada elemento do aplicativo atenda os requisitos funcionais do negcio
conforme descritos:

No documento de requisitos
Na especificao de desenho do negcio
Nos padres de desenvolvimento do ano 2000
Em outros documentos funcionais produzidos durante o andamento do projeto, como resolues de
questes, requisies de mudana e feedbacks.

Este estgio vai tambm incluir o teste de validao que o teste intensivo das novas telas e front
ends. Padres GUI do Windows; Vlidos, invlidos e dados limitados de entrada; Aparncia de tela e
campo; Consistncia geral com o resto do aplicativo.
O terceiro estgio inclui testes funcionais especficos estes so testes de nvel baixo que tm o objetivo
de testar os processos individuais e fluxos de dados.

2.3.2. Teste de Integrao

Este teste prova que todas as reas do sistema fazem interfaces entre si corretamente e que no h
problemas no fluxo de dados. O teste final de integrao prova que o sistema funciona como uma unidade
integrada quando todas as partes estiverem completadas.

2.3.3. Teste de Aceitao (usurio)

Este teste, que planejado e executado pelo(s) representante(s) do negcio (cliente), assegura que o
sistema opera da maneira esperada, e que o material de suporte (como procedimentos e formulrios) est
correto e serve ao seu propsito. um teste de alto nvel, que assegura que no h problemas na
funcionalidade.

2.3.4. Teste de Performance

Este teste assegura que o sistema fornece tempos aceitveis de resposta (que no devem exceder 4
segundos).

2.3.5. Teste de Regresso

Um teste de regresso deve ser feito depois da liberao de cada fase para assegurar que:

No h impacto em softwares liberados anteriormente

H um aumento de funcionalidade e estabilidade do software

O teste de regresso ser automatizado com o uso da ferramenta automatizada de teste.

2.3.6. Teste de quebra & de multi-usabilidade

Qualidade e Teste de Software

Pgina 5

Modelo de um plano de testes

O teste de multi-usabilidade vai provar que possvel que um nmero aceitvel de usurios trabalhem no
sistema ao mesmo tempo. O teste de quebra uma tentativa customizada de quebrar o sistema.

2.3.7. Teste Tcnico

O teste tcnico ser de responsabilidade da equipe de desenvolvimento.

2.3.8. Teste de aceitao operacional (TAO)

Esta fase de teste deve ser feita pela equipe de instalao e suporte de sistema, antes de implantar o
sistema propriamente dito. Esta equipe vai definir seus prprios critrios de testes, e aplic-los.

2.4. Critrios de entrada e de sada de teste de sistema

2.4.1. Critrios de entrada
Os critrios de entrada especificados pelo controlador do sistema devem ser atendidos antes que o Teste
de Sistema comece. No caso de algum critrio no ser atendido, o teste pode comear se a equipe de
negcio e o controlador do teste estiverem em total acordo que o risco gerencivel.

Todos os cdigos desenvolvidos devem ser testados separadamente. O teste de unidade e o teste
de link devem ser completados pela equipe de desenvolvimento.
Planos de teste de sistema devem ser finalizados pelo analista de negcio e pelo analista de teste.
Todos os recursos humanos devem estar disponveis.
Todos os hardwares e ambientes de teste devem estar prontos e livres para serem usados no teste
de sistema.
O teste de aceitao deve ser completado, com uma taxa de sucesso de pelo menos 80% .

Testes de aceitao:
25 casos sero testados. Para atingir o critrio de aceitao, 20 destes 25 devem ser completados com
sucesso. Isto , uma taxa de sucesso de pelo menos 80% deve ser atingida antes que o software seja
aceito para iniciar o teste de sistema. Isto significa que erros encontrados durante os testes de aceitao
no devem impedir que 80% dos aplicativos tenham seus testes completados.
Obs: Estes testes no tm a inteno de fazer um teste profundo do software.
Critrios de recomeo
No caso de o teste de sistema ser suspenso, critrios de recomeo devem ser especificados, e o teste no
deve recomear enquanto o software no atender estes critrios.

Qualidade e Teste de Software

Pgina 6

Modelo de um plano de testes

2.4.2. Critrios de sada
Os critrios de sada detalhados abaixo devem ser atendidos antes que o software de fase 1 possa ser
recomendado promoo para o status de aceitao de operao. Alm disso, recomendamos que
houvesse um mnimo de 2 dias dedicados a um teste final de integrao DEPOIS que a ltima verso for retestada. [Veja a seo 9.3]

Todos os erros de alta prioridade do teste de sistema devem ser consertados e testados.
Se qualquer erro de mdia ou baixa prioridade for notvel, o risco de implantao deve ser
autorizado como aceitvel pelo analista de negcio e pelo especialista do negcio .
O teste de integrao de projeto deve ser finalizado pelo controlador de teste e pelo analista de
negcio.
O teste de aceitao do negcio deve ser finalizado pelo especialista do negcio.

3. FASES E CICLOS DE TESTE

Haver dois estgios principais de teste para novos aplicativos durante o teste de sistema:

Teste de sistema
Teste de aceitao de operao

3.1. Ciclos de teste de sistema

O principal impulso da abordagem (estratgia) testar intensivamente as duas primeiras liberaes, assim
levantando aproximadamente 80% dos erros neste perodo. Com a maioria dos erros consertados, aespadro ou aes freqentemente usadas sero testadas para provar elementos individuais e o
processamento total do sistema na liberao v0.3.
Quando todos os erros (que potencialmente impactam o processamento geral) forem consertados, um
conjunto adicional de casos de teste so processados na liberao v0.4 para assegurar que o sistema
funciona de maneira integrada. esperado que a liberao v0.4 seja a prova final do sistema enquanto
aplicativo nico. No deve haver erros de classe A ou B antes do incio do teste da liberao v0.4.

Casos de teste por verso liberada:

Teste por fase
Aceitao 1
Verso v0.1 Funcional 1
Aceitao de usurio
Aceitao 2
Verso v0.2 Funcional 2
Regresso 1
Aceitao 3
Funcional 3
Verso v0.3 Performance 1
Teste de quebra & de multi-usabilidade
Regresso 1
Regresso 2
Integrao 1

Qualidade e Teste de Software

Pgina 7

Modelo de um plano de testes

Tcnico 1
Verso v0.4 Regresso 1
Regresso 2
Regresso 3
Teste de instalao
Contingncia Apenas teste de conserto por bug

3.1.2. Teste automatizado

Ferramentas de teste automatizado sero usadas em ambiente de teste para teste funcional e teste de
regresso. O foco principal do teste automatizado o teste de regresso da funcionalidade previamente
entregue isto , quando a verso 0.2 do software entregue, a maioria dos testes de regresso da
funcionalidade entregue na verso 0.1 ser automtica. esperado que o benefcio total do teste
automatizado ocorra somente quando os testes tenham sido executados trs ou mais vezes.

3.2. Entrega de software

Durante o teste de sistema, a liberao de novas verses do software deve ser coordenada entre o lder da
equipe de desenvolvimento e o analista de teste de sistema. Entretanto, a menos que sirvam para corrigir
um erro muito grave, novas verses s devem ser liberadas quando objetivos concordados sejam
alcanados (por exemplo, a prxima verso contem correes para um nmero X ou mais de bugs).

Cronograma de liberao:
v0.4
18 de junho

v1.0
29 de junho

Nenhuma

Apenas

funcionalidade

verso de

nova a ser

contingncia

entregue

para

6. Transaes internacionais

nesta

conserto

7. Outros

verso

de bug

Funcionalidade a ser entregue*

v0.1
1 de maio

v0.2
17 de maio

v0.3
31 de maio

1. Funo A
2. Processo B
3. Requisitos Europeus
4. Requisitos Y2K
5. Transaes inter-escritrios

* (por especificao funcional, por prioridade)

Observaes:
Espera-se que 80% das funcionalidades tenham sido completamente testadas antes da liberao da fase 3.
Todas as funcionalidades devem estar presentes na liberao de fase 3.
Nenhuma funcionalidade no entregue anteriormente ser aceita para teste depois da fase 3.

3.3. Reviso formal

H vrios pontos formais de reviso antes e depois do teste de sistema, incluindo a reviso deste
documento. Este um elemento vital para obter um produto de qualidade.

Qualidade e Teste de Software

Pgina 8

Modelo de um plano de testes

3.3.1. Pontos de reviso formal

2. Desenhar
o Teste de
Sistema

1. Planejar
o projeto

5. Construir
o teste de
Sistema

3. Construir
procedimento
s de testes

4. Desenho
ambiente de
teste

8. Teste de
Integrao

10. Trmino
e Reviso

7. Executar
o teste de
Sistema

6. Construir
o ambiente
de teste

9. Inicia o
Teste Piloto

1. Documentao de desenho especificao de requisitos e especificaes funcionais

2. Plano de teste de sistema
3. Planos de testes unitrios & condies de teste
4. Resultados de testes unitrios
5. Condies de teste de sistema
6. Progressos/resultados de teste de sistema
7. Reviso aps teste de sistema
8. Resultados de teste de integrao
9. Reviso de implantao-piloto
10. Reviso do projeto
O diagrama acima mostra a abordagem (estratgia) de teste. As caixas de 1 a 6 mostram os principais
estgios de reviso antes da execuo do teste. As caixas de 7 a 10 mostram as fases planejadas para
antes e depois da execuo do teste.
O diagrama acima se concentra no aspecto de teste do papel da Garantia de Qualidade do Software, mas
h tambm um papel em andamento, para assegurar a qualidade dos entregveis principais atravs do ciclo
de vida do projeto. O papel da Garantia de Qualidade do Software ser assegurar que todas as inspees
de qualidade ocorram para todos os entregveis concordados, e que aes de follow-up e iniciativas sejam
buscadas.
3.3.2. Monitoramento de progressos/resultados

Resultados do teste de aceitao 1

Resultados de teste liberao v0.1
Resultados de teste liberao v0.2
Resultados de teste liberao v0.3
Resultados do teste de performance 1
Resultados dos testes de regresso 1 e 2
Resultados de teste liberao v0.4
Resultados do teste tcnico

4. Cronograma do Teste de Sistema

Qualidade e Teste de Software

Pgina 9

Modelo de um plano de testes

Estas so imagens de alguns cronogramas de projeto de alto nvel. Estes cronogramas
servem somente como exemplos, e provavelmente no correspondem exatamente com o
resto do plano de teste. A melhor imagem a ltima.

Qualidade e Teste de Software

Pgina 10

Modelo de um plano de testes

Qualidade e Teste de Software

Pgina 11

Modelo de um plano de testes

5. RECURSOS
5.1. Humanos

Tipo de recurso

Ttulo

Gerenciamento de
projeto/Funcional

Analista de negcio

Teste

Equipe de suporte de
teste

N.

Data
requisitada

Quem

Status

Joo da
Silva
Outro

Designado

Controlador de teste

Jos da
Silva

Designado

Testadores

1 de maio

A ser designado

Programadores de
suporte

15 de maio

A ser designado

Suporte tcnico

1 de maio

A ser designado

Suporte WAN

25 de maio

A ser designado
A ser designado

Tcnico - Externo

Negcio

Suporte CIS (Central IT

Services Servios
Centrais de TI)

25 de maio

A ser designado

Suporte contbil

15 de maio

A ser designado

Suporte de ligaes
externas

25 de maio

Especialista do
negcio/representante do
negcio

1 de maio

Joo
Carlos

Designado

A ser designado

5.2. Hardware
Um sistema controlado, em separado, ser necessrio para a fase inicial de teste,
montado como um ambiente-padro do negcio. Para manter a integridade do ambiente
de teste, sua rede no deve ser acessvel a ningum de fora do projeto. As impressoras
tambm devem ser exclusivamente para uso da rede de teste.

Qualidade e Teste de Software

Pgina 12

Modelo de um plano de testes

Componentes de hardware requeridos

1 controlador de rede
6 PCs em rede (veja abaixo)
1 estao de trabalho como acelerador de download
1 Motorola 6520
1 servidor Alpha AXP
1 impressora Batch Waste
1 impressora HP LaserJet 4v

Especificaes dos PCs requeridos para o ambiente de teste

1 x P100, 1Gb HD, 16Mb RAM [Especificao mnima atual]
3 x P166, 1.5Gb HD, 32Mb RAM [Especificao mnima atual]
1 x P333, 2.5Gb HD, 64Mb RAM [Especificao mnima atual]
1 Pentium com Windows NT tambm necessrio como centro de teste para controlar e
executar testes automatizados.

5.3. Software
Testar ambientes IMS
Testar ambientes IMS da regio X necessrio para o teste de sistema. Dados adicionais
ou complementares sero fornecidos onde requerido.
Qualidade e Teste de Software

Pgina 13

Modelo de um plano de testes

Testar ambiente de software

O teste de sistema vai rodar nas seguintes verses de software:
Custom Desktop Verso 97.0.1
Windows 95
Visual Basic 5 Runtime Files
MS Office 97
Novell Netware

Sistema de medio de erros

Este teste de sistema usar um sistema de gerenciamento de erros de base de dados do
MS Access. Uma nova base de dados ser implementada exclusivamente para este
projeto.

6. PAPIS E RESPONSABILIDADES
6.1. Equipe de gerenciamento
Lder do projeto Sr. Thiago Lacerda
Assegurar que a fase 1 seja entregue dentro do cronograma, oramento e qualidade
Assegurar que os critrios de sada sejam alcanados antes do trmino do teste de
sistema
Revisar regularmente o progresso do teste junto ao controlador de teste
Relacionar-se com equipes externas, como a de equipe de novos sistemas, por
exemplo
Levantar e gerenciar assuntos/riscos relacionados ao projeto ou fora do controle da
equipe de teste
Revisar e finalizar abordagem, plano e cronograma de teste
Garantia da Qualidade do Software Lder do projeto Sr. Reynaldo Giannechini
Assegurar que a fase 1 seja entregue dentro do cronograma, oramento e qualidade
Revisar regularmente o progresso do teste
Gerenciar assuntos/riscos relacionados equipe de teste de sistema
Fornecer os recursos necessrios para completar o teste de sistema

6.2. Equipe de teste

Planejador/Analista de teste Sr. Brad Pitt
Assegurar que a fase 1 seja entregue dentro do cronograma, oramento e qualidade
Criar condies de teste detalhadas e de alto nvel
Produzir os resultados esperados
Reportar progressos em reunies regulares de Status Report
Coordenar reviso e trmino das condies de teste
Gerenciar ciclos individuais de teste e resolver questes/problemas dos testadores
Assegurar que os resultados/problemas do teste de sistema sejam reportados
Qualidade e Teste de Software

Pgina 14

Modelo de um plano de testes

imediatamente, e que o acompanhamento seja feito
Assegurar que os critrios de entrada sejam alcanados antes que o teste de sistema
inicie
Assegurar que os critrios de sada sejam alcanados antes do trmino do teste
Testadores
Identificar dados de teste
Executar as condies de teste
Elaborar relatrios de erros de software
Administrar o sistema de medio de erros

6.3. Equipe de negcio

Analista de negcio Sr. Keanu Reeves
Revisar planos detalhados e de alto nvel para o teste de sistema
Definir procedimentos
Resolver assuntos de desenho
Resolver assuntos de negcio
Participar das reunies dirias da equipe de reviso de erros
Representante do negcio ?? (a ser designado)
Executar teste de aceitao do usurio
Definir condies de teste e resultados esperados para o teste de aceitao do negcio
Resolver assuntos de usurio
Resolver assuntos de desenho

6.4. Equipe de suporte de teste

Programadores de suporte
Participar das reunies dirias da equipe de reviso de erros
Coordenar e dar suporte ao teste de sistema
Resolver erros
Re-liberar software de teste depois de correes
Dar suporte aos testadores de sistema

6.5. Equipe de suporte externo

Suporte a servios centrais de TI
Dar suporte a servios centrais de TI, se necessrio
Resolver questes de servios centrais de TI, se necessrio

Suporte IMS
Fornecer suporte ao teste de sistema
Dar suporte s regies IMS
Resolver assuntos de solues adaptadas ao sistema operacional, se necessrio
Fazer integrao e conformidade contbil, se necessrio
Resolver questes que surjam do backup remoto
Qualidade e Teste de Software

Pgina 15

Modelo de um plano de testes

Suporte contbil
Fornecer suporte tcnico contbil, se necessrio
Resolver questes, se necessrio
Suporte tcnico
Fornecer suporte ao ambiente de hardware
Fornecer suporte ao software de teste
Fornecer software para o ambiente de teste de sistema
Suporte de acesso
Fornecer e dar suporte s bases de dados de teste

7. Gerenciamento de erro & gerenciamento de

configurao
Durante o teste de sistema, erros sero anotados em Relatrios de Erros, medida que
forem detectados. Estes relatrios sero dados de entrada colocados no final de cada dia
no sistema de gerenciamento de erros, com o status erro levantado ou questo
levantada. A equipe de reviso de erros vai se reunir todas as manhs s 10h na sala de
reunies para revisar e priorizar os fatos levantados no dia anterior, e design-los ou
deix-los de lado conforme apropriado. A equipe deve ter os seguintes representantes:

A. Lder da equipe de desenvolvimento

B. Analista de negcio
C. Analista de teste
D. Representante do negcio

Erros que foram concordados como vlidos sero categorizados pela equipe de reviso
de erros da seguinte forma:

Categoria A Erros srios que impeam a continuidade do teste de sistema de

uma funo em particular, ou graves erros de dados.
Categoria B Erros relativos a dados srios ou faltantes que no impeam a
implantao.
Categoria C Pequenos erros que no impedem nem afetam a funcionalidade.

Erros da categoria A devem ser eliminados pela equipe de correes de bugs em 48

horas (a contar da hora em que o erro for levantado na reunio da equipe de reviso de
erros at a correo ser liberada no ambiente do teste de sistema). No caso de um erro
de categoria A que impea o teste de sistema de continuar, a eliminao deve ser dentro
de 4 horas.
Erros de categoria B devem ser solucionados em 1 dia, e os de categoria C em 3 dias.
Entretanto, a liberao de novas verses do software devem ser coordenadas com o
analista de teste novas verses devem somente ser liberadas quando concordadas, e
onde haja um benefcio definitivo (por exemplo, que contenha correes para um nmero
X de bugs).
Qualidade e Teste de Software

Pgina 16

Modelo de um plano de testes

8. RELATRIO DE SITUAO
8.1. Relatrio de Situao
A preparao de teste e o progresso de teste devem ser formalmente reportados em uma
reunio semanal de status. Quem deve comparecer a esta reunio:

Gerente do projeto
Lder da equipe de desenho de negcio
Lder da equipe de desenvolvimento

Um relatrio de situao (status) deve ser preparado pelo analista de teste para facilitar
esta reunio. Este relatrio deve conter as seguintes informaes:
1. Satus atual X planejamento (Adiantado/Atrasado/No cronograma)
2. Progresso de tarefas planejadas da semana anterior
3. Tarefas planejadas para a prxima semana, incluindo tarefas remanescentes da
semana anterior
4. Estatstica de erros do sistema de medio de erros
5. Questes/Riscos

9. Questes, riscos e premissas

9.1. Questes/riscos
1. Mudanas e incluses no sero consideradas para esta verso, exceto: (1) onde
houver a permisso e a concordncia expressas do analista de negcio e do analista de
teste; (2) onde as mudanas/incluses no requeiram significativo esforo da equipe de
teste e no afetem o cronograma de teste. Este um assunto srio em potencial, pois
qualquer grande mudana no desenho vai requerer tempo adicional para re-planejar o
teste e para criar condies de teste suplementares.

Responsvel: Byron Ruthlenn

Finalizao da lista definitiva de incluses.
2. O desenho do software deve ser final, e a documentao deve ser completa,
informativa e finalizada por todas as partes antes que o teste de sistema comece.
Responsvel: D. A. Stone
3. Uma fraqueza da abordagem (estratgia) da entrega por fases que o alto grau de
interdependncia no cdigo significa que a menor mudana pode ter srios efeitos em
reas do aplicativo que aparentemente no mudaram. O pressuposto da equipe de teste
que funcionalidades previamente entregues e testadas somente requeiram testes de
regresso para verificar que elas ainda funcionam, ou seja, os testes no tero a inteno
de descobrir novos erros. Por isso recomendamos que haja um mnimo de dois dias de
testes de regresso DEPOIS que a correo final tenha sido re-testada. Isto, porm,
Qualidade e Teste de Software

Pgina 17

Modelo de um plano de testes

impe uma restrio de tempo na finalizao do perodo de testes, o que requer a
concordncia do lder do projeto.
Responsvel: Byron Ruthlenn
4. Teste automatizado
A maior parte dos testes de regresso ser feita usando a ferramenta de teste
automatizado. Entretanto, por causa da carga de trabalho requerida para implantar
completamente e eliminar os bugs da ferramenta de teste, provvel que o retorno
apenas seja maximizado depois da terceira vez que o teste rodar para cada liberao. Os
outros principais usos da ferramenta de teste so: (1) carregar o teste; (2) permitir teste
por multi-usurios; (3) entrar dados repetitivos.
Responsvel: Analista de teste

9.2. Premissas

O software ser entregue no prazo

O software ter a qualidade requisitada
O software no ser impactado por mudanas de conformidade Y2K feitas na sua
estrutura externa. Por exemplo, qualquer mudana externa ter que ser compatvel
com este aplicativo
Todos os bugs que possam travar o sistema recebero ateno imediata da equipe
de desenvolvimento
Todos os bugs encontrados em uma verso do software sero consertados e
testados individualmente pela equipe de desenvolvimento antes que uma nova
verso seja liberada
A funcionalidade entregue no prazo
Os recursos requeridos estaro disponveis
Todos os acordos de servio sero cumpridos
A ferramenta de teste automatizado vai funcionar e interagir corretamente com o
software
Toda a documentao ser atualizada e entregue equipe de teste de sistema
Especificaes funcionais e tcnicas sero aprovadas pelo negcio
A intranet vai estar completamente funcional antes que o projeto comece

10. Trmino formal

Este documento deve ser formalmente aprovado antes que o teste de sistema possa
comear. As seguintes pessoas devem assinar;
Assinaturas:
Gerente do projeto
SQA
Equipe de teste
Equipe de desenvolvimento

Qualidade e Teste de Software

Byron Ruthlenn
Colm Jones
Dion Hais
Erwin Smith

Pgina 18

Modelo de um plano de testes

11. APNDICES
11.1. Propsito da equipe de reviso de erros
Assegurar mxima eficincia das equipes de desenvolvimento e de teste de sistema para
a liberao do novo software atravs da cooperao de todas as partes envolvidas.
Isto ser alcanado atravs de reunies dirias cujas funes sero:

Classificar o status de cada erro levantado

Priorizar os erros vlidos
Assegurar que documentao suficiente sobre os erros esteja disponvel
Concordar sobre contedo e cronograma para liberaes de software no
teste de sistema
Assegurar uma fonte concordada de informao de reportao de erro
Identificar assuntos que possam afetar a performance do teste de sistema

11.2. Pauta da reunio da equipe de reviso de erros

Revisar aes da reunio anterior

Classificar e priorizar cada erro
Revisar erros para verificar duplicidade
Concordar na prioridade de cada erro
Determinar adequao de documentao associada a cada erro levantado
Concordar no contedo e cronograma de liberaes
Revisar aes designadas em reunies anteriores

11.3. Classificao de bugs

1. Um bug "A" trava o sistema ou de tal importncia que pode radicalmente afetar a
funcionalidade do sistema.
Exemplos de bugs que travam o sistema:
- Se por causa de um travamento durante o processamento de um aplicativo, um usurio
no consegue completar este aplicativo
- Dados incorretos so passados ao sistema resultado em corrompimento ou travamento
do sistema.
Exemplos de funcionalidade severamente afetada:
- Clculo incorreto de pagamentos
- Produo incorreta de acordos de crdito
2. Bugs so classificados como "B"quando:

Qualidade e Teste de Software

Pgina 19

Modelo de um plano de testes

- Afetam um elemento menos importante da funcionalidade. Exemplo: um default de um
falor no est correto e precisa ser corrigido manualmente.
- Os dados afetados no tm um grande impacto. Exemplo: um dado de um cliente no foi
enviado corretamente para a base de dados.
- Existe um mtodo alternativo para completar o processo. Exemplo: um problema ao ler
os detalhes de um crdito. Esta mudana pode ser entrada manualmente.
3. Bugs do tipo "C" so inofensivos. Exemplos: falta de texto nas janelas de ajuda, opes
em duplicidade.

11.4. Procedimento para manuteno de sistema de registro de erros

1. O controlador de teste deve passar qualquer grande erro/anomalia para o lder da equipe de
desenvolvimento ou seu representante designado, antes de fazer um registro formal do erro. Isto tem
algumas vantagens:
- Evita esforo desnecessrio dos testadores
- Pe o desenvolvedor imediatamente a par do problema
- Permite que o desenvolvedor adicione mecanismos necessrios para localizar o erro
2. Todos os bugs levantados devem estar nos corretos formulrios de erro, e conter todas as informaes
relevantes
3. O erro deve ser registrado no dia em que ocorrer, com o status 'LEVANTADO'
4. Deve haver uma reunio diria da equipe de suporte ao teste de sistema, para discutir, priorizar e
concordar em todos os erros registrados. Durante estas reunies, erros podem ser baixados,
identificados como duplicatas, passados aos programadores, etc.
5. O registro de erros ser atualizado com o status de todos os erros depois desta reunio. Exemplo:
duplicata, com programador, etc.
6. Uma vez que o erro foi consertado e estiver pronto para liberao, os formulrios correspondentes
devem ser passados ao controlador de teste, para que ele mude o seu status para Consertado para ser
re-testado.
7. Quando o erro for re-testado e estiver correto, seu status deve mudar para Fechado.
8. Relatrios de status de erros devem ser produzidos pelo sistema de erros, para uso nas reunies da
equipe de reviso de erros.

11.5. Processo noturno checagem de contabilidade e sistemas de

informao computadorizados
Requisito de teste

Itens a checar

Nvel de teste

Contabilidade
Quando a transferncia de dados estiver completa, relatrio
deve ser checado contra:
1. Transaes similares
2. Formulrios de dados de entrada de teste

1. Relatrio de legado

1. Checagem em
nvel de campo

X
Relatrio de
transaes do
escritrio

2. Checagem em
nvel de campo

2. Relatrio
X

Qualidade e Teste de Software

Pgina 20

Modelo de um plano de testes

Formulrios de entrada
Depois de abrir/alterar, o relatrio de alteraes deve ser
checado contra:
1. Instrues de alteraes rejeitadas
2. Dados de entrada correspondentes aos formulrios

1. Relatrio de
alteraes

1. Satisfazer as
razes para rejeio

2. Relatrio de
alteraes

2. Checagem em
nvel de campo

Formulrios de entrada
de teste
Imprimir arquivos de contas e de clientes e checar detalhes
dos campos contra dados de entrada dos formulrios das
filiais

Entradas da
contabilidade

Checagem em nvel
de campo

X
Formulrios de entrada
de teste

11.7. MEDIDAS DE GARANTIA DE QUALIDADE DE

SOFTWARE
(i) DATA
- Data de incio do envolvimento da Garantia de Qualidade do Software

(ii) ESFORO
-Nmero de dias/homem da Garantia de Qualidade do Software para planejamento de
teste
-Nmero de dias/homem da Garantia de Qualidade do Software para reviso dos planos
de teste
-Nmero de dias/homem da Garantia de Qualidade do Software para executar os testes

(iii) VOLUME
-Nmero de testes identificados

(iv) QUALIDADE
-Nmero de testes aprovados na primeira vez
-Porcentagem de testes aprovados na primeira vez
-Nmero de erros levantados durante o teste de regresso
-Nmero de erros gerados como resultado de consertos incorretos
-Nmero de erros levantados por categoria (A/B/C)
-Nmero de erros levantados por cdigo de motivo
-Nmero de erros levantados por funes de negcio de alto nvel

(v) TEMPO
Qualidade e Teste de Software

Pgina 21

Modelo de um plano de testes

- Tempo mdio de conserto de erro

12. DOCUMENTAO DE CONTROLE

12.1. Formulrio on-line de entrada de erro
12.2. Documentao de controle de checagem
12.3. Verificao & teste de sada
12.4. Formulrio de entrada de erro no-consertado
12.5. Erros designados equipe de desenvolvimento
12.6. Linhas de comunicao do SQA
12.7. Caminhos de processamento de erros
12.8. Suporte ao teste de sistema
12.9. Fluxo de status de erros.

12.9.1 Caminho Proposto para o Processo de Erros

12.9.2 Procedimento para correes de Erros

Qualidade e Teste de Software

Pgina 22

Modelo de um plano de testes

12.9.3 Fluxos de Status de Erros

Qualidade e Teste de Software

Pgina 23