Uma feature só está pronta quando quem não a escreveu vê cada caso funcionando

Na tarde de 14 de outubro, a gente disparou duas vezes seguidas a rotina que procura atividades atrasadas. Antes do segundo disparo, o banco tinha 7 eventos e 3 execuções. Depois dele, tinha os mesmos 7 e 3, e o número de avisos no sino não mudou. Esse resultado é um dos 27 prints que a gente juntou antes de mostrar a feature a alguém.

Na TOPO, uma feature só está pronta quando alguém que não a escreveu consegue ver, com print, cada caso funcionando. Os testes automáticos rodam antes, na CI. O QA vem depois e olha o sistema publicado em staging, do jeito que o cliente vai usar.

A feature

As automações deixam o cliente da TOPO montar regras no formato quando, se e então. Por exemplo: quando uma atividade atrasa, se ela é de um certo departamento, então a TOPO avisa uma pessoa no sino.

O motor é nosso. Cada evento é gravado no PostgreSQL antes de entrar numa fila no Redis, então um evento não se perde se o processo cair.

O roteiro vem antes do navegador

Quem faz o QA escreve o roteiro antes de abrir a tela. Cada passo diz o que deve acontecer. Ao lado entra o que foi visto e o print que prova. Cada print tem hora e uma frase dizendo o que ele mostra.

Foram 7 passos em staging, num cliente de teste que é nosso. O roteiro inteiro rodou em quinze minutos.

A feature nasce desligada em staging e em produção. O primeiro passo a ligou só para o cliente de teste, com a chave por cliente. A API confirmou: ligada nele e desligada em outro cliente.

Depois vieram os casos:

• Regra criada pela tela. A lista começa vazia. O editor é preenchido, a confirmação avisa que a regra vale só para eventos a partir de agora, e a regra aparece na lista como Ligada.
• Atividade atrasada. Para não esperar um dia, a gente recuou no banco o prazo de uma atividade de teste. O valor anterior ficou guardado. A rotina respondeu com sucesso.
• Aviso no sino. O analista de teste viu o aviso com o nome da regra e o texto do atraso. O clique abriu a atividade, marcada como atrasada.
• Execução registrada. A aba Execuções mostra a linha Sucesso, com o item e o filtro que passou.
• Segundo disparo que não repete. É a contagem do começo deste post. Nada mudou no banco nem no sino.
• Teste que simula sem enviar. O botão Testar roda a regra sobre um evento real e mostra quem seria avisado. Nada sai para ninguém.

A aba Execuções mostra a execução de verdade, marcada Sucesso, e as duas simulações feitas com o exemplo.

No último caso, a gente contou tudo antes e depois:

No cliente de teste	Antes do Testar	Depois do Testar
Execuções	3	4
Execuções simuladas	2	3

A única execução nova é simulada. Nenhum aviso saiu e nenhum e-mail novo foi registrado.

O Testar sobre um evento real diz que nada foi enviado e mostra quem seria avisado.

Um caso apareceu sem a gente pedir. Cinco atividades já estavam atrasadas antes de a regra existir. Elas geraram evento, mas nenhuma execução. A regra vale daqui para a frente, como a tela promete, e o banco confirma.

Um passo parcial fica marcado como parcial

Dos 7 passos, 6 passaram inteiros. O sexto passou em parte, e o relatório diz por quê.

A gente queria uma execução filtrada, de uma regra cujo filtro não passa. O cliente de teste tem um só departamento. E o mesmo item não gera dois eventos no mesmo dia, de propósito. Então essa prova saiu como simulação sobre um item real, e não como execução de verdade.

A gente também queria ver a resposta exata que outro cliente recebe ao pedir uma regra que não é dele. O usuário de outro cliente foi barrado, assim como o analista sem permissão. Mas ele parou na checagem de permissão, antes de chegar à regra. A resposta exata do caso não foi reproduzida.

Com isso, quem lê o relatório sabe o que está provado e o que ainda falta provar.

No último passo, a gente desfez o que tinha forçado. O prazo e a data de ativação voltaram ao valor anterior, conferidos no banco. A regra ficou pausada, pronta para o próximo teste.

Dois defeitos que só a tela mostrou

O QA achou dois defeitos. Nos dois, o banco estava certo. O erro estava no que a pessoa vê.

O primeiro aparecia na regra nova. O Testar gravava o rascunho, abria a página da regra e o resultado sumia. A execução simulada estava no banco. O problema era a troca de endereço: ao salvar, a regra nova ganha página própria, o editor recarrega e o resultado guardado no formulário se perdia. O conserto roda a simulação antes da troca e entrega o resultado à página nova pelo cache do React Query. Um teste automático novo repete esse caminho.

O segundo era visual. Na aba Execuções, o selo "passou" aparecia cortado como "pas...". Dá para ver no primeiro print, à direita da linha Sucesso. A linha agora quebra como nas outras listas, e o selo não encolhe.

O conserto dos dois foi escrito 13 minutos depois do fim do QA. Na mesma tarde, ele estava publicado em staging, antes de qualquer pessoa testar a feature. Em produção, ela segue desligada por padrão.