Um plano de teste é um documento detalhado que descreve áreas e atividades de teste de software. Ele descreve a estratégia de teste, objetivos, cronograma de teste, recursos necessários (recursos humanos, software e hardware), estimativa de teste e resultados de teste.

O plano de teste é a base de todos os testes de software. É a actividade mais crucial que garante a disponibilidade de todas as listas de actividades planeadas numa sequência apropriada.

O plano de teste é um modelo para conduzir atividades de teste de software como um processo definido que é totalmente monitorado e controlado pelo gerente de teste. O plano de teste é preparado pelo Test Lead (60%), Test Manager (20%) e pelo engenheiro de teste (20%).

Tipos de plano de teste

Existem três tipos de plano de teste

• Plano Mestre de Teste
• Plano de teste de fase
• Planos de teste específicos do tipo de teste

Plano Mestre de Teste

O Plano Mestre de Teste é um tipo de plano de teste que possui vários níveis de teste. Inclui uma estratégia de teste completa.

Plano de teste de fase

Um plano de teste de fase é um tipo de plano de teste que aborda qualquer fase da estratégia de teste. Por exemplo, uma lista de ferramentas, uma lista de casos de teste, etc.

Planos de Teste Específicos

Plano de teste específico projetado para os principais tipos de teste, como testes de segurança, testes de carga, testes de desempenho, etc. Em outras palavras, um plano de teste específico projetado para testes não funcionais.

Como escrever um plano de teste

Fazer um plano de teste é a tarefa mais importante do processo de gerenciamento de teste. De acordo com o IEEE 829, siga as sete etapas a seguir para preparar um plano de teste.

• Primeiro, analise a estrutura e arquitetura do produto.
• Agora projete a estratégia de teste.
• Defina todos os objetivos do teste.
• Defina a área de teste.
• Defina todos os recursos utilizáveis.
• Programe todas as atividades de maneira apropriada.
• Determine todos os resultados do teste.

Componentes ou atributos do plano de teste

O plano de teste consiste em várias partes, que nos ajudam a derivar toda a atividade de teste.

Objetivos. Consiste em informações sobre módulos, recursos, dados de teste etc., que indicam o objetivo da aplicação, o comportamento da aplicação, objetivo, etc.

Escopo: Ele contém informações que precisam ser testadas com o respectivo aplicativo. O Escopo pode ser dividido em duas partes:

• Na mira
• Fora do escopo

Na mira: Estes são os módulos que precisam ser testados rigorosamente (em detalhes).

Fora do escopo: Estes são os módulos que não precisam ser testados rigorosamente.

Por exemplo , Suponha que temos um aplicativo Gmail para testar, onde recursos a serem testados como Compor e-mail, Itens enviados, Caixa de entrada, Rascunhos e a recursos que não foram testados como Ajuda , e assim por diante, o que significa que na fase de planejamento decidiremos qual funcionalidade deve ser verificada ou não com base no prazo fornecido no produto.

Agora como decidimos quais recursos não devem ser testados?

Temos os seguintes aspectos onde podemos decidir qual recurso não será testado:

prime sem código em java

• Como vemos acima que Ajuda recursos não serão testados, pois foram escritos e desenvolvidos pelo redator técnico e revisados ​​por outro redator profissional.
• Suponhamos que temos uma aplicação que possui P, Q, R e S recursos, que precisam ser desenvolvidos com base nos requisitos. Mas aqui, o recurso S já foi projetado e utilizado por alguma outra empresa. Portanto, a equipe de desenvolvimento comprará S dessa empresa e integrará recursos adicionais como P, Q e R.

Agora, não realizaremos testes funcionais no recurso S porque ele já foi utilizado em tempo real. Mas faremos os testes de integração e de sistema entre os recursos P, Q, R e S porque os novos recursos podem não funcionar corretamente com o recurso S, como podemos ver na imagem abaixo:

• Suponha que na primeira versão do produto, os elementos que foram desenvolvidos, como P, Q, R, S, T, U, V, W…..X, Y, Z . Agora o cliente irá fornecer os requisitos para os novos recursos que melhoram o produto na segunda versão e os novos recursos são A1, B2, C3, D4 e E5.

Depois disso, escreveremos o escopo durante o plano de teste como

Escopo

Recursos a serem testados

A1, B2, C3, D4, E5 (novos recursos)

P, Q, R, S, T

Recursos que não devem ser testados

W X Y Z

Portanto, verificaremos primeiro os novos recursos e depois continuaremos com os recursos antigos, pois isso pode ser afetado após a adição dos novos recursos, o que significa que também afetará as áreas de impacto, portanto, faremos uma rodada de testes de regressão para P, Q , R…, recursos T.

Metodologia de teste:

Ele contém informações sobre como realizar um tipo diferente de teste, como teste funcional, teste de integração e teste de sistema, etc. Nisto decidiremos que tipo de teste; executaremos os vários recursos com base nos requisitos da aplicação. E aqui, também devemos definir que tipo de teste usaremos nas metodologias de teste para que todos, como a gerência, a equipe de desenvolvimento e a equipe de teste possam entender facilmente porque os termos de teste não são padrão.

Por exemplo, para aplicações independentes, como Adobe Photoshop , realizaremos os seguintes tipos de testes:

Teste de fumaça → Teste funcional → Teste de integração → Teste de sistema → Teste Adhoc → Teste de compatibilidade → Teste de regressão → Teste de globalização → Teste de acessibilidade → Teste de usabilidade → Teste de confiabilidade → Teste de recuperação → Teste de instalação ou desinstalação

E suponha que tenhamos que testar o https://www.jeevansathi.com/ aplicativo, portanto realizaremos os seguintes tipos de testes:

Abordagem

Este atributo é usado para descrever o fluxo do aplicativo durante a execução do teste e para referência futura.

Podemos entender o fluxo da aplicação com a ajuda dos aspectos abaixo:

Escrevendo os cenários de alto nível Escrevendo o gráfico de fluxo

Escrevendo os cenários de alto nível

Por exemplo , suponha que estejamos testando o Gmail aplicativo:

• Faça login no Gmail - envia um e-mail e verifica se está na página Itens Enviados
• Logar em …….
• ……
• …....

Estamos escrevendo isso para descrever as abordagens que devem ser adotadas para testar o produto e apenas para os recursos críticos onde escreveremos os cenários de alto nível. Aqui, não nos concentraremos em cobrir todos os cenários porque pode ser decidido pelo engenheiro de teste específico quais recursos devem ser testados ou não.

Escrevendo o gráfico de fluxo

O gráfico de fluxo é escrito porque escrever os cenários de alto nível é um processo demorado, como podemos ver na imagem abaixo:

Estamos criando gráficos de fluxo para obter os seguintes benefícios, como:

• A cobertura é fácil
• Mesclar é fácil

A abordagem pode ser classificada em duas partes que são as seguintes:

arquitetura von neumann

• Abordagem de cima para baixo
• Abordagem de baixo para cima

Suposição

Ele contém informações sobre um problema ou questão que pode ter ocorrido durante o processo de teste e quando estamos escrevendo os planos de teste, as suposições garantidas seriam feitas como recursos e tecnologias, etc.

Risco

Estes são os desafios que precisamos enfrentar para testar o aplicativo na versão atual e se as suposições falharem, então os riscos estão envolvidos.

Por exemplo, o efeito para um aplicativo, a data de lançamento é adiada.

Plano de Mitigação ou Plano de Contingência

É um plano de backup preparado para superar os riscos ou problemas.

Vejamos um exemplo de suposição, risco e plano de contingência juntos porque estão correlacionados entre si.

Em qualquer produto, o suposição que faremos é que todos os 3 engenheiros de teste estarão lá até a conclusão do produto e cada um deles receberá módulos diferentes, como P, Q e R. Neste cenário específico, o risco poderia ser isso se o engenheiro de teste deixasse o projeto no meio dele.

Portanto, o plano de contingência será atribuído um proprietário principal e subordinado a cada recurso. Portanto, se o engenheiro de teste sair, o proprietário subordinado assumirá esse recurso específico e também ajudará o novo engenheiro de teste, para que ele possa entender os módulos atribuídos.

As suposições, riscos e plano de mitigação ou contingência são sempre precisos no próprio produto. Os vários tipos de riscos são os seguintes:

• Perspectiva do cliente
• Abordagem de recursos
• Parecer técnico

Papel e Responsabilidade

Ele define a tarefa completa que precisa ser executada por toda a equipe de teste. Quando chega um grande projeto, então o Gerente de testes é uma pessoa que escreve o plano de teste. Se houver de 3 a 4 projetos pequenos, o gerente de teste atribuirá cada projeto a cada Líder de Teste. E então, o líder de teste escreve o plano de teste para o projeto que lhe foi atribuído.

Vejamos um exemplo onde entenderemos as funções e responsabilidades do gerente de teste, do líder de teste e dos engenheiros de teste.

Função: Gerente de Teste

Nome: Ryan

Responsabilidade:

• Preparar (escrever e revisar) o plano de teste
• Conduzir a reunião com a equipe de desenvolvimento
• Conduza a reunião com a equipe de testes
• Conduza a reunião com o cliente
• Realizar uma reunião stand up mensal
• Assinar nota de lançamento
• Lidando com escalações e problemas

Função: Líder de Teste

Nome: Harvey

Responsabilidade:

• Preparar (escrever e revisar) o plano de teste
• Realizar reuniões stand up diárias
• Revise e aprove o caso de teste
• Prepare o RTM e os relatórios
• Atribuir módulos
• Cronograma de tratamento

Função: Engenheiro de Teste 1, Engenheiro de Teste 2 e Engenheiro de Teste 3

Nome: Louis, Jéssica, Donna

Atribuir módulos: M1, M2 e M3

Responsabilidade:

• Escreva, revise e execute os documentos de teste que consistem em casos de teste e cenários de teste
• Ler, revisar, compreender e analisar o requisito
• Escreva o fluxo do aplicativo
• Execute o caso de teste
• RTM para os respectivos módulos
• Rastreamento de defeitos
• Prepare o relatório de execução do teste e comunique-o ao Líder de Teste.

Agendar

É usado para explicar o tempo para funcionar, o que precisa ser feito ou este atributo cobre quando exatamente cada atividade de teste deve começar e terminar? E os dados exatos também são mencionados para cada atividade de teste para uma data específica.

Portanto, como podemos ver na imagem abaixo, para a atividade específica haverá uma data de início e uma data de término; para cada teste em uma compilação específica, haverá uma data especificada.

Por exemplo

• Escrevendo casos de teste
• Processo de execução

Rastreamento de defeitos

Geralmente isso é feito com a ajuda de ferramentas porque não podemos rastrear manualmente o status de cada bug. E também comentamos como comunicamos os bugs que são identificados durante o processo de teste e enviamos de volta para a equipe de desenvolvimento e como a equipe de desenvolvimento irá responder. Aqui também mencionamos a prioridade dos bugs como alta, média e baixa.

A seguir estão vários aspectos do rastreamento de defeitos:

Técnicas para rastrear o bug
…..
……
……
……Ferramentas de rastreamento de bugs
Podemos comentar o nome da ferramenta que utilizaremos para rastrear os bugs. Algumas das ferramentas de rastreamento de bugs mais comumente usadas são Jira, Bugzilla, Mantis e Trac, etc.<Gravidade
A gravidade pode ser a seguinte:
Bloqueador ou impedimento
…..
….. (Explique com um exemplo no plano de teste)
Por exemplo , haverá defeito no módulo; não podemos prosseguir para testar outros módulos porque se o bug for bloqueado, podemos prosseguir para verificar outros módulos.
Crítico
……
….. (Explique com um exemplo no plano de teste)
Nessa situação, os defeitos afetarão o negócio.
Principal
….
…. (Explique com um exemplo no plano de teste)
Menor
…..
….. (Explique com um exemplo no plano de teste)
Esses defeitos são aqueles que afetam a aparência do aplicativo.Prioridade
Alto-P1
…..
Médio-P2
…..
Baixo-P3
…..
…..
P4

Portanto, com base na prioridade de bugs como alta, média e baixa, iremos categorizá-los como P1, P2, P3 e P4.

Ambientes de teste

Esses são os ambientes onde testaremos a aplicação, e aqui temos dois tipos de ambientes, que são de Programas e hardware configuração.

O configuração de software significa os detalhes sobre diferentes Sistemas operacionais como Windows, Linux, UNIX e Mac e vários Navegadores como Google Chrome, Firefox, Opera, Internet Explorer , e assim por diante.

E a configuração de hardware significa a informação sobre diferentes tamanhos de RAM, ROM e os processadores .

Por exemplo

• O Programas inclui o seguinte:

Servidor

Nota: Os servidores acima são os servidores usados ​​pela equipe de teste para testar o aplicativo.

Cliente

supw

Observação: os detalhes acima fornecem os vários sistemas operacionais e navegadores nos quais a equipe de testes testará o aplicativo.

• O Hardware inclui o seguinte:

Servidor : Sol StarCat 1500

Este servidor específico pode ser usado pela equipe de teste para testar seu aplicativo.

Cliente:

Possui a seguinte configuração, que é a seguinte:

Nota: Fornecerá a configuração dos sistemas dos engenheiros de teste que compõem a equipe de teste.

Processo para instalar o software
……
…..
…..

A equipe de desenvolvimento fornecerá a configuração de como instalar o software. Se a equipe de desenvolvimento ainda não fornecer o processo, iremos escrevê-lo como Desenvolvimento Baseado em Tarefas (TBD) no plano de teste.

Critérios de entrada e saída

É uma condição necessária que precisa ser satisfeita antes de iniciar e interromper o processo de teste.

Critério de entrada

Os critérios de entrada contêm as seguintes condições:

• O teste de caixa branca deve ser concluído.
• Entenda e analise o requisito e prepare os documentos de teste ou quando os documentos de teste estiverem prontos.
• Os dados de teste devem estar prontos.
• Build ou o aplicativo deve estar preparado
• Módulos ou recursos precisam ser atribuídos a diferentes engenheiros de teste.
• O recurso necessário deve estar pronto.

Critério de saída

Os critérios de saída contêm as seguintes condições:

• Quando todos os casos de teste forem executados.
• A maioria dos casos de teste deve ser passado .
• Depende da gravidade dos bugs, o que significa que não deve haver nenhum bloqueador ou bug grave, embora existam alguns bugs menores.

Antes de começarmos a realizar testes funcionais, todos os itens acima Critério de entrada deve ser seguido. Depois de realizarmos os testes funcionais e antes de fazermos os testes de integração, então o Critérios de saída de o teste funcional deve ser seguido porque a porcentagem de critérios de saída é decidida pela reunião com o gerente de desenvolvimento e de teste porque sua colaboração pode atingir a porcentagem. Mas se os critérios de saída dos testes funcionais não forem seguidos, não poderemos prosseguir para os testes de integração.

Aqui com base na gravidade dos bugs significa que a equipe de testes teria decidido prosseguir para as próximas fases.

Automação de testes

Neste, decidiremos o seguinte:

• Qual recurso deve ser automatizado e não automatizado?
• Qual ferramenta de automação de teste usaremos em qual estrutura de automação?

Automatizamos o caso de teste somente após o primeiro lançamento.

Aqui surge a questão de saber com que base nós vai decidir quais recursos devem ser testados?

Na imagem acima, podemos ver que os recursos mais comumente usados ​​precisam ser testados continuamente. Suponha que tenhamos que verificar o aplicativo Gmail onde estão os recursos essenciais Compor e-mail, itens enviados e caixa de entrada . Portanto, testaremos esses recursos porque realizar testes manuais leva mais tempo e também se torna um trabalho monótono.

Agora, como decidimos quais recursos não serão testados?

Suponha a ajuda O recurso do aplicativo Gmail não é testado repetidamente porque esses recursos não são usados ​​regularmente, portanto, não precisamos verificá-lo com frequência.

Mas se alguns recursos estiverem instáveis ​​e tiverem muitos bugs , o que significa que não testaremos esses recursos porque eles precisam ser testados repetidamente durante os testes manuais.

Se há um recurso que precisa ser testado com frequência , mas esperamos a alteração dos requisitos desse recurso, portanto, não verificamos porque alterar os casos de teste manuais é mais confortável em comparação com a alteração no script de teste de automação.

'fórmula do pedreiro'

Estimativa de esforço

Para isso, planejaremos o esforço necessário a ser aplicado por cada membro da equipe.

Entregável de teste

São os documentos provenientes da equipe de testes, que entregamos ao cliente junto com o produto. Inclui o seguinte:

Plano de teste Casos de teste Scripts de teste RTM (Matriz de Rastreabilidade de Requisitos) Relatório de defeitos Relatório de execução de teste Gráficos e métricas Notas de versão

Gráficos e Métricas

Gráfico

Neste, discutiremos sobre os tipos de gráficos enviaremos e também forneceremos uma amostra de cada gráfico.

Como podemos ver, temos cinco gráficos diferentes que mostram os diversos aspectos do processo de teste.

Gráfico1: Neste, mostraremos quantos defeitos foram identificados e quantos defeitos foram corrigidos em cada módulo.

Gráfico 2: A Figura um mostra quantos defeitos críticos, maiores e menores foram identificados para cada módulo e quantos foram corrigidos para seus respectivos módulos.

Gráfico3: Neste gráfico específico, representamos o construir gráfico sábio , o que significa que em cada compilação quantos defeitos foram identificados e corrigidos para cada módulo. Com base no módulo, determinamos os bugs. Nós vamos adicionar R para mostrar o número de defeitos em P e Q, e também adicionamos S para mostrar os defeitos em P, Q e R.

Gráfico4: O líder de teste projetará o Análise de tendências de bugs gráfico que é criado todo mês e enviar também para a Administração. E é como a previsão que é feita no final do produto. E aqui também podemos avalie as correções de bugs como podemos observar que arco tem um tendência ascendente na imagem abaixo.

Gráfico 5: O Gerente de testes projetou esse tipo de gráfico. Este gráfico tem como objetivo entender a lacuna na avaliação de bugs e os bugs reais que ocorreram, e este gráfico também ajuda a melhorar a avaliação de bugs no futuro.

Métricas

Assim como acima, criamos o gráfico de distribuição de bugs, que está na figura 1, e com a ajuda dos dados mencionados acima, desenharemos as métricas também.

Por exemplo

Na figura acima, mantemos os registros de todos os engenheiros de teste em um projeto específico e quantos defeitos foram identificados e corrigidos. Também podemos usar esses dados para análises futuras. Quando surge um novo requisito, podemos decidir quem fornecerá o recurso desafiador para teste com base no número de defeitos encontrados anteriormente, de acordo com as métricas acima. E estaremos em uma situação melhor para saber quem consegue lidar muito bem com os recursos problemáticos e encontrar o número máximo de defeitos.

Nota de lançamento: É um documento elaborado durante o lançamento do produto e assinado pelo Test Manager.

Na imagem abaixo, podemos ver que o produto final foi desenvolvido e implantado para o cliente, e o nome da versão mais recente é Beta .

O Nota de lançamento consiste no seguinte:

• Manual do usuário.
• Lista de defeitos pendentes e abertos.
• Lista de recursos adicionados, modificados e excluídos.
• Lista da plataforma (Sistema Operacional, Hardware, Navegadores) na qual o produto é testado.
• Plataforma na qual o produto não é testado.
• Lista de bugs corrigidos na versão atual e lista de bugs corrigidos na versão anterior.
• Processo de instalação
• Versões do software

Por exemplo

Suponha que Beta é a segunda versão do aplicativo após a primeira versão Alfa é libertado. Alguns dos defeitos identificados no primeiro lançado e que foram corrigidos no lançado posteriormente. E aqui também apontaremos a lista de recursos recém-adicionados, modificados e excluídos da versão alfa até a versão beta.

Modelo

Esta parte contém todos os templates dos documentos que serão utilizados no produto, e todos os engenheiros de teste utilizarão apenas esses templates no projeto para manter a consistência do produto. Aqui, temos diferentes tipos de modelo que são usados ​​durante todo o processo de teste, como:

• Modelo de caso de teste
• Modelo de revisão de caso de teste
• Modelo RTM
• Modelo de relatório de bug
• Relatório de execução de teste

Vejamos uma amostra do documento do plano de teste

Página 1

Página3-página18

Página-20

Na página 1, preenchemos principalmente apenas o Versões, autor, comentários e revisado por campos, e após a aprovação do gestor, mencionaremos os detalhes no Aprovado até e data de aprovação Campos.

Principalmente o plano de teste é aprovado pelo Test Manager e os engenheiros de teste apenas o revisam. E quando os novos recursos chegarem, modificaremos o plano de teste e faremos as modificações necessárias em Versão campo e, em seguida, será enviado novamente para posterior revisão, atualização e aprovação do gestor. O plano de teste deve ser atualizado sempre que ocorrer alguma alteração. Na página 20, o Referências especifique os detalhes sobre todos os documentos que usaremos para escrever o documento do plano de teste.

Observação:

Quem escreve o plano de teste?

• Líder de teste→60%
• Gerente de Teste→20%
• Engenheiro de Teste→20%

Portanto, como podemos ver acima que em 60% do produto, o plano de teste é escrito pelo Test Lead.

Quem revisa o Plano de Teste?

• Líder de teste
• Gerente de testes
• Engenheiro de testes
• Cliente
• Equipe de desenvolvimento

O Engenheiro de Teste revisa o plano de teste para a perspectiva do módulo e o gerente de teste revisa o plano de teste com base na opinião do cliente.

Quem aprova o plano de teste?

• Cliente
• Gerente de testes

Quem escreve o caso de teste?

• Líder de teste
• Engenheiro de testes

Quem analisa o caso de teste?

variáveis ​​globais js

• Engenheiro de testes
• Líder de teste
• Cliente
• Equipe de desenvolvimento

Quem aprova os casos de teste?

• Gerente de testes
• Líder de teste
• Cliente

Diretrizes do Plano de Teste

• Recolha seu plano de teste.
• Evite sobreposição e redundância.
• Se você acha que não precisa de uma seção já mencionada acima, exclua essa seção e prossiga.
• Seja específico. Por exemplo, ao especificar um sistema de software como parte do ambiente de teste, mencione a versão do software em vez de apenas o nome.
• Evite parágrafos longos.
• Use listas e tabelas sempre que possível.
• Atualize o plano quando necessário.
• Não use um documento desatualizado e não utilizado.

Importância do Plano de Teste

• O plano de teste orienta nosso pensamento. Isto é como um livro de regras, que deve ser seguido.
• O plano de teste ajuda a determinar os esforços necessários para validar a qualidade do aplicativo de software em teste.
• O plano de teste ajuda essas pessoas a entender os detalhes do teste relacionados ao exterior, como desenvolvedores, gerentes de negócios, clientes, etc.
• Aspectos importantes como cronograma de teste, estratégia de teste, escopo de teste, etc., são documentados no plano de teste para que a equipe de gerenciamento possa revisá-los e reutilizá-los em outros projetos semelhantes.