Heb jij weleens een keuze gemaakt voor een tool die achteraf gezien toch niet de verstandigste bleek? Helaas een ervaring die veel IT professionals weleens opdoen. En gezien de tools in de moderne ontwikkelomgevingen niet meer aan te slepen zijn, denk ik dat dit nog weleens vaker het geval gaat zijn.. Als testautomatiseerders hebben wij binnen PerformanceArchitecten veel ervaring met het selecteren van de juiste tool. In deze blog een paar tips die er voor zorgen dat jij blij wordt van je toolkeuze in plaats van je eraan te ergeren!
Wanneer je het hebt over test-automatisering gaat het al snel over het gebruik van tools. Er zijn immers vele tientallen, zo niet honderden tools op de markt. Sommige tools zijn breed inzetbaar, maar er zijn ook specialistische tools. Bovendien komen ze met uiteenlopende prijskaartjes, van open-source tot enterprise licenties. Maar hoe kies je nu de tool die het best past bij jouw teams, producten en organisatie? Dat het in de praktijk behoorlijk lastig is, blijkt wel uit de volgende drie situaties die wij in de praktijk vaak tegenkomen als wij bij een organisatie binnenkomen:
Er is ooit gekozen voor een tool of suite die gericht is op het geautomatiseerde end-to-end testen. Het benodigde onderhoud is alleen een beetje onderschat..
Technisch blijkt de gekozen tool een schot in de roos, maar bij de selectie zijn toch wat randvoorwaarden over het hoofd gezien..
De ontwikkelaars in het team uiten veel weerstand tegen het gebruik van de door de organisatie voorgeschreven tooling.
Herkenbaar? Lees hieronder welke valkuilen hieraan ten grondslag liggen en welke lessen we hieruit kunnen trekken. Tot slot nog een aantal handvatten die van pas kunnen komen wanneer jouw team of organisatie voor een toolselectie staat. Hoewel deze blog toegespitst is op testautomatiseringstools, zullen de genoemde criteria, valkuilen en best practices ook van toepassing zijn op toolselecties in andere vakgebieden.
Valkuil 1 - “Testautomatisering = het automatiseren van testen”
Allereerst zien we vaak dat men de huidige testaanpak en bijbehorende testgevallen als uitgangspunt nemen wanneer een testautomatiseringsaanpak (met bijbehorende tooling) bepaald wordt. Dat is erg voor de hand liggend, omdat met de bestaande testaanpak ook voldoende inzicht in de kwaliteit van de software verkregen kon worden. Toch kleeft er ook een probleem aan deze aanpak. De bestaande testgevallen worden hoogstwaarschijnlijk met de hand uitgevoerd op de gebruikersinterface van een applicatie. Wanneer je diezelfde handelingen wilt gaan automatiseren, dan wordt de focus van de toolselectie automatisch gericht op front-end of end-to-end testtools. Eigenlijk is de testtool dus al gekozen voordat de testaanpak goed uitgedacht is. Het resultaat kan zijn dat er een geautomatiseerde testset ontstaat die zich voornamelijk in de GUI afspeelt, waardoor de testen relatief traag zijn en lastig onderhoudbaar zijn. In de praktijk uit zich dat vaak in testen die altijd op rood staan en uiteindelijk een oplossing die geen waarde toevoegt voor het team en het ontwikkelproces.
Valkuil 2 - “Er zijn meer randvoorwaarden dan de technische fit”
Een toolselectie gaat vaak op een organische manier. Er wordt een bepaalde uitdaging ervaren waar vast een oplossing voor is. Hierop wordt een onderzoekje gedaan waarbij gekeken wordt of we iemand kennen die een geschikte tool weet, of er wordt wat gegoogeld en nadat we hebben gecheckt of de technische requirements kloppen doen we on the go een proof of concept. Zeker bij open source tooling iets wat vaak laagdrempelig is. Helaas is het vaak zo dat er verderop in de tijd toch belemmeringen opduiken die vooraf niet waren voorzien. Denk aan ondersteuning die ontbreekt door een te kleine, inactieve community, of later in het ‘project’ benodigde functionaliteiten die er niet zijn. Maar ook aan ontbrekende skills in het team om de oplossing volop te adopteren, of weerstand elders in de organisatie. Uiteindelijk zien we dan dat het initiatief een stille dood sterft en alle moeite voor niets is geweest.
Valkuil 3 – “One tool does it all”
De derde valkuil die we in de praktijk vaak tegenkomen is dat men probeert alle (typen) geautomatiseerde testen van een team, of zelfs de hele organisatie, onder te brengen in één tool of framework. Op het eerste oog klinkt het ideaal dat je een totaaloplossing hebt voor allerlei testsoorten. Een dergelijke testsuite bestaat doorgaans uit verschillende componenten voor het bouwen, inplannen en analyseren van de geautomatiseerde testen. Deze opzet heeft echter wel een keerzijde. Het blijkt namelijk niet of nauwelijks te integreren in het bestaande ontwikkelproces, waardoor testautomatisering een afgezonderd eilandje wordt. Het resultaat is dan dat een dergelijke oplossing slecht geadopteerd wordt door het ontwikkelteam.
Ditzelfde probleem zien we ook geregeld bij “low-code” tools, waarbij de testen begrijpelijk zijn voor “personen uit de business”. Het klinkt ideaal dat de projectmanager of product owner zonder code-kennis zelf testen kan schrijven door middel van hapklare componenten, maar in de praktijk komt daar doorgaans weinig van terecht. Het resulteert echter wel in weerstand bij de teamleden die in hun dagelijkse werk op deze tool aangewezen zijn: de ontwikkelaars of testers.
De sleutel tot succes
Op de één of andere manier is het lastig voor veel teams om voor de juiste tool te kiezen. Soms terwijl er een complex traject voor is opgezet, maar ook bij laagdrempelige selecties. De sleutel tot succes? Maak in ieder geval gebruik van de volgende handvatten.
Bedenk dat een tool alleen maar een hulpmiddel is. Het wordt alleen een succes als eerst goed nagedacht is over de aanpak. Pas daarna is het mogelijk de tool te kiezen die daar het best bij ondersteunt. PerformanceArchitecten ondersteunt hier graag bij!
Doe een goede omgevingsanalyse. Beter hier even aandacht aan geven en dit te checken bij je stakeholders, dan er later achter te komen dat het toch niet past. Ik gebruik altijd één van onze checklisten om snel te kunnen checken of we niet iets vergeten.
Als je effectief en flexibel wil zijn als team heb je een tool nodig dat goed integreert bij jouw werkzaamheden. Wij onderzoeken daarom altijd of het aansluit bij de werkwijze van iedereen die met de tool werkt.