​

OmniDom Depósitos — QA Test Documentation

​

📌 Suíte de Testes

• Nome da funcionalidade testada: Gestão, Cadastro e Configuração de Depósitos
• Módulo/sistema identificado: Módulo de Logística / OmniDom
• Pré-condições gerais: Usuário autenticado, empresa habilitada e permissão total na tela de Depósitos.

​

🧪 Casos de Teste

• Tipo: Positivo
• Pré-condição: Estar na página logada de “Depósitos”.
• Dados de Entrada: Empresa vinculada: “Empresa X”, Nome: “Depósito Teste”, Código Interno: “TST-01”, Estrutura: “Loja”, CEP: “09540-000”.
• Passos:
  1. Clicar no botão ”+ Novo Depósito”.
  2. Preencher “Empresa”, “Nome”, “Código Interno” e tipo de “Estrutura”.
  3. Descer para os dados viários e preencher o “CEP”. Acionar busca.
  4. Confirmar o preenchimento automático geográfico.
  5. Validar a submissão geral e salvar.
• Resultado Esperado: O modal desaparece sem travamentos visuais e o alerta do sistema (“Depósito criado com sucesso!”) pipoca no ambiente.
• Critério de Aprovação: Confirmação dos dados persistida na tabela/grid central e validação do fluxo do CEP respondendo corretamente ao gatilho.
• Origem: Observado nas telas.

• Tipo: Borda / Lógico
• Pré-condição: Ter ao menos dois depósitos listados (Depósito A sendo classificado como Padrão e Depósito B como convencional).
• Dados de Entrada: Ação de click e confirmação no pop-up via “Depósito B”.
• Passos:
  1. Localizar a linha referencial ao “Depósito B”.
  2. Abrir seu menu de contextos (reticências ou action box).
  3. Clicar para torná-lo Padrão.
• Resultado Esperado: O toast afirmativo relatará o sucesso operacional; a interface retirará a flag de Padrão do grid de A, depositando a insígnia unicamente no campo do “Depósito B”.
• Critério de Aprovação: Impossibilidade imperativa do DOM e Banco manterem dois depósitos rotulados como centrais.
• Origem: Observado nas telas / Testado a partir dos comandos de Action.

• Tipo: Negativo
• Pré-condição: Etapa do Cadastro rodando normal até o Campo do CEP.
• Dados de Entrada: CEP puramente inexistente (ex: “00000-000”).
• Passos:
  1. Inserir a numeração fantasma falseada na API do ViaCEP ou similar.
  2. Acionar a lupa ou perder o foco do componente (onBlur).
• Resultado Esperado: Os campos Logradouro, Cidade, Bairro e Estado continuam trancados ou estritamente em branco. O sistema lança o alerta ou desabilita o Save.
• Critério de Aprovação: O campo trava sua rotina automática na ausência de validação via WebService logístico.
• Origem: Inferido das boas-práticas de formulários UI da plataforma (extensão obrigatória de Teste QA).

​

📋 Regras de Negócio Testadas

• RN1: Resolução de CEP Remota Ativa
  • Casos de teste relacionados: CT1, CT3.
• RN2: Unicidade Lógica do Flag Padrão de Expedição
  • Casos de teste relacionados: CT2.

​

⚠️ Cenários de Exceção

• Tempo de resposta demasiadamente longo da API correios no CEP forçando um estado eterno de “Loading” travando a execução modal inteira do front-end. O botão de salvamento não pode habilitar durante o fetch.

​

📊 Matriz de Cobertura