Trendsz, Test engineering

Data is tegenwoordig big en booming. Werd data eerder pas verzameld als er een business case aan ten grondslag lag, tegenwoordig wordt data ook verzameld om aan mogelijke toekomstige business cases invulling te kunnen geven. Hoe ga je als tester om met data in een wereld waarin steeds meer en non-stop data binnenkomt? Rein Hochstenbach en Xander Damen van Bartosz houden zich hier mee bezig bij een grote financiële instelling. De een vanuit de oude, de ander vanuit de nieuwe wereld. In een reeks blogs delen zij hun kennis over testen en data.

Oud & nieuw

Grofweg bestaan er vandaag de dag twee data werelden: de oude wereld van gestructureerde data die nog te behappen is in klassieke database structuren en de nieuwe wereld van bijvoorbeeld Facebook, LinkedIn en Google. In deze nieuwe wereld heeft data een groot volume, is ongestructureerd, gevarieerd en wordt op grote schaal gegenereerd. Hoe ga je daar mee om? De standaard databasestructuren voldoen niet meer; je bent daarmee langer dan een dag bezig om de data die je in een dag binnenkrijgt te verwerken en je kunt niet inspelen op veranderende structuren. Dus moeten er oplossingen komen. Vanuit IT-ers, architecten en ook testers!

Testen zonder begin en eind

Werken met data verandert je wereld als tester. In de oude wereld was het eenvoudig om overzicht te krijgen. Door middel van verschillende batches leidde je data stap voor stap door het systeem heen. Je weet dat er data moet zijn als een batch gedraaid heeft. Zo niet dan heb je een bevinding en kun je stappen nemen. Maar tegenwoordig – in de nieuwe wereld – is data streaming: data loopt constant door het systeem heen. Dat is een continu proces en dus lastig bij het testen. Want dan wil je liever een begin- en eindpunt van een proces hebben zodat je daar je tests op kunt inrichten. De nieuwe wereld met streaming data roept voor een tester allerlei vragen op: hoe integreert de streaming data met de batch data? Wanneer is mijn testdata verwerkt? Dus wanneer kan ik m’n check doen? Als bij mijn check blijkt dat data er nog niet is, heb ik dan een bevinding of heb ik gewoon te vroeg gecheckt? Hoe richt ik mijn geautomatiseerde tests in, zonder dat deze tijdsafhankelijk en flaky (dan weer succesvol, dan weer falend) worden?

"Wil je als tester werken met data, zorg dan dat je de concepten binnen de complexe datawereld begrijpt"

Datalogistiek project

Zelf hebben wij onze ervaring met data en testen opgedaan bij een groot datalogistiek project bij een financiële instelling. Bij de start van het project was er weinig voorhanden op het gebied van datalogistiek testen. Er moest dus veel zelf opgezet worden. Dat leidde soms tot frustraties, maar is nog steeds meestal heel uitdagend! Het leuke aan werken met data is dan ook dat je als tester de ruimte en mogelijkheid krijgt om nieuwe manieren van testen te ontdekken omdat nog niet alles uitgedacht is. Je denkt zelf na over hoe je dingen het beste vormgeeft. Daarvoor moet je wel eigen initiatief durven nemen. Passief uitvoeren wat je opgedragen wordt, is er in de snel veranderende wereld van data niet bij.

De tester in data-land

De rol van een tester is anders binnen een datalogistiek project; het is hierin namelijk nog belangrijker om verder te kijken dan je eigen systeem. Want je hebt te maken met data die van het ene naar het andere systeem stroomt, met elkaar interacteert en wordt vervormd. Ondanks dat alles moeten alle partijen met de data om kunnen blijven gaan. Je kan bijvoorbeeld te maken krijgen met datastromen op dag-, week- en maandbasis, die op een punt in het systeem weer bij elkaar komen. Het testen van datastromen binnen een datalogistiek project stelt je voor andere (technische) uitdagingen dan het testen van een standaard operationeel informatiesysteem. Een datalogistiek project heeft geen gebruikersinterface en dus geen uitdagingen op het gebied van usability. Daarnaast heeft een datalogistiek project meer integratie uitdagingen dan een operationeel informatiesysteem. Deze traditionele systemen zijn vaak onderdeel van een keten met één leverend en één afnemend systeem. In de datalogistieke wereld heb je daarentegen te maken met tientallen leverende en tientallen afnemende systemen, waarbij de data van deze leverende systemen gecombineerd moet worden.

"Het testen van datastromen stelt je voor andere (technische) uitdagingen dan het testen van een standaard operationeel informatiesysteem"

Dynamisch en complex

De datawereld is dynamisch, dat maakt het uitdagend en leuk! Wel is het van belang dat je flexibel bent, zeker in de nieuwe wereld. Je kunt niet één tool leren kennen en denken dat je daarmee het hele project kunt draaien. Tooling wisselt namelijk maandelijks, afhankelijk van wat er bedacht wordt. Als tester moet je daar natuurlijk zo snel mogelijk op aanhaken: hoe werkt een tool? Wat doet die? Welke test cases heb ik nodig? Dat is iets anders dan een traditioneel testtraject waar je vooraf weet waar je het komende half jaar of langer mee bezig bent. In de datalogistiek krijg je daarnaast te maken met datastromen uit alle domeinen van een organisatie, afnemers met verschillende belangen en wetgeving op het gebied van data en privacy die steeds meer in beweging is.

Technisch en conceptueel

Om in de complexe oude en nieuwe wereld van data te kunnen acteren als tester, is het essentieel om de concepten die een rol spelen te begrijpen. Je moet de gedachte achter een datawarehouse snappen. Er zit een bepaalde modelleringstechniek achter. Als je die snapt, begrijp je hoe data in elkaar zit, hoe het samenhangt, waarom dingen zo gebouwd zijn. Een achtergrond in de IT, bedrijfsprocessen en de samenhang daartussen helpt ook bij het begrijpen van de concepten.

Blogs over data en testen

De wereld van het testen in de datalogistiek is een onbeschreven terrein. Terwijl het een enorm interessant onderwerp is! In een serie blogs willen wij de kennis over data en testen die we de afgelopen jaren hebben opgedaan delen. De volgende onderwerpen komen hierin aan bod:

  1. Batch versus streaming data
  2. Structured versus unstructured data
  3. Historisch wijzigend versus events / transacties
  4. Time to market versus quality to market
  5. Data-driven versus business requirement driven
  6. Privacy en wetgeving
  7. Data in motion vs data at rest; security

 

Deze blog is geschreven door Rein Hochstenbach en Xander Damen

Lees hier de vervolgblog over data verwerking: batch of streaming

Wil je ons nieuwste Paarsz magazine per post ontvangen? Laat dan je gegevens achter.

Ontwerp zonder titel (19)

Werken bij Bartosz?

Vincent Verhelst

Geïnteresseerd in Bartosz? Dan ga ik graag met jou in gesprek. We kunnen elkaar ontmoeten met een kop koffie bij ons op kantoor. Of tijdens ontbijt, lunch, borrel of diner op een plek die jou het beste uitkomt. Jij mag het zeggen.

Mijn Paarsz