Base de teste diferente da produção: o que precisa ser igual

A base de teste serve a uma decisão específica: aprovar ou recusar uma mudança. Estrutura de tabelas, campos usados no fluxo, regras de negócio ativas e os casos de exceção precisam estar presentes. Histórico antigo, campos sem uso no fluxo testado e volume de anos podem ser cortados. O critério é o cenário, não a semelhança com a produção.

Cada área envolvida declara quais cenários interessam e por quê. Sem essa declaração, o teste aprova o que ninguém definiu, e a discussão volta depois da virada. O registro do que ficou de fora vale tanto quanto o registro do que rodou.

A atualização da base de teste acompanha a mudança de regra, não apenas o calendário. Quando uma regra de negócio muda em produção, o teste perde validade até que o recorte seja refeito. Uma base atualizada toda semana ainda pode estar errada se a regra mudou ontem.

Dados de pessoa, de documento e de pagamento entram mascarados, mas a integridade entre tabelas precisa continuar. Um mascaramento que quebra o vínculo entre registros invalida a junção e esconde justamente o defeito que o teste deveria encontrar. Quem responde pela base é uma pessoa, com nome, não uma área.

A base de teste não reproduz o comportamento da produção sob concorrência real, volume alto e falha de terceiros. Latência de rede, indisponibilidade de serviço externo e disputa de recurso aparecem na operação, não no ambiente controlado. Esses pontos ficam fora do teste e precisam ser tratados como risco declarado.

Também não substitui o acompanhamento depois da entrada em produção. Parte dos defeitos só aparece com a distribuição real dos dados. Quando um cenário não pode ser reproduzido, a decisão é monitorar na virada com plano de reversão, não declarar que passou no teste.