O que é um plano de teste?

Um plano de teste é um documento criado conjuntamente por um cliente e uma equipe de QA que inclui
todas as informações sobre o processo de teste. A cooperação entre o cliente e a equipe de QA começa com
este documento, o que aumenta as chances de cooperação bem sucedida.

Por que você precisa de um plano de teste?

Em primeiro lugar, um plano de teste lhe dá uma compreensão clara de como os testes serão conduzidos. No
curso do planejamento, você responderá a uma série de perguntas sobre suas necessidades de teste,
prioridades e resultados esperados para definir expectativas claras e determinar o custo e o cronograma para
o seu projeto. Aqui estão algumas outras razões pelas quais você precisa investir tempo no planejamento de
testes:

Para definir metas claras, expectativas e requisitos para o processo de teste. Ao participar do planejamento de
testes com sua equipe de QA, você entenderá o que esperar de sua cooperação.

Para ter melhor controle sobre o processo de teste. Durante o planejamento do teste, você definirá que tipos
de relatórios você quer obter e com que frequência. Por exemplo, pode ser conveniente para você obter um
relatório semanal por e-mail. Discuta isso com sua equipe de QA para acompanhar o processo de teste.

Para esclarecer o tempo, esforço e despesas necessárias para testar seu produto. Antes de realmente testar
seu produto, sua equipe de QA irá estimar o escopo do trabalho e, em seguida, dividi-lo em marcos menores.
Essa abordagem permite que uma equipe de QA estime o tempo necessário para testes, estabeleça prazos
realistas e calcule o custo.

Agora que você entende por que o planejamento de testes é uma parte inevitável do processo de garantia de
qualidade, vamos para um guia detalhado para escrever um plano de teste.

Guia passo a passo para criar um plano de teste

Uma vez que você tenha se decidido sobre a equipe de QA para testar seu produto, é hora de criar um plano
de teste. Aqui está um exemplo de um plano de teste criado pela equipe de QA rubygarage para um de nossos
projetos.

Exemplo de um plano de teste criado pela equipe rubygarage

Passo 1 — Analise o produto
O primeiro pilar de testes bem sucedidos é a análise minuciosa do seu produto, suas características e suas
funcionalidades. Depois disso, a equipe de QA precisa descobrir seus objetivos de negócios para garantir que o
produto final possa atendê-los. Para obter o ponto de vista do usuário final, a equipe de testes também
precisa entender quem é o público-alvo.

Passo 2 — Projetar uma estratégia de teste

A estratégia de teste é sobre a forma como uma equipe de QA vai testar um produto. Sua equipe pode usar
diferentes técnicas de teste, dependendo dos casos de uso do seu produto e das necessidades da sua
empresa.

Definindo o escopo dos testes

Ao definir o escopo dos testes, você e sua equipe de QA devem criar uma lista de todos os componentes do
produto a serem testados. Esta é uma lista de todo o hardware, software e middleware com o que você deseja
que seu produto seja compatível. Dizem que os itens desta lista estão "no escopo". Todo hardware, software e
middleware que é irrelevante para o seu projeto e não será testado para compatibilidade com seu produto
estão "fora de escopo".

A garantia de qualidade não deve ser considerada um processo caro e demorado. Leia nosso post sobre as
melhores abordagens para reduzir o custo de testes de produtos de software.

Identificando tipos de testes

Nesta fase, você e sua equipe de QA devem discutir que tipo de teste usar durante o processo de garantia de
qualidade. Você pode escolher diferentes tipos de testes dependendo do produto em si e de suas metas de
teste.

Aqui estão alguns tipos de testes que uma equipe de QA pode usar para verificar diferentes partes do seu
produto de software:

O teste de API ajuda a verificar o desempenho, funcionalidade e segurança das interfaces de programação de
aplicativos.

O teste de integração verifica módulos de software individuais combinados em um grupo. Este tipo de teste
visa identificar falhas que podem aparecer quando os módulos interagem.

Os testes do sistema ajudam a verificar um produto como um todo e certifique-se de que ele funciona como
deveria.

O teste de instalação/desinstalação garante o funcionamento impecável dos processos de instalação e

remoção do produto.

Etapa 3 — Defina os objetivos da prova

Nesta fase, sua equipe de QA pedirá que você liste todos os recursos que deseja testar. Você deve fornecer à
sua equipe de QA uma lista de recursos priorizados de acordo com sua importância. Como resultado, a equipe
de QA pode começar a testar os recursos mais importantes para reduzir o tempo de comercialização.

As características secundárias devem ser testadas após as primárias. Você também pode listar recursos que
não precisam ser testados.

Passo 4 — Determinar critérios de teste

Durante esta etapa, você e sua equipe de QA devem decidir sobre os critérios que determinam um resultado
bem-sucedido dos testes. A equipe de QA rubygarage define os seguintes critérios de teste:

Critérios de suspensão
Os critérios de suspensão são condições sob as quais os testes devem ser temporariamente interrompidos. Ao
definir critérios de suspensão, uma equipe de QA evita desperdiçar tempo e esforço quando os testes são
impossíveis ou sem sentido.

Exemplo: Se 40% dos casos de teste falharem, a equipe de QA deve suspender os testes até que a equipe de
desenvolvimento corrija todos os casos com falha.

Critérios de saída
Os critérios de saída descrevem condições sob as quais os testes são considerados bem sucedidos e a
funcionalidade testada pode ser encaminhada para outra etapa.

Exemplo: Se mais de 95% dos casos críticos de teste funcionarem corretamente, os testes foram bem
sucedidos.

Passo 5 — Recursos do plano

Nesta etapa, você deve enumerar todos os recursos necessários para a realização de testes, incluindo tempo,
pessoas, dinheiro e equipamentos.

O número de especialistas necessários para um projeto ficará claro após a fase de estimativa, quando o escopo
do trabalho for completamente definido. Ao trabalhar com uma equipe dedicada, você pode aumentar o
número de engenheiros de QA que trabalham em seu projeto se você precisar lançar rapidamente.

Quanto aos recursos de equipamentos e sistemas, você e sua equipe de QA devem concordar com coisas
como dispositivos, redes, servidores, etc. para serem usados durante verificações de garantia de qualidade.

Passo 6 — Planeje o ambiente de teste

Decidir sobre o ambiente de hardware e software é uma obrigação ao planejar atividades de QA. O ambiente
de teste é o software e hardware no qual a equipe de testes executará casos de teste. É importante definir
esse ambiente para garantir que seu produto possa atender às necessidades de seus usuários finais.

Passo 7 — Combine horários e estimativas

Durante a fase de estimativa, a equipe de QA divide todo o processo de teste em subtarefas para entender
quanto tempo levará para testar cada recurso separado.

Uma vez que a estimativa é feita, a equipe de QA define um cronograma, marcos e cronograma para o projeto.
Você pode aumentar o número de membros da equipe para cumprir seus prazos, dependendo de suas
necessidades.

Passo 8 — Esclarecer os resultados do teste

Durante esta etapa, você e sua equipe de QA devem concordar com os entregadores a serem fornecidos
durante sua cooperação. Uma equipe de QA cria entregas antes, durante e depois dos testes.
Saiba como a equipe de QA da RubyGarage testa vários projetos e quais benefícios nosso fluxo de trabalho
pode lhe dar.

Componentes de teste a serem criados

Ao criar um plano de teste, uma série de documentos e componentes são gerados para esclarecer detalhes do
processo de teste e sua cooperação com sua equipe de QA.

ID do plano de teste
Um ID do plano de teste inclui dados sobre a versão do projeto e o tipo de plano de teste. Criar um ID de plano
de teste é conveniente para uma equipe de QA, pois ajuda a manter todos os projetos e documentação em
ordem.

Introdução
Neste componente de teste, a equipe de QA dá uma breve descrição do projeto e especifica os objetivos do
teste, juntamente com quaisquer restrições que possam aparecer.

Referências
Neste componente de teste, a equipe de QA lista todos os documentos relacionados com o projeto, como uma
Especificação de Requisitos do Sistema (SRS), documentos de caso de uso, estratégia de teste, plano de
projeto, diretrizes do projeto, etc.

Itens de teste
Neste componente de teste, a equipe de QA lista todas as versões de software/produto que devem ser
incluídas nos testes.

Exemplo: Os testes devem ser feitos tanto na parte frontal quanto na parte traseira do aplicativo em
ambientes Windows e Linux.

Lista de recursos a serem testados

Todos os recursos que serão testados devem ser listados aqui. Os recursos a serem testados devem ser
referenciados com as especificações de design ou requisito.

Exemplo: Os recursos a serem testados são a página de login, painel e relatórios.

Lista de recursos a não serem testados

Além de listar quais recursos não serão testados, é importante explicar por que não há necessidade de testá-
los.
Exemplo: O pagamento usando PayPal está prestes a ser removido do aplicativo, portanto não há necessidade
de testar esse recurso.

Aproximação
Nesta seção, o cliente e a equipe de QA determinam a abordagem geral dos testes. A abordagem escolhida
deve incluir informações sobre tipos de testes, métodos de teste (manual ou automatizado; testes de caixa
branca, preta ou cinza) para serem aplicados durante verificações de garantia de qualidade.

Passar e reprovar critérios

Os critérios de aprovação são os critérios que indicam resultados de testes bem-sucedidos. Dependendo do
tipo de teste, os critérios de aprovação e falha podem variar.

Exemplo: Todas as principais funcionalidades do aplicativo devem funcionar como pretendido, mais de 95%
dos casos de teste devem passar, e não deve haver bugs críticos.

Se os resultados dos testes não atenderem aos critérios de aprovação, o teste é considerado como falho.

Requisitos de suspensão e retomada

Os requisitos de suspensão garantem um desenvolvimento mais eficaz do produto e a fixação de bugs. É
importante adiar mais testes em caso de falhas graves. Para isso, você e sua equipe de QA precisam
estabelecer critérios para suspender e retomar os testes.

Entregas de teste
Nesta seção, você e sua equipe de QA listam todos os documentos e relatórios que a equipe de QA deve
fornecer a você. Esta lista também inclui informações sobre etapas quando cada entrega deve ser
apresentada. A lista de entregas pode incluir documentos como um plano de teste, casos de teste e relatórios
de bugs.

Testando tarefas
Nesta seção, a equipe de QA especifica as tarefas de teste que precisa para concluir em um determinado
projeto.

Exemplo: O ambiente de teste deve estar pronto antes da fase de execução do teste. A equipe de QA deve
preparar um relatório de resumo de teste.

Necessidades ambientais
Nesta seção, você e sua equipe de QA devem especificar os ambientes de hardware e software necessários
para testes de produtos. Veja como as necessidades ambientais podem parecer:

Browser Version

Chrome 66

Firefox 60

Safari 11

IE 11
Estimar
Todo projeto tem que ser estimado em termos de tempo e esforço necessários para testes. Uma estimativa
pode ser apresentada na forma de um documento contendo uma lista de decomposição de recursos. Esta lista
deve incluir todos os recursos que precisam ser testados e o tempo planejado para testes. Enquanto estima,
uma equipe de QA deve incluir estimativas otimistas e pessimistas para explicar complicações imprevisíveis
que podem ocorrer durante o processo de teste.

Horário
O cronograma divide todo o fluxo de trabalho de teste em marcos. Esses marcos são apresentados em ordem
cronológica com prazos para que seja mais fácil controlar o processo de teste.

Necessidades de pessoal e treinamento

Aqui, a equipe de QA precisa indicar se os membros da equipe precisam de habilidades ou conhecimentos
adicionais para realizar as atividades de teste.

Responsabilidades
Nesta seção, você pode encontrar deveres e responsabilidades distribuídos dentro da equipe. Os deveres
podem ser representados em uma matriz RACI onde raci representa responsável, responsável, consultado e
informado. É importante incluir essas informações em um plano de teste, uma vez que uma matriz RACI torna
claras as funções e responsabilidades, permite que você estime a carga de trabalho de cada membro da
equipe e distribua tarefas uniformemente, e simplifique a comunicação entre você e seu cliente e dentro de
sua equipe de testes.

Riscos
Nesta seção, a equipe de QA afirma a probabilidade de que os riscos ocorram com base em fatores de risco
previamente identificados, juntamente com um plano para mitigar tais riscos.

Suposições e dependências
Suposições são ideias sobre o fluxo do processo de teste que são expressas antes do início dos testes. As
suposições não têm nenhuma evidência factual e são baseadas na experiência de uma equipe de QA. No
entanto, eles podem influenciar o curso dos testes.

Dependências são cadeias de tarefas interdependentes. Por exemplo, sem que uma tarefa seja concluída, a
equipe de QA pode não ser capaz de passar para outra fase de teste. Descrever essa sequência garante um
processo de teste impecável.

Aprovações
Nesta seção, o cliente e a equipe de QA determinam quem é o responsável pela aprovação do plano de teste.

Encerrando
Com um plano de teste detalhado, sua cooperação com uma equipe de QA tem todas as chances de ser eficaz.
Considerando todos os aspectos do teste, juntamente com uma equipe de garantia de qualidade, você é
obrigado a desfrutar de sua cooperação e, o que é mais importante, os resultados.

Você precisa testar seu produto e descobrir se ele atende aos requisitos de negócios e usuários? Vamos
verificar cada canto e fenda para ter certeza de que tudo funciona como deveria. Entre em contato conosco
para começar!