Padrões de Escrita

Linguagem

• Escreva em português brasileiro
• Use linguagem clara e objetiva
• Evite jargões desnecessários
• Seja consistente com termos técnicos

Frontmatter

Campos Obrigatórios

Campo	Tipo	Descrição
id	string	Identificador único (RT001)
titulo	string	Nome descritivo
produto	string	Slug do produto
modulo	string	Módulo/área do sistema
tipo	enum	funcional, api, performance, seguranca
prioridade	enum	alta, media, baixa
status	enum	ativo, rascunho, obsoleto
tags	array	Tags para busca
ultima_atualizacao	date	Data no formato YYYY-MM-DD
autor	string	Nome do autor
versao	string	Versão do documento

Tags Recomendadas

Use tags que ajudem na busca e categorização:

Por funcionalidade:

• login, cadastro, checkout, pagamento, relatorio

Por tipo de teste:

• smoke, regressao, integracao, e2e

Por característica:

• seguranca, performance, acessibilidade

Por criticidade:

• critico, blocker

Casos de Teste

Estrutura do Caso

### CT001 - Nome Descritivo

**Objetivo:** Uma frase clara sobre o que está sendo validado.

**Prioridade:** Alta | **Tipo:** Positivo

| Passo | Ação | Resultado Esperado |
|-------|------|-------------------|
| 1 | Verbo no infinitivo | Resultado observável |

**Resultado Esperado Final:** Estado final esperado.

Boas Práticas

1. Nome do caso - Descreva o que está sendo testado, não como

   • Bom: "Login com credenciais válidas"
   • Ruim: "Preencher email e senha e clicar"

2. Passos - Comece com verbo no infinitivo

   • Bom: "Acessar", "Preencher", "Clicar", "Verificar"
   • Ruim: "O usuário acessa", "Deve preencher"

3. Resultado esperado - Seja específico e observável

   • Bom: "Mensagem 'Login realizado' é exibida"
   • Ruim: "Sistema funciona corretamente"

4. Dados de teste - Use valores concretos

   • Bom: "user@test.com"
   • Ruim: "um email válido"

Prioridades

Prioridade	Quando Usar
Alta	Funcionalidades críticas, fluxos principais, smoke tests
Média	Funcionalidades importantes, cenários alternativos
Baixa	Edge cases, cenários raros, melhorias de UX

Tipos de Teste

Tipo	Descrição
Positivo	Valida o comportamento esperado (happy path)
Negativo	Valida tratamento de erros e exceções

Informações para Automação

Sempre inclua quando possível:

1. Seletores - Preferencialmente data-testid
2. APIs - Endpoint, método, request e response
3. Código exemplo - Na stack de automação do produto

Padrão de Seletores

// Preferência de seletores (do melhor para o pior)
'[data-testid="login-button"]'  // 1. data-testid (ideal)
'#login-button'                  // 2. ID único
'.login-form button[type=submit]' // 3. Combinação de seletores
'button'                         // 4. Tag genérica (evitar)

Versionamento

• Major (1.0 → 2.0): Mudanças estruturais significativas
• Minor (1.0 → 1.1): Novos casos de teste, atualizações
• Patch (1.0.0 → 1.0.1): Correções pequenas (opcional)

Histórico de Alterações

Sempre registre mudanças significativas:

| Data | Versão | Autor | Descrição |
|------|--------|-------|-----------|
| 2025-01-29 | 1.1 | Nome | Adicionado CT005 para validação de campos |
| 2025-01-15 | 1.0 | Nome | Versão inicial |