Trendsz, Testautomatisering

Bij het testen van onze Informatica PowerCenter-applicatie deden we de toetsing voorheen handmatig. “Kunnen we de analyses niet op de één of andere manier automatiseren,” vroeg een tester tijdens een projectoverleg een paar jaar geleden. Welke groeifasen kwamen er nu bij een internationale bank voor een datawarehouseproject voor; van testautomatisering met batch files tot en met op basis van Specification by example met Fitnesse?

Projectcontext

PowerCenter is een veelgebruikte Extractie, Transformatie en Laden tool (ETL) dat gebruikt wordt voor de bouw van bedrijfsdatawarehouses. Ons project had als doel om met behulp van Informatica PowerCenter overzichten te digitaliseren en online te distribueren. Dit werd met een Agile (Scrum)-aanpak gedaan en vond plaats binnen een grote Nederlandse bank. Een probleem waar het ontwikkelteam tegenaan liep, was dat wanneer elke twee weken incrementeel nieuwe software en functionaliteit opgeleverd wordt, het vrijwel onmogelijk is om alle toetsingen handmatig uit te voeren. Na een aantal maanden zou de regressietest hypothetisch gezien de volledige twee weken aan testresources in beslag nemen. Dit zou de ontwikkeling van nieuwe functionaliteiten in komende sprints in gevaar brengen.

Om zonder extra resources iedere twee weken software op te kunnen leveren, waren we genoodzaakt om ons toetsingsproces met geautomatiseerd testen te ondersteunen. Geautomatiseerd testen, is bij Agile projecten inmiddels de standaard geworden. De projecten zien in dat de investering in testautomatisering resulteert in sneller en op reproduceerbare wijze, software kunnen valideren. Dit zijn dan ook voordelen waar we binnen ons project naar streefden. In ons traject naar een volwassen testautomatisering, liepen we een aantal fasen door, namelijk van batch files tot en met de basis van Specification By Example.

Gekozen ETL-teststrategie

Voordat we de aangehoude groeifasen – onze roadmap – doornemen, is het belangrijk helder te hebben op welke aspecten we testten en welke strategie we kozen. Bij ETL-systeemtesten zijn de volgende aspecten belangrijk:

  • Correcte transformatie van data, van source- naar targettabellen;
  • Correcte lading van ‘in-scope’ data zonder dataverlies;
  • Adequate verwerking van foutieve data.

Om invulling te geven aan bovenstaande aspecten, kozen we als teststrategie om voor iedere business requirement en -regel één of meerdere testgevallen te definiëren. Voor elk testgeval werd een zo klein mogelijke test-dataset gebruikt. Doordat de sourcetabellen met een relatief kleine dataset gevuld waren, werden de targettabellen ook met een relatief kleine dataset gevuld. Hierdoor was handmatig valideren van het resultaat van een kleine set van testgevallen nog werkbaar.

Fasen van handmatig testen naar geautomatiseerd testen

Stap 1: Testautomatisering met Batch files –> Stap 2: Testautomatisering met Fitnesse –> Stap 3: Regressietest automatisering met Fitnesse –> Stap 4: Specification by Example met Fitnesse

1305 – Big Data en veel testwerk wat nu – John Kronenberg

Stap 0 – Handmatig testen

In het begin van het project deden we al onze ETL-testen handmatig. We hadden een gevulde Excelsheet met SQL statements en de volgorde waarin de PowerCenter workflows moesten worden uitgevoerd. We controleerden de output visueel, maar legden de voorspelling niet vast. Naast het feit dat dit een arbeidsintensieve manier van testen is, is een defect reproduceren erg lastig. Daarnaast kwam het in ons project regelmatig voor dat een developer de oorzaak van een gevonden defect in de foutieve uitvoer van het testgeval zocht. Het was in zo’n geval tijdrovend om dit vermoeden te ontkrachten, of te bevestigen.

In deze stap namen we het besluit om testautomatisering in ons testproces in te zetten.

Stap 1 – Gedeeltelijke testautomatisering met batch files

Als eerste plaatsten we de SQL-statements die we voorheen handmatig uitvoerden, in een tekstbestand en regelden we de automatische verwerking van dit bestand met een batch file. Een Oracle Architect ontwikkelde een script voor het geautomatiseerd uitvoeren van een PowerCenter workflow. In deze fase voerden we testgevallen uit door een batch file op te starten. We hadden daarmee een belangrijk nadeel van handmatig testen verholpen: defects waren reproduceerbaar. We misten alleen nog een oplossing om de testuitvoer geautomatiseerd te controleren en om op een eenvoudige wijze testsets te definiëren.

Stap 2 – Testautomatisering met Fitnesse

We onderzochten of de testtool Fitnesse geschikt was voor geautomatiseerde outputcontrole. Dit was inderdaad het geval. Om Fitnesse te kunnen gebruiken, moesten we wel programmeercode maken om het systeem dat getest moest worden (SUT), te koppelen. Die programmeercode heet binnen Fitnesse een ‘fixture’. Voor ondersteuning van onze teststrategie hadden we in ieder geval de volgende fixtures nodig:

  • Eén om testdata in sourcetabellen te plaatsen;
  • Eén om workflows in Informatica PowerCenter te starten;
  • Eén om outputverwachting met gevonden records te vergelijken;
  • Eén om een database-tabel leeg te maken.

Bij de aanmaak van de fixtures werd goed afgestemd wat ze moesten doen en wat voor de tester de verwachte syntax was. De fixture voor het starten van workflows, baseerden wij op het script dat al in een eerder stadium (stap 1) was ontwikkeld.

Stap 3 – Regressietest automatisering met Fitnesse

We plaatsten met terugwerkende kracht alle testgevallen van voorgaande sprints in Fitnesse. We promoveerden deze testgevallen tot regressietestgevallen. Zo creëerden we met relatief weinig inspanning een geautomatiseerde regressietestset. Een nadeel van onze inrichting van Fitnesse was dat de testen behoorlijk technisch van aard waren. Voor de business stakeholders was het lastig om te begrijpen hoe we de requirements en rules valideerden. In de volgende stap vonden we hiervoor een oplossing.

Stap 4 – Specification by Example met Fitnesse

Fitnesse is behalve een testtool ook een stand-alone wiki die voor documentatie gebruikt kan worden. Daarin kunnen zelfs requirements vastgelegd worden. Een aparte set met requirements-documenten in bijvoorbeeld MS-Word wordt overbodig. Het voordeel is dat de kans groter is dat de documentatie synchroon loopt met de gebouwde software. De testtool (en dus de Fitnesse wiki) moet namelijk altijd synchroon lopen met de gebouwde software. Dit zorgt ervoor dat de regressietestset in de tijd gezien altijd blijft slagen.

Wanneer voorbeelden gebruikt worden om de requirements te beschrijven (ook wel ‘Key Examples’ genoemd), kunnen die ook automatisch door Fitnesse worden gevalideerd. De methode om requirements in voorbeelden te beschrijven, wordt ‘Specification by Example‘ genoemd.

Door in de voorbeelden de taal te spreken van onze business stakeholders, konden we de communicatie met hen aanzienlijk verbeteren. Zij kregen een beter begrip van hoe de tests waren uitgevoerd en welke functionaliteiten waren gebouwd. Het werd daardoor gemakkelijk(er) om hierop terugkoppeling te geven.

“Automatiseren met Fitnesse heeft geleid tot reproduceerbare defects, verbeterde kwaliteit en snelheid en een betere alignment tussen de business stakeholders en ons team”

Ervaringen tot nu toe

We zijn blij dat een vraag van een tester uiteindelijk tot een succesvolle implementatie van testautomatisering heeft geleid. Het is ons gelukt om, weliswaar met vallen en opstaan, onze tests binnen onze ETL-omgeving met Fitnesse te automatiseren. Niet onbelangrijk is het vertrouwen dat we van het management en de business sponsor hebben gekregen. Dit heeft geleid tot reproduceerbare defects, verbeterde kwaliteit en snelheid en een betere alignment tussen de business stakeholders en ons team. Ons succes bleef niet onopgemerkt. Ook andere projecten wilden op deze wijze gaan werken. Gelukkig waren de door ons ontwikkelde fixtures in Fitnesse flexibel en herbruikbaar. Hierdoor was het mogelijk om zonder al te veel moeite, onze Fitnesse-oplossing ook voor de andere PowerCenter-projecten binnen de desbetreffende bank te gebruiken.

Verwachting voor de toekomst

We zijn ervan overtuigd dat de combinatie van Fitnesse en Specification by Example heel krachtig is, ook voor niet-ETL-projecten. Het zorgde voor een betere business-IT alignment en efficiëntietoename in ons ontwikkelproces. We verwachten een vergelijkbaar resultaat voor andere IT-projecten en denken dat deze combinatie de komende jaren erg in populariteit zal stijgen. Wij kunnen niet wachten.

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

    werkenbij overall

    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.

    Bartosz Meetsz

    SUMMER edition

    Jun24

    Bartosz Meetsz is een interactief online event waar je een kijkje achter de schermen bij Bartosz krijgt.

    We delen onze visie op het testvak en onze consultants vertellen over hun ervaringen met diverse initiatieven zoals onze technische gilde en de scrummaster community.

    Mijn Paarsz