O que é, o que faz e o que entrega 1. O que é O CEBI Tester é a ferramenta de validação funcional de liberação de versão dos sistemas. Ele executa, sem intervenção, os casos de teste já catalogados contra o ambiente de um cliente, recolhe evidência de cada passo e emite um veredito sobre a versão: apta, apta com ressalvas ou não recomendada. A pergunta que ele responde não é "a tela abriu?", e sim: O processo de negócio continuou funcionando do início ao fim, e os dados que ficaram gravados estão consistentes? É a diferença entre a tela dizer que gravou e ter gravado. Quando o caso permite, a ferramenta confere no banco o que a tela afirmou. 2. O problema que ele resolve A validação de uma versão era feita a partir de checklists em texto, lidos e executados à mão a cada liberação. Isso tem três custos: Custo O que acontecia Tempo Cada liberação recomeçava do zero, tela a tela Cobertura O que não dava tempo de conferir simplesmente não era conferido — e ninguém sabia o que ficou de fora Rastro "Testei e passou" não é evidência; sem print e sem dado, a conversa com o desenvolvimento vira opinião contra opinião O CEBI Tester transforma cada item de checklist em caso permanente: escrito uma vez, executado quantas vezes for preciso, sempre do mesmo jeito, sempre deixando prova. 3. O que ele faz, numa execução Cada rodada percorre esta sequência, sozinha: Identifica o ambiente do cliente escolhido e valida que ele responde. Detecta a versão publicada lendo o próprio sistema — a versão nunca é digitada, porque muda várias vezes ao dia e sobe por módulo. Prepara a base, quando o cliente exige preparação (perfil de permissão, massa, parâmetros). Seleciona os casos no catálogo, conforme o escopo pedido. Executa pela interface e pela API, como um usuário faria. Captura evidência de cada passo: prints, dados da tela, requisições e respostas, console e rede. Confere na base o que a tela afirmou, nos casos em que isso é possível. Classifica a causa de cada falha — produto, ambiente, base ou a própria ferramenta. Grava o resultado e gera o relatório da versão. O passo 8 é o que diferencia a ferramenta de um robô de clique: falha não vira defeito automaticamente. Falta de massa, ambiente fora do ar e permissão ausente saem como bloqueio, com o motivo medido — não como acusação ao produto. 4. O que ele entrega Veredito da versão Apta, apta com ressalvas ou não recomendada, com o que impede liberar explicitado: reprovados de severidade Crítica/Alta, casos sem causa identificada e módulos sem nenhuma medição. Cobertura Quanto do catálogo foi efetivamente exercido naquela rodada. Cobertura baixa não é defeito do produto — é aviso de que a versão foi pouco medida, e isso fica registrado em vez de passar despercebido. Defeitos com evidência Cada defeito sai com severidade, passo a passo para reproduzir, prints, dados e o contexto (versão, ambiente, caso). Dá para copiar e abrir o chamado sem reescrever nada. Bloqueios por responsável O que não pôde ser medido, agrupado por de quem depende destravar: ambiente, base ou a própria ferramenta. Isso vira lista de trabalho, não discussão. Relatório da versão Documento completo, com quatro escopos de impressão — do resumo executivo ao dossiê com evidências. Histórico Defeito que reincide é marcado como tal, inclusive com a contagem de versões seguidas. Registra também defeito retirado, para que uma retratação não suma sem rastro. Catálogo permanente A biblioteca de casos é o ativo que fica: hoje são 388 casos, 338 automatizados, em 15 ambientes de cliente configurados. Produto Casos Automatizados Balcão Comercial 275 275 Baixa 63 63 Hidrometria 49 — Usuários — — 5. Como a IA entra (e onde ela não entra) Claude (IA) CEBI Tester (programa) Quando Ao chegar uma versão nova; ao analisar falha sem causa determinada Em toda execução Faz Interpreta as demandas, faz análise de impacto, seleciona a regressão, escreve os casos que faltam, redige o resumo executivo Prepara a base, autentica, executa, compara, confere no banco, classifica a causa, gera relatório e evidências Custa token Sim Não Depois que um caso é escrito e aprovado, ele roda quantas vezes for preciso sem IA. O trabalho caro acontece uma vez; a execução é barata e repetível. 6. O que ele não faz Não decide sozinho liberar. Ele mede e sustenta a decisão com evidência; a decisão é do time. Não testa desempenho nem carga. O escopo é funcional. Não envia nada para cliente. E-mail e SMS só saem para destinos autorizados do time — nas bases de homologação o contato cadastrado costuma ser de pessoa real. Não inventa resultado. Quando não dá para medir, o caso sai bloqueado, com a causa. Caso bloqueado nunca é contado como aprovado. Não cobre o que não está no catálogo. O que não tem caso escrito aparece como módulo sem medição — a lacuna é exibida, não escondida. 7. Resultados até aqui A ferramenta encontrou defeitos que a conferência manual não pegava — entre eles, um modal de pagamento que mostrava só parte do valor devido, uma operação de desagrupamento que falha na primeira chamada e deixa o agrupamento pela metade, e uma segunda via de parcela que não é emitida em nenhum ambiente. E derrubou acusações falsas ao produto: casos que pareciam defeito e eram limitação da própria automação — grid paginado lido pela metade, aviso que some da tela em quatro segundos, botão julgado antes de preencher os campos obrigatórios. Cada um desses virou regra permanente da ferramenta. A segunda parte vale tanto quanto a primeira: uma ferramenta que acusa o que não existe perde a confiança do desenvolvimento na primeira reunião.