Quase todo conteúdo sobre “checklist de go-live” que você encontra em português foi escrito para e-commerce. Testar o catálogo, simular uma compra, conferir o cálculo de frete, ver se o cupom aplica. É útil se você tem uma loja. Mas se o que você vai publicar é um web app — um SaaS, um portal do cliente, um backoffice, uma ferramenta interna —, esse checklist cobre metade do mapa e ignora justamente a parte que mais quebra: estados de usuário, permissões, dados que persistem e integrações que falham em silêncio.
Este texto faz esse reframe. A ideia não é te transformar em engenheiro de QA nem te vender a fantasia de 100% de cobertura de testes. É o oposto: qual é o mínimo de qualidade que separa um go-live tranquilo de um domingo consertando produção às pressas — para quem não tem um time de QA e não vai ter tão cedo. Spoiler: é menos trabalho do que parece, desde que você teste as coisas certas.
O que “testar antes do go-live” significa aqui (definição)
Go-live de web app com segurança é subir sabendo que os fluxos que geram receita e risco funcionam, que erro em produção gera alerta e que dá para reverter em minutos. Não é cobrir tudo — é cobrir o que dói.
Guarde essa hierarquia: fluxo crítico > cobertura total. Um app com teste em cada função e um checkout quebrado é pior do que um app com três fluxos críticos garantidos e o resto no olho. Qualidade sob restrição de tempo é priorização, não perfeccionismo.
Por que testar depois sai caro
Vale gastar um parágrafo no argumento econômico, porque ele muda a conversa de “custo de testar” para “custo de não testar”. A literatura de engenharia de software é consistente há décadas: quanto mais tarde um defeito é encontrado, mais caro ele é para corrigir. Um relatório clássico do Systems Sciences Institute da IBM, amplamente citado em análises sobre o custo de bugs, aponta que consertar um problema em produção pode custar ordens de grandeza mais do que pegá-lo nas fases iniciais.
E não é só o custo do conserto em si. Como detalha uma análise em português sobre o custo efetivo dos bugs, o problema em produção soma retrabalho, indisponibilidade, impacto na experiência do usuário e custo operacional. Ou seja: o cálculo “não tenho tempo para testar” quase sempre está comparando as horas erradas. As horas de teste antes são baratas; as horas de incêndio depois é que custam caro — e vêm acompanhadas de cliente insatisfeito.
O mínimo viável de QA em quatro camadas
Você não precisa de uma pirâmide de testes acadêmica. Precisa de quatro camadas, em ordem de prioridade. Se o tempo acabar, você para na camada que der — mas nunca comece pela última.
1. Smoke test: o app está de pé?
Smoke test é a verificação mais rápida possível de que o essencial não está quebrado. Dá para acessar? Dá para logar? A tela principal carrega sem erro? O registro central (pedido, projeto, lead — o que for o coração do seu app) pode ser criado? Se a fumaça já sobe aqui, pare: não faz sentido testar detalhe algum enquanto o app não fica em pé. É o teste que você roda logo depois de cada deploy, inclusive em produção, em menos de cinco minutos.
2. Fluxos críticos: o que gera receita e risco
Aqui mora o grosso do valor. Liste os fluxos que, se quebrarem, custam dinheiro ou confiança na hora: pagamento, cadastro, login, reset de senha, captura de lead, e toda ação irreversível — excluir, enviar, cobrar, publicar. Teste cada um de ponta a ponta, com dados reais de teste, do primeiro clique até a confirmação. Esses são os fluxos que você garante sempre, a cada release, nem que seja manualmente com um roteiro escrito.
3. Casos de borda dos críticos
Depois que o caminho feliz funciona, teste o infeliz dos mesmos fluxos. Cartão recusado. E-mail já cadastrado. Sessão expirada no meio da compra. Envio de formulário com internet caindo. Você não vai cobrir todos os edge cases do universo — vai cobrir os que acontecem nos fluxos que importam. É aqui que idempotência aparece: clicar “pagar” duas vezes não pode gerar duas cobranças.
4. Regressão dos caminhos que já quebraram
Toda vez que um bug escapa e é corrigido, ele vira um item permanente da sua lista de verificação. Software tende a reabrir buracos já fechados quando ninguém está olhando. Manter um roteiro de regressão — mesmo que seja uma planilha de “confira estas 10 coisas antes de cada deploy” — é o que impede o mesmo problema de voltar pela terceira vez.
Checklist de go-live para quem não tem QA
Imprima, cole na parede, use a cada lançamento:
| Camada | Item | Passa? |
|---|---|---|
| Smoke | App carrega, login funciona, tela principal abre | ☐ |
| Smoke | Registro central pode ser criado | ☐ |
| Crítico | Pagamento / cobrança de ponta a ponta | ☐ |
| Crítico | Cadastro, login, reset de senha, logout | ☐ |
| Crítico | Captura de lead / formulário principal chega ao destino | ☐ |
| Crítico | Ações irreversíveis pedem confirmação e funcionam | ☐ |
| Borda | Cartão recusado, e-mail duplicado, sessão expirada | ☐ |
| Borda | Duplo clique não duplica cobrança (idempotência) | ☐ |
| Permissões | Usuário comum não acessa rota/dado de admin | ☐ |
| Integrações | Webhooks e APIs externas respondem e tratam falha | ☐ |
| Observabilidade | Erro em produção gera alerta para alguém | ☐ |
| Rollback | Reversão para versão anterior ensaiada e funcionando | ☐ |
Repare que metade desses itens não aparece em nenhum checklist de e-commerce. Permissões, idempotência, integrações e rollback são o que diferencia testar um web app de testar uma loja. E são exatamente os itens que se cruzam com os riscos de publicar apps em produção — testar antes é a outra face de auditar antes.
Rollback e observabilidade: o que fazer quando algo passa
Nenhum teste pega tudo. Por isso as duas últimas linhas do checklist são as mais importantes: elas são o seu plano para quando um bug inevitavelmente escapar.
Observabilidade é ter olhos em produção. Um erro que ninguém vê é um erro que só o cliente vai reportar — e aí já é tarde. Ter alerta de erro configurado, nem que seja um aviso simples no seu canal de time, transforma “descobri pela reclamação” em “descobri antes do cliente”. Na primeira hora após o go-live, alguém precisa estar olhando ativamente.
Rollback é o botão de voltar. E o ponto que quase todo mundo erra: rollback só conta se você já ensaiou. Ter a teoria de que “dá para reverter” não vale nada se você nunca reverteu de fato. Ensaie uma vez, em ambiente controlado, para saber que funciona — porque a hora de descobrir que o rollback está quebrado não pode ser a hora em que você precisa dele. Esse rigor é parte da mesma disciplina de levar um MVP do zero à produção sem depender de sorte.
Como caber isso num prazo apertado
A objeção é sempre a mesma: “o prazo não deixa”. Então priorize por camada e seja honesto sobre onde parou. Se só deu para smoke test e fluxos críticos, tudo bem — você cobriu o que mais dói e sabe o que ficou de fora. O pecado não é ter cobertura parcial; é ter cobertura parcial e fingir que testou tudo.
Escreva os roteiros uma vez e reutilize a cada release. O primeiro go-live dá trabalho de montar a lista; o décimo é só rodar a checklist. É assim que um time sem QA dedicado constrói qualidade: transformando o conhecimento de “o que costuma quebrar” em um ritual repetível. Quando esse ritual passa a valer também para código gerado por IA, o cuidado é ainda maior — um app do Lovable pede endurecimento antes de encarar usuário real, e o teste de fluxos críticos é onde as falhas aparecem.
Se a sua operação já cresceu a ponto de o go-live manual virar gargalo, o passo seguinte é automatizar essa checklist num pipeline. É parte do que fazemos em DevOps e infraestrutura: transformar o roteiro de qualidade que hoje mora numa planilha em testes que rodam sozinhos a cada deploy. Mas não pule etapas — automatizar um processo que você ainda não tem só automatiza o caos. Primeiro o método, depois a máquina.
O resumo honesto: você não precisa de um time de QA para subir com segurança. Precisa de uma lista curta das coisas que doem, de olhos em produção na primeira hora e de um rollback que você já testou. Isso não é o ideal de um livro de engenharia — é o mínimo que separa um lançamento profissional de uma aposta. E o mínimo, feito de verdade, já coloca você à frente da maioria.
Perguntas frequentes
Preciso de um time de QA para fazer go-live com segurança?
Não. Você precisa de um método, não de um time dedicado. Smoke test dos fluxos que geram receita e risco, um plano de rollback e alguém observando os erros na primeira hora já cobrem a maior parte do que dá errado.
O que é smoke test e por que começar por ele?
Smoke test é a verificação rápida de que os fluxos principais não estão quebrados: dá para logar, criar o registro central, pagar ou enviar. É o primeiro filtro porque, se a fumaça já sobe aqui, não faz sentido testar o resto.
Testar em produção depois de publicar não resolve?
Resolve caro. Estudos clássicos apontam que corrigir um bug em produção custa muito mais do que pegá-lo antes. Além do conserto, você paga em downtime, retrabalho e cliente que testou, não funcionou e não volta.
Quais fluxos são realmente críticos?
Os que geram dinheiro e os que geram risco: pagamento, cadastro, login, captura de lead e qualquer ação irreversível. Se um desses quebra em produção, você perde receita ou confiança na hora. O resto pode esperar.
Qual a diferença entre go-live de e-commerce e de web app?
O de e-commerce foca em catálogo, checkout e frete. O de web app inclui estados de usuário, permissões, dados persistentes e integrações — mais caminhos para quebrar. O princípio é o mesmo, mas a superfície de teste é maior.
Rollback é mesmo parte de teste?
É parte do go-live, e testá-lo antes é o que o torna confiável. Não adianta ter a teoria de que dá para voltar; você precisa ter voltado ao menos uma vez em ensaio. Rollback não ensaiado é rollback que falha no pior momento.