Introdução

"Cadê a documentação desse sistema?"

"Não tem."

Se essa conversa te soa familiar, bem-vindo ao clube. 80% dos projetos não têm documentação adequada. E você precisa testar mesmo assim.

Este artigo te ensina técnicas práticas para testar quando não há especificação, manual, ou qualquer tipo de guia. Porque falta de documentação não é desculpa para não garantir qualidade.

---

A Realidade Nua e Crua

Cenários Comuns:

• Documentação perdida há anos
• Desenvolvedores originais saíram da empresa
• Ninguém sabe como funciona
Cenário 2: Startup/projeto novo
• "Vamos documentar depois"
• Prazo apertado
• Prioridade é entregar
Cenário 3: Mudanças constantes
• Documentação desatualizada
• Mais confunde que ajuda
• Melhor ignorar
Sua missão: Testar de qualquer jeito.

---

1. Exploração Ativa

O Que É?

Usar o sistema como um usuário real para entender como funciona.

Como Fazer?

Passo 1: Navegue sem objetivo

• Clique em tudo
• Preencha formulários
• Teste todos os botões
• Explore todos os menus

Passo 2: Anote TUDO

Tela: Cadastro de Cliente Campos:

• Nome (obrigatório, texto, max 100 chars)
• CPF (obrigatório, máscara 999.999.999-99)
• Email (obrigatório, validação de formato)
• Telefone (opcional, máscara (99) 99999-9999)

Botões:

• Salvar: Cria registro e redireciona para lista
• Cancelar: Volta para lista sem salvar

Validações observadas:

• CPF duplicado: "CPF já cadastrado"
• Email inválido: "Email inválido"

Passo 3: Crie sua própria documentação

• Documente enquanto explora
• Faça screenshots
• Anote comportamentos
• Registre mensagens de erro

---

2. Engenharia Reversa

O Que É?

Deduzir regras de negócio observando comportamentos.

Técnica: Teste e Observe

Exemplo: Teste 1:

Ação: Cadastrar com idade = 17 Resultado: "Idade mínima: 18 anos" Conclusão: Sistema exige maioridade

Teste 2:

Ação: Cadastrar com CPF já existente Resultado: "CPF já cadastrado" Conclusão: CPF deve ser único

Teste 3:

Ação: Deixar campo telefone vazio Resultado: Cadastro criado com sucesso Conclusão: Telefone é opcional

Técnica: Análise de Mensagens

Mensagens de erro revelam regras:

"Senha deve ter no mínimo 8 caracteres" → Regra: senha ≥ 8 chars

"Data não pode ser futura" → Regra: data ≤ hoje

"Valor máximo: R$ 10.000,00" → Regra: valor ≤ 10000

---

3. Perguntas Certas

❌ Perguntas Ruins

"Como funciona o sistema?"

• Muito genérica
• Resposta vaga
• Não ajuda

"Pode me explicar tudo?"

• Impossível de responder
• Perde tempo
• Não é específica

✅ Perguntas Boas

"O que acontece se eu tentar cadastrar um CPF duplicado?"

• Específica
• Testável
• Resposta clara

"Qual a idade mínima permitida?"

• Direta
• Regra de negócio
• Fácil de validar

"Posso deixar o campo telefone vazio?"

• Sim/Não
• Simples
• Acionável

Template de Perguntas

Para VALIDAÇÕES: "O que acontece se eu [ação inválida]?"

Para REGRAS: "Qual o [limite/mínimo/máximo] de [campo]?"

Para FLUXOS: "Depois de [ação], o que deveria acontecer?"

Para DEPENDÊNCIAS: "Se eu [ação A], isso afeta [campo/funcionalidade B]?"

---

4. Usando o Checklist da Caixinha

Vantagem: Funciona MESMO sem saber as regras!

Testes Universais

CRUD Básico

☐ Criar registro ☐ Consultar registro ☐ Editar registro ☐ Excluir registro

Você não precisa saber as regras para testar se CRUD funciona.

Validações de Campo

☐ Deixar vazio (obrigatório?) ☐ Caracteres especiais ☐ Limite de caracteres ☐ Formato inválido

Teste isso em TODOS os campos, sempre.

Segurança Básica

☐ Script injection: <script>alert('xss')</script> ☐ SQL injection: ' OR '1'='1 ☐ HTML injection:

teste

Não precisa de documentação para testar segurança.

---

5. Análise de Código (Se Tiver Acesso)

O Que Procurar?

Validações no Código

php if ($idade < 18) { return "Idade mínima: 18 anos"; }

→ Regra descoberta: idade ≥ 18

Queries SQL

sql SELECT * FROM clientes WHERE cpf = ?

→ Regra descoberta: CPF é usado para busca

Comentários

javascript // TODO: Validar se email já existe

→ Possível bug: validação não implementada

---

6. Comparação com Sistemas Similares

Técnica: Benchmarking

Pergunta: Como outros sistemas fazem? Exemplo:

Testando cadastro sem documentação:

• Como o Gmail valida email?
• Como o Facebook valida data de nascimento?
• Como o Amazon valida CEP?
Use como referência:
• Padrões de mercado
• Boas práticas conhecidas
• Comportamentos esperados

---

7. Teste Exploratório Estruturado

O Que É?

Testar sem casos pré-definidos, mas com objetivo.

Técnica: Session-Based Testing

Estrutura:

Sessão: 90 minutos Objetivo: Explorar funcionalidade de cadastro Foco: Validações de campos

Descobertas:

• Campo nome aceita números (bug?)
• CPF não valida dígitos verificadores (bug!)
• Email aceita espaços (bug?)

Próxima sessão: Testar fluxo de edição

Técnica: Tours

Tour do Usuário Novato:
• Use como alguém que nunca viu o sistema
• Tente fazer tarefas comuns
• Anote dificuldades
Tour do Usuário Malicioso:
• Tente quebrar o sistema
• Dados inválidos
• Ações inesperadas
Tour do Usuário Apressado:
• Clique rápido
• Pule etapas
• Não leia mensagens

---

8. Documentando Enquanto Testa

Por Que Documentar?

• Você vai esquecer
• Outros vão precisar
• Vira base de conhecimento

O Que Documentar?

Fluxos Principais

Fluxo: Cadastrar Cliente

• Acessar /clientes
• Clicar "Novo Cliente"
• Preencher formulário
• Clicar "Salvar"
• Sistema redireciona para lista
• Mensagem: "Cliente cadastrado com sucesso"

Regras Descobertas

REGRAS DE NEGÓCIO - Cadastro de Cliente

Campos Obrigatórios:

• Nome
• CPF
• Email

Validações:

• CPF: Deve ser único
• Email: Formato válido
• Idade: Mínimo 18 anos

Comportamentos:

• Telefone opcional
• CEP busca endereço automaticamente
• Ao salvar, envia email de boas-vindas

Bugs Encontrados

BUG #001 Título: Campo nome aceita números Severidade: Baixa Passos: Cadastrar com nome = "123" Resultado: Aceita Esperado: Rejeitar (apenas letras)

---

9. Ferramentas que Ajudam

DevTools do Navegador

Network Tab:
• Veja requisições
• Descubra endpoints
• Entenda payloads
Console:
• Veja erros JavaScript
• Execute comandos
• Teste comportamentos
Application:
• Veja cookies
• Inspecione localStorage
• Analise sessões

Postman/Insomnia

• Teste APIs diretamente
• Descubra parâmetros
• Entenda respostas

Banco de Dados

Se tiver acesso:

• Veja estrutura de tabelas
• Entenda relacionamentos
• Descubra constraints

---

10. Estratégia Completa

Passo a Passo

Dia 1: Exploração

☐ Navegar por todo o sistema ☐ Testar todos os fluxos principais ☐ Anotar tudo que observar

Dia 2: Perguntas

☐ Listar dúvidas ☐ Perguntar ao time ☐ Documentar respostas

Dia 3: Testes Básicos

☐ Aplicar checklist da caixinha ☐ CRUD completo ☐ Validações universais

Dia 4: Testes Específicos

☐ Testar regras descobertas ☐ Cenários de erro ☐ Edge cases

Dia 5: Documentação

☐ Consolidar descobertas ☐ Criar casos de teste ☐ Compartilhar com time

---

Checklist de Sobrevivência

EXPLORAÇÃO: ☐ Naveguei por todo o sistema? ☐ Testei todos os fluxos principais? ☐ Anotei comportamentos observados?

PERGUNTAS: ☐ Fiz perguntas específicas? ☐ Documentei respostas? ☐ Validei com testes?

TESTES UNIVERSAIS: ☐ CRUD completo? ☐ Validações de campos? ☐ Segurança básica?

DOCUMENTAÇÃO: ☐ Registrei fluxos? ☐ Documentei regras? ☐ Anotei bugs?

FERRAMENTAS: ☐ Usei DevTools? ☐ Testei APIs? ☐ Consultei banco (se possível)?

---

Conclusão

Falta de documentação é frustrante, mas não é desculpa.

Use as técnicas deste artigo:
• Exploração ativa
• Engenharia reversa
• Perguntas certas
• Checklist universal
Lembre-se:
• Documente enquanto testa
• Compartilhe descobertas
• Construa conhecimento

---

Inscreva-se no canal LiraQuality no YouTube

Compartilhe no fórum da comunidade