Data testing

Wat is data testing?

Data testing is het automatisch controleren of je data voldoet aan regels die je vooraf hebt vastgelegd. Elke test legt een concrete verwachting op: het ordernummer is nooit leeg, elke klant staat maar een keer in de tabel, het bedrag valt binnen een normaal bereik. Draait de test, dan krijg je een helder antwoord: geslaagd, of hier zijn de rijen die de regel breken.

Het is voor data wat unit tests en integratietests zijn voor software. Een ontwikkelaar test zijn code zodat een fout opvalt voor ze bij de gebruiker terechtkomt. Een data-team test zijn tabellen zodat een foute lading opvalt voor ze in een rapport terechtkomt. In beide gevallen leg je je aannames vast als een controle die automatisch draait, telkens opnieuw.

Let wel: een test bevestigt niet dat je data juist is, alleen dat ze de regel volgt die jij hebt geschreven. Een test op bedrag groter dan nul laat een bedrag van een euro door dat eigenlijk honderd had moeten zijn. Je tests zijn zo goed als de verwachtingen die je erin stopt.

De courante testtypes

De meeste tests vallen in een handvol vaste categorieën. Je herkent ze terug in zowat elke tool.

• Niet leeg (not null)
  Een verplicht veld mag nooit leeg zijn. Elk order heeft een ordernummer, elke actieve klant een btw-nummer.

• Uniek
  Een sleutel komt maar een keer voor. Twee orders met hetzelfde ordernummer wijzen op een dubbele lading of een fout in de bron.

• Toegelaten waarden en bereik
  Een veld mag alleen bepaalde waarden bevatten. Een orderstatus is "geplaatst", "verzonden" of "geannuleerd" en niets anders. Een korting ligt tussen 0 en 100 procent.

• Referentiële integriteit
  Een verwijzing wijst naar iets dat bestaat. Elk order verwijst naar een klant die effectief in de klantentabel staat, geen order naar een klant-id dat nergens voorkomt.

• Rij-aantal en volume
  Het aantal rijen ligt binnen een verwacht bereik. Een dag met nul nieuwe orders, of plots tien keer zoveel als gewoonlijk, verdient een blik voor je erop verder rekent.

• Versheid (freshness)
  De data is recent genoeg. De verkooptabel hoort na de nachtelijke verwerking een rij van vandaag te bevatten. Is de jongste rij drie dagen oud, dan is er onderweg iets blijven hangen.

Waar draaien de tests?

Tests horen thuis in de pijplijn zelf, als vaste stap na elke verwerking. Je leest uit de bron, transformeert, en voor het resultaat naar de volgende laag of naar een dashboard gaat, laat je de tests erop los.

De winst zit in fail fast: breekt een test, dan stopt de verwerking daar en gaat de foute lading niet verder. Beter een dashboard dat even op de cijfers van gisteren blijft staan dan een dashboard dat vol vertrouwen verkeerde cijfers toont. Zonder die stap reist een fout mee tot in het rapport, waar uitgerekend iemand anders ze ontdekt dan wie ze veroorzaakte.

Dit leunt aan tegen data observability, al is het niet hetzelfde. Tests controleren regels die je zelf hebt bedacht en die je verwacht. Observability bewaakt continu de bredere gezondheid van je data en slaat ook alarm bij afwijkingen die je nergens in een regel had gegoten.

De tools die een team tegenkomt

Drie namen kom je vroeg of laat tegen.

dbt heeft tests ingebouwd. In een YAML-bestand verklaar je per kolom welke regels gelden: unique, not_null, accepted_values en relationships (de controle op referentiële integriteit). dbt bouwt daar automatisch een SQL-query van die de rijen teruggeeft die falen. Een test die nul rijen teruggeeft, is geslaagd. Complexere controles schrijf je zelf als een query die niets mag teruggeven.

Great Expectations is een Python-framework dat elke controle een expectation noemt: een verifieerbare verwachting over je data, in de geest van een assertion in een unit test. Je bundelt die expectations tot een suite en valideert er batches data tegen.

Soda gebruikt een YAML-taal (SodaCL) waarin je checks kort opschrijft, bijvoorbeeld row_count boven een grens, missing_count op een kolom gelijk aan nul, duplicate_percent onder een drempel of freshness onder een dag. Elke check eindigt op geslaagd, gefaald of een waarschuwing.

De drie doen in de kern hetzelfde: een regel vastleggen en er de data tegen aftoetsen. Welke je kiest hangt vooral af van waar de rest van je stack al staat.

Een voorbeeld op een verkooptabel

Neem een tabel orders met de kolommen order_id, klant_id, status, bedrag en order_datum. Een zinnige set tests ziet er zo uit:

• order_id is uniek en nooit leeg. Vangt dubbele en halve ladingen.

• klant_id verwijst naar een bestaande klant. Een order zonder geldige klant hoort niet in je omzetrapport.

• status is geplaatst, verzonden of geannuleerd. Een tikfout of een nieuwe, onbekende status valt meteen op.

• bedrag ligt tussen 0 en 100.000 euro. Een negatief bedrag of een order van een miljoen wijst op een fout in de bron of de omrekening.

• de jongste order_datum is niet ouder dan een dag. Zo weet je dat de nachtelijke verwerking effectief nieuwe orders binnenhaalde.

Draaien deze vijf tests groen, dan durf je het dashboard vertrouwen. Breekt de statustest omdat er plots "in behandeling" opduikt, dan weet je precies waar te kijken, nog voor iemand een verkeerd cijfer aan de zaakvoerder toont.

Data testing versus datareconciliatie

De twee lijken op elkaar en worden vlot verward, maar ze stellen een andere vraag.

Data testing toetst regels af op een dataset. Klopt deze tabel met de verwachtingen die ik erover heb geschreven: geen lege sleutels, geen dubbels, bedragen binnen bereik? Je hebt maar een kant nodig.

Datareconciliatie vergelijkt twee datasets met elkaar. Komt mijn kopie na een verwerking of migratie overeen met het origineel: evenveel rijen, dezelfde totalen? Je hebt twee kanten nodig en legt ze naast elkaar.

Ze vullen elkaar aan. Reconciliatie ziet dat er twee orders verdwenen tussen bron en warehouse. Data testing ziet dat een bedrag in de doeltabel negatief werd. De ene bewaakt de overdracht, de andere de inhoud.

Data testing en het data contract

Tests zijn ook de tanden achter een data contract. Zo'n contract legt tussen de producent en de gebruikers van een dataset vast welk schema, welke kwaliteit en welke frequentie beloofd wordt. Zonder controle blijft dat een goed voornemen. De kwaliteitsregels uit het contract, geen nulls op de sleutel, alleen toegelaten statussen, verwachte volumes, vertalen rechtstreeks naar tests die bij elke verwerking draaien. Breekt de bron een belofte, dan faalt de test en houdt ze de wijziging tegen voor die verderop schade aanricht.

Zo hangt data testing samen met datakwaliteit in het algemeen: een kwaliteitsregel is pas een garantie zodra een test ze automatisch en herhaald afdwingt.