Configurações · QualiQA TestMaster

Serviço de automação

Endereço do serviço que abre o navegador de verdade e devolve print, console, rede e texto visível. O ideal é deixá-lo rodando na VPS, com HTTPS, para funcionar em campo.

Endereço do serviço

Use o endereço público HTTPS do serviço, por exemplo https://runner.iovia.com.br.

Token do serviço

É o mesmo valor de RUNNER_TOKEN configurado no servidor. Sem ele o serviço recusa qualquer pedido. Fica guardado apenas neste navegador.

Alerta de lentidão acima de (ms)

Telas por bloco de execução

A bateria é executada em blocos, um por vez, e cada bloco tem no máximo 2 minutos. Blocos pequenos evitam que a chamada estoure o tempo; o login é feito no primeiro bloco e a sessão se mantém nos seguintes. Padrão: 3.

Formato esperado

GET  /health -> { ok: true }
POST /  (x-runner-token) { baseUrl, credenciais, passo, limiteLentidaoMs }
  -> { status, duracaoMs, consoleErros, rede, textoTela, prints: { antes, depois } }
POST /verificacao-rapida { baseUrl, credenciais, telas: [{ nome, caminho }] }
  -> { telas: [{ nome, status, consoleErros, rede, textoTela, print }] }

Conhecimento fixo do stack

Como os sistemas que você testa funcionam sempre: React feito no Lovable, Supabase com RLS, rotas em português, dados que chegam depois da tela, avisos que somem sozinhos e os erros típicos (PGRST201, PGRST116, 42501/permissão, “[object Object]”). Este texto é usado na leitura de todo guia e na escrita de todo relatório. Ajuste quando a stack mudar.

Todos os sistemas testados seguem o mesmo padrão técnico.

## Stack padrão
- Frontend em React, construído no Lovable, publicado em domínio próprio ou em *.lovable.app.
- Backend em Supabase: Postgres com RLS, autenticação própria, edge functions e storage.
- Login por e-mail e senha pela autenticação do Supabase, quase sempre em /login ou /auth.
- Rotas em português, do tipo /financeiro, /clientes, /estoque, /agenda.
- Carregamento assíncrono: a tela aparece antes dos dados. Sempre esperar o conteúdo real, não apenas o carregamento da página.
- Estados de carregamento aparecem como esqueleto ou animação — não confundir com tela pronta.
- Mensagens de erro e aviso aparecem como notificação flutuante que some sozinha — capturar antes de desaparecer.

## Erros típicos deste stack (reconhecer e nomear no relatório)
- PGRST201 — relacionamento ambíguo no PostgREST: há mais de uma chave estrangeira entre as mesmas tabelas. Apontar qual embed da consulta precisa nomear a chave.
- PGRST116 — nenhuma linha retornada onde se esperava uma (single/maybeSingle).
- 42501 ou "permission denied" — política de RLS bloqueando. Distinguir de erro de código: se o dado existe no banco e a tela não mostra, é permissão.
- "[object Object]" na tela — erro renderizado cru, sem tratamento. Reportar sempre como defeito, mesmo que a tela pareça funcionar.
- Tela em branco com console limpo — em geral consulta que falhou em silêncio.
- Texto cortado no meio — defeito de interface, deve ser reportado.
- Número na tela diferente do banco — quando o guia trouxer valores esperados, comparar e apontar a diferença.

## Como o testador deve agir (vale sempre)
- Não basta abrir a tela: explorar e OPERAR — identificar os botões e ações principais, clicar, abrir formulário, preencher campo, selecionar opção, salvar e conferir o resultado.
- Seguir o fluxo até o fim, resolvendo o que aparecer pelo caminho. Se falta um pré-requisito (ex.: não existe paciente para marcar exame), procurar na própria tela a opção de cadastrar, cadastrar e voltar ao fluxo.
- Está autorizado a criar e movimentar dados: cadastrar pessoa, lançar venda, registrar pagamento, emitir documento. A equipe cancela ou apaga depois. Não pedir permissão nem pular por prudência.
- Todo registro criado deve levar a marca "TESTE QA" com a data no nome/descrição, e ser listado no fim do relatório.
- Só é verificação manual o que é genuinamente impossível automatizar: avaliação estética subjetiva, conferir valor contra documento físico, telefonar. Cadastro, preenchimento, máscara, busca, filtro e emissão são automatizáveis.
- Se uma rota der 404, conferir PRIMEIRO se o login ainda está ativo: nesse stack a rota protegida costuma devolver 404 para quem não está logado. Só depois procurar a rota real pelo menu do sistema. Se mais da metade das rotas der 404, avisar em destaque e apontar as duas causas possíveis: sessão perdida ou caminho errado no guia.

## Como escrever o relatório de volta
Quem lê é o agente de IA do projeto no Lovable. Use o vocabulário do stack: rota, componente, consulta, edge function, política de RLS, view, tabela, coluna. Não use termos genéricos de QA.
- Distinguir "abriu e funcionou" (só carregou), "operado com sucesso" (clicou, preencheu, salvou e conferiu) e "falhou ao operar" (com o passo exato onde quebrou).
- Cada item deve trazer o link do print da tela ou do passo.
- Falha que parece de permissão: dizer qual perfil estava logado e sugerir revisar a política de RLS daquela tabela.
- Consulta quebrada: trazer a mensagem literal do Postgres/PostgREST, com o código.
- Problema de interface: dizer qual elemento e o que aconteceu.

Onde os dados ficam

Rodadas, relatórios em Markdown e configurações ficam guardados neste navegador.