Principes voor testautomatisering

Organisaties moeten steeds sneller veranderen om aan de veranderende vraag van klanten te blijven voldoen. Dit stelt hoge eisen aan de ontwikkeling van applicaties. Klanten eisen niet alleen snelheid maar ook extreme gebruikersvriendelijkheid. Werkt bijvoorbeeld een webwinkel niet naar behoren dan is er snel een alternatief voorhanden. Agile softwareontwikkeling sluit goed aan op deze veranderbehoefte en is inmiddels in een groot deel van de organisaties doorgedrongen. Om aan de groeiende hoeveelheid (test)werk te blijven voldoen neemt het aandeel en het belang van testautomatisering toe. Echter, wil testautomatisering daadwerkelijk ondersteunend zijn aan de veranderende organisatie dan stelt dat andere eisen aan mensen en (test)processen. Het goed begrijpen van de impact van testautomatisering is daarom belangrijk. Architectuur kan mede helpen doordat het op een gestructureerde manier inzicht kan geven. Het maakt het mogelijk om een gestructureerd plan te maken waarbij alle belangrijke onderdelen worden meegenomen.

Het startpunt van architectuur is een set van principes; richtinggevende uitspraken die aangeven wat belangrijk is. Omdat deze principes voor een belangrijk deel hetzelfde zijn voor elke organisatie hebben wij een generieke set van principes voor testautomatisering geïdentificeerd. Vanuit onze kennis en ervaring van testen, testautomatisering en architectuur hebben we beschreven wat wij denken dat belangrijk is. Deze principes zijn voor ons tevens een startpunt voor een boek dat we schrijven over testautomatisering, waarin de principes en de architectuur verder uitwerkt worden en tegelijkertijd dienen als ‘paraplu’ voor de rest van het boek. De volgende principes belichten respectievelijk het organisatie- en het informatievoorzieningsperspectief.

Organisatieprincipes

Principe 1: Testautomatisering past bij de doelstellingen en volwassenheid van de organisatie

Testautomatisering is geen doel op zich; het is een manier om organisatiedoelstellingen te ondersteunen. De mate waarin het bijdraagt verschilt per organisatie. Het vraagt een investering, die moet worden gerechtvaardigd, en het vraagt vooral een organisatieverandering. Zo leidt het bijvoorbeeld tot een verschuiving van de taken van de testengineer, die meer software-ontwikkeltaken krijgt. Testautomatisering veronderstelt ook een minimum volwassenheidsniveau, met name op het gebied van software-ontwikkeling. Een goede analyse van de organisatiecontext en de kosten en baten van testautomatisering (business case) is daarom noodzakelijk. Volwassenheidsmodellen helpen reële ambitieniveaus te definiëren en geven meer zicht op de noodzakelijke inspanning.

Principe 2: Testautomatisering is gebaseerd op een heldere visie, beleid en architectuur

De implementatie van testautomatisering moet niet lichtzinnig worden opgevat. Het is een relatief complex onderwerp dat vraagt om het maken van allerlei keuzes. Denk hierbij aan positionering van testautomatisering in de organisatie of de opzet van testautomatisering. Het maken van weloverwogen keuzes helpt om testautomatisering toekomstvast in te richten. Er moet ook voorkomen worden dat testautomatisering een ‘one-size-fits-all’ aanpak wordt; je kunt er ook in doorschieten. Door het opstellen van een testvisie wordt duidelijk welke doelstellingen testautomatisering vooral dient en welke risico’s het vooral adresseert. Testbeleid legt de belangrijkste uitgangspunten vast over hoe er met testen wordt omgegaan en wat de rol van testautomatisering daar in is. Testarchitectuur beschrijft de inrichting van testen op hoofdlijnen zoals het te hanteren proces en de te gebruiken tools.

Principe 3: Testautomatisering houdt rekening met de menselijke maat

De mens is de allesbepalende factor en dat is ook zo bij testautomatisering. De term ‘automatisering’ lijkt er wellicht op dat de mensen minder belangrijk worden, maar niets is minder waar. De activiteiten verschuiven en stellen juist hogere eisen aan mensen. Iedereen die een betrokkenheid heeft bij testen moet begrijpen waarom testautomatisering belangrijk is en wat hun betrokkenheid inhoudt. Er zal dus goed moeten worden gekeken naar de impact op de rollen die benodigd zijn bij de testprocessen en bijbehorende competenties. Enerzijds verdwijnt repeterend werk en zal de nadruk komen te liggen op de analyse van de testresultaten. Anderzijds zal het belang van de rol van testengineer toenemen. Een veranderkundig perspectief op testautomatisering is daarom erg belangrijk.

Principe 4: Testautomatisering vraagt een weloverwogen afweging tussen risico en inspanning

Testen en het automatiseren van tests kost tijd en alles doortesten kost in veel gevallen teveel tijd. Het is daarom belangrijk de testinspanning te richten op de zaken die de meeste aandacht vragen, of op die delen die de grootste risico’s lopen. In het verleden werd er niet altijd doorgerekend of testen voldoende toegevoegde waarde bood. Testautomatisering kost echter meer inspanning, waardoor het belangrijker is om de waarde vooraf goed te bepalen. Het is daarom belangrijk om een rekenmodel te gebruiken waarin alle factoren die risico en inspanning bepalen zijn benoemd. Dit rekenmodel zal intelligent moeten zijn zodat de onderdelen die waarvoor automatisering waardevol is onderscheiden worden van onderdelen waarvoor dat het niet geval is. Een globalere versie van het rekenmodel moet ook worden gebruikt bij het opstellen van de business case voor testautomatisering.

Informatievoorzieningsprincipes

Principe 5: Testautomatisering is modelgebaseerd

Er worden in het testproces allerlei modellen en gegevens gebruikt die betrekking hebben op de applicatie die wordt getest. Deze modellen kunnen direct in het testproces worden toegepast, ondermeer voor het automatisch genereren van testscripts en de verwachte testresultaten. Dit zorgt ervoor dat de ontwikkel- en beheerinspanning wordt geminimaliseerd, dat inconsistenties zoveel mogelijk worden voorkomen en dat aanpassingen in de applicatie zo min mogelijk vragen om aanpassingen in de testscripts. Deze kunnen dan opnieuw worden gegenereerd. Het in gestructureerde, modelgebaseerde vorm vastleggen van functionaliteit stelt hogere eisen aan het analyse- en ontwerpproces. Functionaliteit wordt bij voorkeur in pseudocode beschreven.

Principe 6: Gegevens voor testautomatisering worden expliciet beheerd

Gegevens spelen een belangrijke rol in testautomatisering. Omdat de kwaliteit van processen in sterke mate afhankelijk is van de kwaliteit van de gegevens vragen deze laatste expliciete aandacht, en dat geldt dus ook voor de gegevens die worden gebruikt bij testautomatisering. Aandacht voor gegevensbeheer (ook wel: data governance) betekent onder meer het expliciet maken van taken en verantwoordelijkheden. Wie is bijvoorbeeld verantwoordelijk voor de testware na het afronden van het project? Als er geen goede afspraken zijn dan is er een reële kans dat de testware niet consistent is en daarmee onbruikbaar. Versie- en configuratiebeheer op de betrokken gegevens is daarom essentieel.

Principe 7: Testautomatisering houdt expliciet rekening met informatiebeveiliging

Klanten verwachten dat organisaties op een zorgvuldige manier met hun gegevens omgaan en dat deze niet in handen komen van onbevoegden. Wet- en regelgeving zoals de ‘Wet Bescherming Persoonsgegevens’ stelt hieraan ook expliciete grenzen. Testautomatisering dient daarom ook specifieke aandacht te hebben voor informatiebeveiliging. Gegevens die gebruikt worden bij het testen mogen niet herleidbaar zijn naar individuen (zoals klanten). Gegevens bevinden zich ook bij voorkeur binnen Europa en niet onder invloed van specifieke overheden, bijvoorbeeld in het kader van de ‘Patriot Act’. In meer algemene zin dient aandacht te zijn voor informatiebeveiligingsrisico’s en maatregelen, en het daarvoor noodzakelijke beleid.

Principe 8: Testautomatiseringstools zijn noodzakelijk maar niet leidend

Testautomatisering vraagt ondersteuning door tools; deze dienen de automatisering mogelijk te maken en uit te voeren. Het is echter belangrijk om te beseffen dat tools slechts ondersteunend zijn; de echte uitdagingen zijn met name organisatorisch van aard. De tools dienen vooral de doelstellingen en de risico’s goed te ondersteunen, wanneer ze meer dan dat doen dan sluiten ze niet goed aan. Voor sommige organisaties en applicaties kan een set van eenvoudige tools voldoende zijn, terwijl in andere situaties een meer uitgebreide toolset noodzakelijk is. De keuze voor testtools zou daarom gebaseerd moeten zijn op de testvisie en -beleid. Dure tools zijn niet per definitie beter.

We hebben in dit artikel een aanzet gegeven voor de zaken waarvan wij denken dat ze belangrijk zijn bij het inrichten van testautomatisering. Een architectuurbenadering draagt volgens ons bij aan een beter begrip en inzicht. Testarchitectuur is dan ook een belangrijke competentie in het kader van testautomatisering. Wij zijn benieuwd of anderen de door ons geschetste principes herkennen zodat we ze kunnen aanscherpen.

Auteurs:
Jos van Rooyen
M.m.v. Danny Greefhorst
M.m.v. Marcel Mersie

Pakketten en testen; een vertragende factor?!

Pakketten en testen. Is dat een logische combinatie? Is het inderdaad een vertragende factor of kan het elkaar juist versterken.

Pakketten kies je om bepaalde redenen. Het gebruik maken van generieke oplossingen of standaarden vanuit de markt, onvoldoende capaciteit om zelf te kunnen ontwikkelen etc. Zo zijn vele redenen te bedenken om te werken met (standaard) pakketten. Een pakket staat niet op zich maar is geïntegreerd in het totale landschap binnen een organisatie. Het pakket vult een onderdeel van de keten in. Daarbij is het natuurlijk van belang dat de keten goed functioneert en er voor zorgt dat de klanten tevreden zijn en blijven.

Zoals bij maatwerk systemen het geval is krijg je ook bij pakketten te maken met updates t.a.v. het pakket of bijvoorbeeld andere wensen t.a.v. de inrichting door bijvoorbeeld veranderende business omstandigheden. Deze wijzigingen moeten gevalideerd worden om te voorkomen dat er allerlei ongewenste neveneffecten gaan ontstaan. De benodigde inspanning kan flink oplopen en heeft wellicht ook een repeterend karakter bij meerdere releases per jaar. Vooral als er (nog) handmatig getest wordt. De benodigde inspanning wordt mede bepaald door de omvang van een regressietest. Uiteraard is deze omvang afhankelijk van de aard van de wijzigingen.

Handmatig testen heeft een grote waarde maar is niet toereikend meer gezien de hoeveelheid updates die beschikbaar zijn, de snelheid waarmee deze geïmplementeerd moeten worden en de tijd die nodig is voor de testuitvoering.

Dan is het toepassen van geautomatiseerd testen een absolute must om het ontwikkeltempo bij te kunnen houden. Zeker gezien als je richting een DevOps situatie gaat bewegen.

Echter, bij de introductie van testautomatisering worden nieuwe uitdagingen geïntroduceerd. Testautomatisering moet herhaalbaar, herbruikbaar en overdraagbaar zijn. Het opvoeren van een bijvoorbeeld een pensioen polis met ingangsdatum vandaag is mooi en de gedefinieerde testgevallen kun je vandaag perfect uitvoeren. Alleen morgen is vandaag niet meer en dan werken je gedefinieerde testgevallen niet meer. Kortom, je testgevallen zijn niet herbruikbaar en herhaalbaar.

Wat kun je er aan doen? De oplossing is voorhanden. Zoals je een informatiesysteem bouwt op basis van een architectuur moet je testautomatisering ook opzetten onder architectuur. We noemen dat testautomatiserings-architectuur waarmee je o.a. herbruikbaarheid en herhaalbaarheid van je geautomatiseerde testen bereikt.

Door deze aanpak kun je snel en gedegen een wijziging, fix, release etc. valideren waarmee de doorlooptijd van de test en daardoor de doorlooptijd van een release aanzienlijk kunt verkorten. Je bereikt dan de situatie dat testen geen vertragende factor meer is maar een katalysator om wijzigingen snel in productie te kunnen zetten.

Wil je meer weten over het opzetten van een toekomstvaste testautomatiserings-architectuur? Kijk dan in het boek: testautomatisering wendbaar organiseren of de website https://mailchi.mp/a6bc6ba0b694/testautomatisering.

Heb je naar aanleiding van dit artikel vragen?

Heb je een vraag of wil je met ons sparren? Neem gerust contact op met Martijn. Hij denkt graag met je mee!