Cronograma de plano de testes de QA

O que o modelo contém

Repare que as barras de execução se sobrepõem e que o laço de defeitos corre por toda a extensão delas. É essa a cara de um cronograma de testes de verdade:

Planejamento e critérios de teste, Estratégia de teste, escopo e priorização baseada em risco, os critérios de entrada e de saída de cada fase escritos antes de a execução começar, estimativa e plano de alocação. Marco: plano e critérios aprovados.
Prontidão de ambiente e de massa de teste, O portão de verdade. Construção do ambiente, configuração e simuladores de integração, provisionamento e mascaramento da massa de teste, acessos e usuários, e um teste de fumaça que prova o ambiente antes de qualquer um testar nele. Marco: critérios de entrada do ambiente atendidos.
Desenho de testes e automação, Desenho de condições e de casos de teste, rastreabilidade de volta aos requisitos, framework de automação, construção da suíte de regressão e os scripts de teste de desempenho. Marco: casos prontos para execução.
Execução, unitário, integrado, sistema, Ondas de execução sobrepostas, e não uma fila: testes unitários e de componente, testes integrados e de interface, e então testes de sistema e de segurança. Marco: critérios de saída do teste de sistema atendidos.
Laço de triagem, correção e reteste, O laço que de fato consome o calendário, triagem diária, atribuição de severidade, ciclos de correção, reteste e impacto em regressão, e as decisões sobre defeitos postergados. Marco: limiares de defeito atingidos.
UAT, regressão e prontidão para release, Teste de aceitação pelo usuário de negócio, regressão completa, execuções de desempenho e de carga, a revisão de prontidão e o aceite formal. Marco: release aprovado.

Quem usa este modelo

Líderes de QA, gerentes de testes e engenheiros de release usam isto para agendar um ciclo de testes antes de uma entrega. Ele define critérios de entrada e saída, a prontidão de ambiente e de dados de teste, as fases funcionais e de integração sobrepostas, o ciclo de triagem de defeitos e a regressão final, ajudando os times a ver se os testes de fato cabem dentro da janela de release.

A falha de cronograma mais comum em QA é tratar ambiente e massa de teste como tarefa, e não como portão. Se o ambiente está instável ou a massa não sustenta os cenários, os testadores continuam apontando horas, mas geram defeitos sobre o ambiente em vez de sobre o produto, e essas horas são irrecuperáveis. Escreva os critérios de entrada do ambiente, rode um teste de fumaça contra eles, e recuse-se a iniciar a execução enquanto não passarem. A segunda falha é planejar o laço de defeitos como folga. Correção e reteste não são custo acessório em volta do teste; na maioria dos projetos é a barra mais longa do gráfico, e deve ser desenhada como tal.

Como adaptar

Escreva critérios de entrada e de saída de verdade nas notas de cada linha de fase, taxa de aprovação, defeitos abertos por severidade, cobertura, para que os portões sejam verificáveis, e não retóricos.
Sobreponha as ondas de execução conforme a sua cadência de build; enfileirá-las ponta a ponta quase sempre superestima a duração total e subestima o risco.
Dimensione o laço de defeitos pelas suas taxas históricas de descoberta e de correção, e não por um percentual do esforço de teste.
Acrescente uma linha por interface ou sistema integrado se o teste integrado depender de parceiros que controlam os próprios ambientes.
Se a massa vier de produção, ponha o mascaramento ou a anonimização como barra própria e anterior à liberação do ambiente, sob a LGPD, copiar base de produção para um ambiente de teste com dado pessoal em claro é tratamento sem base legal, e resolver isso depois custa a fase inteira.
Antecipe o UAT por módulo se você entrega de forma incremental, em vez de num único corte.
Acrescente uma linha de congelamento de código antes da regressão, e mantenha a regressão depois dela, regressão contra build em movimento não é regressão.

Dicas de cronograma

Faça os critérios de saída numéricos. "Teste concluído" não é portão; "zero defeito de severidade 1 aberto, menos de cinco de severidade 2, 95% dos casos planejados executados" é.
Provisione a massa antes de o desenho de testes terminar. Quem desenha descobre lacunas de dado, e o provisionamento de massa é o item de maior prazo do plano.
Faça triagem diária no pico da execução. Reunião semanal de triagem significa que um defeito pode ficar cinco dias parado antes de alguém decidir quem corrige.
Proteja a regressão do fluxo de correções. Toda correção tardia invalida parte da rodada de regressão, e é para isso que existe a linha de congelamento de código.
Acompanhe a taxa de descoberta de defeitos, e não a contagem. Taxa de descoberta caindo é o sinal honesto de que uma fase está convergindo; a contagem bruta não diz quase nada.

Este modelo está em português. Páginas relacionadas ainda não traduzidas abrem em inglês.

Perguntas frequentes

O que são critérios de entrada e de saída num plano de testes?

Critérios de entrada são as condições que precisam ser verdadeiras para uma fase começar, ambiente estável, build implantado, massa carregada, teste de fumaça aprovado. Critérios de saída são as condições para declará-la encerrada, cobertura de execução, taxa de aprovação e defeitos abertos por severidade. Ambos devem ser numéricos, acordados antes da execução e efetivamente cobrados.

Por que as fases de teste se sobrepõem em vez de correr em sequência?

Porque os builds chegam de forma incremental. O teste integrado pode começar pelos módulos já testados unitariamente, e o UAT pode começar pelas jornadas concluídas enquanto o teste de sistema continua em outro ponto. Enfileirar as fases infla o cronograma e esconde a restrição real, que normalmente é o laço de correção e reteste.

Quanto tempo devo reservar para correção de defeitos?

Dimensione pelo seu histórico: defeitos encontrados por dia de teste, a proporção que exige correção, e o seu tempo médio de correção mais reteste. Na maioria dos projetos o laço é a barra mais longa do gráfico. Alocar um percentual fixo do esforço de teste é a forma habitual de estourar o prazo.

Posso usar dados de produção como massa de teste?

Com cuidado, e nunca em claro. A LGPD trata a cópia de base de produção para ambiente de teste como tratamento de dado pessoal, com todas as obrigações que vêm junto, e ambiente de teste costuma ter controle de acesso mais frouxo do que produção. O caminho usual é mascarar, anonimizar ou gerar massa sintética, com o mascaramento como barra própria antes da liberação do ambiente, e a decisão registrada, porque é uma das primeiras coisas perguntadas numa auditoria.

E se o ambiente de teste não estiver pronto?

Não comece a execução. Testar contra ambiente instável produz defeito de ambiente, e não defeito de produto, e o tempo é irrecuperável. O modelo faz da prontidão do ambiente um marco com portão e um teste de fumaça na frente, justamente para que essa decisão seja visível em vez de absorvida em silêncio.

Quando o UAT deve começar?

Depois de atendidos os critérios de saída do teste de sistema para o escopo que o UAT vai cobrir, e não depois de todo o teste de sistema, em toda parte, estar concluído. UAT é validação de negócio, então precisa de build estável e de massa com cara de real; rodá-lo contra um build que ainda recebe correções desperdiça o usuário de negócio, que é o recurso mais escasso do plano.

O modelo de plano de testes de QA é gratuito?

Sim. Downloads gratuitos em Excel, PowerPoint e CSV, e edição online gratuita, sem cadastro.