Als het op testautomatisering aankomt, zijn er veel talen die je kunt gebruiken en nog veel meer tools om uit te kiezen. Dus welke taal/talen en/of tool(s) moet je kiezen voor je project(en)?
Hoewel het onmogelijk is om een one-size-fits-all keuzeplan of procedure te schrijven voor elke situatie, kan ik wel een aantal inzichten bieden die je kunnen helpen bij het maken van de keuze die voor jou de juiste is.
NOTE: In dit artikel richt ik me op de aspecten van taal / tool selectie die vaak over het hoofd worden gezien. Ik ga ervan uit dat je een duidelijk beeld hebt van het probleem dat de taal / de tool op moet lossen.
Veel voorkomende valkuilen
Er zijn een aantal valkuilen die kunnen leiden tot het kiezen van een taal of tool die niet optimaal is. Misschien is er snel resultaat, terwijl de gebruikers van het framework tijd verliezen met het analyseren van problemen omdat de logs niet de benodigde informatie bevatten.
Of misschien is er veel lijm code nodig om te communiceren met verschillende interfaces.
Misschien doet de tool zijn werk, maar is het (bijna) onmogelijk om de tests op VM's of in containers uit te voeren.
Alleen tools die al in gebruik zijn binnen het bedrijf komen in aanmerking
"We hebben (licenties voor) deze tool aangeschaft, dus alle teams moeten het gebruiken voor testen / testautomatisering."
Aangezien het tool landschap voortdurend in ontwikkeling is, is het onwaarschijnlijk dat een goede keuze die in het verleden is gemaakt, de optimale keuze is om aan de huidige behoeften te voldoen. De kans is groot dat er nu betere / meer passende tools beschikbaar zijn om aan de huidige behoeften van het team of de teams te voldoen. Misschien kan de klus worden geklaard met de reeds aangeschafte tool, maar het risico is reëel dat de kosten van efficiëntieverlies (in vergelijking met een andere, meer passende tool) hoger zijn dan de kosten van de reeds aangeschafte tool. Soms is je verlies nemen en geen gebruik maken van reeds gekochte licenties de goedkopere optie.
Dit geldt ook voor gratis tools. Er zijn misschien geen licentiekosten te betalen, maar het leren van een nieuwe tool / framework / taal kost tijd en dus geld. Het verschil in efficiëntie van tooling door een betere afstemming op het probleem kan er nog steeds voor zorgen dat investeren in de nieuwe tool / framework / taal de goedkopere oplossing is.
Alleen open source of gratis tools komen in aanmerking
In het huidige tooling-landschap is er voor bijna elke automatiseringsuitdaging wel een gratis of open source tool beschikbaar.
Toch adviseer ik om ook gelicenseerde producten mee te nemen in het tool selectie proces.
Natuurlijk zijn er zorgen over vendor lock-in en daar moet rekening mee worden gehouden.
Maar als een betaalde tool een passende oplossing biedt voor het automatiseringsprobleem en het kiezen van een gratis alternatief betekent dat het team meer uren moet investeren om tot hetzelfde resultaat te komen, dan kan gratis de duurdere optie zijn.
De (abonnements)kosten van tools lopen sterk uiteen, maar bedenk altijd dat de uren die de teamleden besteden ook niet gratis zijn.
Alleen "ontwikkeltalen" komen in aanmerking
Het lijkt logisch om een automatiseringsframework te kiezen op basis van de taal of talen die bij de ontwikkeling van de applicatie worden gebruikt. Meerdere mensen in het team hebben die al een grondige kennis en ervaring hebben van de taal waarin het gekozen framework is geschreven kan een voordeel zijn: heeft zo zijn voordelen hebben:
het zal (in het algemeen) gemakkelijk zijn om de tool te integreren in de ontwikkel- / CI/CD-omgeving
geavanceerde use cases van een framework zullen over het algemeen gemakkelijk te begrijpen zijn door de mensen met ervaring in de gekozen taal
code reviews, pair programming en coaching / training zal gemakkelijk te organiseren zijn binnen het team
Maar men moet zich realiseren dat deze aanpak gemakkelijk kan leiden tot tunnelvisie / tool lock-in. Elke taal ecosysteem heeft een toonaangevende unit test framework en de kans is groot dat de ontwikkelaars het gebruiken. Omdat het unit test framework bekend is, is de kans groot dat het gebruikt zal worden om de automatiseringsuitdaging aan te gaan (zelfs als het om integratie of E2E testen gaat). Dit kan ofwel via een plug-in voor het unit test framework of via een eigen implementatie.
Als je die weg inslaat, kan het unit test framework snel veranderen in een hamer.
In plaats van te zoeken naar het beste gereedschap voor het probleem, wordt het probleem een spijker waar op gehamerd moet worden.
De laatste 5-10 jaar heeft dit taalvooroordeel nog een ander effect gehad waar we ons bewust van moeten zijn. In het verleden was de GUI voor een systeem vaak een native Windows applicatie, geïmplementeerd in dezelfde taal als de back-end / server.
Dit is in de loop der jaren veranderd; met de opkomst van browser applicaties is de GUI voor een typisch systeem niet langer een native Windows applicatie. Deze browser-based GUI's zijn bijna uitsluitend JavaScript / TypeScript applicaties. Tegelijkertijd zijn er weinig back-ends / servers geïmplementeerd in die talen.
Dit heeft in veel bedrijven geleid tot de situatie waarin het testframework is geschreven in de back-end taal, maar het voert tests uit om de front-end / GUI te verifiëren (die niet meer in dezelfde taal geschreven is). Tegelijkertijd zijn er unit tests voor de GUI elementen die geschreven worden door de front-end ontwikkelaars. Daarnaast kunnen er ook (component) integratietesten zijn om de belangrijkste flows door de GUI te valideren. Deze tests / flows en de onderliggende methoden kunnen vaak niet worden herbruikt door de testautomatisering oplossing, omdat deze in een andere taal is. Het moge duidelijk zijn dat dit een zeer onwenselijke situatie is en dat het voordeel van het gebruik van een taal die al binnen het team wordt gebruikt, in feite een nadeel kan zijn geworden.
Er wordt alleen gekeken naar de tech stack van het team zelf
Bij het selecteren van een tool om een uitdaging voor jouw team aan te pakken, is het gemakkelijk om de rest van de organisatie te vergeten.
Hoewel steeds meer tools platformonafhankelijk zijn, zijn ze dat niet allemaal.
Als het hele team op Windows-machines werkt, is een tool die alleen voor Windows is bedoeld misschien een goede keuze.
Maar als ergens in de toekomst de behoefte ontstaat om het Ops-team de tests te laten draaien op een (schaduw) productieomgeving, is dat misschien helemaal niet mogelijk als de Ops-cloudomgeving volledig op Linux gebaseerd is.
Het omgekeerde komt ook voor: ontwikkeling wordt gedaan op Mac en Linux, maar de gebruikers die acceptatietesten doen werken op Windows.
Andere overwegingen
Bij het kiezen van een tool of taal zijn er andere factoren om rekening mee te houden dan wat er al in gebruik is binnen het bedrijf.
Tool of taal ecosysteem en gemeenschap
Een bepaalde tool of taal kan goed passen bij het probleem dat opgelost moet worden, maar het kan uiteindelijk niet de juiste keuze zijn.
Kijk bij de selectie van een tool / taal ook naar het ecosysteem en de community rondom de tool / taal. Stel de volgende vragen:
Zijn er (kwalitatief goede) tutorials beschikbaar?
Wordt de tool / taal actief onderhouden?
Wie zit er achter de tool? Een individu, een kleine startup, een toegewijd team gesteund door een groot bedrijf?
Is er een actieve community die nieuwe gebruikers verwelkomt en bereid is om vragen te beantwoorden?
Zijn er libraries / extensions beschikbaar om veel voorkomende problemen op te lossen?
Tool of taal volwassenheid
Bijna elke dag komen er nieuwe tools en talen bij. Sommige tools / talen bouwen voort op andere, andere kiezen een geheel nieuwe benadering om hetzelfde probleem op te lossen.
Afhankelijk van jouw behoefte, kan een "new kid on the block" een goede optie zijn of helemaal niet geschikt. Als je in een klein team werkt en niet hoeft te integreren met automatiseringsoplossingen van andere teams, zou het prima moeten zijn om iets nieuws te proberen (en over te stappen als het in de praktijk niet blijkt te werken).
Aan de andere kant, als de tool moet worden uitgerold in een grote organisatie, kan het geen aanvaardbaar scenario zijn om over te stappen als het ergens niet werkt. Ook kunnen er eisen worden gesteld aan de beschikbare documentatie en ondersteuning waaraan nieuwe tools mogelijk nog niet voldoen.
Bepaal bij de evaluatie van een nieuwe tool / taal of wat nu beschikbaar is in de nabije toekomst voldoende zal zijn. Zo niet, zorg dan dat je een alternatief klaar hebt als de tool / taal niet de verwachte vooruitgang boekt.
Grootschalige migraties vs. hybride strategieën
In grote (corporate) omgevingen kan de introductie van nieuwe talen of tools een impact hebben die veel verder reikt dan de scope van het team zelf. Dit hoeft een nieuwe taal of tool niet uit te sluiten, maar om een bedrijfsbrede adoptie te garanderen moet er een duidelijk implementatieplan zijn. Er zijn verschillende benaderingen mogelijk, variërend van een grootschalige migratie in korte tijd tot een geleidelijke migratie over een langere tijdspanne.
Welke aanpak geschikt is, hangt af van de situatie in het bedrijf, maar als je geen plan hebt dat op (management)steun kan rekenen, verkleint dat de kans op succes op de lange termijn.
De arbeidsmarkt
Personeelsverloop in een organisatie is een constant proces. Dit is misschien niet het eerste waar je aan denkt bij het kiezen van een tool of taal voor een project, maar het verdient wel enige overweging.
Jong talent dat de arbeidsmarkt betreedt, zal tijdens hun studie bepaalde tools en talen gebruikt hebben. Zijn dat de tools en talen die in uw bedrijf worden gebruikt? Gebruikt u dezelfde tools en talen als vergelijkbare organisaties?
Denk ook aan "what's hot and what's not". Ervaren kandidaten zullen bij vacatures ook kijken naar hun CV en persoonlijke groei. Weinig professionals zullen enthousiast worden van het vooruitzicht om te werken met talen of tools die worden beschouwd als legacy, te exotisch of gewoon niet leuk om mee te werken.
Uw keuze kan een impact hebben op hoe gemakkelijk het zal zijn om toekomstige vacatures in te vullen.
Afsluitende opmerkingen
Hoewel de in dit artikel besproken aspecten lang niet alle overwegingen zijn die een rol spelen bij de keuze van talen/tools, heb je hopelijk toch wat nieuwe inzichten opgedaan. Heb ik overwegingen gemist die volgens jou vaak over het hoofd gezien worden? Heb je een andere kijk op de besproken overwegingen?
Ik hoor graag van je, voel je vrij om contact met me op te nemen via robin.mackaij@enqore.tech.