SlideShare uma empresa Scribd logo
Marcello A. Lima
marcello.a.lima@hsbc.com.br

            Apoio
Um plano de testes documenta a
estratégiaqueseráusadaparaverificar e
assegurarque um produtoousistema segue as
especificações e outrosrequisitos. O plano de
testes é
normalmentepreparadopeloengenheiro de
testes.
 ◦ A test plan documents the strategy that will be used to verify and ensure
   that a product or system meets its design specifications and other
   requirements. A test plan is usually prepared by or with significant input
   from Test Engineers. (Wikipedia)
                             http://en.wikipedia.org/wiki/Test_plan
•   Test plan identifier
•   Introduction
•   Test items
•   Features to be tested
•   Features not to be tested
•   Approach
•   Item pass/fail criteria
•   Suspension criteria and resumption requirements
•   Test deliverables
•   Testing tasks
•   Environmental needs
•   Responsibilities
•   Staffing and training needs
•   Schedule
•   Risks and contingencies
•   Approvals
Auxilia a organizar as versões tanto de software
como de testware.
Algumas informações importantes que devem
constar ao se identificar um plano de testes:
   •Nome breve do TestPlan (Unique Short Name)

   •Data e número da versão

   •Autor e informações de Contato

   •Histórico de revisões
Descreve o propósito do plano de testes.
Essencialmente é o sumário executivo do plano
de testes.
Pode incluir referências a outros planos e
documentos, descrição do projeto, etc.
São os itens que estão dentro do escopo do
plano de testes.
Pode se basear em:
 Requerimentos
 Especificações de Design
 Manuais de usuário
 Manuais ou guias de operação
 Procedimentos ou manuais de instalação
Define o que deve ser testado do ponto de vista
do USUÁRIO.
Não é uma descrição técnica do sistema, mas
sim o ponto de vista do usuário sobre cada
funcionalidade.
Determina o nível de risco de cada
funcionalidade do ponto de vista do usuário
(Alto, Médio, Baixo).
Define o que não deve ser testado do ponto de
vista do USUÁRIO.
Identifique o porque de não se testar algo.
Deve ser a estratégia para o plano de testes.
Regras e processos devem ser identificados.
Como serão feitos os testes de Regressão,
reuniões, métricas e outros itens importantes
para os testes.
Quais serão os critérios para finalização dos
testes?
O Objetivo é identificar quando um item passou
ou não no processo de testes.
Descreve em que circustâncias os testes devem
ser suspensos e quando os mesmos podem ser
reiniciados.
Define o que será entregue pela fase de testes.
Ex.:
 TestPlan
 Especificações de Design
 Especificações de Testes
 Procedimentos de Testes
 Scripts
 Etc.
Define as atividades para cada entregável
(deliverable)
As atividades devem ter atividades
correspondentes e milestonesno cronograma
do projeto.
Define os requisitos para o ambiente de testes
como por exemplo:
  Hardware
  Software
  SO’s
  Ferramentas
  Segurança
  Etc.
Define Quem Faz o Quê.
Ex.:
 Determinar Riscos
 Prover o treinamento necessário
 Quem toma a decisão go/no go
 Etc.
Identifica as necessidades críticas de
treinamento dos recursos.
Ex.:
Treinamento no produto
Treinamento nas ferramentas necessárias
Define o cronograma dos testes.
Deve ser realista e ter suas estimativas
validadas. Se a estimativa para desenvolvimento
da aplicação é imprecisa, todo o projeto pode
ser afetado, inclusive seus testes.
Define os riscos do projeto dando ênfase ao
processo de testes.
Ex.:
 Falta de recursos para testes
 Indisponibilidade de ferramentas, hardware
  ou software
 Entrega tardia
 Etc.
Define quem pode aprovar o processo como
completo e permitir que o projeto passe para a
próxima etapa.
www.realtesting.com.br
Serviços

 Treinamentos especializados em qualidade e teste
de software
 Parceria com a TestAnywhere:
    Consultoria
    Outsourcing (terceirização de serviços)
    Revenda oficial da AutomatedQA
  (TestComplete)
Treinamentos

 Diagnóstico
 Capacitação em teste de software
 Avaliação de Usabilidade
 Automação de Testes Funcionais
 Testes de Performance e Stress
  Teste de Software Avançado: Gestão de teste e
modelagem de processos de testes com
ferramentas Open Source
 Preparatório Oficial da Certificação Brasileira de
Teste de Software - CBTS
Contato




     Tatiana Gonzaga
contato@realtesting.com.br
mans.lima@gmail.com

Mais conteúdo relacionado

Mais procurados

Teste de software
Teste de softwareTeste de software
Teste de software
COTIC-PROEG (UFPA)
 
Pesquisa Ferramentas e Gestão de Testes de Software
Pesquisa Ferramentas e Gestão de Testes de SoftwarePesquisa Ferramentas e Gestão de Testes de Software
Pesquisa Ferramentas e Gestão de Testes de Software
João Júnior
 
Teste de software
Teste de softwareTeste de software
Teste de software
Daniel Paulo de Assis
 
4 engenharia de software
4   engenharia de software4   engenharia de software
4 engenharia de software
Felipe Bugov
 
Testes de software
Testes de softwareTestes de software
Testes de software
teste
 
Validação e Testes de software
Validação e Testes de softwareValidação e Testes de software
Validação e Testes de software
Rondinelli Mesquita
 
Implantação de um Processo de Teste de Software - Randerson Melville
Implantação de um Processo de Teste de Software - Randerson Melville Implantação de um Processo de Teste de Software - Randerson Melville
Implantação de um Processo de Teste de Software - Randerson Melville
minastestingconference
 
Testes Funcionais
Testes FuncionaisTestes Funcionais
Testes Funcionais
Juliana Maria Lopes
 
Teste de Software
Teste de SoftwareTeste de Software
Teste de Software
Wagner Zaparoli
 
Fundamentos de Testes de Software
Fundamentos de Testes de SoftwareFundamentos de Testes de Software
Fundamentos de Testes de Software
Álvaro Farias Pinheiro
 
Palestra Teste de Software: princípios, ferramentas e carreira
Palestra Teste de Software: princípios, ferramentas e carreiraPalestra Teste de Software: princípios, ferramentas e carreira
Palestra Teste de Software: princípios, ferramentas e carreira
Taís Dall'Oca
 
Palestra Fundamentos de Testes - Tche linux POA
Palestra Fundamentos de Testes  - Tche linux POAPalestra Fundamentos de Testes  - Tche linux POA
Palestra Fundamentos de Testes - Tche linux POA
Aline Zanin
 
Teste de software
Teste de softwareTeste de software
Teste de software
Rafael Sanches
 
Teste de Aceitação: problemas, desafios e abordagens
Teste de Aceitação: problemas, desafios e abordagensTeste de Aceitação: problemas, desafios e abordagens
Teste de Aceitação: problemas, desafios e abordagens
Synergia - Engenharia de Software e Sistemas
 
Testes Funcionais - Unidade IV
Testes Funcionais - Unidade IVTestes Funcionais - Unidade IV
Testes Funcionais - Unidade IV
João Lourenço
 
Testes De Software - Uma Visão Geral
Testes De Software - Uma Visão GeralTestes De Software - Uma Visão Geral
Testes De Software - Uma Visão Geral
paulo peres
 
Introdução a Testes de Software - Unidade I
Introdução a Testes de Software - Unidade IIntrodução a Testes de Software - Unidade I
Introdução a Testes de Software - Unidade I
João Lourenço
 
OS FUNDAMENTOS DE TESTE DE SOFTWARE E SUA IMPORTÂNCIA NA QUALIDADE DE PROJETOS
OS FUNDAMENTOS DE TESTE DE SOFTWARE E SUA IMPORTÂNCIA NA QUALIDADE DE PROJETOSOS FUNDAMENTOS DE TESTE DE SOFTWARE E SUA IMPORTÂNCIA NA QUALIDADE DE PROJETOS
OS FUNDAMENTOS DE TESTE DE SOFTWARE E SUA IMPORTÂNCIA NA QUALIDADE DE PROJETOS
Luiz Ladeira
 
Teste Regressão
Teste RegressãoTeste Regressão
Teste Regressão
elliando dias
 
Teste de Software
Teste de SoftwareTeste de Software
Teste de Software
Sérgio Souza Costa
 

Mais procurados (20)

Teste de software
Teste de softwareTeste de software
Teste de software
 
Pesquisa Ferramentas e Gestão de Testes de Software
Pesquisa Ferramentas e Gestão de Testes de SoftwarePesquisa Ferramentas e Gestão de Testes de Software
Pesquisa Ferramentas e Gestão de Testes de Software
 
Teste de software
Teste de softwareTeste de software
Teste de software
 
4 engenharia de software
4   engenharia de software4   engenharia de software
4 engenharia de software
 
Testes de software
Testes de softwareTestes de software
Testes de software
 
Validação e Testes de software
Validação e Testes de softwareValidação e Testes de software
Validação e Testes de software
 
Implantação de um Processo de Teste de Software - Randerson Melville
Implantação de um Processo de Teste de Software - Randerson Melville Implantação de um Processo de Teste de Software - Randerson Melville
Implantação de um Processo de Teste de Software - Randerson Melville
 
Testes Funcionais
Testes FuncionaisTestes Funcionais
Testes Funcionais
 
Teste de Software
Teste de SoftwareTeste de Software
Teste de Software
 
Fundamentos de Testes de Software
Fundamentos de Testes de SoftwareFundamentos de Testes de Software
Fundamentos de Testes de Software
 
Palestra Teste de Software: princípios, ferramentas e carreira
Palestra Teste de Software: princípios, ferramentas e carreiraPalestra Teste de Software: princípios, ferramentas e carreira
Palestra Teste de Software: princípios, ferramentas e carreira
 
Palestra Fundamentos de Testes - Tche linux POA
Palestra Fundamentos de Testes  - Tche linux POAPalestra Fundamentos de Testes  - Tche linux POA
Palestra Fundamentos de Testes - Tche linux POA
 
Teste de software
Teste de softwareTeste de software
Teste de software
 
Teste de Aceitação: problemas, desafios e abordagens
Teste de Aceitação: problemas, desafios e abordagensTeste de Aceitação: problemas, desafios e abordagens
Teste de Aceitação: problemas, desafios e abordagens
 
Testes Funcionais - Unidade IV
Testes Funcionais - Unidade IVTestes Funcionais - Unidade IV
Testes Funcionais - Unidade IV
 
Testes De Software - Uma Visão Geral
Testes De Software - Uma Visão GeralTestes De Software - Uma Visão Geral
Testes De Software - Uma Visão Geral
 
Introdução a Testes de Software - Unidade I
Introdução a Testes de Software - Unidade IIntrodução a Testes de Software - Unidade I
Introdução a Testes de Software - Unidade I
 
OS FUNDAMENTOS DE TESTE DE SOFTWARE E SUA IMPORTÂNCIA NA QUALIDADE DE PROJETOS
OS FUNDAMENTOS DE TESTE DE SOFTWARE E SUA IMPORTÂNCIA NA QUALIDADE DE PROJETOSOS FUNDAMENTOS DE TESTE DE SOFTWARE E SUA IMPORTÂNCIA NA QUALIDADE DE PROJETOS
OS FUNDAMENTOS DE TESTE DE SOFTWARE E SUA IMPORTÂNCIA NA QUALIDADE DE PROJETOS
 
Teste Regressão
Teste RegressãoTeste Regressão
Teste Regressão
 
Teste de Software
Teste de SoftwareTeste de Software
Teste de Software
 

Semelhante a Plano de testes

Aula 8 - Plano de Teste.pptx
Aula 8 - Plano de Teste.pptxAula 8 - Plano de Teste.pptx
Aula 8 - Plano de Teste.pptx
AlexandreLisboadaSil
 
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
 
Visão de Testes de Software segundo o SWEBOK
Visão de Testes de Software segundo o SWEBOKVisão de Testes de Software segundo o SWEBOK
Visão de Testes de Software segundo o SWEBOK
Mário Pravato Junior
 
Planificação do Projeto de Software
Planificação do Projeto de SoftwarePlanificação do Projeto de Software
Planificação do Projeto de Software
Rogerio P C do Nascimento
 
11 1 --teste_de_software_motivação_e_conceitos_basicos
11 1 --teste_de_software_motivação_e_conceitos_basicos11 1 --teste_de_software_motivação_e_conceitos_basicos
11 1 --teste_de_software_motivação_e_conceitos_basicos
Fabricio Guimaraes Soares
 
Teste de Software - Introdução
Teste de Software - IntroduçãoTeste de Software - Introdução
Teste de Software - Introdução
Joeldson Costa Damasceno
 
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
 
Semana da informática - Qualidade e Teste de Software
Semana da informática - Qualidade e Teste de SoftwareSemana da informática - Qualidade e Teste de Software
Semana da informática - Qualidade e Teste de Software
Douglas Coutinho, CTFL
 
Ciclo de vida de testes implementado v2
Ciclo de vida de testes implementado   v2Ciclo de vida de testes implementado   v2
Ciclo de vida de testes implementado v2
douglasdc7m
 
3 engenharia de software
3   engenharia de software3   engenharia de software
3 engenharia de software
Felipe Bugov
 
Qualidade
QualidadeQualidade
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
 
Gestão de Projetos e Programas - Aula # 10
Gestão de Projetos e Programas - Aula # 10Gestão de Projetos e Programas - Aula # 10
Gestão de Projetos e Programas - Aula # 10
Ethel Capuano
 
Palestra ALATS SP - FIAP Teste de Software
Palestra ALATS SP - FIAP  Teste de SoftwarePalestra ALATS SP - FIAP  Teste de Software
Palestra ALATS SP - FIAP Teste de Software
Elias Nogueira
 
Uma Metodologia Para Teste De Software No Contexto Da Melhoria De Processo
Uma Metodologia Para Teste De Software No Contexto Da Melhoria De ProcessoUma Metodologia Para Teste De Software No Contexto Da Melhoria De Processo
Uma Metodologia Para Teste De Software No Contexto Da Melhoria De Processo
crc1404
 
Introdução a automação de testes - 5º Congresso Online de TI
Introdução a automação de testes - 5º Congresso Online de TIIntrodução a automação de testes - 5º Congresso Online de TI
Introdução a automação de testes - 5º Congresso Online de TI
Rafael Amaral
 
Fundamentos e Carreira em Teste de Software (Aula Magna UniSalesiano)
Fundamentos e Carreira em Teste de Software (Aula Magna UniSalesiano)Fundamentos e Carreira em Teste de Software (Aula Magna UniSalesiano)
Fundamentos e Carreira em Teste de Software (Aula Magna UniSalesiano)
Júlio de Lima
 
Modelo plano de_testes
Modelo plano de_testesModelo plano de_testes
Modelo plano de_testes
Isaias Silva
 
Maturidade em automação de testes
Maturidade em automação de testesMaturidade em automação de testes
Maturidade em automação de testes
Cristiano Caetano
 
Engenharia de Requisitos - Aula 2
Engenharia de Requisitos - Aula 2Engenharia de Requisitos - Aula 2
Engenharia de Requisitos - Aula 2
Tiago Barros
 

Semelhante a Plano de testes (20)

Aula 8 - Plano de Teste.pptx
Aula 8 - Plano de Teste.pptxAula 8 - Plano de Teste.pptx
Aula 8 - Plano de Teste.pptx
 
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
 
Visão de Testes de Software segundo o SWEBOK
Visão de Testes de Software segundo o SWEBOKVisão de Testes de Software segundo o SWEBOK
Visão de Testes de Software segundo o SWEBOK
 
Planificação do Projeto de Software
Planificação do Projeto de SoftwarePlanificação do Projeto de Software
Planificação do Projeto de Software
 
11 1 --teste_de_software_motivação_e_conceitos_basicos
11 1 --teste_de_software_motivação_e_conceitos_basicos11 1 --teste_de_software_motivação_e_conceitos_basicos
11 1 --teste_de_software_motivação_e_conceitos_basicos
 
Teste de Software - Introdução
Teste de Software - IntroduçãoTeste de Software - Introdução
Teste de Software - Introdução
 
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
 
Semana da informática - Qualidade e Teste de Software
Semana da informática - Qualidade e Teste de SoftwareSemana da informática - Qualidade e Teste de Software
Semana da informática - Qualidade e Teste de Software
 
Ciclo de vida de testes implementado v2
Ciclo de vida de testes implementado   v2Ciclo de vida de testes implementado   v2
Ciclo de vida de testes implementado v2
 
3 engenharia de software
3   engenharia de software3   engenharia de software
3 engenharia de software
 
Qualidade
QualidadeQualidade
Qualidade
 
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
 
Gestão de Projetos e Programas - Aula # 10
Gestão de Projetos e Programas - Aula # 10Gestão de Projetos e Programas - Aula # 10
Gestão de Projetos e Programas - Aula # 10
 
Palestra ALATS SP - FIAP Teste de Software
Palestra ALATS SP - FIAP  Teste de SoftwarePalestra ALATS SP - FIAP  Teste de Software
Palestra ALATS SP - FIAP Teste de Software
 
Uma Metodologia Para Teste De Software No Contexto Da Melhoria De Processo
Uma Metodologia Para Teste De Software No Contexto Da Melhoria De ProcessoUma Metodologia Para Teste De Software No Contexto Da Melhoria De Processo
Uma Metodologia Para Teste De Software No Contexto Da Melhoria De Processo
 
Introdução a automação de testes - 5º Congresso Online de TI
Introdução a automação de testes - 5º Congresso Online de TIIntrodução a automação de testes - 5º Congresso Online de TI
Introdução a automação de testes - 5º Congresso Online de TI
 
Fundamentos e Carreira em Teste de Software (Aula Magna UniSalesiano)
Fundamentos e Carreira em Teste de Software (Aula Magna UniSalesiano)Fundamentos e Carreira em Teste de Software (Aula Magna UniSalesiano)
Fundamentos e Carreira em Teste de Software (Aula Magna UniSalesiano)
 
Modelo plano de_testes
Modelo plano de_testesModelo plano de_testes
Modelo plano de_testes
 
Maturidade em automação de testes
Maturidade em automação de testesMaturidade em automação de testes
Maturidade em automação de testes
 
Engenharia de Requisitos - Aula 2
Engenharia de Requisitos - Aula 2Engenharia de Requisitos - Aula 2
Engenharia de Requisitos - Aula 2
 

Plano de testes

  • 2. Um plano de testes documenta a estratégiaqueseráusadaparaverificar e assegurarque um produtoousistema segue as especificações e outrosrequisitos. O plano de testes é normalmentepreparadopeloengenheiro de testes. ◦ A test plan documents the strategy that will be used to verify and ensure that a product or system meets its design specifications and other requirements. A test plan is usually prepared by or with significant input from Test Engineers. (Wikipedia) http://en.wikipedia.org/wiki/Test_plan
  • 3. Test plan identifier • Introduction • Test items • Features to be tested • Features not to be tested • Approach • Item pass/fail criteria • Suspension criteria and resumption requirements • Test deliverables • Testing tasks • Environmental needs • Responsibilities • Staffing and training needs • Schedule • Risks and contingencies • Approvals
  • 4. Auxilia a organizar as versões tanto de software como de testware. Algumas informações importantes que devem constar ao se identificar um plano de testes: •Nome breve do TestPlan (Unique Short Name) •Data e número da versão •Autor e informações de Contato •Histórico de revisões
  • 5. Descreve o propósito do plano de testes. Essencialmente é o sumário executivo do plano de testes. Pode incluir referências a outros planos e documentos, descrição do projeto, etc.
  • 6. São os itens que estão dentro do escopo do plano de testes. Pode se basear em:  Requerimentos  Especificações de Design  Manuais de usuário  Manuais ou guias de operação  Procedimentos ou manuais de instalação
  • 7. Define o que deve ser testado do ponto de vista do USUÁRIO. Não é uma descrição técnica do sistema, mas sim o ponto de vista do usuário sobre cada funcionalidade. Determina o nível de risco de cada funcionalidade do ponto de vista do usuário (Alto, Médio, Baixo).
  • 8. Define o que não deve ser testado do ponto de vista do USUÁRIO. Identifique o porque de não se testar algo.
  • 9. Deve ser a estratégia para o plano de testes. Regras e processos devem ser identificados. Como serão feitos os testes de Regressão, reuniões, métricas e outros itens importantes para os testes.
  • 10. Quais serão os critérios para finalização dos testes? O Objetivo é identificar quando um item passou ou não no processo de testes.
  • 11. Descreve em que circustâncias os testes devem ser suspensos e quando os mesmos podem ser reiniciados.
  • 12. Define o que será entregue pela fase de testes. Ex.:  TestPlan  Especificações de Design  Especificações de Testes  Procedimentos de Testes  Scripts  Etc.
  • 13. Define as atividades para cada entregável (deliverable) As atividades devem ter atividades correspondentes e milestonesno cronograma do projeto.
  • 14. Define os requisitos para o ambiente de testes como por exemplo:  Hardware  Software  SO’s  Ferramentas  Segurança  Etc.
  • 15. Define Quem Faz o Quê. Ex.:  Determinar Riscos  Prover o treinamento necessário  Quem toma a decisão go/no go  Etc.
  • 16. Identifica as necessidades críticas de treinamento dos recursos. Ex.: Treinamento no produto Treinamento nas ferramentas necessárias
  • 17. Define o cronograma dos testes. Deve ser realista e ter suas estimativas validadas. Se a estimativa para desenvolvimento da aplicação é imprecisa, todo o projeto pode ser afetado, inclusive seus testes.
  • 18. Define os riscos do projeto dando ênfase ao processo de testes. Ex.:  Falta de recursos para testes  Indisponibilidade de ferramentas, hardware ou software  Entrega tardia  Etc.
  • 19. Define quem pode aprovar o processo como completo e permitir que o projeto passe para a próxima etapa.
  • 21. Serviços Treinamentos especializados em qualidade e teste de software Parceria com a TestAnywhere: Consultoria Outsourcing (terceirização de serviços) Revenda oficial da AutomatedQA (TestComplete)
  • 22. Treinamentos Diagnóstico Capacitação em teste de software Avaliação de Usabilidade Automação de Testes Funcionais Testes de Performance e Stress Teste de Software Avançado: Gestão de teste e modelagem de processos de testes com ferramentas Open Source Preparatório Oficial da Certificação Brasileira de Teste de Software - CBTS
  • 23. Contato Tatiana Gonzaga contato@realtesting.com.br

Notas do Editor

  1. Esteja preparado para discutir por que um determinado nível de risco foi determinado.
  2. Identify WHY the feature is not to be tested, there can be any number of reasons.• Not to be included in this release of the Software.• Low risk, has been used before and is considered stable.• Will be released but not tested or documented as a functional part of the release ofthis version of the software.
  3. Are any special tools to be used and what are they?• Will the tool require special training?• What metrics will be collected?• Which level is each metric to be collected at?• How is Configuration Management to be handled?• How many different configurations will be tested• Hardware• Software• Combinations of HW, SW and other vendor packages• What are the regression test rules? How much will be done and how much at each testlevel.• Will regression testing be based on severity of defects detected?• How will elements in the requirements and design that do not make sense or areuntestable be processed?• If this is a master test plan the overall project testing approach and coveragerequirements must also be identified.• Specify if there are special requirements for the testing.• Only the full component will be tested.• A specified segment of grouping of features/components must be tested together.©2001 - Software Quality Engineering - Version 7.0A - 9• Other information that may be useful in setting the approach are:• MTBF, Mean Time Between Failures - if this is a valid measurement for the testinvolved and if the data is available.• SRE, Software Reliability Engineering - if this methodology is in use and if theinformation is available.• How will meetings and other organizational processes be handled.• Are there any significant constraints to testing.• Resource availability• Deadlines• Are there any recommended testing techniques that should be used, if so why?
  4. What are the Completion criteria for this plan? This is a critical aspect of any test planand should be appropriate to the level of the plan. The goal is to identify whether or not a testitem has passed the test process.• At the Unit test level this could be items such as:• All test cases completed.• A specified percentage of cases completed with a percentage containing somenumber of minor defects.• Code coverage tool indicates all code covered.• At the Master test plan level this could be items such as:• All lower level plans completed.• A specified number of plans completed without errors and a percentage withminor defects.• This could be an individual test case level criterion or a unit level plan or it can begeneral functional requirements for higher level plans.• What is the number and severity of defects located?• Is it possible to compare this to the total number of defects? This may be impossible,as some defects are never detected.• A defect is something that may cause a failure, and may be acceptable to leave in theapplication.• A failure is the result of a defect as seen by the User, the system crashes, etc.
  5. Suspension Criteria and Resumption RequirementsKnow when to pause in a series of tests or possibly terminate a set of tests. Once testingis suspended how is it resumed and what are the potential impacts, (i.e. regression tests).If the number or type of defects reaches a point where the follow on testing has no value,it makes no sense to continue the test; you are just wasting resources.©2001 - Software Quality Engineering - Version 7.0A - 10• Specify what constitutes stoppage for a test or series of tests and what is theacceptable level of defects that will allow the testing to proceed past the defects.• Testing after a truly fatal error will generate conditions that may be identified asdefects but are in fact ghost errors caused by the earlier defects that were ignored.
  6. What is to be delivered as part of this plan?• Test plan• Test design specifications.• Test case specifications• Test procedure specifications• Test item transmittal reports• Test logs• Test Incident Reports• Test Summary reports• Test Incident reportsTest data can also be considered a deliverable as well as possible test tools to aid in thetesting processOne thing that is not a test deliverable is the software; that is listed under test items and isdelivered by development.These items need to be identified in the overall project plan as deliverables (milestones)and should have the appropriate resources assigned to them in the project tracking system.This will ensure that the test process has visibility within the overall project tracking processand that the test tasks to create these deliverables are started at the appropriate time. Anydependencies between these deliverables and their related software deliverable should beidentified.
  7. Test TasksThere should be tasks identified for each test deliverable. Include all inter-taskdependencies, skill levels, etc. These tasks should also have corresponding tasks andmilestones in the overall project tracking process (tool).If this is a multi-phase process or if the application is to be released in increments theremay be parts of the application that this plan does not address. These areas need to beidentified to avoid any confusion should defects be reported back on those future functions.©2001 - Software Quality Engineering - Version 7.0A - 11This will also allow the users and testers to avoid incomplete functions and prevent waste ofresources chasing Non-defects.If the project is being developed as a multi-party process this plan may only cover aportion of the total functions/features. This needs to be identified so that those other areashave plans developed for them and to avoid wasting resources tracking defects that do notrelate to this plan.When a third party is developing the software this section may contain descriptions ofthose test tasks belonging to both the internal groups and the external groups.
  8. Environmental NeedsAre there any special requirements for this test plan, such as:• Special hardware such as simulators, static generators etc.• How will test data be provided. Are there special collection requirements or specificranges of data that must be provided?• How much testing will be done on each component of a multi-part feature?• Special power requirements.• Specific versions of other supporting software.• Restricted use of the system during testing.• Tools (both purchased and created).• Communications• Web• Client/Server• Network• Topology• External• Internal• Bridges/Routers• Security
  9. ResponsibilitiesWho is in charge? There should be a responsible person for each aspect of the testing andthe test process. Each test task identified should also have a responsible person assigned.This includes all areas of the plan, here are some examples.• Setting risks.• Selecting features to be tested and not tested.©2001 - Software Quality Engineering - Version 7.0A - 12• Setting overall strategy for this level of plan.• Ensuring all required elements are in place for testing.• Providing for resolution of scheduling conflicts, especially if testing is done on theproduction system.• Who provides the required training?• Who makes the critical go/no go decisions for items not covered in the test plans?• Who delivers each item in the test items section?
  10. ScheduleShould be based on realistic and validated estimates. If the estimates for the developmentof the application are inaccurate the entire project plan will slip and the testing is part of theoverall project plan.As we all know the first area of a project plan to get cut when it comes to crunch time atthe end of a project is the testing. It usually comes down to the decision, ‘Let’s put somethingout even if it does not really work all that well’. And as we all know this is usually the worstpossible decision.• How slippage in the schedule will to be handled should also be addressed here.• If the users know in advance that a slippage in the development will cause a slippagein the test and the overall delivery of the system they just may be a little more tolerantif they know it’s in their interest to get a better tested application.• By spelling out the effects here you have a change to discuss them in advance of theiractual occurrence. You may even get the users to agree to a few defects in advance ifthe schedule slips.• At this point all relevant milestones should be identified with their relationship to thedevelopment process identified. This will also help in identifying and trackingpotential slippage in the schedule caused by the test process.• It is always best to tie all test dates directly to their related development activity dates.This prevents the test team from being perceived as the cause of a delay. Forexample: if system testing is to begin after delivery of the final build then systemtesting begins the day after delivery. If the delivery is late system testing starts fromthe day of delivery, not on a specific date.There are many elements to be considered for estimating the effort required for testing. Itis critical that as much information as possible goes into the estimate as soon as possible inorder to allow for accurate test planning. For a generalized list of considerations refer to theestimation document in Appendix C.
  11. Risks and ContingenciesWhat are the overall risks to the project with an emphasis on the testing process?• Lack of personnel resources when testing is to begin.• Lack of availability of required hardware, software, data or tools.• Late delivery of the software, hardware or tools.• Delays in training on the application and/or tools.©2001 - Software Quality Engineering - Version 7.0A - 14• Changes to the original requirements or designs.• Specify what will be done for various events, for example:• Requirements definition will be complete by January 1, 19XX, and if therequirements change after that date the following actions will be taken.• The test schedule and development schedule will move out an appropriate numberof days. This rarely occurs, as most projects tend to have fixed delivery dates.• The number of test performed will be reduced.• The number of acceptable defects will be increased.• These two items could lower the overall quality of the delivered product.• Resources will be added to the test team.• The test team will work overtime.• This could affect team morale.• The scope of the plan may be changed.• There may be some optimization of resources. This should be avoided if possiblefor obvious reasons.• You could just QUIT. A rather extreme option to say the least.Management is usually reluctant to accept scenarios such as the one above even thoughthey have seen it happen in the past. The important thing to remember is that if you donothing at all, the usual result is that testing is cut back or omitted completely, neither ofwhich should be an acceptable option
  12. ApprovalsWho can approve the process as complete and allow the project to proceed to the nextlevel (depending on the level of the plan).• At the master test plan level this may be all involved parties.• When determining the approval process keep in mind who the audience is.• The audience for a unit test level plan is different than that of an integration,system or master level plan.• The levels and type of knowledge at the various levels will be different as well.• Programmers are very technical but may not have a clear understanding of theoverall business process driving the project.• Users may have varying levels of business acumen and very little technical skills.