Welkom terug! In mijn vorige artikel over Tosca en CI pipelines heb ik o.a. uitgelegd hoe je Tosca kan koppelen met Azure DevOps en een GitHub repository. Hierbij werd gebruik gemaakt van de zogenaamde Tosca CI client, die in Tosca versie 15.2 “legacy” is geworden. In de steeds transformerende en innoverende wereld van de informatie- en communicatietechnologie, waarin Cloud-technologie een steeds grotere rol speelt, is door Tricentis gekozen voor meer flexibele “CI-oplossingen”. Dit zijn voor Tosca respectievelijk, de Tosca Execution Client, en de Tosca Server Execution API. In dit artikel ligt de focus op de Tosca Execution Client, en de Tosca Server Execution API zal in mijn volgende artikel (deel 2) aan de orde komen.
Laten we eerst even een stapje terug doen, en analyseren welke trends er op dit moment spelen in het “Agile en DevOps wereldje”, met een speciale focus op test tooling. Volgens Gartner zien we een trend van DevOps richting zogenaamde “Value Streams”; van “samenwerkingsbenadering” om resultaten te maximaliseren (DevOps) richting een continue stroom van waarde -en kwaliteits optimalisatie (Value Streams). De CI voor “Continuous Integration” wordt vergezeld met de CI voor “Continuous Improvement”, een term dat al vaker is gebruikt, en makkelijk onder CI/CD kan worden gecategoriseerd, maar een kwestie van definitie of begripsbepaling is. Dit is nog allemaal abstract, maar hoe zien de trends er concreet uit voor test tooling binnen CI?
Kijken we naar een open source test automation framework als Selenium, dan zien we dat Selenium een mooie ontwikkeling heeft doorgemaakt, mede dankzij een (inter)actieve wereldwijde online community. Wat in 2004 begon als een “klein Javascript projectje” van een engineer bij Thoughtworks, groeide uit tot een mega open source project, waar bijna iedere IT-organisatie wereldwijd (al dan niet gedeeltelijk of indirect) nog steeds de vruchten van plukt. Maar even terugspoelen in de tijd!
In de periode na 2004 ontdekte de “Selenium community” al gauw dat de “JavascriptTestRunner” nog niet helemaal vlekkeloos opereerde bij web of GUI testen, dit vanwege de zogenaamde "Same Origin Policy". Om dit probleem op te lossen werd door een andere engineer bij Thoughtworks, Selenium RC (Remote Control of Selenium 1) ontwikkeld. In die periode werd de naam Selenium geïntroduceerd, afgeleid van het scheikundig element “Se” met atoomnummer 34. Met de daaropvolgende introductie van de “WebDriver” werd automatisch testen van webapplicaties nog eenvoudiger: Selenium RC en WebDriver werden in 2008 “gemerged” tot Selenium 2. In de tussenliggende periode veranderd er wereldwijd heel veel op frontend gebied, vooral met name hoe men naar web development ging kijken. In het begin hadden ontwikkelaars minder development tools tot hun beschikking. Een front-end ontwikkelaar had bijvoorbeeld alleen het Document Object Model (DOM) en een handvol web-API's om de inhoudsstructuur te manipuleren door middel van “Single Page Applications” (SPA’s). Met de introductie van de “Abstraction Layer”, zoals JQuery, werd DOM-manipulatie eenvoudiger. Dit betekende tegelijkertijd dat test tools, zoals het populaire Selenium, mee moesten innoveren en ontwikkelen. Innovatieve ideeën op front-end gebied (responsive designs etc.) zetten door met de introductie van moderne Javascript frameworks, zoals React en Angular. Parallel daaraan, en mede door stormachtige ontwikkelingen op het gebied van mobiele technologie, werd in 2011 “Selenium side kick” Appium geboren. Het goed testen van mobiele applicaties werd steeds belangrijker, en is nog steeds heel belangrijk!
De community ontwikkelde Selenium verder en door innovaties op het gebied van cloud-technologie kwamen verscheidene IT-bedrijven met nieuwe ideeën en initiatieven voor het testen in de cloud m.b.v. Selenium, denk aan Saucelabs en Browerstack. Met de introductie van Selenium 4, eind 2021, was een nieuw “testing” tijdperk aangebroken, vooral een periode waarin testautomatisering niet meer uitsluitend “een feestje” van test engineers was.
Het testen, en kwaliteit in het algemeen, is een integraal en onlosmakelijk onderdeel van het gehele softwareontwikkelproces, van begin tot eind; De gehele keten, van blauwdruk via tekentafel en ontwikkeling tot de eindgebruiker. We kunnen inmiddels met 100% zekerheid zeggen, dat testautomatisering zonder CI/CD geen testautomatisering is. En dit zien we (gelukkig) terug in de basisprincipes van DevOps en CI/CD. Een testtool dat niet “compatible” is met andere tools of geen uitgebreide integratiemogelijkheden heeft, zal in het “CI/CD spectrum” geen lang leven beschoren zijn. Recent heeft Tricentis niet zonder reden Testim overgenomen, een “AI-based SaaS test automation platform”. Testim is een cloud platform dat bijna alle belangrijke “test facetten” omvat. Denk bijvoorbeeld aan het voorbereiden en uitvoeren van de scripts, recording, maintenance, error-handling, rapportage en nog een aantal andere handige features. Met Selenium onder de motorkap i.c.m. het concept van “dynamic locators” zijn meer testsoorten tegelijkertijd mogelijk.
En nu terug waar het allemaal om draait: de Tosca Execution Client! Laten we uitgaan van een scenario, waarbij de klant een specialist inhuurt voor het opzetten van een gedistribueerd testproces in een al reeds ingerichte Tosca infrastructuur. De “reeds ingerichte Tosca infrastructuur” is in mijn geval, om het eenvoudig te houden, een lokaal ingerichte Tosca Commander, Tosca Server en DEX Agent. Bovendien is de Tosca Server geconfigureerd met het “http” protocol. Voor wie meer wil weten over configureren met “https”, hou mijn blogs in de gaten!
Hoe gaan we o.b.v. mijn “lokale scenario” een gedistribueerd testproces bewerkstelligen? Allereerst hebben we de tools nodig voor het opbouwen van de test tool chain. In dit scenario hebben we allereerst uiteraard de Tosca Execution Client nodig als “mediator” voor het uitvoeren van de Test Events. Betreffende Tosca Execution Client kun je downloaden via GitHub, waar het door Tricentis wordt onderhouden (zie link onderaan artikel). Heb je de client eenmaal gedownload, dan ziet de folder-structuur er als volgt uit (zie figuur 1)
Figuur 1. Tosca Execution Client
In mijn geval heb ik lokaal een “CI” map aangemaakt, waarin ik de “Tosca Execution Client” als submap heb geplaatst. In de submap zitten 3 bestanden, en voor onze lokale Windows-machine, gaan we gebruik maken van het Powershell-script (“tosca_execution_clent.ps1”), een script-based client. Het script maakt gebruikt van de “Execution API” van de Tosca Server. Het andere script is bedoeld voor Linux-machines. Voor we gaan starten met het script, zal de startsituatie op de Tosca server er als volgt uit moeten zien voor de DEX monitor (zie figuur 2).
Figuur 2. DEX Monitor
Met andere woorden, de connectie tussen Tosca Server en DEX Agent moet OK/succesvol zijn. Verder is het belangrijk om te weten, dat DEX in Tosca versie 15.2 uitsluitend werkt met AOS (Automation Object Service). Uiteraard moet je het een en ander ook nog configureren in zowel Tosca Commander als Tosca Server, maar dit wordt bekend verondersteld. In Tosca Commander heb ik een workspace, waarin ik een Test Event heb aangemaakt gekoppeld aan een eenvoudige intaketest (“1 | Intake”), zie hiervoor figuur 3.
Figuur 3. Test Event
Nu is het tijd voor een eerste test met de Tosca Execution Client! Hoe doen we dat? Zoals je weet is de Tosca Execution Client “script-based” en is Tosca Commander voor de testuitvoering verder niet nodig. De volgende stap is je workspace in kwestie inchecken en daarna je workspace netjes afsluiten. Navigeer vervolgens naar de “Tosca Execution Client” map en open op dat niveau het Powershell venster, zoals weergegeven in figuur 4.
Figuur 4. Powershell
Laten we beginnen met een eenvoudige “script-based” test commando. In figuur 5 heb ik een test commando toegevoegd waarin een Test Event wordt uitgevoerd van een Tosca workspace genaamd “DEX”.
Figuur 5. Powershell Test Commando
In bovenstaande commando wordt allereerst het client script (“tosca_execution_client.ps1”) aangeroepen, om vervolgens 3 parameters mee te geven, te weten:
- “toscaServerUrl”
- “events”
- “projectName”
De namen van bovenstaande paramaters spreken voor zich. Let erop dat de hostname van de Tosca Server kan worden geïndentificeerd als zijnde url van de Tosca Server, anders kan de client niet communiceren met de “Execution API” van de Tosca Server. Bovendien is het belangrijk om te weten dat “organisatie policies” het runnen van powershell scripts kunnen blokkeren. Voor het opzetten van een “script-based” testinfrastructuur is het belangrijk om alle belanghebbenden mee te nemen in de communicatielijnen, inclusief het team of afdeling verantwoordelijk voor infra en security.
Als we vervolgens op ENTER klikken, dan wordt de Test Event “0 | Test” uit de “DEX” workspace uitgevoerd. Als de Test Event op DEX succesvol is afgerond, dan verschijnen er 2 extra sub-mappen in de “hoofdmap”(zie figuur 6).
Figuur 6. Sub-mappen “logs” en “results”
Het gaat hier om de sub-mappen “logs” en “results”. In de eerste map worden de client-logs opgeslagen en in de tweede map de testresultaten. Betreffende testresultaten worden overigens ook geladen in de “ExecutionList” map van Tosca Commander. Kijken we naar de DEX monitor op de Tosca Server, dan zien we dat Test Event “0 | Test” door de Tosca Execution Client succesvol is uitgevoerd (zie figuur 7).
Figuur 7. DEX Test Events with ToscaExecutionClient
Openen we in Tosca Commander vervolgens workspace “DEX”, dan zien we dat de testresultaten in figuur 8 netjes in de “ExecutionList” worden weergegeven.
Figuur 8. Testresultaten ExecutionList
Nu hebben we het eerste stukje “CI” succesvol gerealiseerd, maar we zijn er nog niet! Wil je meer weten en ben je benieuwd hoe het uiteindelijk afloopt? Hou mijn blogs dan in de gaten! In deel 2 zal ik CI tool Jenkins gebruiken, deze koppelen aan een GitHub repository en dieper ingaan op de “Tosca Server Execution API”. Stay tuned!
*Tricentis
Verder groeien in Tosca?
Nu kun je jezelf rekenen tot een select gezelschap van DevOps-gildes! Gaaf toch? Wil jij iedere dag leren en kunnen sparren met vakgenoten over bijvoorbeeld Tosca of andere testautomationtoolings? Neem gerust contact op, ik vertel je er graag meer over. Benieuwd naar mijn volgende artikel (5de in de reeks)? Voor nu even een zomerstop. In de tussentijd, bekijk gerust de vacatures en wie weet, misschien worden we wel collega's.
* Tosca is sinds de introductie van Tosca-versie 15.2 afgelopen juni, is Tosca CI niet meer “de standaard” feature voor CI-integratie tussen Tosca en willekeurige CI-tools. Tosca CI wordt vervangen door de “Tosca Execution Client” en daarbij is er een API beschikbaar, de zogenaamde “Tosca Server Execution API”. Beide nieuwe features werken uitsluitend via “Distributed Execution” via AOS (Automation Object Service). Uiteraard is gaat dit niet van de ene op de andere dag. Gebruik je bijvoorbeeld Tosca versie 15.0 LTS, dan ontvang je support tot 3 jaar na de introductie, in dit specifieke geval tot 13 december 2024. LTS staat overigens voor Long Time Service. Bovendien biedt Tricentis Support of de actieve Tosca community meestal tussenoplossingen of workarounds voor “legacy(-wordende)” features. Meer info over Tosca releases/support, GitHub en Git:
Kan ik je helpen?
Testspecialisten
Als testen niet alleen je vak maar ook je passie is, ontdek dan onze testcommunity!
