Dados ruins custam dinheiro, mas dados silenciosamente errados custam muito mais.
Segundo o Gartner, a má qualidade de dados custa às organizações uma média de USD 12,9 milhões por ano. O que agrava o problema é que grande parte desse custo passa despercebida: decisões são tomadas com números que parecem certos, mas não são. Ou seja, o dado existe, está disponível, mas está desatualizado, incompleto ou fora dos padrões esperados.
Em ambientes orientados por dados, a confiabilidade das métricas depende diretamente da confiabilidade das informações que as sustentam. Por isso, três testes essenciais se destacam como a primeira linha de defesa: freshness, completeness e validity. Entender o que cada um faz, como funciona na prática e por que os três precisam agir em conjunto é o que separa pipelines frágeis de pipelines confiáveis.
Por que testes de qualidade de dados são uma decisão estratégica
Antes de mergulhar nos testes, vale entender o que está em jogo.
Dados de baixa qualidade impactam a organização em vários níveis. O primeiro é o financeiro: deixar um erro chegar ao cliente final ou à decisão estratégica exige retrabalho e resulta em custos mais altos, multas ou perda de receita. O segundo é a confiança: se as informações são questionáveis, o tomador de decisão hesita e a credibilidade do produto de dados é perdida e a cultura analítica fica desgastada. O terceiro, e último, é o valor da marca: quando a organização comete erros constantes nas operações, como cobranças indevidas e recomendações irrelevantes, a reputação diminui.
Um levantamento do IBM Institute for Business Value revelou que mais de um quarto das organizações estima perder mais de USD 5 milhões por ano por problemas de integridade nos dados. O impacto vai além das finanças: funcionários chegam a dedicar até 27% do seu tempo corrigindo registros incorretos, segundo pesquisa da Harvard Business Review, tempo que poderia ser investido em análise e decisão.
O que diferencia empresas maduras não é a ausência de problemas nos dados, mas a capacidade de reconhecê-los, monitorá-los e reduzir seu impacto antes que cheguem às camadas de decisão. É exatamente aí que entram os testes de freshness, completeness e validity.
Os três testes essenciais de qualidade de dados
Para tornar os conceitos concretos, vamos usar o Spotify como fio condutor. A empresa tem mais de 600 milhões de usuários e um algoritmo de personalização que depende de eventos processados em tempo real. As consequências de falhas nos dados, nesse contexto, são imediatas e mensuráveis.
Freshness: o dado está atualizado?
A utilidade de um dado tem prazo de validade. Nos negócios, tomar decisões com informações atrasadas induz ao erro porque representa um cenário que já não existe mais. Em contextos operacionais e executivos, dados que chegam tarde não são apenas inconvenientes, são irrelevantes.
Pense no Spotify: se o sistema demorasse horas para processar que você acabou de começar a ouvir jazz, suas recomendações diárias continuariam presas ao heavy metal da semana passada. Assim, o valor do produto, aqui, está justamente na baixa latência.
Na prática, o teste de freshness monitora o intervalo entre o momento em que o evento ocorreu e sua disponibilidade para análise. A implementação envolve definir um SLA de atualização compatível com a necessidade do negócio e configurar alertas automáticos para quando a defasagem exceder o limite aceitável. Ferramentas como o dbt oferecem configuração nativa de freshness por fonte de dados, com thresholds customizáveis e notificações integradas ao pipeline.
A pergunta central do teste é simples: há quanto tempo esse dado não é atualizado, e isso é aceitável para o negócio?
Completeness: o dado está todo aqui?
A completude garante a integridade dos registros, verificando se tudo o que deveria existir de fato existe. Falhas de completeness se manifestam de formas variadas: períodos sem registros, grupos ausentes, campos críticos vazios ou volumes inesperadamente reduzidos em relação ao histórico.
Voltando ao Spotify: se uma falha de completeness fizesse com que apenas 70% das músicas ouvidas fossem registradas, os pagamentos dos artistas seriam calculados incorretamente. O impacto não seria apenas técnico, mas jurídico e financeiro, afetando contratos e relações comerciais.
Na prática, o teste verifica a ausência de valores nulos em campos essenciais e monitora a volumetria dos registros em comparação a períodos anteriores. A implementação utiliza testes de not null para campos obrigatórios e detecção de anomalias de volume, com alertas quando a contagem de registros cai abaixo de um limite esperado. Frameworks como o Great Expectations permitem definir essas expectativas de forma declarativa, criando um contrato formal entre o dado e quem o consome.
A pergunta central: tudo que deveria estar aqui está?
Validity: o dado faz sentido?
Um dado pode estar atualizado e completo, mas ser totalmente inválido. Quando isso acontece, a perda de confiança não se restringe àquela métrica específica, ela se estende a todo o ecossistema analítico. Uma vez que o analista descobre que um campo estava errado, passa a questionar todos os outros.
No Spotify, as músicas são classificadas com métricas internas de estilo: BPM, energia, acústica, dançabilidade. Se um erro técnico atribuísse uma música a uma categoria inexistente no sistema, esse valor seria inválido. O algoritmo de rádio automática poderia acabar tocando uma música melancólica numa playlist de festa, degradando a experiência do usuário sem nenhum aviso.
Na prática, o teste de validity verifica se o dado segue o formato, tipo e intervalo de valores permitidos pela regra de negócio. A implementação cobre tipos incorretos, valores fora de faixa permitida e strings que não obedecem ao formato esperado. Tanto o dbt quanto o Great Expectations oferecem testes nativos para accepted values, verificação de tipos e validações de formato customizadas.
A pergunta central: esse dado está dentro do que o negócio considera aceitável?
Como os três testes se conectam
Freshness, completeness e validity não são testes independentes. Eles funcionam como camadas complementares de proteção, e a ausência de qualquer um deles cria um ponto cego no pipeline.
Sem freshness, a métrica fala do passado. O dado existe, está completo e é válido, mas descreve um estado que já foi superado. Sem completeness, a métrica conta uma história incompleta. O dado é recente e válido, mas faltam pedaços que distorcem qualquer agregação. Sem validity, a métrica descreve um mundo que não existe. O dado é recente e completo, mas não segue os padrões que tornam a informação interpretável.
Os três juntos formam o que a literatura de engenharia de dados chama de “contrato de dados“: um acordo implícito, ou explícito quando bem documentado, de que os dados que chegam a uma camada de consumo atendem a requisitos mínimos de qualidade. Esse contrato é o que permite que analistas e cientistas de dados confiem no que estão usando, sem precisar questionar a origem a cada nova análise.
Segundo a dbt Labs, equipes que implementam verificações sistemáticas em seus pipelines reduzem significativamente o tempo de identificação e resolução de incidentes, além de aumentar a autonomia dos times que consomem informações. A qualidade deixa de ser um problema de engenharia e se torna um habilitador de produtividade para toda a organização.
Ferramentas para colocar os testes em prática
A boa notícia é que não falta suporte ferramental para implementar esses testes em pipelines modernos.
O dbt é a ferramenta mais adotada por times de engenharia de dados para transformação e validação. Ele oferece testes genéricos nativos, como not null, unique, accepted values e relationships, além de configuração de freshness por source com thresholds definidos em YAML.
O modelo declarativo do dbt facilita a revisão e o versionamento das regras junto ao código.
O Great Expectations é uma biblioteca open source que permite definir “expectativas” sobre os registros: um campo deve ser não nulo, um valor deve estar dentro de uma faixa, ou uma data deve ser posterior a determinado período. As expectativas funcionam como documentação viva: descrevem o que o dado deve ser e alertam quando ele deixa de sê-lo.
Para times que trabalham com observabilidade em escala, soluções como Monte Carlo e Acceldata complementam os testes estáticos com detecção de anomalias baseada em machine learning, identificando desvios de comportamento que testes tradicionais não capturam.
A escolha da ferramenta depende da maturidade do time e da complexidade do pipeline, mas o princípio é o mesmo: as verificações precisam estar no pipeline, não serem aplicadas manualmente após incidentes.
Conclusão
Qualidade de dados não é um requisito técnico que o time de engenharia resolve sozinho. É uma decisão estratégica que determina se as informações serão usadas com confiança ou questionadas a cada análise.
Implementar testes de freshness, completeness e validity é o ponto de partida para qualquer cultura analítica madura. Esses três testes garantem que, ao olhar para um número, o tomador de decisão não perca tempo verificando se o dado está certo, e possa focar no que realmente importa: decidir qual será o próximo passo da empresa.
Quer estruturar esse tipo de processo na sua operação? Entre em contato com a Oper ou explore outros conteúdos do blog sobre engenharia e governança de dados.
