In deze blog bekijken en vergelijken we de verschillende aspecten uit de twee verschillende werelden in dataland. Wat zijn de verschillen? En hoe ga je daar mee om in je testaanpak? Eerst kijken we de manier waarop de data kunnen worden verwerkt: als batch of streaming. En hoe test je beide manieren van dataverwerking?
Bij batch data verwerking, tegenwoordig vaak aangeduid als extract transform load (etl), worden data op een traditionele manier verwerkt: gegevens worden verzameld en daarna als batch volgens een vast proces verwerkt. Vanaf de eerste computersystemen in de jaren vijftig en zestig is dit de manier van verwerken geweest. Tegenwoordig wint streaming data echter terrein. Bij streaming data verwerking worden gegevens niet verzameld, maar verwerkt op het moment van ontstaan (realtime). Er is hierbij dus niet één moment en proces van verwerking. Dit vergt dan ook een andere testaanpak. Wat zijn de verschillen in testaanpak en waardoor ontstaan deze?
Het testen van een batchverwerking
Stel dat bij een bank na afsluiting van een boekingsdag alle transacties vanuit het transactiesysteem worden verzameld en doorgestuurd naar een ander systeem om deze transacties te verwerken. Laten we er voor dit voorbeeld vanuit gaan dat het een eenvoudige (batch)verwerking is, waarbij data verzameld en zonder bewerking doorgestuurd worden om uiteindelijk te worden geladen in een datawarehouse. Extract-load, zonder transform dus. Maar er zijn natuurlijk ook complexere batchverwerkingen denkbaar, waarbij grote hoeveelheden data verzameld, geïntegreerd en bewerkt worden, om vervolgens geaggregeerd en opgeslagen te worden.
De testaanpak bij deze batch georiënteerde systemen is meestal grotendeels identiek, maar kan erg complex zijn; als er bijvoorbeeld historische opslag van de transacties plaatsvindt en de batchverwerking met meerdere tijdslijnen dient om te gaan. Gegeven blijft dat je een uitgangssituatie kunt definiëren, waarna een proces plaatsvindt en een uitkomst gecontroleerd kan worden.
In het algemeen kan je stellen dat batch georiënteerde systemen een proces met een kop en een staart kennen. Die kop en die staart zijn ideale ankerpunten om je testen op in te richten. Aan de kop zet je testdata klaar, je start de verwerking en na de verwerking controleer je de uitvoer van het proces. In dit concrete voorbeeld kan je er bijvoorbeeld voor kiezen om een X-aantal transacties in het bronsysteem klaar te zetten. Na het draaien van de batchverwerking dienen alle transacties geladen te zijn in het datawarehouse.
Het testen van streaming data verwerking
Bij streaming data verwerking is er zoals gezegd niet één moment en proces van verwerking, omdat data niet verzameld worden, maar verwerkt op het moment van ontstaan. In bovenstaand voorbeeld van het transactiesysteem bij een bank spaart het systeem bij streaming verwerking de transacties niet op tot het einde van de boekingsdag, maar verstuurt deze meteen op het moment van ontstaan voor verwerking naar het datawarehouse. Elke keer worden individuele transacties dus verstuurd en verwerkt, geaggregeerd met de bestaande data en opgeslagen.
Over het algemeen zijn deze verwerkingsprocessen minder complex, omdat geen grote hoeveelheden data met elkaar gecombineerd, geïntegreerd en geaggregeerd worden. Het systeem verwerkt transactie voor transactie en dat is daarmee overzichtelijker. Nadeel is dat deze processen geen kop en geen staart hebben, omdat verwerking op het moment van het ontstaan van de data al start. Met andere woorden, de kraan staat continu open.
Dit vergt dan ook een andere testaanpak. Je kunt testdata de pijplijn in stoppen, maar er is geen start en einde van het verwerkingsproces waar je een signaal van ontvangt dat de data verwerkt is. Dit start- en eindpunt ontbreekt omdat het verwerkingsproces, in tegenstelling tot batchverwerking, dus continue draait. Je hebt daardoor geen goede ankerpunten om je testen op in te richten.
Wanneer kun je de controle van de verwerking beginnen? De complexiteit bij de testaanpak ligt daarmee op een ander vlak dan bij batchverwerking. Waar je bij batchverwerking de uitdagingen in de testaanpak liggen in het testen van verschillende tijdslijnen of historische opslag van de gegevens, liggen deze uitdagingen voor het testen van een streaming data onder andere in de timing. Een oplossing hiervoor is het inbouwen van wachttijden in je testautomatisering, maar iedereen met enige ervaring in testautomatisering, bijvoorbeeld bij het testen van webpagina’s, weet dat dat eigenlijk een doodzonde is.
Een andere mogelijkheid is je testautomatisering afhankelijk te maken van de status van het proces. Zo zijn er bij streaming processen wachtrijen (als er veel wordt aangeboden, moeten de data geparkeerd worden als het verwerken niet meteen kan plaatsvinden) die je kunt uitvragen. Zijn alle wachtrijen leeg, dan zouden alle data verwerkt moeten zijn en kun je je eindstatus van het proces controleren. Dit kun je inbouwen in je testscript, maar je zou ook testbaarheid in je systeem kunnen inbouwen, door afhankelijk van de omgeving waarop het proces draait (testomgeving of productieomgeving) eventueel een testscript te starten bij het event dat de wachtrij leeg raakt.
De tester en streaming data
Een testspecialist kan in een batch georiënteerde wereld prima uit de voeten met de voor hem of haar bekende werkwijze. Deze is namelijk niet anders dan het testen van een ander informatiesysteem. Het gaat dan om testdata klaarzetten, actie uitvoeren en controles uitvoeren. In een landschap met streaming data moet de tester echter uit een ander vaatje tappen. Door constante verwerking is onder andere timing een issue. De bekende valkuilen van testautomatisering komen hierbij om de hoek kijken.
In onze volgende blog gaan we verder inzoomen op een andere dimensie voor testers in een data-logistieke wereld: gestructureerde en ongestructureerde data.
Xander Damen en Rein Hochstenbach, test consultants bij Bartosz ICT
