Auteur: Rachid Ben Allal ● rachid.benallal@closesure.nl
Redactie: Kimberly Snoyl en Eric Spaargaren
Gezien mijn opleidingsachtergrond had ik geen enkele ervaring met softwaretesten. Nadat ik mij had ingelezen in onder andere T-Map heb ik na een aantal jaren de overstap gemaakt naar CMG. Daar ben ik in aanraking gekomen met tools als LoadRunner, WinRunner en wat wij de dag van vandaag kennen als HP QTP. Ik heb sindsdien een onvoorwaardelijke liefde ontwikkeld voor het vak en zie mij zelf in de toekomst niet meer overstappen naar een andere sector. Ik heb voor veel verschillende opdrachtgevers gewerkt, met name in de commerciële hoek. Denk aan opdrachtgevers als Canon, TeleNet (het Belgische Ziggo), DELA en De Lage Landen. Momenteel werk ik voor Capgemini en ben ik ingezet bij de NS (Nederlandse Spoorwegen). Op het huidige project ben ik in aanraking gekomen met Codeless Automation, daar waar wij het verder in het gesprek over gaan hebben. Wat hobby’s betreft: ik fiets en wandel graag. Daarnaast ben ik een (bord)spelfanaat, met name Magic:The Gathering.
Leuk! Een enorme variatie aan opdrachten. Mooi om te zien. Op dit moment ben je ingezet bij de NS met als rol Test Automation Architect. Wat doe je zoal in een dergelijke rol?
Als Test Automation Architect ga je een stapje verder dan de rol als bijvoorbeeld Test Automation Engineer. Je bent verantwoordelijk voor het inrichten, bijhouden en monitoren van het testframework an sich. Dat gaat een stuk verder dan testen. Vragen waarmee je te maken krijgt zijn bijvoorbeeld: hoe kan je op de beste manier de testen middels automation vormgeven, hoe moet dat er dan uit zien, welke informatie of tooling moet er gedeeld of aangevraagd worden, zodat het voor een ieder op het project duidelijk is wat er gebeurd?
Minder uitvoerend, meer regisserend?
Inderdaad. Zeker in de beginfase wanneer je het project wilt opzetten. Op het moment dat het draait, kom je wel dichterbij de uitvoering. Bij de NS heb ik op dit moment ook een coachende rol en train ik testers uit ontwikkelteams om te gaan met bepaalde tools.
Zie je jezelf ook als onderdeel van een ontwikkelteam? Hoe positioneer je de rol als Test Automation Architect?
Wij zijn wel opgenomen in het project, maar vallen buiten het ontwikkelteam. Wel merken wij de afgelopen tijd dat de werkzaamheden projectoverstijgend zijn en denken daarom op termijn ook uit het project te worden getrokken.
In eerste instantie zijn wij bezig geweest met het opzetten van het framework voor de DevOps teams, zodat zij er gebruik van kunnen maken. Naarmate men steeds beter met het framework om is leren gaan, zijn wij meer als ‘serviceteam’ gaan fungeren.
Dus vooral adviserend en waar nodig ook probleemoplossend.
Ben je als Test Automation Architect ook betrokken bij leverancier- en toolselectie?
Zeker. De keuze was eigenlijk vrij snel gemaakt. De omgeving waarin ik werkzaam ben is een SAP omgeving (Binnen het huidige project wordt er gemigreerd van SAP ECC naar S4/HANA en worden drie financiële stromingen samengebracht tot één met ook één SAP systeem in plaats van drie. Ook de communicatie met omliggende tooling zoals SAP HR, SAP SRM en PowerBI is onderdeel van dit project). Na een korte analyse is in overeenstemming met de projectleiding gebleken dat WorkSoft de meest geschikte tool is.
Aha, een SAP landschap. Had je daar al eerder ervaring mee?
Nee, helemaal niet. Toen ik bij aanvang te horen kreeg dat ik in een SAP omgeving terecht zou komen, moest ik even lachen.
Waarom?
Toen ik begon bij CMG kwam ik voor de keuze te staan óf het avontuur als ‘allround tester’ óf als ‘SAP tester’. Ik koos bewust toen voor allround tester en raad eens. Twintig jaar later beland je toch nog in een omgeving waar je te maken hebt met SAP software.
Hier en daar lees ik dat voor SAP systemen specifieke testtooling wordt gebruikt. Is WorkSoft een dergelijke tool?
Jazeker. Ik kende WorkSoft niet eerder en wist dus ook niet wat ik kon verwachten. Men wist mij wel meteen te vertellen dat het een ‘codeless automation’ tool is en dat het zijn/haar sporen heeft verdiend in de SAP markt. Daar moest ik in eerste instantie hard om lachen. Ik kom namelijk uit een wereld waarin het schrijven van code (scripten) onontkoombaar is. Daarbij dacht ik dat een codeless automation tool voor geen meter zou werken. Wat blijkt; het werkt als een tierelier!
Het enthousiasme spat er van af, merk ik. Waarom?
Dat heeft te maken met een aantal zaken. Ten eerste wil je als consultant je klant zoveel mogelijk van dienst zijn en uiteindelijk deze klant zover krijgen dat de techniek en/of implementatie zelfstandig beheerd en uitgevoerd wordt. Daarbij wil je het de klant eenvoudig maken bij het werven van medewerkers door minder gericht te zoeken naar bepaalde specialisme en kennis. Iemand die logisch kan denken, redeneren en de Engelse taal begrijpt zou voldoende moeten zijn. Bij een codeless automation tool heb je geen specifieke vaardigheden nodig, zoals het kunnen scripten van programmacode.
Daarnaast is het traject van ‘adoptie’, dus het inlezen en uitproberen van de tool erg soepel verlopen. Wij (een collega en ik) hebben bij de NS bijvoorbeeld geen training gehad, maar hebben zelf het initiatief genomen om het tool te leren. Je begint ergens en neemt wat testscenario’s op. Uiteindelijk zijn wij zover gekomen dat wij zelf mensen op het project trainen en leren omgaan met de tool. Voor de NS erg rendabel.
Wat moet ik mij voorstellen bij een dergelijke training die jullie verzorgen?
Nou, heel basaal. Het zijn lessen van drie keer twee uur. Hoe werkt het? Wat zijn de mogelijkheden? Gezien het feit dat wij nu dus ook als serviceteam opereren, staan wij bijna 24/7 in contact met de gebruikers. Wij reviewen het werk van de gebruikers, doen upgrades van bepaalde features en fungeren als vraagbaak.
Je geeft aan dat er, vergeleken met andere test automation frameworks, weinig tot geen scripting aan te pas komt. Hebben jullie iemand ervan moeten overtuigen dat dit tool het meest geschikt is? Zo ja, op welke manier?
Wat in ieder geval buiten kijf stond, was dat het codeless moest zijn. Een aantal andere harde eisen was schaalbaarheid, mogelijkheden voor shift-left en shift-right implementatie en integratie in een pipeline. Met dat laatste zijn wij nog niet zover, maar wel hard op weg. Voordat de projectverantwoordelijken in zee gingen met WorkSoft, is er een business-case geschreven. Met inachtneming van de eisen, is gekozen voor WorkSoft.
Is WorkSoft een dedicated tool dat wordt gebruikt op het project? Draaien er andere testtools naast?
Voor ik antwoord geef op de vraag zal ik ter verduidelijking kort schetsen hoe de tool eruitziet. WorkSoft bestaat uit verschillende features. Allereerst is er de record en playback functionaliteit. Neem het scenario op en laat dat reviewen. Deze feature heet Analyze. Op het moment dat men denkt: okee, dit script doet wat wij willen, daar zitten de testen en controles in die wij willen uitvoeren, dan komt dit script in de feature Certified terecht. Inmiddels is dan ook bekend welke elementen worden ‘geraakt’. Op het moment dat het script door de Certify feature wordt verwerkt, is alle data nog hardcoded. Wij hebben daarom besloten dat voor elke transactie in SAP een bouwblok wordt ontwikkeld. Dit bouwblok is compleet data-onafhankelijk. Ten slotte kent WorkSoft een Execution Manager. Deze feature biedt bijvoorbeeld de mogelijkheid om testen te schedulen (lights-out testen). Bovendien kun je de test dan remote uitvoeren, terwijl je lokaal verder werkt aan andere scripts.
WorkSoft is de nummer één dedicated tool dat wordt gebruikt als het gaat om het functioneel end-to-end testen van de UI (User Interface). Persoonlijk is het streven om zoveel als mogelijk codeless automation te gaan hanteren in de ontwikkelpijplijn.
Hoeveel gebruikers werken bij de NS met deze tool?
In denk een stuk of twintig (het serviceteam van twee personen meegerekend). Binnen de huidige DevOps teams zitten er per team twee à drie personen die getraind zijn of getraind moeten worden. Deze groep zal de komende tijd alleen maar groeien, gezien de laatste interessepeiling.
Bovendien zijn er ondertussen meer projecten aan aangehaakt/geïnteresseerd geraakt in het gebruik van de tool waardoor wij als team ook een transitie hebben moeten ondergaan om optimaal support te kunnen bieden. Zo hebben wij de verantwoordelijkheid van het maken van de feitelijke scripts verplaatst van ons team naar de diverse te ondersteunende teams, onze klanten zeg maar. Hierdoor hebben we onszelf in staat gesteld om andere taken op te pakken, meer gericht op het bieden van de dienstverlening (Service Delivery), integratie en support.
Ten slotte zijn we ook bezig om de tool in zetten ten behoeve van Test Data Management, denk hierbij aan het gebruiken van geanonimiseerde data in het volledige testproces/DataOps en dat multi-domein. Dus ik verwacht nog een redelijke groei dit jaar.
Uit dit gesprek en jouw enthousiasme krijg ik de indruk dat WorkSoft een tool is met een laag instapniveau. Klopt dat?
Jazeker! Ik heb een goed voorbeeld. Binnen Capgemini is een aantal trainees werkzaam en één van hen kreeg de opdracht om aan de slag te gaan met de tool. Binnen een week of drie was deze persoon al op volle snelheid en kon direct worden ingezet bij de NS. Ik houd dat uiteraard vanaf de zijlijn in de gaten en review het werk waar nodig. De personen die wij trainen, hebben geen enkele ervaring met Test Automation, maar lopen hier echt mee weg.
Gemakkelijk te adopteren dus. Hoe gaan de programmeurs hiermee om?
De programmeurs hechten waarde aan kwaliteit, maar ook aan snelheid. Ook zij zijn steeds vaker verbaasd over de mogelijkheden die WorkSoft biedt als het gaat om het makkelijk testen van bepaalde scenario’s.
Veel voordelen dus, maar zijn er ook nadelen te noemen?
In eerste instantie is dat de prijs. Men moet deze tool niet bij een kleine klant naar binnen willen ‘rollen’. Dan is de klant bij wijze van spreken meer geld kwijt aan de tool dan dat zij kwijt zijn aan het project. Het is een ‘license based product’. Daarnaast schort het nog wat aan de performance. Ook hier wordt aan gewerkt!
Let wel: Om de volle waarde van een dergelijke oplossing te kunnen gebruiken en uit te rollen is het wel noodzakelijk dat er een Test Automation (Support) team aanwezig is voor onder andere technisch en functionele beheer, training en support, maar ook om duidelijke richtlijnen met betrekking tot het gebruik van de tool op te stellen. Bovendien is een degelijk QA beleid van belang, zoals gebruik maken peer-reviews.
Helder! Dank voor dit gesprek. Veel succes en plezier op het project!