Num sistema de pedidos por foto, a leitura simulada deixou validar o fluxo inteiro sem pagar por nenhuma leitura real. O que ela não pegou ensinou mais do que o que ela confirmou.
Anderson Silveira · 16 de setembro de 2026
Uma distribuidora de lubrificantes recebia pedidos como foto de papel no WhatsApp, e alguém redigitava tudo. É o tipo de trabalho manual que pede automação: repetitivo, com regra conhecida e erro caro. O sistema que construí mantém o gesto de fotografar: a IA lê a anotação, cruza cada linha com o catálogo e propõe os itens. A pessoa revisa linha por linha antes de confirmar.
Quando se automatiza um trabalho desses, a tentação é validar a parte que chama atenção, que é a IA lendo a letra corrida. Mas a pergunta que decidia se a automação funcionava era outra: o comprador consegue revisar uma proposta da máquina e confirmar o pedido certo?
Para responder a essa, eu não precisava de leitura real. O fluxo roda de ponta a ponta com uma leitura simulada, que devolve uma extração fixa casada com o catálogo, sem nenhuma chamada paga. A revisão, a linha em dúvida, a linha não reconhecida que trava o botão e o pedido que chega ao painel igual a qualquer outro, tudo isso deu para exercitar sem gastar nada com IA. Em produção, a funcionalidade ficou desligada a pedido do cliente até a leitura real ser ativada. Religar é mudar uma chave.
O momento em que o tema ficou claro veio depois. Passando o fluxo inteiro de novo com a leitura simulada, apareceu no rodapé da revisão um “Total estimado R$ 0,00”. O cliente tinha pedido para tirar o preço de todas as telas; a regra funcionava, mas dois lugares ainda imprimiam dinheiro zerado. Nenhum teste reclamou. E, na mesma semana, a suíte inteira passou verde enquanto a API, rodando de verdade, respondia erro no catálogo. Validar cedo resolve muita coisa. Não resolve se o que você valida não é o sistema que vai para o ar. Este artigo é sobre como validar uma automação antes de ligar a parte cara dela.
Comece pela hipótese
Protótipo sem hipótese vira apresentação. Uma hipótese boa diz o que se acredita, para quem, e o que provaria o contrário:
Escrita do jeito que eu escreveria hoje, a do pedido por foto seria: o comprador consegue transformar a foto da anotação num pedido correto sem redigitar; confirmada se ele resolve cada linha duvidosa sem ajuda; refutada se confirma linha errada sem perceber.
Vale separar três perguntas, porque pedem testes diferentes:
- Valor: isso resolve algo que importa? Aqui, tirar a redigitação do back-office.
- Usabilidade: a pessoa consegue usar? Aqui, a tela de revisão.
- Viabilidade: a tecnologia entrega? Aqui, a precisão da leitura.
A leitura simulada foi útil exatamente porque separou a segunda da terceira. Ela não diz nada sobre a precisão da IA. Diz tudo sobre o que acontece em volta dela.
A fidelidade acompanha a pergunta
| Baixa fidelidade | Alta fidelidade ou código | |
|---|---|---|
| Custo para mudar | Minutos | Horas ou dias |
| Boa para testar | Fluxo, ordem das etapas, conceito | Interação, estados, texto, confiança |
| Risco | A pessoa preenche lacunas com imaginação | Parece pronto, e o time se apega |
Regra que uso: quanto mais cedo a dúvida, mais baixa a fidelidade. A exceção é quando a interação é o objeto do teste. Uma revisão com linha sugerida, linha não identificada, quantidade editável e botão que só libera no fim tem estados demais para telas estáticas. Aí um protótipo em código, com a parte cara trocada por uma simulação, vale mais que qualquer desenho.
O cuidado é que código parece produto. Se ele vira a base sem revisão, a validação vira atalho de desenvolvimento.
Pessoas, tarefas e o limite dos cinco
A referência mais citada é o artigo de Jakob Nielsen, de 2000: cinco participantes encontram a maior parte dos problemas de usabilidade de um desenho. A ressalva que se perde: é por rodada, dentro de um processo iterativo, por perfil, e serve para achar problemas, não para medir taxa de sucesso.
A tarefa é o instrumento. Ela descreve a situação, nunca o botão:
| Tarefa ruim | Tarefa melhor (exemplo ilustrativo) |
|---|---|
| Clique em “Enviar foto” e confirme os itens | A oficina precisa de três baldes e uma caixa de óleo. Você anotou no papel. Faça o pedido. |
| Veja se a linha amarela está certa | O pedido chegou à loja com um item que você não pediu. Descubra de onde ele veio. |
Defina antes o que é sucesso. No pedido por foto, sucesso não é “confirmou”. É “confirmou o pedido que estava no papel”.
Teste verde não é sistema funcionando
Esta é a parte que o caso acrescentou ao método. Três episódios, de três projetos:
- No sistema de pedidos, os testes liam o código-fonte de um pacote compartilhado; a API em pé lia a versão compilada dele, que estava velha. A suíte passou inteira, e o catálogo e a tela inicial do comprador respondiam erro. Publicar confiando no verde teria derrubado as duas telas mais usadas.
- No Glint, uma rodada de navegação por todas as rotas achou um formulário de contato com a organização que enviava para um endereço que não existia. A chamada não acusava o erro, a tela mostrava sucesso, e a mensagem se perdia.
- Também no Glint, uma campanha de QA com agentes especialistas levou a suíte de 378 para 1.049 testes. No caminho, apareceram um funil que sempre mostrava zero pessoas (o dado era gravado por um nome e lido por outro) e uma suspensão de conta que só barrava no login: quem já estava logado seguia com acesso.
O padrão é o mesmo: o teste confirmava uma coisa vizinha da que importava. Por isso, depois do verde, eu passo o fluxo no sistema rodando, com dado de verdade ou simulado, olhando a tela. Foi assim que o “R$ 0,00” apareceu.
Validar o custo e o trade-off, não só a tela
Duas decisões de validação que não são de usabilidade.
Estimar antes de disparar. No agente jurídico, cada rodada de análise tem custo real, então a tela mostra a estimativa antes do botão, contra o orçamento que resta no caso. O trilho completo do credor foi validado de ponta a ponta num caso real, da triagem à minuta homologada. E mesmo assim, quando um advogado rodou um caso próprio, a minuta falhou duas vezes; as duas falhas viraram conserto no mesmo dia. Numa delas, o chat nunca tinha funcionado em dossiê grande: a conta de tamanho media uma unidade e o limite real era outra. A validação estava medindo a coisa errada.
Deixar o custo na tela. No Glint, o QR rotativo impede que o print de um ingresso válido circule, mas exige internet no celular do participante na portaria. Em vez de ligar para todos, a opção nasceu desligada por padrão, com o aviso escrito ao lado do interruptor. Validar aqui foi perguntar em que contexto a proteção vira fila.
O ciclo
- 01Hipótese
O comprador revisa a proposta da máquina e confirma o pedido certo.
- 02Simular o caro
Leitura simulada, extração fixa, nenhuma chamada paga.
- 03Tarefas
A anotação no papel vira pedido, sem as palavras da tela.
- 04Sessões
Cerca de cinco pessoas por perfil, por rodada.
- 05Sistema em pé
Passar o fluxo na API rodando, não só na suíte.
- 06Severidade
Classificar o que apareceu e corrigir antes de ligar.
Severidade: nem todo achado pesa igual
Cruzo dois eixos: quantas pessoas o problema atingiria e o que ele causa. Os itens abaixo são achados reais dos casos acima; as posições são leitura minha, não medição.
| Severidade | Critério | O que fazer |
|---|---|---|
| 4 | Impede a tarefa principal, ou causa perda de dados ou de dinheiro | Corrigir antes de lançar |
| 3 | A pessoa consegue, com muito esforço, erro ou ajuda | Corrigir nesta rodada |
| 2 | Hesitação perceptível, sem impedir | Próximo ciclo |
| 1 | Cosmético | Registrar; corrigir se for barato |
O “R$ 0,00” é um bom exemplo de severidade que engana. Parece cosmético. Num sistema em que o cliente pediu para esconder preço porque cada comprador tem sua negociação, um valor zerado na tela de confirmação gera dúvida exatamente no momento de confirmar.
O que eu faria diferente
- Testar a mudança de regra em todas as telas, com o fluxo simulado ligado. Esconder o preço deu certo porque a decisão morava num lugar só. Os dois lugares que escaparam eram os que eu não olhei: a agenda de retirada e o rodapé da revisão, numa funcionalidade que estava desligada.
- Compilar o pacote compartilhado antes de testar a API em pé. Virou regra depois do susto.
- Pôr a revisão na mão de compradores antes de ligar a leitura real. As dores foram deduzidas do processo, não de entrevista. A simulação deixa fazer essa rodada sem custo; é o passo que eu daria antes de religar a chave.
- Testar o vocabulário do balcão contra o catálogo real. Na simulação, “cx 24” foi casado com o tambor, e não com a caixa de 24 frascos. Pode ser efeito do catálogo de teste, mas é exatamente o tipo de erro caro que a revisão humana existe para pegar.
Checklist antes da próxima rodada
- A hipótese está escrita, com critério de confirmação e de refutação?
- Valor, usabilidade e viabilidade estão separados, e cada um tem o seu teste?
- A parte cara (IA, pagamento, integração) pode ser simulada para validar o resto?
- As tarefas descrevem situações, sem as palavras da interface?
- O que conta como sucesso foi definido antes?
- São cerca de cinco pessoas por perfil, com outra rodada depois da correção?
- Depois do teste verde, alguém passou o fluxo no sistema rodando?
- O custo e o trade-off estão visíveis para quem decide ligar a funcionalidade?
- Os achados foram classificados por severidade, e não só listados?
Numa automação, a IA é quase sempre a parte cara. Também é a que menos precisa estar ligada para validar o fluxo em volta dela. Simular essa parte deixa validar cedo. Olhar o sistema rodando é o que impede que o verde da suíte passe por validação.