Redactie: Eric Spaargaren
Auteur: Rachid Ben Allal ● benallal.r@live.nl
IT en ook het vak softwaretesten ontwikkelt zich in een rap tempo. Er verschijnen vrijwel jaarlijks nieuwe technieken, tools en frameworks op de markt. Welke trends zie jij in 2020?
‘Ik moet eerlijk bekennen dat ik slecht ben in het bijhouden van trends. Over de afgelopen jaren wordt er steeds meer van hetzelfde geroepen en soms vraag ik mij af of ik daar in mee moet gaan. De lijstjes met trends die voorafgaand het nieuwe jaar worden samengesteld, zie ik persoonlijk als contentverrijking. Uiteindelijk gaat het om wat wordt verwacht van de tester tegenwoordig en in de toekomst.’
Ook op dat gebied is inderdaad een ontwikkeling gaande. Hoe zie jij dat vanuit jouw perspectief?
‘Persoonlijk vind ik dat je je als professional altijd moet afvragen of je nog van toegevoegde waarde bent in de rol die je hebt op dat moment. Een omgeving waar bijvoorbeeld volgens het Shift-Left principe wordt gewerkt, vraagt simpelweg een andere mindset van de tester(s) aldaar. Je ziet een heleboel testers die moeite hebben om de slag te maken van testen in een traditionele omgeving (waterfall), naar testen in een Scrum/DevOps omgeving waar automation een onmisbare schakel is.’
‘Als tester ontkom je er tegenwoordig niet aan om wat te weten over Automation en mee te kunnen praten, te kunnen lezen en bepaalde zaken te kunnen herkennen. Daar wil ik wel aan toevoegen dat men niet meteen in staat hoeft te zijn om vanaf nul Automation op te bouwen, daar waar veel organisaties in mijn optiek te veel tijd aan besteden. Het is een kwestie van efficiëntie waarbij je je als organisatie de vraag moet stellen: in hoeverre is deze TA-oplossing van toegevoegde waarde?’
Over efficiëntie gesproken: in een van jouw artikelen las ik onder andere dat Test Automation een vorm is van Software Development. Kan daarmee gesteld worden dat het efficiënter is om Test Automation over te laten aan een ontwikkelaar?
‘Dat klopt, Test Automation zie ik als een vorm van Software Development. Of het efficiënter is om dat over te laten aan de ontwikkelaar(s), is voor mij een minder interessant vraagstuk. Je streeft als team namelijk hetzelfde belang na: kwaliteit. Ik denk dat het interessanter is om na te denken over hoe je het gat tussen de tester en de ontwikkelaar kleiner kunt maken. Voor een deel betekent dat testers technisch vaardiger moeten worden, maar dat er ook nog veel werk te doen is om de ontwikkelaar mee te nemen in de werkzaamheden van de tester. Denk daarbij aan het meegeven van testkennis, -ervaring en -inzichten. Daar waar ik ontwikkelaars voorheen niet altijd bereid vond om zich te bemoeien met het testvak, zie ik tegenwoordig dat zij beter weten wat het testvak inhoudt en daarover willen meedenken. Ik denk dat daar de meeste winst te halen valt in geval je als organisatie wendbaarder wilt zijn.’
Een poos geleden heb je een artikel geschreven waarvan de titel meteen mijn interesse wekte: we don’t need more automation engineers! Hier heb je waarschijnlijk al de nodige discussies over gevoerd, maar ik ben toch nog wel benieuwd welk aspect je hier wilde ‘aanwakkeren’?
‘Haha, een ware clickbait en het werkt! Waar het eigenlijk om gaat, is het volgende: Wat ik om mij heen zie gebeuren (gelukkig wel steeds minder), is dat het leren van een tool en/of een bepaald trucje veelal als doel wordt gehanteerd. Dat werkt niet. De tool zou juist een middel moeten zijn om een bepaald doel te bereiken. Test Automation Engineering gaat niet enkel om het leren werken met een tool of het leren van een programmeer/script-taal, maar ook om het kunnen begrijpen en toepassen van principes en patronen binnen Software Development. Daarbij moet het fundament softwaretesten niet uit het oog worden verloren. Een TA-engineer zie ik dan ook als een hybride vorm van een softwaretester en een softwaredeveloper. Daarom is een Test Automation Engineer tegenwoordig veel meer dan het kunnen toepassen van een softwaretesttool.
Ik heb een tijd geleden deelgenomen aan een sessie waarin het onder andere ging over Test Automation versus Check Automation. Tijdens deze sessie was een aantal van de deelnemers van mening dat Test Automation meer een vorm is van Check Automation, valideren/controleren of alles nog werkt. Hoe kijk jij hier tegenaan?
‘Er zijn in ons beroepsveld mensen die aanstoot nemen aan de term testautomatisering en heel scherp zitten op het verschil tussen een test en een check. Ik vind het belangrijk dat mensen het verschil zien tussen wat een test is en wat een check is. Persoonlijk hecht ik weinig waarde aan hoe je het uiteindelijk noemt.
‘Mijn definitie voor testautomatisering is vrij simpel en tegelijkertijd vrij breed. Ik definieer testautomatisering namelijk als het inzetten van tools om testactiviteiten efficiënter uit te kunnen voeren. En of dat dan het geautomatiseerd uitvoeren van checks is, het genereren van testdata of het gebruiken van stubs, wat mij betreft valt dat onder de noemer testautomatisering. Ik vind het onderscheid tussen check en test wel belangrijk als het je hebt over: wat wil je automatiseren? Wat zou je wel/niet moeten automatiseren? Uiteindelijk gaat het er om wat het meest efficiënt is om te doen als tester.’
Hoe kijk je naar de ontwikkeling van low-code test automation oplossingen? Een niet-tester die met behulp van modellen een testsuite kan opzetten. Kan dit ten koste gaan van de kwaliteit van het eindproduct?
‘Laat ik vooropstellen dat ik niks heb tegen low-code tools als onderdeel van Test Automation. Het gaat namelijk over een veel hoger doel wanneer je het hebt over Test Automation, namelijk als tester bepaalde informatie sneller kunnen opleveren en sneller feedback te ontvangen. Bij low-code tools en Test Automation in code zit voor mij de afweging tussen initieel gebruiksgemak (de drempel bij low-code tools is veel lager) en flexibiliteit en gemak van integratie. Low-code tools zijn makkelijker in gebruik, maar je levert daarentegen flexibiliteit in. In hoeverre is het bijvoorbeeld te integreren met andere frameworks? De low-code tools die flexibel genoeg zijn om te kunnen integreren in pipelines en te schalen waar nodig, ben ik nog niet tegengekomen’.
Na wat inhoudelijke zaken te hebben besproken wil ik ten slotte overgaan naar een ietwat persoonlijkere vraag. Tegenwoordig organiseer je met enige regelmaat een workshop en/of cursus (al dan niet in opdracht). Je schrijft blogs, artikelen, schuift aan bij interviews/podcasts. Kortom, heel actief als het gaat om kennisdeling binnen de testcommunity. Vertel eens, wat zijn jouw drijfveren en in hoeverre ‘leer’ jij van al deze ervaringen?
‘Je gaf aan dat je wel eens een workshop Rest Assured van mij via TestNet hebt bijgewoond. Best grappig, dat was namelijk mijn hernieuwde introductie in het geven van trainingen. Daar is het allemaal een beetje begonnen. Daarvoor heb ik vanuit mijn toenmalige werkgever ook wel tool-trainingen georganiseerd. Vervolgens is het een tijdje op de plank blijven liggen (na uitdiensttreding) en heb ik met de workshop Rest Assured op TestNet het vuurtje weer aangewakkerd. Trainingen geven vind ik ontzettend leuk, omdat je ten eerste met verschillende mensen in aanraking komt. Daarnaast haal ik er heel veel lol uit om mensen iets bij te brengen. Interessant hierbij, en dat blijft de uitdaging voor mezelf, is om relatief complexe materie (in de ogen van de deelnemers) zo over te brengen dat ze dat binnen de duur van zo’n training op kunnen pakken en daar vervolgens iets mee kunnen. Het moment dat ik constateer dat deelnemers die eerder nooit een regel code hebben opgeschreven, na afloop van de training aangeven dat het ‘kwartje’ is gevallen is voor mij een teken van voldoening en daar haal ik enorm veel energie uit.’
‘Je zou het niet verwachten, maar bij het geven van een training leer ik minstens zo veel als dat de deelnemers doen. Ik sta absoluut open voor feedback. Hetgeen wat ik in een training laat zien, is de manier zoals ik het heb geleerd, maar dat wilt niet zeggen dat dat de beste manier is. Feedback kan ervoor zorgen dat ik trainingen optimaliseer waar nodig. Het is een complete misvatting als men denkt dat je een expert moet zijn om een training te kunnen geven.
—END