No desenvolvimento de software, ninguém em sã consciência lança código para produção sem o testar. Escrevem-se testes automáticos que verificam, a cada alteração, se tudo continua a funcionar; é uma disciplina básica, assumida por todos. E, no entanto, no mundo dos dados, uma prática equivalente ainda é rara: todos os dias, dados são carregados em warehouses e usados para decisões importantes sem que ninguém verifique, de forma sistemática, se estão sequer corretos. Confia-se que estão bem, até ao dia em que um relatório mostra um número absurdo e alguém pergunta, tarde de mais, "isto está certo?". Os testes de dados são a resposta a este ponto cego — a disciplina de verificar automaticamente que o que entra no warehouse é fiável, antes de contaminar tudo o que vem a seguir.
A ausência desta prática é uma das maiores fontes de desconfiança nos dados de uma empresa. Um único erro que passa despercebido — um valor duplicado, um campo em falta, um número numa unidade errada — propaga-se por relatórios, alimenta decisões e mina a confiança em toda a plataforma de dados. Uma vez que alguém encontra um número furado, começa a duvidar de todos. Os testes de dados existem precisamente para apanhar estes problemas na origem, antes de eles se tornarem visíveis da pior forma possível.
Este artigo não é sobre uma ferramenta específica. É sobre uma mudança de mentalidade: tratar os dados com a mesma disciplina de verificação que já aplicamos ao software, porque as consequências de dados errados são tão graves — ou mais — do que as de código com bugs.
Porque os dados precisam de testes tanto como o código
Há uma diferença perigosa entre software e dados que explica porque os testes de dados são tão negligenciados. Quando o código tem um bug, muitas vezes rebenta de forma visível — o programa falha, dá erro, para. Quando os dados estão errados, o sistema continua a funcionar alegremente: o pipeline corre, o relatório aparece, os gráficos desenham-se. Só que os números estão errados. O erro nos dados é silencioso, e é essa silenciosidade que o torna tão perigoso — passa despercebido durante muito tempo, contaminando decisões, até que o dano acumulado obriga a olhar para trás.
Esta característica muda tudo. Com código, a ausência de erro visível é um sinal razoável de que está a funcionar. Com dados, a ausência de erro visível não diz nada — pode estar tudo bem ou pode estar tudo mal, e não há forma de saber sem verificar ativamente. É por isso que confiar que "os dados estão bem porque o pipeline não falhou" é uma ilusão perigosa. O pipeline pode correr na perfeição e carregar dados completamente errados.
O que um teste de dados verifica
Um teste de dados é uma verificação automática de uma regra que os dados devem cumprir. Antes de os dados serem aceites no warehouse ou usados a jusante, testa-se se respeitam o que se espera deles. Se uma regra falhar, o sistema avisa — e, idealmente, trava o carregamento — em vez de deixar passar dados suspeitos. É o equivalente a um controlo de qualidade à entrada de uma fábrica: nada avança para a linha de produção sem passar na inspeção.
Estas regras traduzem, em verificações concretas, aquilo que sabemos que deve ser verdade sobre os dados. Algumas são universais — uma chave única não deve ter duplicados, um campo obrigatório não deve estar vazio. Outras vêm do conhecimento do negócio — uma venda não pode ter valor negativo, uma idade não pode ser 200, o total de hoje não pode ser dez vezes o de ontem sem uma razão. Cada regra que se codifica num teste é uma rede que apanha uma classe de erros antes de eles fazerem estragos.
Os tipos de teste que mais valem
- Unicidade: verificar que as chaves não têm duplicados — a causa número um de totais inflados que ninguém percebe.
- Não-nulo: confirmar que os campos obrigatórios estão preenchidos, para não perder registos ou distorcer médias silenciosamente.
- Intervalos e valores válidos: garantir que os números caem dentro do que faz sentido — sem preços negativos, sem percentagens acima de cem, sem datas no futuro onde não deviam estar.
- Consistência e volume: apanhar mudanças suspeitas — uma tabela que de repente tem metade das linhas, um total que salta de forma inexplicável — que sinalizam um problema na fonte.
O poder de falhar cedo e em voz alta
A grande virtude dos testes de dados não é só apanharem erros — é apanharem-nos no momento e no sítio certos. Um erro detetado à entrada, antes de ser carregado, é barato de corrigir: sabe-se exatamente o que falhou e porquê, e nada a jusante foi ainda contaminado. O mesmo erro descoberto semanas depois, num relatório da direção, é caro e embaraçoso: já influenciou decisões, já minou a confiança, e rastrear a sua origem no meio de tudo o que veio a seguir é um pesadelo. A regra é clara: quanto mais cedo se apanha um problema de dados, mais barato é resolvê-lo — e os testes são o que permite apanhá-lo o mais cedo possível.
Há um valor adicional em falhar "em voz alta". Quando um teste falha e trava o carregamento, o problema torna-se impossível de ignorar — alguém tem de o resolver antes de os dados avançarem. Isto é infinitamente melhor do que a alternativa silenciosa, em que os dados errados passam e o problema só se descobre quando causa dano. Um bom sistema de testes transforma erros silenciosos e caros em alertas ruidosos e baratos.
O erro de testar tudo (ou nada)
Há duas formas de falhar com testes de dados. A primeira é não ter nenhuns, confiando na sorte — o ponto de partida da maioria das empresas. A segunda, menos óbvia, é o exagero: tentar testar tudo, criar centenas de regras que ninguém mantém, e gerar tantos alertas que as pessoas começam a ignorá-los, incluindo os importantes. Um sistema de testes que grita a toda a hora por variações inofensivas é tão inútil como um que nunca grita — em ambos os casos, os alertas deixam de ser levados a sério.
O equilíbrio está em testar o que importa: as regras cujo incumprimento causaria dano real, sobre os dados mais críticos. Começar pelos poucos testes de alto valor — as chaves dos dados mais usados, os campos que alimentam os relatórios mais importantes — e crescer a partir daí, com critério. Poucos testes bem escolhidos, que raramente falham mas quando falham significam mesmo alguma coisa, valem mais do que centenas que ninguém consegue seguir.
Um caso concreto
Uma empresa descobriu, da pior forma, o custo de não testar os dados. Durante semanas, um relatório de vendas usado pela direção mostrou números ligeiramente inflacionados, sem que ninguém desconfiasse — os valores pareciam plausíveis, apenas "um bom período". A causa era um problema na fonte que, a certa altura, começou a carregar algumas transações em duplicado. Como nada verificava a unicidade das chaves, os duplicados passaram silenciosamente para o warehouse e inflaram os totais. O problema só foi descoberto quando alguém, por acaso, cruzou o relatório com outra fonte e reparou na discrepância — e, a essa altura, várias decisões já tinham sido tomadas com base em números errados. Depois deste episódio doloroso, a equipa introduziu testes de dados nos pontos críticos: um teste de unicidade nas chaves das tabelas de factos principais, testes de intervalo nos valores de venda, e uma verificação de volume que sinalizava saltos anormais no número de linhas. Semanas depois, quando um problema semelhante voltou a surgir na fonte, o teste de unicidade falhou imediatamente e travou o carregamento — o problema foi resolvido no próprio dia, antes de sequer chegar a um relatório. O custo de montar aqueles poucos testes pagou-se por completo na primeira vez que apanharam um erro que, de outra forma, teria voltado a contaminar as decisões. A empresa aprendeu que a confiança nos dados não se assume — verifica-se.
Confiança conquistada, não assumida
No fundo, os testes de dados são uma expressão de uma verdade simples: a confiança nos dados não é um estado natural, é algo que se conquista e se mantém com trabalho. Uma plataforma de dados sem testes pede às pessoas que confiem nela por fé; uma com testes ganha essa confiança por prova, demonstrando continuamente que o que entra é verificado. E como a confiança é o ativo mais valioso e mais frágil de qualquer plataforma de dados, os testes que a sustentam são um dos investimentos com melhor retorno em toda a engenharia de dados.
Adotar esta disciplina é, mais do que uma questão técnica, uma mudança de cultura: passar de "esperamos que os dados estejam bem" para "sabemos que verificámos que estão". Essa mudança de postura é o que separa as organizações em que os dados são verdadeiramente uma fundação fiável daquelas em que são uma fonte permanente de dúvida.
Na prática
Se na tua empresa os dados são carregados e usados sem que nada verifique, de forma sistemática, se estão corretos, tens um ponto cego que mais cedo ou mais tarde vai custar caro. Começa pequeno e pelo mais importante: escolhe as tabelas mais críticas e adiciona meia dúzia de testes de alto valor — unicidade das chaves, campos obrigatórios preenchidos, valores dentro do razoável. Esses poucos testes vão apanhar a maioria dos erros que hoje passam despercebidos. Os dados que alimentam as tuas decisões mais importantes estão a ser verificados antes de os usares, ou estás simplesmente a confiar que estão bem?
