Pular para o conteúdo principal

MDS · Modular Development Style

Plano de Testes

O artefato-padrão que lista o que validar antes de entregar: testes internos (Alfa, pela equipe) e testes com o cliente (Beta, por papel). Companheiro do DRS, do Roadmap, do Inventário e das Jornadas.

PLANO DE TESTES, MDS

O companheiro que responde o que validar antes de entregar. Onde o Roadmap diz em que ordem construir e o Inventário diz o que precisa existir, o Plano de Testes diz como a equipe e o cliente confirmam que o sistema está correto, completo e pronto para operar. É o peso de 20% no modelo de progresso MDS (40 Roadmap + 40 Inventário + 20 Testes).

Por que existe

Um sistema pode ter todos os artefatos criados e todas as tarefas marcadas e ainda assim entregar algo que não funciona como o cliente esperava. A lacuna é de validação: quem testou? o quê testou? com que critério? O Plano de Testes fecha essa lacuna com dois momentos distintos e complementares.

O Alfa acontece antes de mostrar ao cliente: a equipe percorre o sistema inteiro, requisito por requisito, e confirma que cada critério de aceite é satisfeito. O Beta acontece com o cliente: cada papel opera o sistema em cenários reais e reporta o que não funciona, não encaixa ou confunde. Os dois juntos garantem que a entrega não é só “tecnicamente pronta” mas “operacionalmente aprovada”.

As duas frentes

Alfa (testes internos, pela equipe)

A equipe valida o sistema inteiro antes de mostrar ao cliente. O Alfa cobre:

  • Um item por requisito funcional: para cada RF do DRS, um caso de teste com o critério de aceite H1 (Dado/Quando/Então). Se o RF tem H1, o caso de teste replica exatamente esse H1.
  • Testes gerais transversais: visual (paridade com o protótipo ou spec, responsividade, dark/light mode se aplicável), segurança (acesso negado a papéis sem permissão, dados isolados por tenant), performance (tempos de resposta dentro do esperado), mobile (operações críticas funcionam em tela pequena) e regressão (funcionalidades anteriores não foram quebradas).

Os itens Alfa usam o prefixo TA- e partem de zero (TA-01, TA-02…).

Beta (testes com o cliente e usuários reais)

O cliente e os usuários reais operam o sistema em cenários do dia a dia. O Beta cobre:

  • Um item por jornada de cada papel: para cada ator e cada função descrita nas Jornadas dos Atores, um caso de teste que replica a jornada completa (como entra, onde entra, o que faz, o que espera como resultado).
  • Coleta de feedback estruturado: ao fim de cada jornada, o testador responde o que funcionou, o que travou e o que confundiu. O feedback vira ajustes antes da liberação final.

Os itens Beta usam o prefixo TB- e partem de zero (TB-01, TB-02…).

Princípios

  • Rastreabilidade ao DRS e às Jornadas. Todo item Alfa aponta o RF que cobre; todo item Beta aponta o ator e a função das Jornadas que replica. Nenhum item fica sem origem.
  • Critério observável, não subjetivo. “Funciona” não é critério. O item declara o que se faz e o que se observa como resultado esperado.
  • Checklist com estado compartilhado. O aprovado/não aprovado de cada item é persistido e compartilhado, com barra de progresso própria (peso 20% no progresso geral do DRS).
  • Bloqueante para entrega. Nenhum item Alfa em aberto autoriza o início do Beta; nenhum item Beta em aberto autoriza a entrega final ao cliente.

Formato canônico

Mesmo formato de card dos outros companheiros (checkbox, código, título; corpo indentado que vira o acordeon):

- [ ] {TA-01} RF-XXX-001 Nome do requisito
  **Critério (H1):** Dado [contexto], Quando [ação], Então [resultado esperado].
  **Como executar:** passos concretos para reproduzir o cenário de teste.
  **Resultado observado:** (preenchido ao testar)

- [ ] {TB-01} Jornada do Atendimento, Triagem de leads novos
  **Ator:** Atendimento (pré-venda).
  **Como executar:** simular chegada de um lead novo e percorrer a jornada completa.
  **O que validar:** lead aparece na caixa, primeiro contato é registrado, tags aplicadas.
  **Feedback:** (preenchido ao testar)

Como se liga à família

O Plano de Testes é gerado a partir de dois companheiros:

  • O DRS alimenta o Alfa: cada RF com H1 vira um item TA-. Os testes gerais transversais cobrem o que o DRS declara de qualidade e restrições (blocos de Segurança, Performance, Atores e Jornadas do DRS).
  • As Jornadas dos Atores alimentam o Beta: cada função de cada ator vira um item TB-.
  • O Roadmap e o Inventário são pré-requisitos: o Alfa só começa quando todas as tarefas e artefatos da fase testada estão marcados como feitos.

Infraestrutura (Modulareasy)

O Plano de Testes é um documento doc_kind = 'tests' com parent_slug igual ao slug do DRS. Reaproveita a mesma renderização de cards dos outros companheiros e a mesma tabela de progresso (peso 20% no progresso global). O DRS, o Roadmap, o Inventário, as Jornadas e o Plano de Testes formam a família de 5 e se cruzam: cada um aponta para os outros quatro. Em entregas white-label, o Plano de Testes herda a identidade visual do DRS.

A família MDS responde a cinco perguntas: o DRS diz o que o sistema faz; o Roadmap diz em que ordem construir e como verificar; o Inventário diz o que precisa existir e como deve ser; as Jornadas dos Atores dizem como cada papel opera o sistema; e o Plano de Testes diz o que validar antes de entregar (Alfa interno e Beta com o cliente).

Voltar para MDS