SlideShare uma empresa Scribd logo
Modelo de um plano de testes
Qualidade e Teste de Software Página 1
Modelo de um plano de testes
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.
Modelo de um plano de testes
Qualidade e Teste de Software Página 2
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
Modelo de um plano de testes
Qualidade e Teste de Software Página 3
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:
Modelo de um plano de testes
Qualidade e Teste de Software Página 4
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
Modelo de um plano de testes
Qualidade e Teste de Software Página 5
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
Modelo de um plano de testes
Qualidade e Teste de Software Página 6
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.
Modelo de um plano de testes
Qualidade e Teste de Software Página 7
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
Modelo de um plano de testes
Qualidade e Teste de Software Página 8
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.
Modelo de um plano de testes
Qualidade e Teste de Software Página 9
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 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
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
Modelo de um plano de testes
Qualidade e Teste de Software Página 10
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.
Modelo de um plano de testes
Qualidade e Teste de Software Página 11
Modelo de um plano de testes
Qualidade e Teste de Software Página 12
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)
1 25 de maio A ser designado
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
1 1 de maio A ser designado
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.
Modelo de um plano de testes
Qualidade e Teste de Software Página 13
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.
Modelo de um plano de testes
Qualidade e Teste de Software Página 14
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
Modelo de um plano de testes
Qualidade e Teste de Software Página 15
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
Modelo de um plano de testes
Qualidade e Teste de Software Página 16
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).
Modelo de um plano de testes
Qualidade e Teste de Software Página 17
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,
Modelo de um plano de testes
Qualidade e Teste de Software Página 18
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
Modelo de um plano de testes
Qualidade e Teste de Software Página 19
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:
Modelo de um plano de testes
Qualidade e Teste de Software Página 20
- 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
Modelo de um plano de testes
Qualidade e Teste de Software Página 21
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
Formulários de entrada
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
Formulários de entrada
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
Modelo de um plano de testes
Qualidade e Teste de Software Página 22
- 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
Modelo de um plano de testes
Qualidade e Teste de Software Página 23
12.9.3 Fluxos de Status de Erros

Mais conteúdo relacionado

Mais procurados

Exemplo de documento de requisitos
Exemplo de documento de requisitosExemplo de documento de requisitos
Exemplo de documento de requisitos
Leandro Rodrigues
 
Teste de software
Teste de softwareTeste de software
Teste de software
Rafael Sanches
 
Verificação, Validação e Teste de Software
Verificação, Validação e Teste de SoftwareVerificação, Validação e Teste de Software
Verificação, Validação e Teste de Software
Camilo Almendra
 
Introdução ao Teste de Software - Uma abordagem prática
Introdução ao Teste de Software - Uma abordagem práticaIntrodução ao Teste de Software - Uma abordagem prática
Introdução ao Teste de Software - Uma abordagem prática
Fabrício Campos
 
Papéis em Teste e Qualidade de Software
Papéis em Teste e Qualidade de SoftwarePapéis em Teste e Qualidade de Software
Papéis em Teste e Qualidade de Software
Camilo Ribeiro
 
Teste de Software
Teste de SoftwareTeste de Software
Teste de Software
Sérgio Souza Costa
 
Processo de Teste de Software - Monografia
Processo de Teste de Software - MonografiaProcesso de Teste de Software - Monografia
Processo de Teste de Software - Monografia
Rodrigo Kammers
 
Arquitetura básica de testes para seu projeto Java
Arquitetura básica de testes para seu projeto JavaArquitetura básica de testes para seu projeto Java
Arquitetura básica de testes para seu projeto Java
Elias Nogueira
 
Teste de software
Teste de softwareTeste de software
Teste de software
COTIC-PROEG (UFPA)
 
Teste de Software Introdução à Qualidade
Teste de Software Introdução à Qualidade Teste de Software Introdução à Qualidade
Teste de Software Introdução à Qualidade
Camilo Ribeiro
 
Qualidade de Software
Qualidade de SoftwareQualidade de Software
Qualidade de Software
Tiago Antônio da Silva
 
UML - Criando Diagramas Eficientes
UML - Criando Diagramas EficientesUML - Criando Diagramas Eficientes
UML - Criando Diagramas Eficientes
Rodrigo Cascarrolho
 
Testes Funcionais
Testes FuncionaisTestes Funcionais
Testes Funcionais
Juliana Maria Lopes
 
Introdução a Automação de Teste de Software
Introdução a Automação de Teste de SoftwareIntrodução a Automação de Teste de Software
Introdução a Automação de Teste de Software
Camilo Ribeiro
 
Aula 3 técnicas de teste de software1
Aula 3   técnicas de teste de software1Aula 3   técnicas de teste de software1
Aula 3 técnicas de teste de software1
Tiago Vizoto
 
Especificação de Requisitos de Software
Especificação de Requisitos de SoftwareEspecificação de Requisitos de Software
Especificação de Requisitos de Software
Ralph Rassweiler
 
Engenharia de Requisitos
Engenharia de RequisitosEngenharia de Requisitos
Engenharia de Requisitos
Cloves da Rocha
 
Planejamento de testes em um mundo ágil
Planejamento de testes em um mundo ágilPlanejamento de testes em um mundo ágil
Planejamento de testes em um mundo ágil
Ariane Izac
 
Ferramentas para testes de software
Ferramentas para testes de softwareFerramentas para testes de software
Ferramentas para testes de software
Norton Guimarães
 
Qualidade de software
Qualidade de softwareQualidade de software
Qualidade de software
Alvaro Oliveira
 

Mais procurados (20)

Exemplo de documento de requisitos
Exemplo de documento de requisitosExemplo de documento de requisitos
Exemplo de documento de requisitos
 
Teste de software
Teste de softwareTeste de software
Teste de software
 
Verificação, Validação e Teste de Software
Verificação, Validação e Teste de SoftwareVerificação, Validação e Teste de Software
Verificação, Validação e Teste de Software
 
Introdução ao Teste de Software - Uma abordagem prática
Introdução ao Teste de Software - Uma abordagem práticaIntrodução ao Teste de Software - Uma abordagem prática
Introdução ao Teste de Software - Uma abordagem prática
 
Papéis em Teste e Qualidade de Software
Papéis em Teste e Qualidade de SoftwarePapéis em Teste e Qualidade de Software
Papéis em Teste e Qualidade de Software
 
Teste de Software
Teste de SoftwareTeste de Software
Teste de Software
 
Processo de Teste de Software - Monografia
Processo de Teste de Software - MonografiaProcesso de Teste de Software - Monografia
Processo de Teste de Software - Monografia
 
Arquitetura básica de testes para seu projeto Java
Arquitetura básica de testes para seu projeto JavaArquitetura básica de testes para seu projeto Java
Arquitetura básica de testes para seu projeto Java
 
Teste de software
Teste de softwareTeste de software
Teste de software
 
Teste de Software Introdução à Qualidade
Teste de Software Introdução à Qualidade Teste de Software Introdução à Qualidade
Teste de Software Introdução à Qualidade
 
Qualidade de Software
Qualidade de SoftwareQualidade de Software
Qualidade de Software
 
UML - Criando Diagramas Eficientes
UML - Criando Diagramas EficientesUML - Criando Diagramas Eficientes
UML - Criando Diagramas Eficientes
 
Testes Funcionais
Testes FuncionaisTestes Funcionais
Testes Funcionais
 
Introdução a Automação de Teste de Software
Introdução a Automação de Teste de SoftwareIntrodução a Automação de Teste de Software
Introdução a Automação de Teste de Software
 
Aula 3 técnicas de teste de software1
Aula 3   técnicas de teste de software1Aula 3   técnicas de teste de software1
Aula 3 técnicas de teste de software1
 
Especificação de Requisitos de Software
Especificação de Requisitos de SoftwareEspecificação de Requisitos de Software
Especificação de Requisitos de Software
 
Engenharia de Requisitos
Engenharia de RequisitosEngenharia de Requisitos
Engenharia de Requisitos
 
Planejamento de testes em um mundo ágil
Planejamento de testes em um mundo ágilPlanejamento de testes em um mundo ágil
Planejamento de testes em um mundo ágil
 
Ferramentas para testes de software
Ferramentas para testes de softwareFerramentas para testes de software
Ferramentas para testes de software
 
Qualidade de software
Qualidade de softwareQualidade de software
Qualidade de software
 

Semelhante a Modelo plano de_testes

Es capítulo 2 - processos de software
Es   capítulo 2  - processos de softwareEs   capítulo 2  - processos de software
Es capítulo 2 - processos de software
Felipe Oliveira
 
Analise sistemas 05
Analise sistemas 05Analise sistemas 05
Analise sistemas 05
Caroline Raquel Rodrigues
 
Rational Unified Process (RUP)
Rational Unified Process (RUP)Rational Unified Process (RUP)
Rational Unified Process (RUP)
Carlos Henrique Martins da Silva
 
Teste de software - Processo de Verificação e Validação
Teste de software - Processo de Verificação e ValidaçãoTeste de software - Processo de Verificação e Validação
Teste de software - Processo de Verificação e Validação
Joeldson Costa Damasceno
 
Ciclo de vida processo
Ciclo de vida processoCiclo de vida processo
Ciclo de vida processo
Patrícia Melo
 
Introdução a Engenharia de Software - Prof.ª Cristiane Fidelix
Introdução a Engenharia de Software - Prof.ª Cristiane FidelixIntrodução a Engenharia de Software - Prof.ª Cristiane Fidelix
Introdução a Engenharia de Software - Prof.ª Cristiane Fidelix
Cris Fidelix
 
[Portfólio Acadêmico] [FIT] Mapas de navegação, lista de tarefas e fluxograma...
[Portfólio Acadêmico] [FIT] Mapas de navegação, lista de tarefas e fluxograma...[Portfólio Acadêmico] [FIT] Mapas de navegação, lista de tarefas e fluxograma...
[Portfólio Acadêmico] [FIT] Mapas de navegação, lista de tarefas e fluxograma...
Rafael Kanaoka
 
Metodologias Ageis
Metodologias AgeisMetodologias Ageis
Metodologias Ageis
MarcosMaozinha
 
Aula 01 - Introdução Engenharia de requisitos - Prof.ª Cristiane Fidelix
Aula 01 - Introdução Engenharia de requisitos - Prof.ª Cristiane FidelixAula 01 - Introdução Engenharia de requisitos - Prof.ª Cristiane Fidelix
Aula 01 - Introdução Engenharia de requisitos - Prof.ª Cristiane Fidelix
Cris Fidelix
 
Eng.ª do Software - 4. Processos de software
Eng.ª do Software - 4. Processos de softwareEng.ª do Software - 4. Processos de software
Eng.ª do Software - 4. Processos de software
Manuel Menezes de Sequeira
 
Gerenciamento da Qualidade de Software 4.pptx
Gerenciamento da Qualidade de Software 4.pptxGerenciamento da Qualidade de Software 4.pptx
Gerenciamento da Qualidade de Software 4.pptx
Roberto Nunes
 
Plano+de+gerenciamento+da+qualidadev exemplo
Plano+de+gerenciamento+da+qualidadev exemploPlano+de+gerenciamento+da+qualidadev exemplo
Plano+de+gerenciamento+da+qualidadev exemplo
Rudileine Fonseca
 
Plano+de+gerenciamento+da+qualidadev exemplo
Plano+de+gerenciamento+da+qualidadev exemploPlano+de+gerenciamento+da+qualidadev exemplo
Plano+de+gerenciamento+da+qualidadev exemplo
Rudileine Fonseca
 
ES4.ppt
ES4.pptES4.ppt
Aula9 TEES UFS Gestao de Configuração de SW
Aula9 TEES UFS  Gestao de Configuração de SWAula9 TEES UFS  Gestao de Configuração de SW
Aula9 TEES UFS Gestao de Configuração de SW
Rogerio P C do Nascimento
 
Gestão de Configuração de Software
Gestão de Configuração de Software Gestão de Configuração de Software
Gestão de Configuração de Software
Rogerio P C do Nascimento
 
Aula Gestão de Projetos
Aula Gestão de ProjetosAula Gestão de Projetos
Aula Gestão de Projetos
Rudson Kiyoshi Souza Carvalho
 
4 engenharia de software
4   engenharia de software4   engenharia de software
4 engenharia de software
Felipe Bugov
 
Este trabalho trata
Este trabalho trataEste trabalho trata
Este trabalho trata
Roni Reis
 
Capitulo 02 sommerville
Capitulo 02 sommervilleCapitulo 02 sommerville
Capitulo 02 sommerville
Fabricio Schlag
 

Semelhante a Modelo plano de_testes (20)

Es capítulo 2 - processos de software
Es   capítulo 2  - processos de softwareEs   capítulo 2  - processos de software
Es capítulo 2 - processos de software
 
Analise sistemas 05
Analise sistemas 05Analise sistemas 05
Analise sistemas 05
 
Rational Unified Process (RUP)
Rational Unified Process (RUP)Rational Unified Process (RUP)
Rational Unified Process (RUP)
 
Teste de software - Processo de Verificação e Validação
Teste de software - Processo de Verificação e ValidaçãoTeste de software - Processo de Verificação e Validação
Teste de software - Processo de Verificação e Validação
 
Ciclo de vida processo
Ciclo de vida processoCiclo de vida processo
Ciclo de vida processo
 
Introdução a Engenharia de Software - Prof.ª Cristiane Fidelix
Introdução a Engenharia de Software - Prof.ª Cristiane FidelixIntrodução a Engenharia de Software - Prof.ª Cristiane Fidelix
Introdução a Engenharia de Software - Prof.ª Cristiane Fidelix
 
[Portfólio Acadêmico] [FIT] Mapas de navegação, lista de tarefas e fluxograma...
[Portfólio Acadêmico] [FIT] Mapas de navegação, lista de tarefas e fluxograma...[Portfólio Acadêmico] [FIT] Mapas de navegação, lista de tarefas e fluxograma...
[Portfólio Acadêmico] [FIT] Mapas de navegação, lista de tarefas e fluxograma...
 
Metodologias Ageis
Metodologias AgeisMetodologias Ageis
Metodologias Ageis
 
Aula 01 - Introdução Engenharia de requisitos - Prof.ª Cristiane Fidelix
Aula 01 - Introdução Engenharia de requisitos - Prof.ª Cristiane FidelixAula 01 - Introdução Engenharia de requisitos - Prof.ª Cristiane Fidelix
Aula 01 - Introdução Engenharia de requisitos - Prof.ª Cristiane Fidelix
 
Eng.ª do Software - 4. Processos de software
Eng.ª do Software - 4. Processos de softwareEng.ª do Software - 4. Processos de software
Eng.ª do Software - 4. Processos de software
 
Gerenciamento da Qualidade de Software 4.pptx
Gerenciamento da Qualidade de Software 4.pptxGerenciamento da Qualidade de Software 4.pptx
Gerenciamento da Qualidade de Software 4.pptx
 
Plano+de+gerenciamento+da+qualidadev exemplo
Plano+de+gerenciamento+da+qualidadev exemploPlano+de+gerenciamento+da+qualidadev exemplo
Plano+de+gerenciamento+da+qualidadev exemplo
 
Plano+de+gerenciamento+da+qualidadev exemplo
Plano+de+gerenciamento+da+qualidadev exemploPlano+de+gerenciamento+da+qualidadev exemplo
Plano+de+gerenciamento+da+qualidadev exemplo
 
ES4.ppt
ES4.pptES4.ppt
ES4.ppt
 
Aula9 TEES UFS Gestao de Configuração de SW
Aula9 TEES UFS  Gestao de Configuração de SWAula9 TEES UFS  Gestao de Configuração de SW
Aula9 TEES UFS Gestao de Configuração de SW
 
Gestão de Configuração de Software
Gestão de Configuração de Software Gestão de Configuração de Software
Gestão de Configuração de Software
 
Aula Gestão de Projetos
Aula Gestão de ProjetosAula Gestão de Projetos
Aula Gestão de Projetos
 
4 engenharia de software
4   engenharia de software4   engenharia de software
4 engenharia de software
 
Este trabalho trata
Este trabalho trataEste trabalho trata
Este trabalho trata
 
Capitulo 02 sommerville
Capitulo 02 sommervilleCapitulo 02 sommerville
Capitulo 02 sommerville
 

Último

Segurança Digital Pessoal e Boas Práticas
Segurança Digital Pessoal e Boas PráticasSegurança Digital Pessoal e Boas Práticas
Segurança Digital Pessoal e Boas Práticas
Danilo Pinotti
 
História da Rádio- 1936-1970 século XIX .2.pptx
História da Rádio- 1936-1970 século XIX   .2.pptxHistória da Rádio- 1936-1970 século XIX   .2.pptx
História da Rádio- 1936-1970 século XIX .2.pptx
TomasSousa7
 
Guardioes Digitais em ação: Como criar senhas seguras!
Guardioes Digitais em ação: Como criar senhas seguras!Guardioes Digitais em ação: Como criar senhas seguras!
Guardioes Digitais em ação: Como criar senhas seguras!
Jonathas Muniz
 
Logica de Progamacao - Aula (1) (1).pptx
Logica de Progamacao - Aula (1) (1).pptxLogica de Progamacao - Aula (1) (1).pptx
Logica de Progamacao - Aula (1) (1).pptx
Momento da Informática
 
TOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdf
TOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdfTOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdf
TOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdf
Momento da Informática
 
Escola Virtual - Fundação Bradesco - ITIL - Gabriel Faustino.pdf
Escola Virtual - Fundação Bradesco - ITIL - Gabriel Faustino.pdfEscola Virtual - Fundação Bradesco - ITIL - Gabriel Faustino.pdf
Escola Virtual - Fundação Bradesco - ITIL - Gabriel Faustino.pdf
Gabriel de Mattos Faustino
 
PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...
PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...
PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...
Faga1939
 

Último (7)

Segurança Digital Pessoal e Boas Práticas
Segurança Digital Pessoal e Boas PráticasSegurança Digital Pessoal e Boas Práticas
Segurança Digital Pessoal e Boas Práticas
 
História da Rádio- 1936-1970 século XIX .2.pptx
História da Rádio- 1936-1970 século XIX   .2.pptxHistória da Rádio- 1936-1970 século XIX   .2.pptx
História da Rádio- 1936-1970 século XIX .2.pptx
 
Guardioes Digitais em ação: Como criar senhas seguras!
Guardioes Digitais em ação: Como criar senhas seguras!Guardioes Digitais em ação: Como criar senhas seguras!
Guardioes Digitais em ação: Como criar senhas seguras!
 
Logica de Progamacao - Aula (1) (1).pptx
Logica de Progamacao - Aula (1) (1).pptxLogica de Progamacao - Aula (1) (1).pptx
Logica de Progamacao - Aula (1) (1).pptx
 
TOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdf
TOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdfTOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdf
TOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdf
 
Escola Virtual - Fundação Bradesco - ITIL - Gabriel Faustino.pdf
Escola Virtual - Fundação Bradesco - ITIL - Gabriel Faustino.pdfEscola Virtual - Fundação Bradesco - ITIL - Gabriel Faustino.pdf
Escola Virtual - Fundação Bradesco - ITIL - Gabriel Faustino.pdf
 
PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...
PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...
PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...
 

Modelo plano de_testes

  • 1. Modelo de um plano de testes Qualidade e Teste de Software Página 1 Modelo de um plano de testes 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.
  • 2. Modelo de um plano de testes Qualidade e Teste de Software Página 2 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
  • 3. Modelo de um plano de testes Qualidade e Teste de Software Página 3 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:
  • 4. Modelo de um plano de testes Qualidade e Teste de Software Página 4 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
  • 5. Modelo de um plano de testes Qualidade e Teste de Software Página 5 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
  • 6. Modelo de um plano de testes Qualidade e Teste de Software Página 6 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.
  • 7. Modelo de um plano de testes Qualidade e Teste de Software Página 7 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
  • 8. Modelo de um plano de testes Qualidade e Teste de Software Página 8 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.
  • 9. Modelo de um plano de testes Qualidade e Teste de Software Página 9 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 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 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
  • 10. Modelo de um plano de testes Qualidade e Teste de Software Página 10 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.
  • 11. Modelo de um plano de testes Qualidade e Teste de Software Página 11
  • 12. Modelo de um plano de testes Qualidade e Teste de Software Página 12 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) 1 25 de maio A ser designado 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 1 1 de maio A ser designado 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.
  • 13. Modelo de um plano de testes Qualidade e Teste de Software Página 13 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.
  • 14. Modelo de um plano de testes Qualidade e Teste de Software Página 14 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
  • 15. Modelo de um plano de testes Qualidade e Teste de Software Página 15 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
  • 16. Modelo de um plano de testes Qualidade e Teste de Software Página 16 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).
  • 17. Modelo de um plano de testes Qualidade e Teste de Software Página 17 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,
  • 18. Modelo de um plano de testes Qualidade e Teste de Software Página 18 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
  • 19. Modelo de um plano de testes Qualidade e Teste de Software Página 19 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:
  • 20. Modelo de um plano de testes Qualidade e Teste de Software Página 20 - 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
  • 21. Modelo de um plano de testes Qualidade e Teste de Software Página 21 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 Formulários de entrada 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 Formulários de entrada 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
  • 22. Modelo de um plano de testes Qualidade e Teste de Software Página 22 - 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
  • 23. Modelo de um plano de testes Qualidade e Teste de Software Página 23 12.9.3 Fluxos de Status de Erros