DOCUMENTO DE TESTE

1. INTRODUCÃO

1.1. Visão geral do sistema “X”

O objetivo desta fase do projeto é implantar uma nova plataforma do sistema “X” que irá
possibilitar:

 Remoção de sistemas legados de escritório

 Introdução de “ABC”
 Processamento de transações especiais
 Ausência de restrições no local de captura
 Captura de transações para outros sistemas de processamento
 Novo processo de reconciliação
 Posicionamento para moeda da União Européia e iniciativas futuras

Este programa vai resultar em mudanças significativas nos atuais processos departamentais e
inter-escritório. A funcionalidade será entregue em fases.

A fase 1 vai incorporar as seguintes características:

 Substituição do sistema legado A

 Novo sistema de reconciliação
 Sistema de terceirização para departamentos em diferentes países europeus
 Características novas/revisadas de auditoria e pesquisa

[Inclusões detalhadas estão listadas mais adiante neste documento]

1.2. Propósito deste documento

Este documento deve servir como o Rascunho da Abordagem (estratégia) de Teste para o
Projeto de Desenvolvimento de Sistemas de Negócio.

A preparação para este teste consiste de três estágios principais:

 A Abordagem (estratégia) de Teste define o escopo do teste do sistema, a estratégia

geral a ser adotada, as atividades a serem completadas, os recursos gerais
necessários e os métodos e processos a serem usados para testar a versão. Ela
também detalha as atividades, dependências e esforços requeridos para conduzir o
teste de sistema.
 O Planejamento de Teste detalha as atividades, dependências e esforços requeridos
para conduzir o teste de sistema.

 As Condições/Casos de Teste documentam os testes a serem aplicados, os dados a

serem processados, a cobertura automatizada de teste e os resultados esperados .
1.3. Revisão formal

Há vários pontos formais de revisão antes e durante o teste de sistema. Este é um elemento
vital para alcançar um produto de qualidade.

1.3.1. Pontos formais de revisão ocorrem ao final da elaboração de:

1. Documentação de Desenho
2. Abordagem de teste
3. Planos de Teste Unitário
4. Condições e Resultados do Teste Unitário
5. Condições do Teste de Sistema
6. Progresso do teste de sistema
7. Revisão após o teste de sistema

1.4. Objetivos do Teste de Sistema

Em um nível elevado, o teste de sistema tem o objetivo de provar que:

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

especificações do negócio no documento de especificações de desenho do negócio e
da documentação de requisitos.

 O software é de alta qualidade; o software vai substituir as/dar suporte às funções de

negócio desejadas e alcançar os padrões 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 estão 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 preparação de teste começa
assim que a definição de requisitos é produzido. O planejamento de teste de sistema começou
em um estágio inicial, e por esta razão o teste de sistema vai se beneficiar de iniciativas de
qualidade através do ciclo de vida do projeto.

As responsabilidades entre o departamento de Garantia de Qualidade de Software (SQA) e o

departamento do Projeto são as seguintes:

 Testes Unitários são de responsabilidade da equipe de desenvolvimento

 Testes de sistemas são de responsabilidade da Garantia de Qualidade de Software
 Testes de aceitação de usuário são de responsabilidade da equipe de representação
do usuário
 Testes de conformidade tecnológica são de responsabilidade da equipe de instalação
& suporte de sistemas

2. ESCOPO E OBJETIVOS
2.1. Escopo da abordagem de teste – Funções do sistema
2.1.1. INCLUSÕES (ESCOPO)

O conteúdo desta versão é:

Entregáveis da fase 1

o Processo de transação novo e revisado, com suporte automatizado

o Novos processos de dúvidas do cliente e sistemas
o Processo revisado de auditoria inter-escritórios
o Re-alocação de exceções para o escritório central
o Novo sistema centralizado de gerenciamento de agência
o Processo revisado de gerenciamento de dúvidas
o Processo revisado de recuperações
o Novo processo de reconciliação internacional
o Novo processo de reconciliação contábil

2.1.2. EXCLUSÕES (NÃO ESCOPO)

Quando o escopo de cada fase tiver sido acordado e terminado, inclusões não serão mais
consideradas na versão, exceto:

(1) Onde houver permissão e concordância expressas do analista de negócio e do Analista de

Teste;

(2) Onde as mudanças/inclusões não requerem esforço significativo da equipe de teste (como
preparação extra, novas condições de teste, etc) e não afetem o cronograma de teste.

[Veja a seção 9.1.]

2.1.3. EXCLUSÕES ESPECÍFICAS

 Gerenciamento de caixa não está incluído nesta fase

 Funções de início/término estão excluídas – elas serão tratadas por processos
existentes
 A função de Pedido Especial já existente não será substituída
 Transações com moeda estrangeira
 Dados de câmbio internacional
 Contabilidade ou relatórios de transações em Euros
 Documentação de referência & fontes:

1. Documento de desenho de processo de negócio - Referência: BPD-1011

2. Requisitos de transação para a fase 1 - Referência: TR_PHASE1-4032
3. Problemas & riscos do projeto – T:\Data\Project\PROJECT.MDB
4. Padrões de desenvolvimento de sistema - Referência: DEVSTD-1098-2
5. Ciclo de vida do desenvolvimento de sistema - Referência: SDLC-301

2.2. Processo de teste

b. Desenhar o
Teste de
Sistema

c.
a. Planejar o Desenhar/Constru e. Executar o f. Executar o g. TERMINO
projeto ir procedimentos teste de Sistema teste de Aceite
de testes

d. Construir
ambiente de
teste

O diagrama acima explica a abordagem do processo de teste que será seguida.

a. ORGANIZAR O PROJETO - envolve a criação de um plano de teste de sistema, abordagem de cronograma &
teste, e requisitar/delegar recursos.
b. DESENHAR/CONSTRUIR TESTE DE SISTEMA - envolve identificar ciclos de teste, casos de teste, critérios
de entrada e de saída, resultados esperados, etc. Em geral, as condições de teste e os resultados esperados
serão identificados pela equipe de teste em conjunto com o analista de negócio do projeto ou com o
especialista do negócio. A equipe de teste vai então identificar os casos de teste e os dados requeridos. As
condições de teste são derivadas do desenho do negócio e dos documentos de requisitos de transação.
c. DESENHAR/CONSTRUIR PROCEDIMENTOS DE TESTE - inclui preparar procedimentos como sistemas de
gerenciamento de erro e relatório de status, e preparar as tabelas de dados para a ferramenta automatizada de
teste.
d. CONSTRUIR O AMBIENTE DE TESTE - inclui requisitar/construir hardware e software e preparar dados.
e. EXECUTAR TESTE DE INTEGRAÇÃO DE PROJETO - veja seção 3 – Ciclos e fases de teste.
f. EXECUTAR TESTE DE ACEITAÇÃO DE OPERAÇÕES - veja seção 3 – Ciclos e fases de teste.
g. TÉRMINO - o término acontece quando todos os critérios de saída pré-definidos foram alcançados. Veja a
seção 2.4.

2.2.1. Exclusões

A garantia da qualidade do sistema não vai lidar diretamente com o desenho do negócio em
relação a qualquer questão de desenho e assuntos funcionais.

A equipe de desenvolvimento é o fornecedor da garantia da qualidade do sistema. Se

aparecerem questões funcionais ou relativas ao desenho, elas devem ser resolvidas pela
equipe de desenvolvimento e seus fornecedores.
 2.3. Escopo de teste
Abaixo estão os principais tipos de testes que serão feitos para esta versão. Todos os planos e
condições de testes de sistema serão desenvolvidos a partir de especificações 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 negócio conforme descritos:

 No documento de requisitos
 Na especificação de desenho do negócio
 Nos padrões de “desenvolvimento do ano 2000”
 Em outros documentos funcionais produzidos durante o andamento do projeto, como
resoluções de questões, requisições de mudança e feedbacks.

Este estágio vai também incluir o teste de validação – que é o teste intensivo das novas telas
e “front ends”. Padrões GUI do Windows; Válidos, inválidos e dados limitados de entrada;
Aparência de tela e campo; Consistência geral com o resto do aplicativo.

O terceiro estágio inclui testes funcionais específicos – estes são testes de nível baixo que
têm o objetivo de testar os processos individuais e fluxos de dados.

2.3.2. Teste de Integração

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

2.3.3. Teste de Aceitação (usuário)

Este teste, que é planejado e executado pelo(s) representante(s) do negócio (cliente), assegura
que o sistema opera da maneira esperada, e que o material de suporte (como procedimentos e
formulários) está correto e serve ao seu propósito. É um teste de alto nível, que assegura que
não há problemas na funcionalidade.

2.3.4. Teste de Performance

Este teste assegura que o sistema fornece tempos aceitáveis de resposta (que não devem
exceder 4 segundos).

2.3.5. Teste de Regressão

Um teste de regressão deve ser feito depois da liberação de cada fase para assegurar que:

 Não há impacto em softwares liberados anteriormente

 Há um aumento de funcionalidade e estabilidade do software

O teste de regressão será automatizado com o uso da ferramenta automatizada de teste.

2.3.6. Teste de quebra & de multi-usabilidade

O teste de multi-usabilidade vai provar que é possível que um número aceitável de usuários
trabalhem no sistema ao mesmo tempo. O teste de quebra é uma tentativa customizada de
quebrar o sistema.

2.3.7. Teste Técnico

O teste técnico será de responsabilidade da equipe de desenvolvimento.

2.3.8. Teste de aceitação operacional (TAO)

Esta fase de teste deve ser feita pela equipe de instalação e suporte de sistema, antes de
implantar o sistema propriamente dito. Esta equipe vai definir seus próprios critérios de testes,
e aplicá-los.

2.4. Critérios de entrada e de saída de teste de sistema

2.4.1. Critérios de entrada

Os critérios de entrada especificados pelo controlador do sistema devem ser atendidos antes
que o Teste de Sistema comece. No caso de algum critério não ser atendido, o teste pode
começar se a equipe de negócio e o controlador do teste estiverem em total acordo que o risco
é gerenciável.

 Todos os códigos 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 negócio e pelo
analista de teste.
 Todos os recursos humanos devem estar disponíveis.
 Todos os hardwares e ambientes de teste devem estar prontos e livres para serem
usados no teste de sistema.
 O teste de aceitação deve ser completado, com uma taxa de sucesso de pelo menos
80%.

Testes de aceitação:
25 casos serão testados. Para atingir o critério de aceitação, 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 aceitação não devem impedir que 80% dos aplicativos
tenham seus testes completados.

Obs: Estes testes não têm a intenção de fazer um teste profundo do software.

Critérios de recomeço
No caso de o teste de sistema ser suspenso, critérios de recomeço devem ser especificados, e
o teste não deve recomeçar enquanto o software não atender estes critérios.
 2.4.2. Critérios de saída

Os critérios de saída detalhados abaixo devem ser atendidos antes que o software de fase 1
possa ser recomendado à promoção para o status de aceitação de operação. Além disso,
recomendamos que houvesse um mínimo de 2 dias dedicados a um teste final de integração
DEPOIS que a última versão for re-testada. [Veja a seção 9.3]

 Todos os erros de alta prioridade do teste de sistema devem ser consertados e

testados.
 Se qualquer erro de média ou baixa prioridade for notável, o risco de implantação deve
ser autorizado como “aceitável” pelo analista de negócio e pelo especialista do
negócio.
 O teste de integração de projeto deve ser finalizado pelo controlador de teste e pelo
analista de negócio.
 O teste de aceitação do negócio deve ser finalizado pelo especialista do negócio.

3. FASES E CICLOS DE TESTE

Haverá dois estágios principais de teste para novos aplicativos durante o teste de sistema:

 Teste de sistema
 Teste de aceitação de operação

3.1. Ciclos de teste de sistema

O principal impulso da abordagem (estratégia) é testar intensivamente as duas primeiras
liberações, assim levantando aproximadamente 80% dos erros neste período. Com a maioria
dos erros consertados, ações-padrão ou ações freqüentemente usadas serão testadas para
provar elementos individuais e o processamento total do sistema na liberação v0.3.

Quando todos os erros (que potencialmente impactam o processamento geral) forem

consertados, um conjunto adicional de casos de teste são processados na liberação v0.4 para
assegurar que o sistema funciona de maneira integrada. É esperado que a liberação v0.4 seja
a prova final do sistema enquanto aplicativo único. Não deve haver erros de classe A ou B
antes do início do teste da liberação v0.4.

Casos de teste por versão liberada:

Teste por fase

Aceitação 1
Versão v0.1 Funcional 1
Aceitação de usuário
Aceitação 2
Versão v0.2 Funcional 2
Regressão 1
Aceitação 3
Funcional 3
Versão v0.3 Performance 1
Teste de quebra & de multi-usabilidade
Regressão 1
 Regressão 2
Integração 1
Técnico 1
Versão v0.4 Regressão 1
Regressão 2
Regressão 3
Teste de instalação
Contingência Apenas teste de conserto por bug

3.1.2. Teste automatizado

Ferramentas de teste automatizado serão usadas em ambiente de teste para teste funcional e
teste de regressão. O foco principal do teste automatizado é o teste de regressão da
funcionalidade previamente entregue – isto é, quando a versão 0.2 do software é entregue, a
maioria dos testes de regressão da funcionalidade entregue na versão 0.1 será automática. É
esperado que o benefício total do teste automatizado ocorra somente quando os testes tenham
sido executados três ou mais vezes.

3.2. Entrega de software

Durante o teste de sistema, a liberação de novas versões do software deve ser coordenada
entre o líder da equipe de desenvolvimento e o analista de teste de sistema. Entretanto, a
menos que sirvam para corrigir um erro muito grave, novas versões só devem ser liberadas
quando objetivos concordados sejam alcançados (por exemplo, a próxima versão contem
correções para um número X ou mais de bugs).

Cronograma de liberação:

Funcionalidade a v0.1 v0.2 v0.3 v0.4 v1.0

ser entregue* 1 de maio 17 de maio 31 de maio 18 de junho 29 de junho
1. Função A
2. Processo B Nenhuma Apenas
3. Requisitos
Europeus funcionalidade versão de
4. Requisitos Y2K nova a ser contingência
5. Transações inter-
escritórios entregue para
6. Transações
internacionais nesta conserto
7. Outros versão de bug

* (por especificação funcional, por prioridade)

Observações:
Espera-se que 80% das funcionalidades tenham sido completamente testadas antes da
liberação da fase 3.
Todas as funcionalidades devem estar presentes na liberação de fase 3.
Nenhuma funcionalidade não entregue anteriormente será aceita para teste depois da fase 3.
3.3. Revisão formal
Há vários pontos formais de revisão antes e depois do teste de sistema, incluindo a revisão
deste documento. Este é um elemento vital para obter um produto de qualidade.

3.3.1. Pontos de revisão formal

5. Construir
2. Desenhar o teste de 8. Teste de
o Teste de Sistema Integração
Sistema

3. Construir
1. Planejar procedimento 7. Executar 10. Término
o projeto s de testes o teste de e Revisão
Sistema

4. Desenho 6. Construir 9. Inicia o

ambiente de o ambiente Teste Piloto
teste de teste

1. Documentação de desenho – especificação de requisitos e especificações funcionais

2. Plano de teste de sistema
3. Planos de testes unitários & condições de teste
4. Resultados de testes unitários
5. Condições de teste de sistema
6. Progressos/resultados de teste de sistema
7. Revisão após teste de sistema
8. Resultados de teste de integração
9. Revisão de implantação-piloto
10. Revisão do projeto

O diagrama acima mostra a abordagem (estratégia) de teste. As caixas de 1 a 6 mostram os

principais estágios de revisão antes da execução do teste. As caixas de 7 a 10 mostram as
fases planejadas para antes e depois da execução do teste.

O diagrama acima se concentra no aspecto de teste do papel da Garantia de Qualidade do

Software, mas há também um papel em andamento, para assegurar a qualidade dos
entregáveis principais através do ciclo de vida do projeto. O papel da Garantia de Qualidade do
Software será assegurar que todas as inspeções de qualidade ocorram para todos os
entregáveis concordados, e que ações de follow-up e iniciativas sejam buscadas.

3.3.2. Monitoramento de progressos/resultados

 Resultados do teste de aceitação 1

 Resultados de teste – liberação v0.1
 Resultados de teste – liberação v0.2
 Resultados de teste – liberação v0.3
 Resultados do teste de performance 1
 Resultados dos testes de regressão 1 e 2
 Resultados de teste – liberação v0.4
 Resultados do teste técnico
4. Cronograma do Teste de Sistema
Estas são imagens de alguns cronogramas de projeto de alto nível. Estes
cronogramas servem somente como exemplos, e provavelmente não
correspondem exatamente com o resto do plano de teste. A melhor imagem é a
última.
5. RECURSOS
5.1. Humanos

Tipo de recurso Título Nº. Data Quem Status

requisitada

Gerenciamento de Analista de negócio 1 - João da Designado

projeto/Funcional Silva
Outro

Teste Controlador de teste 1 - José da Designado

Silva
Testadores 4 1 de maio A ser designado

Equipe de suporte de Programadores de 4 15 de maio A ser designado

teste suporte
Suporte técnico 1 1 de maio A ser designado
Suporte WAN 1 25 de maio A ser designado
A ser designado
Técnico - Externo Suporte CIS (Central IT 1 25 de maio A ser designado
Services – Serviços
Centrais de TI)
Suporte contábil 1 15 de maio A ser designado
Suporte de ligações 1 25 de maio João Designado
externas Carlos

Negócio Especialista do 1 1 de maio A ser designado

negócio/representante do
negócio

5.2. Hardware
Um sistema controlado, em separado, será necessário para a fase inicial de
teste, montado como um ambiente-padrão do negócio. Para manter a
integridade do ambiente de teste, sua rede não deve ser acessível a ninguém
de fora do projeto. As impressoras também devem ser exclusivamente para
uso da rede de teste.
Componentes de hardware requeridos

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

Especificações dos PCs requeridos para o ambiente de teste

1 x P100, 1Gb HD, 16Mb RAM [Especificação mínima atual]

3 x P166, 1.5Gb HD, 32Mb RAM [Especificação mínima atual]
1 x P333, 2.5Gb HD, 64Mb RAM [Especificação mínima atual]

1 Pentium com Windows NT também é necessário como centro de teste para

controlar e executar testes automatizados.

5.3. Software
Testar ambientes IMS
Testar ambientes IMS da região X é necessário para o teste de sistema. Dados
adicionais ou complementares serão fornecidos onde requerido.
Testar ambiente de software
O teste de sistema vai rodar nas seguintes versões de software:
Custom Desktop Versão 97.0.1
Windows 95
Visual Basic 5 Runtime Files
MS Office 97
Novell Netware

Sistema de medição 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. PAPÉIS E RESPONSABILIDADES
6.1. Equipe de gerenciamento
Líder do projeto – Sr. Thiago Lacerda
Assegurar que a fase 1 seja entregue dentro do cronograma, orçamento e
qualidade
Assegurar que os critérios de saída sejam alcançados antes do término 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 – Líder do projeto – Sr. Reynaldo

Giannechini
Assegurar que a fase 1 seja entregue dentro do cronograma, orçamento e
qualidade
Revisar regularmente o progresso do teste
Gerenciar assuntos/riscos relacionados à equipe de teste de sistema
Fornecer os recursos necessários 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, orçamento e
qualidade
Criar condições de teste detalhadas e de alto nível
Produzir os resultados esperados
 Reportar progressos em reuniões regulares de Status Report
Coordenar revisão e término das condições de teste
Gerenciar ciclos individuais de teste e resolver questões/problemas dos
testadores
Assegurar que os resultados/problemas do teste de sistema sejam
reportados imediatamente, e que o acompanhamento seja feito
Assegurar que os critérios de entrada sejam alcançados antes que o teste de
sistema inicie
Assegurar que os critérios de saída sejam alcançados antes do término do
teste

Testadores
Identificar dados de teste
Executar as condições de teste
Elaborar relatórios de erros de software
Administrar o sistema de medição de erros

6.3. Equipe de negócio

Analista de negócio – Sr. Keanu Reeves
Revisar planos detalhados e de alto nível para o teste de sistema
Definir procedimentos
Resolver assuntos de desenho
Resolver assuntos de negócio
Participar das reuniões diárias da equipe de revisão de erros

Representante do negócio – ?? (a ser designado)

Executar teste de aceitação do usuário
Definir condições de teste e resultados esperados para o teste de aceitação
do negócio
Resolver assuntos de usuário
Resolver assuntos de desenho

6.4. Equipe de suporte de teste

Programadores de suporte
Participar das reuniões diárias da equipe de revisão de erros
Coordenar e dar suporte ao teste de sistema
Resolver erros
Re-liberar software de teste depois de correções
Dar suporte aos testadores de sistema

6.5. Equipe de suporte externo

Suporte a serviços centrais de TI
Dar suporte a serviços centrais de TI, se necessário
Resolver questões de serviços centrais de TI, se necessário
Suporte IMS
Fornecer suporte ao teste de sistema
Dar suporte às regiões IMS
Resolver assuntos de soluções adaptadas ao sistema operacional, se
necessário
Fazer integração e conformidade contábil, se necessário
Resolver questões que surjam do backup remoto

Suporte contábil
Fornecer suporte técnico contábil, se necessário
Resolver questões, se necessário

Suporte técnico
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

configuração
Durante o teste de sistema, erros serão anotados em Relatórios de Erros, à
medida que forem detectados. Estes relatórios serão dados de entrada
colocados no final de cada dia no sistema de gerenciamento de erros, com o
status “erro levantado” ou “questão levantada”. A equipe de revisão de erros
vai se reunir todas as manhãs às 10h na sala de reuniões 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. Líder da equipe de desenvolvimento

 B. Analista de negócio
 C. Analista de teste
 D. Representante do negócio

Erros que foram concordados como válidos serão categorizados pela equipe de
revisão de erros da seguinte forma:

 Categoria A – Erros sérios que impeçam a continuidade do teste de

sistema de uma função em particular, ou graves erros de dados.
 Categoria B – Erros relativos a dados sérios ou faltantes que não
impeçam a implantação.
 Categoria C – Pequenos erros que não impedem nem afetam a
funcionalidade.

Erros da categoria A devem ser eliminados pela equipe de correções de bugs

em 48 horas (a contar da hora em que o erro for levantado na reunião da
equipe de revisão de erros até a correção ser liberada no ambiente do teste de
sistema). No caso de um erro de categoria A que impeça o teste de sistema de
continuar, a eliminação 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 liberação de novas versões do software devem ser coordenadas

com o analista de teste – novas versões devem somente ser liberadas quando
concordadas, e onde haja um benefício definitivo (por exemplo, que contenha
correções para um número X de bugs).

8. RELATÓRIO DE SITUAÇÃO
8.1. Relatório de Situação

A preparação de teste e o progresso de teste devem ser formalmente

reportados em uma reunião semanal de status. Quem deve comparecer a esta
reunião:

 Gerente do projeto
 Líder da equipe de desenho de negócio
 Líder da equipe de desenvolvimento

Um relatório de situação (status) deve ser preparado pelo analista de teste para
facilitar esta reunião. Este relatório deve conter as seguintes informações:

1. Satus atual X planejamento (Adiantado/Atrasado/No cronograma)

2. Progresso de tarefas planejadas da semana anterior
3. Tarefas planejadas para a próxima semana, incluindo tarefas
remanescentes da semana anterior
4. Estatística de erros do sistema de medição de erros
5. Questões/Riscos

9. Questões, riscos e premissas

9.1. Questões/riscos

1. Mudanças e inclusões não serão consideradas para esta versão, exceto: (1)
onde houver a permissão e a concordância expressas do analista de negócio e
do analista de teste; (2) onde as mudanças/inclusões não requeiram
significativo esforço da equipe de teste e não afetem o cronograma de teste.
Este é um assunto sério em potencial, pois qualquer grande mudança no
desenho vai requerer tempo adicional para re-planejar o teste e para criar
condições de teste suplementares.

Responsável: Byron Ruthlenn

Finalização da lista definitiva de inclusões.
2. O desenho do software deve ser final, e a documentação deve ser completa,
informativa e finalizada por todas as partes antes que o teste de sistema
comece.

Responsável: D. A. Stone

3. Uma fraqueza da abordagem (estratégia) da “entrega por fases” é que o alto

grau de interdependência no código significa que a menor mudança pode ter
sérios efeitos em áreas do aplicativo que aparentemente não mudaram. O
pressuposto da equipe de teste é que funcionalidades previamente entregues e
testadas somente requeiram testes de regressão para verificar que elas ainda
funcionam, ou seja, os testes não terão a intenção de descobrir novos erros.
Por isso recomendamos que haja um mínimo de dois dias de testes de
regressão DEPOIS que a correção final tenha sido re-testada. Isto, porém,
impõe uma restrição de tempo na finalização do período de testes, o que
requer a concordância do líder do projeto.

Responsável: Byron Ruthlenn

4. Teste automatizado
A maior parte dos testes de regressão 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, é provável
que o retorno apenas seja maximizado depois da terceira vez que o teste rodar
para cada liberação. Os outros principais usos da ferramenta de teste são: (1)
carregar o teste; (2) permitir teste por multi-usuários; (3) entrar dados
repetitivos.

Responsável: Analista de teste

9.2. Premissas

 O software será entregue no prazo

 O software terá a qualidade requisitada
 O software não será impactado por mudanças de conformidade Y2K
feitas na sua estrutura externa. Por exemplo, qualquer mudança externa
terá que ser compatível com este aplicativo
 Todos os bugs que possam travar o sistema receberão atenção imediata
da equipe de desenvolvimento
 Todos os bugs encontrados em uma versão do software serão
consertados e testados individualmente pela equipe de desenvolvimento
antes que uma nova versão seja liberada
 A funcionalidade é entregue no prazo
 Os recursos requeridos estarão disponíveis
 Todos os acordos de serviço serão cumpridos
 A ferramenta de teste automatizado vai funcionar e interagir
corretamente com o software
 Toda a documentação será atualizada e entregue à equipe de teste de
sistema
 Especificações funcionais e técnicas serão aprovadas pelo negócio
  A intranet vai estar completamente funcional antes que o projeto comece

10. Término formal

Este documento deve ser formalmente aprovado antes que o teste de sistema
possa começar. As seguintes pessoas devem assinar;

Assinaturas:
Gerente do projeto Byron Ruthlenn
SQA Colm Jones
Equipe de teste Dion Hais
Equipe de desenvolvimento Erwin Smith

11. APÊNDICES
11.1. Propósito da equipe de revisão de erros

Assegurar máxima eficiência das equipes de desenvolvimento e de teste de

sistema para a liberação do novo software através da cooperação de todas as
partes envolvidas.

Isto será alcançado através de reuniões diárias cujas funções serão:

 Classificar o status de cada erro levantado

 Priorizar os erros válidos
 Assegurar que documentação suficiente sobre os erros esteja
disponível
 Concordar sobre conteúdo e cronograma para liberações de
software no teste de sistema
 Assegurar uma fonte concordada de informação de reportação de
erro
 Identificar assuntos que possam afetar a performance do teste de
sistema

11.2. Pauta da reunião da equipe de revisão de erros

 Revisar ações da reunião anterior

 Classificar e priorizar cada erro
 Revisar erros para verificar duplicidade
 Concordar na prioridade de cada erro
 Determinar adequação de documentação associada a cada erro
levantado
 Concordar no conteúdo e cronograma de liberações
 Revisar ações designadas em reuniões anteriores
11.3. Classificação de bugs

1. Um bug "A" trava o sistema ou é de tal importância 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 usuário não consegue completar este aplicativo

- Dados incorretos são passados ao sistema resultado em corrompimento ou

travamento do sistema.

Exemplos de funcionalidade severamente afetada:

- Cálculo incorreto de pagamentos

- Produção incorreta de acordos de crédito

2. Bugs são classificados como "B"quando:

- Afetam um elemento menos importante da funcionalidade. Exemplo: um

default de um falor não está correto e precisa ser corrigido manualmente.

- Os dados afetados não têm um grande impacto. Exemplo: um dado de um

cliente não foi enviado corretamente para a base de dados.

- Existe um método alternativo para completar o processo. Exemplo: um

problema ao ler os detalhes de um crédito. Esta mudança pode ser entrada
manualmente.

3. Bugs do tipo "C" são inofensivos. Exemplos: falta de texto nas janelas de
ajuda, opções em duplicidade.

11.4. Procedimento para manutenção de sistema de registro de

erros

1. O controlador de teste deve passar qualquer grande erro/anomalia para o líder da equipe de
desenvolvimento ou seu representante designado, antes de fazer um registro formal do erro.
Isto tem algumas vantagens:
- Evita esforço desnecessário dos testadores
- Põe o desenvolvedor imediatamente a par do problema
- Permite que o desenvolvedor adicione mecanismos necessários para localizar o erro
2. Todos os bugs levantados devem estar nos corretos formulários de erro, e conter todas as
informações relevantes
3. O erro deve ser registrado no dia em que ocorrer, com o status 'LEVANTADO'
4. Deve haver uma reunião diária da equipe de suporte ao teste de sistema, para discutir,
priorizar e concordar em todos os erros registrados. Durante estas reuniões, 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 reunião.
Exemplo: duplicata, com programador, etc.
6. Uma vez que o erro foi consertado e estiver pronto para liberação, os formulários
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. Relatórios de status de erros devem ser produzidos pelo sistema de erros, para uso nas
reuniões da equipe de revisão de erros.

11.5. Processo noturno – checagem de contabilidade e sistemas

de informação computadorizados

Requisito de teste Itens a checar Nível de teste

Contabilidade
Quando a transferência de dados estiver completa, 1. Relatório de 1. Checagem em
relatório deve ser checado contra: legado nível de campo
1. Transações similares
2. Formulários de dados de entrada de teste X 2. Checagem em
nível de campo
Relatório de
transações do
escritório

2. Relatório

Formulários de
entrada
Depois de abrir/alterar, o relatório de alterações 1. Relatório de 1. Satisfazer as
deve ser checado contra: alterações razões para
1. Instruções de alterações rejeitadas rejeição
2. Dados de entrada correspondentes aos 2. Relatório de
formulários alterações 2. Checagem em
nível de campo
X

Formulários de
entrada de teste
Imprimir arquivos de contas e de clientes e checar Entradas da Checagem em
detalhes dos campos contra dados de entrada dos contabilidade nível de campo
formulários das filiais
X

Formulários de
entrada de teste
11.7. MEDIDAS DE GARANTIA DE QUALIDADE
DE SOFTWARE
(i) DATA

- Data de início do envolvimento da Garantia de Qualidade do Software

(ii) ESFORÇO

-Número de dias/homem da Garantia de Qualidade do Software para

planejamento de teste
-Número de dias/homem da Garantia de Qualidade do Software para revisão
dos planos de teste
-Número de dias/homem da Garantia de Qualidade do Software para executar
os testes

(iii) VOLUME

-Número de testes identificados

(iv) QUALIDADE

-Número de testes aprovados na primeira vez

-Porcentagem de testes aprovados na primeira vez
-Número de erros levantados durante o teste de regressão
-Número de erros gerados como resultado de consertos incorretos
-Número de erros levantados por categoria (A/B/C)
-Número de erros levantados por código de motivo
-Número de erros levantados por funções de negócio de alto nível

(v) TEMPO

- Tempo médio de conserto de erro

12. DOCUMENTAÇÃO DE CONTROLE

12.1. Formulário on-line de entrada de erro
12.2. Documentação de controle de checagem
12.3. Verificação & teste de saída
12.4. Formulário de entrada de erro não-consertado
12.5. Erros designados à equipe de desenvolvimento
12.6. Linhas de comunicação 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 correções de Erros

12.9.3 Fluxos de Status de Erros