Inleiding/Context
Bij bijna alle opdrachtgevers waar Rubix werkt speelt het onderwerp testautomatisering. De ene opdrachtgever is hier al verder mee dan de andere. Sommige opdrachtgevers hebben reeds een tool in gebruik, anderen moeten deze nog selecteren. Bij sommige opdrachtgevers wordt de tool succesvol gebruikt, bij andere opdrachtgevers ligt deze tool op de plank omdat niemand weet hoe hem te gebruiken. Testautomatisering kan erg succesvol zijn als er op de juiste aspecten wordt gelet. Rubix richt zich voornamelijk op het ontwikkelen en testen van middleware; onze ervaring is dat testautomatisering hier succesvol kan worden ingezet. In dit artikel willen we aan de hand van een praktijkvoorbeeld toelichten hoe wij recentelijk een testautomatiseringstraject zijn gestart en waarmee wij rekening hebben gehouden.
Probleemstelling
Eén van onze opdrachtgevers heeft een middleware-team dat integratieoplossingen biedt aan de rest van de organisatie. De ESB die zij hiervoor gebruiken groeit snel. Het middleware-team heeft beperkte kennis van de applicaties die moeten worden geïntegreerd. Deze applicaties zijn daarnaast niet altijd beschikbaar voor integratie op de testomgeving van de afdeling. Componenten van de ESB worden alleen los getest en opgeleverd naar het project. Fouten worden pas in een laat stadium gevonden door het beperkte aantal testen dat er wordt uitgevoerd.
Aanpak
Om eerder fouten op te sporen hebben we een nieuwe teststap toegevoegd aan het ontwikkelproces. Nadat alle losse componenten van een keten op de ESB opgeleverd zijn, wordt dit als geheel getest zonder externe applicaties daarbij te betrekken. Voor deze externe applicaties worden stubs gebruikt, berichten worden verzonden met een testtool.
In een middleware-landschap worden testtools vaak al gebruikt om testen uit te kunnen voeren. Met Parasoft SOAtest is het mogelijk om de testen herbruikbaar te ontwerpen en bouwen en een testverwachting vast te leggen binnen de tool. Hierdoor kunnen testen in het vervolg, binnen een fractie van de tijd die een handmatige test kost, automatisch worden uitgevoerd wanneer er aanpassingen zijn gemaakt in de betreffende software. Daarnaast kunnen dergelijke automatische testen ook in een CI/CD-straat worden gebruikt.
Toolselectie
Veelal worden er trajecten gestart om een tool voor de testautomatisering te selecteren, vervolgens worden er proofs of concept gedaan om te kijken in hoeverre de verschillende tools aan de eisen voldoet. Dit soort trajecten hebben vaak een lange doorlooptijd, zonder de garantie dat er dan uiteindelijk een tool uitkomt die ook nog na een jaar aan alle eisen voldoet. Bij deze opdrachtgever hebben wij besloten om voor een tool te kiezen die we al kenden, waarvan we van tevoren al wisten dat deze aan de meeste eisen zou voldoen. Het voordeel van het automatiseren in middleware is dat testberichten hergebruikt kunnen worden in andere tools. Mocht de tool na verloop van tijd toch niet voldoen aan alle eisen, dan zouden de testberichten dus kunnen worden opgeslagen en worden hergebruikt in een eventuele andere tool.
Je bent dan wel tijd kwijt om de testen opnieuw in te richten in de nieuwe tool, maar dit wordt weer gecompenseerd doordat er geen toolselectietraject aan vooraf is gegaan. Daarnaast zullen de eisen voor de tool helderder zijn doordat er duidelijk is wat de tekortkomingen (en kwaliteiten) zijn van de voorgaande tool.
In ons geval is de keuze voor Parasoft SOAtest de juiste geweest. De tool biedt out of the box al veel functionaliteit. Zo zijn er standaard SOAP, JMS en REST clients beschikbaar. Er kunnen datasources worden gebruikt om testen van data te voorzien. Er zitten standaard tools in voor assertions en XML validaties. Daarnaast is er de mogelijkheid, mochten er nog tools missen, om met behulp van de API zelf herbruikbare tools te schrijven.
Bij het maken van een eigen tool moet er van te voren goed worden nagedacht waar de tool voor gebruikt moet worden. Wanneer er een tool geïmplementeerd is en in testen wordt gebruikt, dan kan deze niet meer zomaar worden aangepast. Aanpassingen kunnen ertoe leiden dat de geïmplementeerde testen hun configuratie kwijt raken en dat testen daardoor fout lopen.
Implementatie
Onderhoudbaarheid van de testen moet één van de belangrijkste kenmerken worden van je test automatisering. De reden hiervoor is als volgt. Veelal wanneer testautomatisering mislukt, komt dit doordat het onderhoud van de testsuites zoveel tijd inneemt dat het niet meer rendabel is en het alleen maar ergernis veroorzaakt. Daarnaast is het ook voor de overdraagbaarheid van belang dat testsuites eenvoudig te onderhouden zijn, wanneer de testautomatiserings-specialist die de tool en de testsuites door en door kent weggaat, moeten de testen ook te begrijpen en te onderhouden zijn door mensen met minder kennis.
In Parasoft SOAtest zijn er verschillende mogelijkheden om testen onderhoudbaar op te stellen:
- Environment Variabelen
- Hiermee kan je variabelen vastleggen voor een bepaalde testomgeving. Denk hierbij aan end points en queuenamen
- Gebruik van (herbruikbare) scripting
- Hiermee kan je bijvoorbeeld unieke id’s en datums mee genereren en deze als (herbruikbare) functies aanbieden(?)
- Datasources
- Datasources maken data driven testing mogelijk. Hierbij kan je je testen laten sturen door datasources. Datasources kunnen op verschillende manier worden gevuld, zo kan er bijvoorbeeld een datasource worden gemaakt die een query uitvoert op een database om test data op te halen
- Reference tests
- In SOAtest kan je testen die zichzelf vaak repeteren vastleggen in een reference test. Vervolgens kan je naar deze stap refereren wanneer je een testsuite maakt waarin deze stap nodig is.
- Extensibility API
- In SOAtest kan je in Java je eigen testtools maken die je vervolgens aan je testsuites kan toevoegen zoals je elke standaardtool van SOAtest aan je testen toevoegt. Je kan dus een tool maken die op een slimme manier een timestamp genereert zoals jij wil, of je kan een tool maken die het aantal bestanden in een folder telt. Dit soort tools stellen je in staat om steeds sneller en eenvoudiger testen te maken.
Hieronder is een voorbeeld te zien van een zelf geschreven date/time tool:
De output van de tool ziet er als volgt uit:
Resultaten
Inmiddels zijn er verschillende ketens geautomatiseerd. Na verloop van tijd zijn er templates gemaakt die als basis voor de nieuwe testen kunnen worden gebruikt. De templates zijn gemaakt naar de behoeften van de opdrachtgever. Zo wordt elk in- en outputbericht opgeslagen per testrun ter bewijsvoering. Daarnaast zorgen deze templates voor uniformiteit, hierdoor worden testen beter onderhoudbaar en overdraagbaar.
De regressietest wordt langzamerhand groter, en voor een aantal ketens is deze ook al gebruikt. De test levert snel inzicht in de kwaliteit. Een regressietest van de meest complexe keten duurt ongeveer 4 uur. Hierin worden ongeveer 45 testen uitgevoerd, waarvan er 3 verantwoordelijk zijn voor ruim 2 uur van de testtijd (vanwege benodigde wachttijden in de tests). Voor de meeste ketens kan er echter binnen een half uur een regressietest zijn uitgevoerd. Dit geeft een snel beeld van de kwaliteit van de opgeleverde software.
Conclusie
De keuze om geen toolselectie traject in te gaan is voor ons de correcte keuze geweest. Parasoft SOAtest biedt alles wat wij nodig hebben. De tool geeft ons de mogelijkheid om de ESB componenten los te testen van de aansluitende applicaties. Daarnaast kunnen we nu binnen enkele uren na een oplevering van een aangepast component een regressietest uitvoeren en daarmee de kwaliteit beoordelen op een consistente manier. Door templates te gebruiken wordt de opbouw van de testen ook consistent, hierdoor zijn de testen snel aan te passen wanneer dit nodig is.
