Meu veredito de entrada: na abertura de um novo armazém, o tempo de testes de integração nunca é suficiente. A única pergunta é se você queima essas horas antes da entrada em produção ou depois, enquanto os telefones do atendimento ao cliente não param de tocar. Vi projetos demais gastarem 80 por cento do orçamento em layouts de endereçamento e comissionamento de equipamentos, deixando uma única semana para as integrações. Então, no dia do lançamento, o fornecedor do WMS, as transportadoras e os marketplaces apontam o dedo uns para os outros enquanto algumas centenas de pacotes aguardam nas estações de embalagem sem etiquetas de envio.
O sandbox não é um acessório: alinhe os ambientes antes de testar qualquer coisa
Em 2024, entrei em um site greenfield de 120,000 pés quadrados em Ontario, Califórnia, uma semana antes da entrada em produção para revisar os testes de integração. O sandbox parecia ótimo: pedido dentro, etiqueta fora, envio confirmado — uma demonstração impecável para os executivos. O dia do lançamento contou outra história. O modelo de etiqueta do sandbox não era o mesmo configurado em produção. O modelo de produção trazia uma regra extra de dígito verificador no campo do número de rastreamento. As etiquetas imprimiam, os scanners as rejeitavam, e os pacotes se acumulavam na indução do separador por meia hora enquanto toda a linha ficava parada.
A lição é chata e concreta: as configurações do sandbox e da produção precisam corresponder item por item — modelos de etiquetas, modelos de impressoras e drivers, contas de transportadoras, fusos horários dos servidores. Reparem especialmente nas contas de transportadoras: as credenciais de teste e as de produção frequentemente têm permissões diferentes. Já vi uma conta de teste que podia comparar tarifas e imprimir etiquetas, mas não conseguia puxar eventos de rastreamento, o que significou que o caminho do webhook de rastreamento ficou totalmente sem teste até o dia do lançamento. Cada divergência é um incidente do dia do lançamento à espera de acontecer. Antes de começar os testes, monte uma lista de verificação de duas colunas — sandbox versus produção — e não comece até que cada linha esteja marcada.
Mais uma coisa sobre o sandbox: alimente-o com dados de formato real, não dados de brinquedo. Cinco SKUs com uma unidade cada não vão revelar nada. Carregue alguns milhares de SKUs, pesos dimensionais reais, os códigos de serviço de transportadora que você realmente vai usar e endereços com apartamentos, caixas postais e o ocasional erro de digitação. A maioria dos bugs de integração que vi não eram erros de lógica — eram erros de formato dos dados, e os dados de brinquedo escondem todos eles.
E no primeiro dia de testes, faça as três partes escreverem a versão da API que estão rodando. A documentação das APIs das transportadoras é revisada três ou quatro vezes por ano, os campos mudam sem aviso, e a versão que você testou no sandbox pode não ser a versão rodando em produção. Faço todo mundo confirmar o número da versão de produção, por escrito, no kickoff — economiza uma semana de acusações depois.
Teste os casos feios, não o caminho feliz
Todo mundo testa o pedido normal. Os pedidos que matam você são as exceções, então construa o plano de testes em torno delas: endereços ausentes ou malformados, pacotes com excesso de peso ou fora de dimensão, SKUs que não existem, estoque negativo, cancelamentos depois que o picking começou, um pedido dividido em várias caixas, vários pedidos fundidos em um. Execute pelo menos três de cada e verifique se o status do pedido concorda nos três sistemas — WMS, marketplace e transportadora. A falha clássica é um desacordo triplo: o marketplace mostra "enviado", o WMS ainda diz "aguardando picking", e sua equipe de atendimento descobre pelos e-mails furiosos.
Não esqueça o ERP também. O fluxo de recebimento de pedidos de compra — ASN entrando, recebimento de mercadoria lançado, instantâneo de estoque sincronizado de volta — merece sua própria rodada de testes. O clássico eterno é a divergência entre estoque inicial e final: o ERP acha que você recebeu 500 unidades, o WMS contou 480, e ninguém concilia até o fechamento do mês virar um exercício forense. Rode um ciclo completo de recebimento a contagem no sandbox e concilie os números antes do lançamento, não depois.
Duas categorias são puladas quase sempre. Primeiro, o pedido de pico de volume: uma semana antes da Black Friday, injete por script vinte mil pedidos por dia no sandbox e veja se os limites de taxa e as filas de mensagens aguentam. Dez pedidos por segundo parecem ótimos no teste; duzentos por segundo durante o pico vão derrubar uma API despreparada. Já vi isso mais de uma vez. Segundo, a devolução. Nove em cada dez sites greenfield nunca executam uma devolução completa no sandbox antes do lançamento, e o caminho da devolução é uma cadeia inteiramente separada — autorização de devolução do marketplace, recebimento no WMS, inspeção, armazenagem, baixa do estoque de volta ao marketplace. Se algum elo quebrar, as devoluções ficam no limbo. A primeira semana de devoluções após o lançamento vai expor cada lacuna que você não testou.
Termine cada dia de testes com conciliação: exporte os status de pedidos dos três sistemas — marketplace, WMS e transportadora — e confirme que o mesmo lote de números de pedido mostra estados consistentes em todos. Escreva o script de conciliação no primeiro dia e rode automaticamente; não revise a olho. Cada divergência é o bug prioritário de amanhã.
Dia de corte: planeje o caminho de volta antes de planejar o de ida
Antes do lançamento, defina a linha de reversão — por escrito. Se a precisão de saída cair abaixo de um piso definido dentro de duas horas do corte, ou a taxa de erros da API cruzar um limite, você reverte imediatamente para o sistema legado ou para pedidos manuais. Pendure na parede da sala de crise. Não deixe como "vamos ver como vai". Na hora, ninguém tem cabeça para tomar essa decisão; só dá para executar uma regra que você escreveu antes.
Mantenha o sistema antigo aquecido no dia de corte. Rode o antigo e o novo em paralelo de meio dia a um dia inteiro: os pedidos fluem para os dois, o despacho sai do sistema antigo, o novo faz validação em sombra. Concretamente, isso significa comparar as primeiras cinquenta etiquetas que o novo sistema imprime com a saída do sistema antigo, linha por linha — endereços, níveis de serviço, números de rastreamento — antes de confiar volume real a ele. A operação paralela custa o dobro de mão de obra por um dia. Pulá-la significa apostar os poucos milhares de pedidos do dia do lançamento na esperança. Mau negócio.
E cubra o turno da noite: as falhas de integração se concentram nas primeiras horas da madrugada após o corte. Desenvolvimento, o supervisor do armazém e o atendimento ao cliente precisam cada um de alguém no local ou de plantão, em um único chat em grupo, com os contatos fixados. Não comece a ligar procurando gente depois que as coisas quebrarem.
Quando foi a última vez que seu sandbox executou uma devolução completa — devolução iniciada no marketplace, recebimento no WMS, inspeção, armazenagem, estoque baixado de volta — de ponta a ponta? Se você não consegue nomear a data, adie o corte em uma semana. Testes de integração não têm "quase bom o suficiente". A produção vai encontrar cada atalho que você tomou, um por um, no dia do lançamento.
Traduzido do inglês. Em caso de divergência, prevalece a versão em inglês.
