Lista de comprovação após a implantação: o que solicitar depois de uma correção

Por que você deve pedir comprovação depois que uma correção entra em produção

Após uma implantação, correções podem ser difíceis de ver. O app parece o mesmo, o bug é complicado de reproduzir, ou só aparece em uma conta específica ou em um momento específico. Então quando você ouve “está corrigido”, fica na dúvida: a mudança chegou à produção, e resolveu o problema certo?

Pular a comprovação é o caminho para aprovar trabalho que na verdade não foi aplicado onde os usuários estão. Uma correção pode ser mesclada mas não implantada, implantada no ambiente errado, ou liberada mas escondida por cache ou feature flag. Às vezes cobre apenas um caso, e o bug ainda existe em um fluxo ligeiramente diferente. Para áreas de alto impacto como autenticação, pagamentos ou correções de segurança, essa incerteza pode custar dinheiro, prejudicar confiança ou criar risco legal.

Uma lista curta de provas após a implantação elimina a adivinhação sem adicionar reuniões. Ela transforma uma atualização vaga em um pequeno conjunto de recibos: o que mudou, onde está rodando e como foi verificado. Com isso em mãos, você pode escanear rapidamente, encaminhar para um cofundador e aprovar com confiança. Isso não é sobre “ficar em cima dos desenvolvedores”. É sobre tornar o trabalho visível.

Você mais precisa de provas quando:

• O problema aconteceu em produção (não apenas em staging)
• A correção mexeu com login, permissões ou dados de conta
• Dinheiro está envolvido (checkout, assinaturas, faturas)
• Segurança foi mencionada (segredos expostos, risco de injeção)
• Usuários relataram o bug repetidamente ou você prometeu um prazo

Exemplo: um desenvolvedor diz “login está consertado”. Uma lista de provas incluiria a versão/build de produção, o horário da implantação e uma captura de tela ou gravação curta do fluxo exato que falhava agora funcionando (mais um teste negativo, como senha errada).

O que é uma “lista de provas” (e o que não é)

Uma lista de provas é um conjunto curto e itemizado de evidências de que uma correção chegou ao lugar certo e funciona como você espera. É o mínimo necessário para confiar numa mudança sem ler código.

Uma lista de provas deve confirmar três coisas:

• Comportamento: o bug desapareceu
• Escopo: o que foi tocado (e o que não foi)
• Tempo: quando a mudança chegou ao ambiente que importa

Deve permanecer enxuta. Para a maioria das correções, 5 a 10 itens são suficientes, desde que cada item seja específico e fácil de verificar. Também deve ficar onde você já acompanha o trabalho (o mesmo ticket, thread de e-mail ou documento compartilhado) para que não desapareça.

Uma lista de provas normalmente inclui:

• Carimbo de implantação e ambiente (produção vs staging)
• Os passos exatos usados para verificar a correção (2 a 5 passos, escritos de forma simples)
• Capturas de tela ou gravações curtas mostrando o comportamento crítico
• Um pequeno conjunto de logs, mensagens de erro ou snapshots de monitoramento que mudaram
• Notas sobre impacto (por exemplo, “apenas login” vs “auth e cobrança”)

Uma lista de provas não substitui um QA completo, nem é um monte de artefatos técnicos que você não consegue interpretar. Ela deve deixar o resultado mais claro.

O que não é:

• Uma mensagem vaga como “corrigido” ou “implantado” sem evidências
• Um plano de testes longo que ninguém vai executar
• Um despejo de código ou lista de arquivos que você não consegue validar
• Notas de release escritas apenas para desenvolvedores
• Uma promessa de “deve estar tudo bem” sem mostrar resultados

Exemplo: se um desenvolvedor corrigiu um bug no checkout, a lista de provas deve mostrar uma compra de teste bem-sucedida (em produção ou no sandbox de pagamento), o horário da implantação e o erro deixando de aparecer.

O que incluir em uma lista de provas

Uma lista de provas após a implantação é um conjunto curto de recibos que responde três perguntas simples: o que mudou, onde você pode ver isso, e quando mudou. Se você pode verificar isso rapidamente, há menos chance de aprovar uma correção que só funcionou no laptop de alguém.

Mantenha o foco em evidências, não numa longa história. Uma página geralmente basta.

O essencial (o conjunto “confiar, mas verificar”)

Peça isto toda vez, mesmo para correções pequenas:

• O que mudou (em linguagem simples): uma a três frases descrevendo a mudança de comportamento. Exemplo: “Login agora bloqueia usuários inativos e mostra uma mensagem clara.”
• Onde ver: o ambiente exato (produção vs staging), o nome da tela e qualquer papel de usuário necessário (admin, usuário normal, usuário convidado). Se for necessário uma conta de teste, inclua qual.
• Prova do resultado: capturas de tela ou uma gravação curta mostrando os passos chave e o estado final (mensagem de erro, novo botão, layout corrigido).
• Quando e quem verificou: horário da implantação, horário do teste e nome da pessoa que testou.
• O que foi testado (breve): fluxo feliz mais os casos de borda importantes (senha errada, sessão expirada, formulário vazio, rede lenta).

Quando possível, inclua um simples “antes vs depois”. Uma captura de tela antes e outra depois costuma ser mais persuasiva que um parágrafo.

Extras úteis (quando quiser prova mais robusta)

Nem sempre são necessários, mas importam quando a correção mexe com segurança, pagamentos ou dados:

• Identificador do commit/build: hash do commit ou número de build que vincula a prova à versão implantada.
• Logs ou nota de monitoramento: uma captura mostrando que o erro deixou de ocorrer, ou uma métrica retornando ao normal.
• Nota de rollback: uma frase sobre como desfariam a mudança se surgir um novo problema.

Se você herdou código bagunçado gerado por IA, peça a lista de provas mais uma nota curta sobre o que foi limpo (por exemplo: “removeu segredo exposto, adicionou validação no servidor”).

Como pedir (passo a passo)

Comece com critérios de aceitação em uma frase. Mantenha claro e testável, como: “Usuários podem entrar com e-mail e senha, e continuam logados após atualizar a página.” Isso dá ao desenvolvedor um alvo claro e a você algo que pode verificar sem adivinhar.

Em seguida, peça uma lista de provas após a implantação que mapeie cada item de aceitação. Evite uma única mensagem “Corrigido e implantado”. Você quer prova por item, porque uma parte pode parecer ok enquanto outra ainda está quebrada.

Um pedido simples que você pode enviar

Você pode pedir sem soar técnico:

• Compartilhe os critérios de aceitação (uma frase, mais os casos de borda que importam).
• Peça prova por item (numerada, assim você pode responder ao item 3 se estiver confuso).
• Solicite ambos: evidência e passos exatos de verificação (para que você possa repetir o teste depois).
• Especifique o ambiente e o nível de acesso (produção vs staging, admin vs usuário normal, conta de teste vs conta real).
• Defina formato e prazo (exemplo: “10 itens curtos até o fim do dia, cada um com prova com carimbo”).

Também deixe claro o que conta como prova. “Capturas de tela servem, mas incluam horário e conta usada.” Se a correção for só backend, uma captura pode não mostrar muito. Nesse caso, peça o resultado visível ao usuário (uma compra bem-sucedida, um e-mail recebido, uma métrica do dashboard atualizando).

Reduza ambiguidade escolhendo o ambiente exato. “Implantado em staging” pode soar tranquilizador enquanto produção continua quebrada. Se você precisa que produção esteja consertada, diga isso.

Formato sugerido de lista de provas (fácil de escanear)

Peça que usem o mesmo mini-template para cada item: o que mudou, onde foi testado, passos exatos, evidência (captura ou gravação curta) e carimbo de data/hora.

Se as correções parecem arriscadas, solicite um breve “antes vs depois” para revisão rápida.

Perguntas a fazer dependendo do tipo de correção

Uma lista de provas deve variar conforme o que foi consertado. Se você fizer sempre as mesmas perguntas, perde detalhes importantes (como um bug de UI que só acontece em um navegador, ou um bug de API ligado a uma requisição específica).

Use estes prompts para obter evidências que você consegue revisar em minutos.

Perguntas por tipo de correção

• Bug de UI (visual ou fluxo de cliques): “Pode mostrar um print antes/depois da tela exata, mais qual navegador e dispositivo foram usados?” Pergunte também: “Quais passos você usou para reproduzir, e quais passos agora mostram que está consertado?” Se for inconsistente, peça uma gravação curta.

• Bug de backend (API, banco de dados, erro de servidor): “Qual requisição exata falhava, e qual resposta temos agora?” Peça um exemplo real com carimbo de data/hora e o ambiente em que foi executado. Se havia um código de erro: “Qual status víamos antes, e qual vemos agora?”

• Correção de autenticação/permissões: “Quais contas de teste foram usadas e quais papéis elas têm?” Depois, pergunte sobre casos de borda: “Testaram login, logout, sessão expirada, reset de senha e um usuário sem acesso?” Se tokens ou cookies estiverem envolvidos: “O que mudou que impede a falha antiga?”

• Correção de segurança (vulnerabilidade): “O que era vulnerável em linguagem simples, e o que um atacante podia fazer?” Siga com: “O que mudou para bloquear isso?” e “Como validaram a correção?” (uma tentativa de teste que agora falha, resultado de scanner ou nota de revisão). Se segredos foram expostos: “As chaves foram rotacionadas, e como sabemos que as antigas não funcionam?”

• Correção de performance (páginas lentas, timeouts): “Qual métrica melhorou, e onde foi medida?” Peça números de antes/depois e o período de medição. Pergunte também: “O teste foi feito com dados e tráfego parecidos com produção ou apenas uma amostra pequena?”

Se estiver lidando com código gerado por IA, correções de segurança merecem prova extra porque mudanças pequenas podem esconder riscos maiores.

Depois de receber a prova, verifique uma coisa você mesmo (uma tela, uma conta, um fluxo). Essa checagem rápida costuma pegar mal-entendidos antes que se tornem outro problema em produção.

Como revisar a prova rapidamente (sem habilidades técnicas profundas)

Trate a lista de provas como uma checagem rápida de confiança, não uma auditoria completa. Seu objetivo é confirmar que a correção é real, está no ambiente certo e corresponde ao que você pediu.

Comece pelo item de maior risco e limite seu tempo a cinco minutos. Se o risco for “usuários não conseguem entrar” ou “pagamentos falham”, verifique isso primeiro.

Fluxo de revisão de 5 minutos

Leia a prova uma vez, depois faça uma checagem rápida:

• Identifique a ação de usuário mais importante (entrar, finalizar compra, reset de senha).
• Confirme o escopo em palavras simples: o que mudou e o que não mudou.
• Verifique carimbos contra a janela de implantação esperada.
• Teste com a mesma configuração que seus usuários têm: tipo de dispositivo, papel de conta e ambiente.
• Pergunte uma coisa de acompanhamento: “O que devo observar nas próximas 24 horas?” Uma boa resposta indica um ou dois sinais, como pico de erro ou tíquetes de suporte sobre uma tela específica.

Depois faça uma checagem de limites. Você não precisa entender o código, mas deve entender o que a mudança não tocou. Uma lista de provas limpa facilita dizer: “Isto tocou login, sessões e redirects, não tocou signup, não tocou cobrança.”

Sinais rápidos de que algo está errado

Sinais de alerta que merecem seguimento:

• A prova é só palavras como “corrigido” sem capturas, logs ou carimbos.
• Evidência vem de staging quando você pediu produção.
• Capturas mostram uma etapa diferente da que falhava (mostram a homepage, não o formulário que quebrava).
• Os passos usam uma conta admin mesmo que a maioria dos usuários seja padrão.

Exemplo: para uma correção de login, peça uma captura de um login real com usuário normal, o carimbo de implantação e uma nota curta sobre o que mudou (por exemplo, “configuração de cookie atualizada” ou “loop de redirecionamento removido”).

Checklist rápido que você pode copiar e usar sempre

Quando uma correção vai ao ar, peça uma lista curta de provas após a implantação. Deve ser rápida de ler, fácil de repetir e específica o bastante para que você verifique em poucos minutos.

Use este checklist como padrão:

• Para cada item de prova: ambiente (prod ou staging), passos exatos, evidência (captura ou clipe) e carimbo de data/hora.
• A evidência combina com a afirmação: mostra a tela exata, tipo de conta e estado ligado ao bug original (não uma página genérica de “funciona agora”).
• Você consegue reproduzir: passos escritos de forma que uma pessoa não técnica consiga seguir e ver o mesmo resultado.
• Mudanças de configuração estão listadas: quaisquer variáveis de ambiente, feature flags, permissões ou configurações de terceiros alteradas são nomeadas (e onde foram modificadas).
• Plano de risco está incluído: se a correção toca auth, pagamentos ou dados, inclua um plano de rollback ou mitigação.

Se quiser um template copiável, envie isto:

Proof list request
1) Issue/Change:
2) Environment: production / staging
3) Location: page/feature + account used
4) Steps to verify:
5) Evidence: screenshot/clip + timestamp:
6) Related config changes (if any):
7) Rollback/mitigation (if high risk):

Se algo parecer vago, insista no que falta. Na maioria das vezes é ou os passos ou a evidência.

Armadilhas comuns e como evitá-las

O maior risco após a implantação é achar que algo está consertado porque você viu “algo” mudar. Prova só funciona quando é específica e ligada ao problema real.

Armadilha 1: Uma captura sem passos

Uma única captura pode ser real e ainda assim sem significado. Pode ser uma página em cache, uma execução de sorte ou um fluxo diferente do que falhava.

Evite pedindo os passos exatos seguidos, os dados usados (conta de teste ou registro de exemplo) e um carimbo de data/hora. Melhor ainda: uma gravação curta do início ao fim.

Armadilha 2: Prova do ambiente errado

Pessoas testam em staging e depois anunciam que está ao vivo.

Evite pedindo que o ambiente seja declarado em palavras claras e incluindo um carimbo de produção. Se seu app mostra uma versão no rodapé ou numa página admin, peça para incluírem.

Armadilha 3: Correções de auth que ignoram papéis e permissões

Bugs de login costumam “funcionar para mim” porque o desenvolvedor testou com conta admin.

Evite pedindo qual papel de usuário foi usado para cada teste e quais permissões esse papel tem. Se há admin, membro e convidado, consiga prova para cada fluxo relevante.

Armadilha 4: Falta de casos de borda

Muitos bugs se escondem em entradas ruins e estados vazios, não no fluxo normal.

Evite pedindo provas para alguns casos de borda: campos em branco, senha errada, sessão expirada e um usuário sem dados ainda.

Armadilha 5: Prova do sintoma, não da causa raiz

Às vezes a UI parece correta, mas o problema subjacente continua e vai voltar.

Evite pedindo uma nota curta de “o que mudou e por quê” mais evidência de que a falha original sumiu (por exemplo, um trecho de log antes/depois).

Se quiser um pedido padrão simples, solicite:

• Ambiente (produção ou staging) e carimbo
• Passos de reprodução testados (os passos do bug original)
• Contas e papéis usados (especialmente para auth)
• Casos de borda testados (2 a 3 realistas)
• Uma nota curta sobre a causa raiz e a mudança exata feita

Exemplo: validar uma correção de login implantada em um projeto real

Um caso realista: seu app foi gerado com uma ferramenta de IA, uma atualização rápida saiu e agora alguns usuários não conseguem entrar. Funciona para você, mas alguns clientes veem erro ou ficam presos.

Você pede uma lista de provas após a implantação para confiar no que mudou e em quem isso ajuda. Não precisa de um relatório extenso. Precisa de prova que combine com o risco: papéis, dispositivos e a falha exata que você viu.

Prova mínima a pedir:

• O identificador de build/release agora em produção, mais o horário da implantação.
• Uma captura de tela de um login bem-sucedido como usuário normal, incluindo a tela de destino.
• Uma captura de tela de login bem-sucedido como admin ou equipe, incluindo uma página restrita por permissões.
• Uma captura de outro tipo de dispositivo (por exemplo, iPhone Safari e Windows Chrome).
• Evidência de que o erro original sumiu: uma captura dos logs ou do tracker de erros filtrada para os últimos 30–60 minutos.

Peça também uma lista curta e numerada: os passos que antes falhavam e os mesmos passos agora passando, com carimbos.

Como decidir:

• Aprovado: papéis e dispositivos funcionam e a taxa de erro cai.
• Aprovado parcialmente: funciona para um papel ou dispositivo apenas; peça uma prova direcionada adicional.
• Pedir rollback: o erro ainda acontece em produção, ou surge um novo problema de login.

Próximos passos quando você ainda não está confiante

Se leu a lista de provas e ainda está inseguro, não ignore. Normalmente duas coisas acontecem: a prova é fraca, ou a correção está certa mas os riscos não foram cobertos (casos de borda, segurança, monitoramento ou rollback).

Primeiro, guarde o que recebeu. Mantenha a lista de provas junto das notas de release, mesmo que incompleta. Semanas depois, quando algo quebrar de novo, esse registro é a forma mais rápida de saber o que mudou, quando e o que foi verificado.

Um plano simples de próximos passos:

• Escreva o que ainda está incerto em linguagem simples.
• Peça 1 ou 2 itens de prova faltantes que resolvam a dúvida.
• Solicite um reteste do caminho de risco, não um “parece ok” geral.
• Combine um plano de rollback se a mudança for de alto risco.
• Agende uma checagem de acompanhamento para revisar métricas e tíquetes de suporte.

Torne repetível. Se perceber que pede sempre os mesmos itens, transforme-os em um template padrão.

Quando escalar para uma revisão independente

Se a correção mexeu com código gerado por IA e continua quebrando, muitas vezes é problema da base de código, não de um bug isolado. Protótipos gerados por IA podem esconder problemas como lógica emaranhada, segredos expostos, auth frágil, queries inseguras e padrões que não escalam. Dá para remendar sintomas por semanas sem resolver a causa.

Nessa situação, uma revisão independente pode ser o caminho mais rápido para confiança. FixMyMess executa auditorias de código gratuitas para identificar o que está quebrado, depois corrige a lógica, endurece a segurança, refatora áreas confusas e prepara implantações com verificação humana.

Se quiser uma ação clara: reúna as provas que já tem, anote o que ainda causa dúvida e decida se precisa de uma intervenção mais profunda (não apenas mais um patch).