Plano de Testes para App

Por que este projeto

Antes de um app ir para a loja, alguém precisa dizer: testei isso, isso e isso, e achei esses problemas. Esse alguém é QA, e o plano de testes é o documento que organiza o trabalho: o que será testado, como, com quais dados, e o que saiu errado. Escolha um app real que você usa (banco, delivery, transporte) e teste como se fosse o QA da empresa. Sem código: é raciocínio, método e registro.

Você vai sair sabendo

O que precisa estar lá no fim

É o contrato do projeto. Quando os 9 estiverem verdade, você terminou.

• App escolhido, plataforma e versão, e o escopo do que será testado, declarados no início
• Mapa de pelo menos cinco funcionalidades com prioridade (alta, média, baixa)
• Pelo menos quinze casos de teste com id, pré-condição, passos, dado de teste e resultado esperado
• Pelo menos dois cenários negativos (entrada errada, sem internet, campo vazio) para cada funcionalidade de prioridade alta
• Cada caso executado com status (passou, falhou, bloqueado) e data
• Pelo menos dois bugs reportados com passos para reproduzir, esperado versus obtido, severidade e evidência (print)
• Resumo com percentual de casos aprovados e uma recomendação (pode lançar, não pode, pode com ressalvas)
• Documento público (Notion, Google Docs ou Sheets, ou GitHub) com as seções nomeadas
• Nenhum dado pessoal real nos prints (nome, saldo, endereço borrados ou de conta de teste)

Etapas

1. 1

   Escolher e mapear

   1 h

   • Escolha o app e a versão. Liste as funcionalidades que uma pessoa usa numa semana normal.
   • Dê prioridade pelo impacto de quebrar.

   Pronto quando: Tabela com cinco ou mais funcionalidades priorizadas.

   Marcar como feita
2. 2

   Escrever os casos

   2 a 3 h

   • Para cada funcionalidade, o caminho feliz e os negativos.
   • Passos numerados, dado de teste explícito, resultado esperado observável.

   Pronto quando: Quinze casos que outra pessoa conseguiria executar sem perguntar nada.

   Marcar como feita
3. 3

   Executar

   1 a 2 h

   • Execute um a um, registre status e data.
   • Quando falhar, guarde o print na hora.

   Pronto quando: Todos os casos têm status.

   Marcar como feita
4. 4

   Reportar bugs

   1 h

   • Para cada falha, um bug report com o modelo do kit.
   • Severidade pelo impacto, não pela sua irritação.

   Pronto quando: Dois ou mais bugs que um desenvolvedor reproduziria só lendo.

   Marcar como feita
5. 5

   Resumir e publicar

   30 min

   • Percentual de aprovação, principais riscos, recomendação.
   • Nomeie as seções e publique.

   Pronto quando: O link abre numa aba anônima.

   Marcar como feita

Entrega

Terminou? Marque a conclusão e o projeto vira parte do seu perfil.

Depois