Modelo plano de_testes

Modelo de um plano de testes
Qualidade e Teste de Software Página 1
Traduzido do link:
http://members.tripod.com/~bazman/frame.html
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:DataProjectPROJECT.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
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
a. Planejar o
projeto
b. Desenhar o
Teste de
Sistema
c.
Desenhar/Constru
ir procedimentos
de testes
d. Construir
ambiente de
teste
e. Executar o
teste de Sistema
f. Executar o
teste de Aceite
g. TERMINO

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 ser entregue*
v0.1
1 de maio
v0.2
17 de maio
v0.3
31 de maio
v0.4
18 de junho
v1.0
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
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 do teste de performance 1
 Resultados dos testes de regressão 1 e 2
 Resultados do teste técnico
4. Cronograma do Teste de Sistema
1. Planejar
o projeto
2. Desenhar
o Teste de
Sistema
3. Construir
procedimento
s de testes
4. Desenho
ambiente de
teste
5. Construir
o teste de
Sistema
6. Construir
o ambiente
de teste
7. Executar
o teste de
Sistema
8. Teste de
Integração
9. Inicia o
Teste Piloto
10. Término
e Revisão

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
requisitada
Quem Status
Gerenciamento de
projeto/Funcional
Analista de negócio 1 - João da
Silva
Outro
Designado
Teste Controlador de teste 1 - José da
Silva
Designado
Testadores 4 1 de maio A ser designado
Equipe de suporte de
teste
Programadores de
suporte
4 15 de maio A ser designado
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
Services – Serviços
Centrais de TI)
Suporte contábil 1 15 de maio A ser designado
Suporte de ligações
externas
1 25 de maio João
Carlos
Designado
Negócio Especialista do
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
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
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, relatório
deve ser checado contra:
1. Transações similares
2. Formulários de dados de entrada de teste
1. Relatório de legado
X
Relatório de
transações do
escritório
2. Relatório
X
1. Checagem em
nível de campo
2. Checagem em
nível de campo

Formulários de entrada
Depois de abrir/alterar, o relatório de alterações deve ser
checado contra:
1. Instruções de alterações rejeitadas
2. Dados de entrada correspondentes aos formulários
1. Relatório de
alterações
2. Relatório de
alterações
X
de teste
1. Satisfazer as
razões para rejeição
2. Checagem em
nível de campo
Imprimir arquivos de contas e de clientes e checar detalhes
dos campos contra dados de entrada dos formulários das
filiais
Entradas da
contabilidade
X
de teste
Checagem em nível
de campo
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

Modelo plano de_testes

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Modelo plano de_testes

Ähnlich wie Modelo plano de_testes (20)

Modelo plano de_testes