Verifique o fluxo de checkout de ponta a ponta, em condições reais
Faça você mesmo uma compra completa no site ao vivo — não no staging — cobrindo os caminhos que os clientes realmente usam: checkout como convidado e checkout com sessão iniciada, pelo menos um produto com variantes, e quaisquer códigos de desconto ou promoções ativas no momento. Verifique se os emails de confirmação de encomenda são enviados corretamente e se a encomenda aparece devidamente no seu sistema de administração/encomendas depois.
Não assuma que a cobertura do staging se transfere automaticamente. Gateways de pagamento reais, serviços de impostos reais e APIs de taxas de envio reais por vezes comportam-se de forma diferente dos seus equivalentes de staging ou sandbox, o que é exatamente o motivo por que isto precisa de uma verificação real, em condições ao vivo, e não de confiar no que passou no staging.
Confirme que os gateways de pagamento estão totalmente ativos e corretamente configurados
Verifique se o processamento de pagamentos está a correr em modo real (não de teste/sandbox), se todos os métodos de pagamento que a sua loja suportava anteriormente estão ativados e a funcionar, e se uma transação real liquida corretamente de ponta a ponta — os fundos a chegarem de facto, não apenas um estado de encomenda a mudar. Verifique também a funcionalidade de reembolso, já que é usada com menos frequência do que o checkout e é fácil de deixar por verificar.
Se suportar vários métodos de pagamento ou moedas, teste cada um individualmente em vez de assumir que, porque um método funciona, os restantes estão configurados da mesma forma.
Verifique as regras de impostos e envio com encomendas reais
A lógica de impostos e envio é fácil de errar subtilmente numa migração, já que ambas dependem muitas vezes de configuração que não se mapeia de forma limpa entre plataformas. Faça encomendas de teste para os seus destinos de envio mais comuns e confirme que o imposto é calculado corretamente e que as taxas e métodos de envio disponíveis correspondem ao que pretendia — e não apenas ao que a nova plataforma definiu por defeito.
Preste especial atenção a quaisquer casos especiais de que o seu negócio dependa: isenções de imposto, limiares de envio grátis, regras específicas de região ou restrições de envio em determinados produtos. São exatamente os detalhes de configuração com maior probabilidade de se perderem ou ficarem mal definidos numa migração.
Verifique pontualmente os redirecionamentos, não só os que se lembra
Mesmo com um mapa de redirecionamentos completo construído antes do lançamento, verifique pontualmente uma amostra real de URLs depois da mudança: as suas páginas com mais tráfego, algumas com menos tráfego, e algumas das exceções deliberadas (produtos descontinuados, categorias fundidas). Confirme que cada um redireciona para o destino correto num único salto, sem cadeias nem ciclos.
Verifique também uma amostra de URLs que não deveriam existir no site antigo — erros de digitação, URLs antigos baseados em parâmetros, qualquer coisa que um robô possa ter indexado por acidente — para garantir que resolvem de forma sensata em vez de darem erro de uma forma que pareça um problema maior.
Confirme a continuidade da análise e do tracking
Verifique se a sua plataforma de análise, o tracking de conversões e quaisquer pixels de publicidade estão a disparar corretamente no site novo — uma encomenda de teste feita deve aparecer nos relatórios da sua análise e plataforma de anúncios da mesma forma que aparecia antes. O código de tracking é fácil de perder silenciosamente numa mudança de plataforma, já que um pixel em falta ou mal configurado não produz uma mensagem de erro; simplesmente deixa de reportar dados.
Compare os primeiros números de análise pós-lançamento com a sua referência pré-migração para o mesmo tipo de dia (dia de semana vs. fim de semana, fontes de tráfego semelhantes), em vez de uma comparação bruta antes/depois, já que a variação normal de tráfego pode, de outra forma, mascarar ou imitar um verdadeiro problema de tracking.
Verifique o acesso às contas de cliente e ao histórico de encomendas
Faça com que algumas contas de cliente reais (ou de teste) confirmem que conseguem iniciar sessão, ver o seu histórico de encomendas correto e aceder a quaisquer funcionalidades de conta de que dependiam antes — moradas guardadas, métodos de pagamento guardados quando aplicável, saldos de fidelização ou recompensas se a sua loja os tiver. Os problemas de acesso a contas são altamente visíveis para os clientes que os enfrentam e afetam diretamente a confiança, por isso vale a pena verificá-los deliberadamente em vez de assumir que a migração de contas "provavelmente funcionou".
Se a migração de palavras-passe não fez parte da transferência técnica (comum quando as plataformas usam formas incompatíveis de encriptar palavras-passe), certifique-se de que os clientes têm um caminho claro de redefinição de palavra-passe e que este é comunicado, e não apenas tecnicamente disponível.
Monitorize a cobertura no Search Console nas semanas seguintes
Continue a observar o Search Console (ou o equivalente noutros motores de busca) bem depois do dia de lançamento — erros de rastreio, o estado de indexação e qualquer pico de 404s reportados são os sinais mais precoces de um problema de redirecionamento ou de tag canónica que os testes não apanharam. Compare com a sua referência pré-migração para conseguir distinguir uma regressão real de uma flutuação normal de curto prazo depois de uma alteração do site.
Este período de monitorização é também uma boa altura para voltar a submeter o seu sitemap, caso ainda não o tenha feito, e para confirmar que as páginas que espera ver indexadas estão de facto a aparecer nos resultados de pesquisa ao longo das semanas seguintes, e não apenas a serem rastreadas.
Perguntas frequentes
Durante quanto tempo deve continuar o QA pós-lançamento depois da mudança?
A verificação ativa e diária costuma importar mais na primeira ou duas semanas, quando surgem a maioria dos problemas de configuração e redirecionamentos. A reindexação pelos motores de busca e a estabilização dos padrões de tráfego demoram mais, por isso vale a pena manter uma monitorização mais leve (Search Console, tendências de análise) durante mais tempo — várias semanas é comum — em vez de parar assim que a primeira semana pareça limpa.
Qual é a coisa mais importante a verificar primeiro depois do lançamento?
Um teste real, em condições ao vivo, de checkout e pagamento, já que afeta diretamente a receita e é o único fluxo que todos os clientes tocam. Os problemas de redirecionamentos e tracking também importam, mas um checkout avariado é o problema mais dispendioso de deixar por descobrir, mesmo que por apenas algumas horas.
É normal o posicionamento nas pesquisas cair ligeiramente logo após uma migração?
Alguma flutuação de curto prazo é comum mesmo com uma migração bem executada, já que os motores de busca precisam de tempo para voltar a rastrear e a avaliar os URLs novos. O que não é normal é uma queda sustentada ou um pico de erros de rastreio — esse é o sinal para verificar o seu mapa de redirecionamentos e as tags canónicas à procura de um erro real, em vez de esperar que passe.
Quem na equipa deve ficar responsável pelo QA pós-lançamento?
Idealmente alguém com visão sobre toda a loja, não apenas a equipa técnica de migração — porque várias destas verificações (as regras de impostos parecerem corretas, o comportamento das contas de cliente, se os números de tracking parecem normais) beneficiam de contexto de negócio, e não apenas de verificação técnica de que uma funcionalidade está presente.