Softwarepakketten en testen. Is dat een logische combinatie? Is het inderdaad een vertragende factor of kan het elkaar juist versterken?
Softwarepakketten 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 er vele redenen te bedenken om te werken met (standaard) softwareoplossingen.
Een pakket staat niet op zich, maar is geïntegreerd in het totale landschap binnen een organisatie. De standaard softwareoplossing 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, krijgt men ook bij standaard oplossingen te maken met software-updates in het kader van opgeloste fouten of bijvoorbeeld andere wensen in de inrichting door 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; vooral als er (nog) handmatig getest wordt. Deze inspanning wordt medebepaald door de omvang van een regressietest; uiteraard afhankelijk van de aard van de wijzigingen
Handmatig testen heeft een grote waarde maar is niet meer toereikend, gezien de hoeveelheid updates, 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 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 bijvoorbeeld een pensioenpolis met ingangsdatum vandaag is mooi en de gedefinieerde testgevallen kun je vandaag perfect uitvoeren. Alleen morgen is vandaag niet en dan werken je gedefinieerde testgevallen ook 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 testautomatisering-architectuur; hiermee bereik je o.a. herbruikbaarheid en herhaalbaarheid van je geautomatiseerde testen.
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 verkort wordt. 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 testautomatisering-architectuur? Kijk dan in het boek: Testautomatisering Wendbaar Organiseren of op de website.
Jos van Rooyen