Auteur: Fatih Topcuoglu ● vmax78@hotmail.com
Redactie: Eric Spaargaren
Tegenwoordig is er een breed scala aan testautomatiseringstools beschikbaar die variëren van gratis tot betaalde versies. Het aanbod is zo groot dat zowel testspecialisten als organisaties door de bomen het bos niet meer zien. Testprofessionals zijn vooral bezig met het opdoen van kennis rondom de tools waar organisaties met het vraagstuk worstelen welke tool voor hen het meest geschikte is.
Voor testprofessionals is het lastig om focus te leggen. Een tool gaat vaak gepaard met een onderliggend platform, architectuur en codeertaal. Bij het aanleren moet je al deze aspecten in acht nemen. Hierdoor is het niet haalbaar om een onbeperkt aantal tools in je kennisbagage op te nemen. Probeer toch als professional een langetermijnvisie te creëren en enigszins focus te houden. Er zijn veel platformen, talen en tools beschikbaar op de markt. Staar je niet blind op de grote variëteit, je kunt simpelweg niet alles leren en overal een expert in zijn.
Mijn persoonlijke uitgangspunt hierbij is het aanleren van een wat zwaardere programmeertaal, zoals bijvoorbeeld Java. Vanuit hier is het makkelijker om toolkennis op te doen die gebaseerd is op dat specifieke programmeertaal. Een bijkomend voordeel is dat de drempel naar de wat lichtere programmeertalen, zoals Javascript, lager wordt.
In een Agile omgeving, waarbij de scheidslijn tussen ontwikkelaars en testers steeds dunner wordt, is het aanleren van een programmeertaal op zich al een waardevolle investering.
Naast testprofessionals worstelen organisaties vaak ook met een vergelijkbaar probleem. Welke van de zoveel mogelijke tools past het beste binnen eigen organisatie? Er is simpelweg te veel keuze en het is lastig te bepalen welke tool geschikt is. Meewegende factoren zijn onder andere het eindproduct, de beschikbare architectuur, het platform, de beschikbare kennis en de kosten. Hoe zou deze zoektocht dan het beste aangepakt kunnen worden?
Door vooraf een gedegen analyse uit te voeren bijvoorbeeld. Het is weliswaar een initiële investering waarvan de baten niet direct zichtbaar zijn. Maar de kans dat je verkeerde keuzes maakt, is groter als je deze stap overslaat. Bij een verkeerde keuze ben je direct ‘technische schuld’ aan het opbouwen, het achteraf inlossen van deze schuld kan een kostbare zaak worden. We kennen allemaal wellicht de ‘testpiramide’. Hoe later je in het ontwikkeltraject een bevinding signaleert des te duurder de oplossing wordt. Hetzelfde geldt hier namelijk ook.
Een ander bijkomend aandachtpunt is de eerdergenoemde beschikbare (interne) kennis. Vaak wordt er op projectbasis gewerkt en worden externe professionals ingehuurd om kennis en kunde in te brengen. Een project duurt niet eeuwig, de ingehuurde professionals stromen op een gegeven weer uit. De uitdaging zit hem in de borging van deze (externe) kennis binnen de eigen organisatie. Als dit niet goed ingeregeld is, kan het zomaar gebeuren dat de opgeleverde producten inclusief alle (test)tools in de prullenbak verdwijnen.
Terugkomend op de toolkeuze vanuit organisaties. In sommige gevallen zie je dat organisaties inzetten op ‘low-coding’ tools. Dit soort tools zijn veelal gebaseerd op het ‘record & playback’ principe. Het argument hierachter is dat het laagdrempelig is en dat de business mee kan (test)automatiseren. Echter, het gevaar wat hierachter schuilt, is dat je direct ‘technische schuld’ kan opbouwen. Het zou zonde zijn om achteraf te moeten ontdekken dat de gekozen tool de lading niet dekt en hiermee ongeschikt is.
Om te voorkomen dat je eindigt als ‘a fool with a tool’ is een gedegen analyse vooraf en een langetermijnvisie cruciaal.