Testes de smoke pós-release que fundadores podem rodar em 10 minutos

O que é um smoke test (e por que importa após o deploy)

Um smoke test é uma verificação rápida que você roda logo após uma release para responder a uma pergunta: o produto continua funcionando nas formas que mais importam? Não se trata de achar todos os bugs. É uma checagem rápida de passa/falha que captura as falhas que usuários reais encontram primeiro.

Pense nisso como o conjunto mínimo de ações que um cliente faria: entrar, completar a ação principal (criar ou atualizar algo), receber um email chave e (se você cobra) completar um pagamento. Se qualquer uma dessas coisas quebrar, você quer saber em minutos, não depois que os chamados de suporte se acumularem.

Smoke tests não são QA completo. Eles não substituem testes automatizados, testes aprofundados de casos de borda, revisão de acessibilidade ou testes de segurança. E também não devem levar uma hora. Se sua checagem de release precisa de uma planilha e uma reunião, ela será pulada. O ponto é velocidade e repetibilidade.

Muitas falhas só aparecem depois do deploy porque a produção se comporta diferente do seu laptop. As causas geralmente são chatas, mas cruéis: variáveis de ambiente erradas (chaves de API, configurações de email, webhooks de pagamento), segredos rotacionados, diferenças de permissões, migrations que rodaram mas não corresponderam ao que o código espera, ou comportamento de cache/CDN que altera rotas, cookies ou headers.

Isso é especialmente útil para fundadores que lançam rápido com times pequenos e para qualquer um que dependa de código gerado por IA e protótipos rápidos. Quando você se move rápido, um smoke test simples e consistente pode ser a diferença entre um lançamento calmo e um incêndio.

Antes de começar: 2 minutos de preparação

Um smoke test de 10 minutos funciona melhor quando você não improvisa. Gaste dois minutos montando um pequeno “kit de teste” para que os resultados fiquem claros e repetíveis.

Primeiro, escolha os usuários exatos com os quais você vai testar. Use uma conta normal e uma de admin (ou os papéis que seu app tiver). Certifique-se de que as contas estejam em estado limpo: sem onboarding pela metade, sem trial expirado, sem perfil bloqueado.

Em seguida, confirme onde você está testando. Anote o ambiente deployado (produção, staging ou preview) e a URL exata. Muitos “bugs” são só alguém testando o lugar errado ou confundindo duas versões.

Por fim, garanta que você pode validar as duas coisas que não se veem totalmente pela UI: email e pagamentos. Tenha uma caixa de entrada aberta para o usuário de teste (e verifique spam/promoções). Se seu app cobra, confirme que você está no modo correto (teste vs live) e que pode acessar onde verificar uma cobrança bem-sucedida.

Mantenha uma nota simples aberta e registre os resultados enquanto avança. Não confie na memória.

Tenha prontos:

• Credenciais de usuário de teste e admin
• O nome do ambiente e a URL que você está testando
• Acesso à caixa de entrada de teste (e uma forma de pesquisar nela)
• Onde você verifica resultados de pagamento (se aplicável)

Se algo falhar depois, essas notas (e uma captura de tela, se necessário) economizam horas de troca de informações.

A execução de 10 minutos: fluxo passo a passo simples

Ajuste um cronômetro para 10 minutos e rode a mesma rota toda vez. O objetivo não é provar que tudo funciona. É capturar as falhas que bloqueiam usuários reais logo após o deploy.

Use uma janela privada do navegador para não obter um falso positivo por sessão em cache.

A ordem fixa (não improvise)

Execute as checagens em sequência estrita. Assim você pode comparar resultados entre releases e identificar exatamente onde algo quebrou.

1. Abra o app como um novo usuário faria (da landing page ao app).
2. Faça login (ou sign-up) e confirme que você chega à tela inicial esperada.
3. Execute a ação principal do produto (criar, atualizar e visualizar a entidade principal).
4. Dispare uma notificação que os usuários dependem (email ou in-app).
5. Se você cobra, execute um pequeno fluxo de pagamento end-to-end em modo teste.

O que fazer quando algo quebra

Trate a primeira falha séria como uma placa de pare. Não continue clicando “só para coletar mais info.” Você vai misturar sintomas e perder tempo.

Escreva uma pequena nota de bug que torne a reprodução fácil: o que você clicou, o que esperava, o que aconteceu e qualquer mensagem de erro. Uma captura de tela ajuda, mas os passos importam mais.

Depois de um conserto, reteste a área quebrada primeiro usando os mesmos passos. Se passar, continue na ordem. Rechecar aleatoriamente cria confusão e oculta a causa raiz.

Go/no-go em um minuto

Antes de liberar, decida o que deve passar. Mantenha pouco: login funciona, o fluxo core de criar/editar/ver funciona, emails críticos chegam e pagamentos são bem-sucedidos (se aplicável). Se qualquer item obrigatório falhar, é no-go mesmo que o resto pareça ok.

Checagens de login e autenticação

A maioria dos smoke tests deve começar pela autenticação, porque uma pequena mudança pode trancar todo mundo fora. Use uma janela privada (ou outro navegador) para não usar uma sessão em cache por engano.

As 5 checagens que pegam a maioria das falhas de auth

Rode essas rápidas, em ordem, e pare assim que algo parecer errado:

• Crie uma conta totalmente nova (se o sign-up estiver habilitado) e confirme que você chega à página esperada.
• Faça logout e entre novamente com a mesma conta.
• Abra uma página protegida estando deslogado (por exemplo, a URL do dashboard) e confirme que você é bloqueado ou redirecionado para o login.
• Use “esqueci a senha” e complete o reset. Confirme que o email chega e que o link de reset funciona em uma janela privada.
• Depois do reset, faça login de novo e confirme que você permanece logado após um refresh.

Mantenha o critério simples. Você está confirmando que o app consegue criar uma sessão, mantê-la e proteger páginas privadas.

Uma falha comum: após um deploy, cookies ficam definidos para o domínio errado ou marcados como “secure” de forma que quebram no seu ambiente. O sintoma parece “login funciona”, mas todo refresh te desloga.

Se o app suporta login por Google/GitHub, faça uma passagem rápida também, mas não deixe isso substituir o check de email/senha. Social auth pode passar enquanto o seu tratamento de sessão está quebrado.

Quando qualquer passo falhar, anote a tela exata e a mensagem vista.

Fluxos core CRUD em menos de 3 minutos

CRUD é criar, ver, editar, excluir. Se qualquer um desses quebrar após um deploy, os usuários sentem isso imediatamente. O objetivo aqui não é testar perfeitamente. É um sinal rápido de que seu app ainda é utilizável.

Escolha um “objeto core” em que seu produto vive (um projeto, tarefa, cliente, fatura, anúncio). Use uma conta de teste e rode o mesmo loop sempre.

O loop de CRUD de 3 minutos

Mova-se rápido e mantenha simples:

• Crie um registro novo com um nome curto e único, como “Smoke 2026-01-16 10:05.” Confirme que salva e que você chega onde espera.
• Encontre-o novamente na lista principal (ou dashboard). Se busca ou filtros são chave, use-os uma vez.
• Edite um campo óbvio (renomeie). Verifique dois lugares onde o valor deve aparecer (página de detalhe + lista).
• Delete-o. Confirme que desaparece de verdade após refresh, não só fica escondido.
• Tente uma entrada “ruim” uma vez: deixe um campo obrigatório vazio, cole um texto muito longo ou inclua caracteres especiais. Você quer mensagens de erro claras e humanas.

Se algo falhar, registre o que você fez e o que viu. “Clicar em Salvar -> spinner eterno” é muito mais útil que “CRUD quebrado”.

Como é uma falha bem tratada

Um app bom bloqueia entrada ruim com uma mensagem curta como “Nome é obrigatório.” Um app ruim mostra página em branco, texto bruto de erro ou descarta mudanças silenciosamente.

Se você renomeia um registro e a página de detalhe atualiza, mas a lista ainda mostra o nome antigo após refresh, isso costuma apontar para cache, uma atualização em background falha ou um deploy parcial.

Checagens de email e notificações

Email é onde “tudo parecia bem no app” vira “usuários acham que está quebrado.” Uma verificação rápida de email é uma das partes de maior valor de um smoke test porque pega chaves ausentes, templates errados e envio bloqueado.

Dispare um email transacional real a partir do produto (não por uma ferramenta administrativa). Boas escolhas: reset de senha, convite ou recibo.

Mantenha o check focado:

• Confirme que o email chega em alguns minutos.
• Confirme que o remetente/from parece correto (não um placeholder).
• Procure problemas óbvios de template (como {{name}} aparecendo).
• Clique no botão principal e confirme que ele leva à página certa e que a ação funciona.

Fique atento a sinais que costumam aparecer após deploy mesmo quando a UI parece ok: atrasos longos (workers/filas), duplicados (retries sem idempotência), variáveis faltando, branding/links do ambiente errado ou links que abrem mas falham no passo final.

Se você usa emails de convite, faça um fluxo completo: envie um convite, abra-o em outro navegador (ou janela privada), aceite e confirme que você cai no workspace/conta correta.

Exemplo: você testa reset de senha, o email chega, mas o botão abre uma página dizendo “token inválido.” Isso frequentemente aponta para mismatch na URL do app, domínio do cookie ou chaves secretas entre ambientes.

Checagens de pagamentos e faturamento

Pagamentos falham de formas previsíveis após um deploy: checkout para de funcionar, o callback de sucesso não chega ao seu app ou o usuário paga mas continua aparecendo como não pago. Uma verificação rápida de pagamento é uma das checagens mais valiosas que você pode fazer.

Um pagamento bem-sucedido

Escolha o plano mais barato (ou um item de teste de $1) e faça uma compra completa: do pricing ao recibo.

• Inicie o checkout e confirme valor, moeda e nome do plano estão corretos.
• Complete o pagamento e verifique que você chega em uma página de sucesso clara.
• Atualize o app e confirme que o estado do usuário mudou (plano ativo, acesso destravado, créditos adicionados, o que você vende).
• Abra a conta do usuário ou a tela de faturamento e confirme que o status bate com o que você acabou de comprar.

Se você usa webhook, é aqui que problemas aparecem. Uma falha comum: o pagamento sucede, mas o acesso não é liberado porque a secret do webhook, endpoint ou variável de ambiente mudou.

Caminhos de pagamento falho, cancelado e reembolso

Faça uma execução “ruim” de propósito (cancele no checkout, use um cartão que falha ou dispare qualquer modo de erro que seu provedor suporte). Usuários devem ver uma mensagem normal, não um spinner eterno.

• Cancele ou falhe o pagamento e confirme que o app explica o que aconteceu e o que fazer a seguir.
• Confirme que o usuário não fica marcado como pago (sem acesso, sem créditos adicionados).
• Se seu produto tem reembolso ou cancelamento de assinatura, teste esse fluxo uma vez e confirme que o status atualiza após refresh.

Por fim, verifique o que seu app exibe e envia. Sua UI e emails não devem mostrar números completos de cartão, códigos de segurança, chaves de API ou dumps brutos de erro. Uma boa regra: se você não colaria isso em um chat de suporte, não mostre ao cliente.

Checklist rápido (copie e reuse)

Copie isto nas notas de release para rodar os mesmos checks toda vez. Mantenha consistente. O objetivo é pegar as falhas comuns de “ontem funcionava” logo após o deploy.

Release: __________ Data/hora: __________ Ambiente: __________

O que mudou nesta release (1–2 linhas):

Se algo falhar, escreva o menor detalhe que ajude a debugar: o passo exato, o email do usuário usado e o texto do erro.

Go/No-Go: ________ Responsável: ________ Se No-Go, rollback? ________ Tickets de follow-up: ________

Erros comuns que fazem smoke tests perderem falhas reais

A maior armadilha é testar o app que você gostaria de ter lançado, não o que os usuários realmente recebem. Um smoke test deve ser um pouco incômodo: sessão de navegador nova, domínio real, dados reais e mesmas permissões de um usuário comum.

Um erro comum é permanecer logado como desenvolvedor ou admin. Isso pode esconder permissões quebradas, passos de onboarding faltando e páginas que só funcionam porque você já tem dados semeados. Use janela anônima e uma conta básica, ou crie uma nova toda vez.

Outro erro é testar o ambiente errado. Se você clica num build de preview mas os clientes usam produção, pode perder exatamente o que quebra depois do deploy: variáveis de ambiente erradas, migrations faltando ou callback URL mal configurada.

Email é especialmente traiçoeiro. Muitas vezes funciona localmente com uma inbox dev e depois falha em produção porque falta chave do provedor, domínio de envio não verificado ou mensagens vão para spam. Trate cada deploy como se o email pudesse estar quebrado até ver uma mensagem real chegar.

Auth é outro ponto comum de ruptura. Se você só testa “login funciona”, ainda pode liberar logout, reset de senha ou expiração de sessão quebrados.

Alguns hábitos que fazem seu smoke test pegar mais problemas reais:

• Teste como um usuário novato e como um usuário existente normal (não só como admin).
• Teste no ambiente realmente deployado, não só local ou preview.
• Verifique que um email real chega (e que o link dentro funciona).
• Inclua logout e reset de senha toda vez.
• Se algo falhar, mude uma coisa, reteste e anote o que mudou.

Não ignore “está só lento hoje.” Usuários encontram timeouts, clicam duas vezes e atualizam no meio do carregamento. Se uma página está instável durante seu check de 10 minutos, isso costuma ser o primeiro bug real em produção.

Exemplo: detectar uma falha pós-deploy em minutos

Maya roda um pequeno SaaS. Ela publica uma mudança numa sexta que “só toca a UI” e faz o deploy. Antes de anunciar, ela roda o smoke test em janela privada.

Tudo parece ok até ela tentar reset de senha. O formulário aceita o email e mostra uma mensagem de sucesso, mas nenhum email de reset chega.

Em vez de chutar, ela checa o escopo rápido. Cria uma conta de teste nova para disparar o email de boas-vindas. Esse chega. Depois tenta “alterar email” (se o app envia confirmação). Esse também chega. Então não é “todo email está quebrado.” É especificamente o caminho de reset de senha.

Isso aponta para uma falha pós-deploy comum: um template, um endpoint ou um job de background falhando enquanto o resto do sistema parece saudável. No caso da Maya, a mensagem de reset foi movida para um novo ID de template, mas a variável de ambiente de produção ainda apontava para o antigo.

Agora ela toma uma decisão simples:

• Se usuários não conseguem logar, faça rollback primeiro e depois corrija.
• Se só o reset de senha está afetado e o conserto é seguro, publique um hotfix.
• De qualquer forma, poste uma nota curta de status para que o suporte não seja pego de surpresa.

Ela escolhe o hotfix, atualiza o ID do template, redeploya e repete o passo do reset. O email chega em menos de um minuto.

Por fim, ela atualiza sua checklist para a próxima vez: “disparar reset de senha e confirmar recebimento” além de “verificar o template/worker específico, não só o envio geral de emails.”

Próximos passos quando algo falha (e como FixMyMess pode ajudar)

Quando um smoke test falha, trate como uma placa de pare, não um lombada. Se a mesma falha acontecer duas vezes, bloquear cadastros ou pagamentos, ou parecer um problema de segurança (dados expostos, acesso admin estranho, chaves vazadas), pare a release e faça rollback se possível.

Uma regra simples: se usuários não conseguem logar, criar dados ou pagar, você não está mais “testando.” Você está entregando um produto quebrado.

Capture um pequeno pacote de informações antes de pedir para alguém consertar. Isso economiza horas e acelera o reparo:

• Passos exatos que você seguiu (1, 2, 3), começando de uma aba nova do navegador
• O que você esperava vs o que aconteceu (inclua texto de erro)
• Captura de tela ou gravação curta
• Timestamp e fuso horário
• Detalhes do ambiente (produção vs staging, navegador, email da conta)

Depois transforme a checklist em hábito. Rode-a logo após o deploy e novamente após qualquer hotfix. Se você rastreia issues, marque-as consistentemente (login, CRUD, email, pagamentos) para que padrões apareçam.

Se seu app foi gerado por ferramentas como Lovable, Bolt, v0, Cursor ou Replit, falhas pós-deploy costumam ser sintomas de problemas mais profundos: auth quebrada, segredos expostos, arquitetura bagunçada ou queries inseguras no banco. Nesses casos, remendar só o erro visível nem sempre basta.

Se você herdou uma base de código gerada por IA que continua quebrando após deploy, FixMyMess (fixmymess.ai) pode rodar uma auditoria de código gratuita e depois remediar as causas raízes, desde reparos de auth e lógica até hardening de segurança e preparação para deploy.