Doe even normaal.
Op een dag weet je het, je gaat testautomatiseren. Je bent de handmatige regressietest van anderhalve sprint lang nu wel zat. Je wilt een beter idee krijgen van de historie van je applicatieontwikkeling en de gevonden issues. Je wilt sneller je testresultaten hebben. Je moet natuurlijk ook je nieuwe webapplicatie op verschillende browsers testen en dat moet toch echt een keer gelijktijdig gaan gebeuren. Wellicht test je een API, dat kan ook sneller. Zo zijn er 1001 redenen te noemen om te beginnen met testautomatisering.
Laat het duidelijk zijn, testautomatisering is niet de heilige graal. Je krijgt er zeker wat handigheidjes voor terug, zoals het automatiseren van regressietesten en repetitieve testen behapbaar maken. Daar staat tegenover dat je nu tijd moet stoppen in het bijhouden en bijwerken van je geautomatiseerde testgevallen en je vaak een heel nieuw softwarepakket hebt dat je moet ondersteunen. Daarbij komt dat 100% testautomatisering ook niet bestaat, hoe mooi sommige verhalen ook klinken.
Zelf heb je weinig ervaring met testtools, dus die haal je ergens anders vandaan. Er komt een bedrijfje aan met dé oplossing. Mooie verhalen, leuke (eigen) business cases, dus wat kan er nog fout gaan? Dat is, kortgezegd, een situatie die vaak voorkomt. De verkooppraatjes zijn ontzettend mooi en gaan altijd uit van een best case scenario.
Maar jouw scenario is helemaal niet best case, jouw scenario is uniek voor jou. Want jouw organisatie is op IT-vlak dynamisch en snel aan het ontwikkelen. Er zijn meerdere oplossingen en omgevingen ingezet die allemaal jouw specifieke business ondersteunen. Dus al die mooie verhalen kunnen al direct de prullenbak in. Want die gaan nooit bij je passen. Wat wel gaat passen? Nou, dat is precies de eerste grote valkuil die je tegen gaat komen, de technische fit is nooit perfect. Andere valkuilen hebben meer te maken met het implementeren en de mensen die ermee moeten gaan werken.
Eerlijk gezegd, je weet in de meeste gevallen helemaal niet genoeg om op voorhand te weten wat je tegen gaat komen. Maar dat geldt niet alleen voor jou, dat geldt ook voor de club die je inhuurt om je testautomatisering op poten te krijgen. Die kent jouw interne situatie toch helemaal niet? Waarom komen er dan zoveel aan met een out-of-the-box oplossing en zijn ze overtuigd van hoe goed ‘ie wel niet is?
Er is maar één ding belangrijk: dat jouw organisatie een stap vooruit maakt met testautomatisering, op een manier die bij jou, je medewerkers, je omgeving en je IT landschap past en er perfect op aansluit. Het belangrijkste is dan ook te leren hoe die combinatie werkt en wat daar precies in moet passen om je stappen te zetten. In mijn ervaring is de techniek daarin meestal het minst spannende aspect. Je bent juist meer bezig met iets te laten passen bij het kennisniveau en de werkwijze van je testers, de onderhoudbaarheid, de betrouwbaarheid en de aansluiting op al je te testen omgevingen.
Je weet namelijk niet hoe goed je testtool ligt bij je testers, want hij moet wel in hun workflow passen. Je weet niet hoe de tool gaat werken in jouw specifieke omgeving. En om nou de hele teststraat opnieuw in te richten als je toch niet tevreden bent met je inrichting, is nogal een kostbare zaak. Gelukkig is er een oplossing voor, want ook op het gebied van testautomatisering kun je het gewoon stapje voor stapje doen. Zonder direct een draak van een tool naar binnen te fietsen, omdat het verhaal zo leuk klinkt. Jouw situatie is namelijk uniek.
Na zelf een aantal grote implementaties te hebben gedaan, zie ik de noodzaak voor het zelf experimenteren op het gebied van testautomatiseren. Door alle variabelen, afhankelijkheden en technische en organisatorische uitdagingen die erbij komen kijken is er teveel onduidelijk. Die onduidelijkheid moet eerst zoveel mogelijk weggehaald worden. Niet door uitgebreide planningssessies of andere tijdrovende stappen te zetten, maar juist door héél klein te beginnen. Mijn voorkeur gaat uit naar een tool die dicht bij de te testen applicatie ligt, maar die wel gemakkelijk en flexibel te gebruiken is en weinig eisen stelt aan de omgeving waarop ‘ie draait. Zo kun je een basis opzetten zonder direct de portemonnee te legen.
Je moet dan wel een tooltje hebben dat ook makkelijk, snel en simpel werkt. Zonder al te grote investering vooraf en wel flexibel genoeg om te vormen naar wat je nodig hebt. De complexiteit moet beperkt zijn om de eerste stapjes te kunnen maken. Gelukkig zijn die tools er. Mijn favoriet is wat we bij Praegus de Open Source Toolchain noemen. De naam zegt genoeg, het is een open source pakket dat bestaat uit een keten aan tooltjes die een makkelijke en simpele testtool oplevert, waarmee direct te starten is. Hiermee kan ik snel praten met API’s, met websites en het werkt praktisch direct, zodra er Java en eventueel een browser op een systeem staat. De rapportage is netjes en er is geen gedwongen structuur.
Je kunt hiermee zelf gaan ontdekken wat wel en niet werkt. Een pakket dat ook niet jaren aan ervaring vereist, maar gewoon lekker snel een web of API test kan maken. Een tool gebaseerd op de FitNesse frontend, zodat ook iemand met heel weinig technische ervaring er mee kan werken. Een klassieker die al heel lang meegaat en op zichzelf niet per sé geweldig is, maar wel heel gemakkelijk in gebruik. Het is misschien ook helemaal niet de bedoeling om deze testtool voor de komende 50 jaar te gebruiken, maar het is wel een prettige basis waar nog wat flexibiliteit in zit.
Zo leer ik gaandeweg wat ik eigenlijk echt nodig heb en waar de eigenaardigheden van mijn applicatie zitten. Als er dan een wandelende salespitch aan komt zetten met een tooltje dat tonnen per jaar kost, kan ik in ieder geval de juiste kritische vragen stellen.
Zo kun je stapje voor stapje een basis neerzetten. Je maakt de eerste scripts en je ervaart en ziet wat je nodig hebt. Wil je geavanceerdere stappen zetten? Dan is er altijd hulp in te schakelen.
