Zoekresultaten

Zijn we klaar voor AI-gestuurde testautomatiseringstools? Een blik op testRigor. Bij PerformanceArchitecten vinden we het belangrijk om continu onze kennis te ontwikkelen en bij te houden. Daarom organiseren we elke maand een kennismiddag waarbij we ons verdiepen in verschillende onderwerpen die relevant zijn voor ons werk. Onze laatste kennismiddag stond in het teken van testRigor. Testautomatisering is een essentieel onderdeel van softwareontwikkeling, maar het kan ook veel tijd en moeite kosten om testen te schrijven, uit te voeren en te onderhouden. Vooral als je een snel veranderend product hebt, kan het lastig zijn om je tests stabiel en up-to-date te houden. Volgens de makers is testRigors de oplossing hiervoor: het is een AI-gebaseerd testautomatiseringstool die je in staat stelt om tests te maken in gewoon geschreven taal (in dit geval Engels), zonder code of locators te gebruiken. Met testRigor kun je tests maken die mensen simuleren die web-, mobiele en desktopapplicaties gebruiken. In deze blogpost zullen we je laten zien hoe testRigor werkt en wat onze bevindingen zijn ten opzichte van andere testautomatiseringstools. Hoe werkt testRigor? testRigor maakt gebruik van natuurlijke taalverwerking en machine learning om je tests te begrijpen en uit te voeren. Je kunt tests schrijven als een reeks stappen in gewone taal (Engels). Een bijvoorbeeld: go to "https://testRigor.com/" click "Request a Demo" enter "Name" with "Jan Jansen" enter "Email" with "jan.jansen@testRigor.com" enter "Phone" with "+31 6 12345678" click "Submit" check that a confirmation message appears testRigor zal deze stappen vertalen naar acties die worden uitgevoerd op de browser of het apparaat van je keuze. Je kunt tests uitvoeren op bijna alle browsers op meerdere besturingssystemen, zoals bijvoorbeeld Internet Explorer op Windows en Safari op Mac en iOS. Je kunt ook mobiele tests uitvoeren, inclusief tests op fysieke apparaten en testen van hybride apps. testRigor is compleet web-gebaseerd. De uitvoering gebeurd in de “cloud”. Als een test is uitgevoerd laat testRigor voor elke stap een screenshot zien via de webinterface te zien. Dit wordt zelf dynamisch opgebouwd tijdens het draaien van de testen zodat je de test kan volgen. Het laat alle stappen duidelijk zien en ook kan je eventuele fouten hierin terugvinden. Highlights (en lowlights): testRigor biedt veel opties voor het selecteren, invullen en controleren van objecten, waardoor testcases flexibel en uitgebreid kunnen zijn. Het specifieke taalgebruik van testRigor zorgt voor duidelijkheid en precisie in de teststappen. Maar het vereist een zeer precieze formulering in natuurlijke taal en kan niet vergeleken worden met nieuw en opkomende AI-ondersteunde tooling. Een uitdaging bij testRigor is dat het een trial-and-error-proces kan zijn, waarbij feedback alleen tijdens de uitvoering wordt gegeven. Dit kan de snelheid van het creëren van testen belemmeren en frustratie veroorzaken bij testers. Door binnen de browser de F12-toets te gebruiken en de technische details te bekijken van de website, kan je problemen oplossen. Dit is echter (te) technisch en we hadden verwacht dat dit door het testtool zou worden opgelost. Dan is de vraag waar wordt testRigor uitgevoerd? Ergens in de Cloud. Met de standaard optie/abonnement is het niet duidelijk waar je test uitgevoerd wordt. Onduidelijk is of GDPR compliancy wel voor testRigor ingesteld kan worden: waar staat de data precies? Ook wanneer je test wordt uitgevoerd is onduidelijk; de test wordt gequeued en dan uitgevoerd. Bij onze testen ging dat eigenlijk altijd snel maar het kan zomaar dat er veel testen voor je in de queue staan en je moet wachten op resultaten. Dit zou lastig kunnen worden omdat onze ervaring is dat je qua testontwikkeling veel van trial-and-error afhankelijk bent. Er is een browserplugin beschikbaar om tests op te nemen. Alhoewel testRigor belooft dat veel met natuurlijke tekst kan, hebben we gemerkt dat via het opnemen via de browserplugin de tekst meteen goed staat dus dat heeft wat ons betreft wel een voorkeur. Het is goed om op te merken dat bij testRigor de resultaten en uitvoeringsinformatie (inclusief gegevens) openbaar zijn, tenzij een betaald abonnement wordt gebruikt. Dit is een overweging bij het uitproberen van de tool dat je geen gevoelige informatie in je tests opneemt. testRigor zegt op hun website dat het gebaseerd is op BDD 2.0 oftewel Specification-Driven Development (SDD). BDD is een bekende methode binnen de testcommunity. Als je met Google zoekt op “BDD 2.0” dan vind je alleen maar de site van testRigor, verder heeft niemand het nog over BDD 2.0. Met onze ervaring vinden we eigenlijk dat testRigor niet van BDD 2.0 moet spreken maar van keyword driven 2.0 omdat dit meer op de aloude manier van keyword driven testautomatisering lijkt. De tool biedt flexibiliteit en efficiëntie, maar de stevige prijs van het abonnement kan een overweging zijn. Voor de betaalde versie moet op dit moment $900 per maand betaald worden, oftewel $10.800 per jaar. Conclusie: Voor zover wij kunnen zien is het niet echt AI-gestuurde testautomatisering wat testRigor biedt. Het biedt een intelligente manier van tekst gedreven testautomatisering. Eerlijk is eerlijk: we hadden hier meer van verwacht, zeker als je de prijs voor de betaalde versie in overweging neemt. Het is qua product leuk uitgewerkt met een goede webinterface. We zien wel wat haken en ogen aan het product maar voor een specifieke doelgroep zal dit een goed tool zijn. We hebben een leuke middag met deze tool gehad. We verwachten nog veel van AI-ondersteunde tools in de toekomst. Hopelijk zal testRigor zich nog verder ontwikkelen op dit vlak. Disclaimer: natuurlijk hebben we niet alles kunnen testen, dus wellicht zitten er nog mooie, onontdekte features in de tool die de moeite waard zijn.

Het Next Web (TNW) Conference is een jaarlijks evenement dat professionals uit de wereld van technologie, innovatie en ondernemerschap samenbrengt. Dit jaar vond TNW 2023 plaats in Amsterdam (eigenlijk Zaandam). Ik kreeg de kans om aanwezig te zijn en wil graag mijn ervaringen delen in deze blogpost. Het centrale thema van dit tweedaagse evenement was kunstmatige intelligentie (AI) en de impact hiervan op organisaties maar ook individuen. Eenander onderwerp dat naar voren kwam, was een verfrissende kijk op het verzamelen van data, vaak in combinatie met AI. Het congres bood een breed scala aaninspirerende keynotes van toonaangevende professionals uit de industrie. Daarnaast waren er boeiende paneldiscussies waar de nieuwste trends en ontwikkelingen in de technologiewereld werden besproken. Er werden veel maatschappelijke kwesties aangekaart, zoals inclusiviteit, de rol van AI, privacy en digitale ongelijkheid. Hier volgen enkele hoogtepunten: Met de opkomst van AI is de rol van developers aanzienlijk aan het veranderen. AI en low-code technologieën brengen verschuivingen teweeg waarbij er meer nadruk wordt gelegd op controle en businessanalyse. De rol van een developer zal dus verschuiven van het genereren van code naar het controleren van code. Softwarebedrijven moeten zich ook aanpassen en naast het generen van code ook meer richten op het bieden van tools voor de controle van code. Na Covid is hybride werken op kantoor de norm geworden. Dus het gebruik van kantoorruimtes zal moeten veranderen om te voldoen aan de huidige en toekomstige behoeften. Dit is mogelijk door het inrichten van multifunctionele ruimtes die ook buiten werktijden gebruikt kunnen worden door bijvoorbeeld verenigingen en scholen. Een effectieve kantoorruimte gaat verder dan alleen bureaus en zorgt voor optimaal gebruik van de ruimte. Er werd een demo gegeven van het genereren van audioadvertenties met behulp van ChatGPT en Alexa. Dit was indrukwekkend vanwege de kwaliteit en de mogelijkheid om tijdens het creatieproces vervolg- en detailvragen te stellen. De populariteit van audio neemt toe, met radio, streamingdiensten en vooral podcasts als belangrijke spelers. Het maken van audio is gemakkelijker dan video en de consumptie ervan is minder belastend. Daarom zullen audioadvertenties naar verwachting toenemen, vooral in passende contexten zoals podcasts. De metaverse wint terrein als marketinginstrument. Het verschil tussen het streamen van een product, fysiek aanwezig zijn en de metaverse is dat streamen statisch is, fysiek aanwezig zijn reistijd en wachttijd met zich meebrengt, terwijl het ‘ruimtelijke web’ deze problemen oplost. BMW heeft een interessant experiment uitgevoerd in samenwerking met Warner Music, Epic/Unreal. Door de samenwerking met deze vooraanstaande bedrijven, krijg je daadwerkelijk een mooi product wat aanspreekt. Cijfers (mogelijk bevooroordeeld, “wij van WC-eend”) geven aan dat het effectief is. Steden (niet-Amerikaanse) streven ernaar auto’s te beperken en wegen efficiënter te gebruiken voor fietsers, voetgangers en openbaar vervoer. Het integreren van planning, routes, efficiëntie, kosten en betaalgemak blijft echter een uitdaging. Elektrificatie, gedeelde mobiliteit en efficiëntie zijn op dit moment belangrijke aandachtspunten, maar er is nog veel werk te doen. Oplossingen, zoals het verbannen van dieselvoertuigen, zijn nog niet volledig beschikbaar, maar er wordt hard aan gewerkt. AI speelt een steeds grotere rol in de gamingindustrie, zowel bij het genereren van reacties van niet-speelbare personages (NPC’s) met behulp van grote taalmodellen als bij het verbeteren van de gameplay in open wereld-spellen. Een NPC is een karakter in een videogame dat door de computer wordt gecontroleerd en niet door een speler. Ze worden vaak gebruikt om de spelwereld te bevolken, missies te geven of interactie te hebben met spelers. AI wordt steeds meer geïntegreerd in game-ontwikkelingsframeworks zoals Unity, waardoor ontwikkelaars toegang hebben tot krachtige tools en mogelijkheden om de game-ervaring te transformeren. Een hoogtepunt van het evenement was de presentatie van Nagin Cox, een NASA-engineer die een belangrijke rol speelt in robotische ruimtemissies, waaronder de Mars Rover-missies. Ze is verantwoordelijk voor het plannen en uitvoeren van operationele activiteiten voor de rovers op Mars. Met haar inspirerende en enthousiaste persoonlijkheid wist ze het publiek te motiveren en aan het denken te zetten over de toekomst van ruimtevaart en onze rol daarin. TNW 2023 Conferences bood inspirerende keynotes, boeiende paneldiscussies en inzichten in maatschappelijke vraagstukken. Klein kritiek punt is dat bij dit soort congressen bepaalde sprekers vooral bezig zijn met zichzelf horen praten, zonder daadwerkelijk veel toegevoegde waarde te bieden. Maar al met al heeft het congres mij en de deelnemers geïnspireerd en uitgedaagd om na te denken over de toekomst van technologie en onze rol daarin.

Bij PerformanceArchitecten vinden we het belangrijk een gezellige sfeer te creëren binnen ons team, niet alleen tijdens de werkuren maar ook daarbuiten. Om die reden organiseren we meerdere keren per jaar informele uitstapjes. Minstens één keer per jaar, veelal in september, gaan ook onze partners mee met het uitje. Op zaterdag 23 september was het opnieuw zo ver, en dit keer hadden we gekozen voor een bijzondere ervaring bij 'Eenden Tours Westland'. Voordat we aan ons avontuur begonnen, kregen we een uitleg over hoe de eendjes functioneerden en wat we konden verwachten. In groepjes van drie stapten we vervolgens in onze eigen eendjes en begonnen we aan de Westland Route. Het weer was typisch Nederlands: afwisselend gingen de raampjes open om van het frisse briesje te genieten en weer dicht om de regenbuien te ontwijken. Desondanks weerstonden onze eendjes moedig alle weersomstandigheden. Na dit avontuur, waarbij we onze stuurmanskunsten mochten aanspreken zonder enige stuurbekrachtiging, hadden we allemaal een smakelijke maaltijd verdiend. Het was weer een geslaagde dag!

Eén van de meest genoemde voordelen van de cloud is de in theorie oneindige schaalbaarheid. Zo zou het niet meer nodig zijn om als organisatie veel reservecapaciteit in te richten om pieken op te vangen en de performancerisico’s zouden helemaal verdwijnen. Maar is dat wel altijd zo? Wanneer wel, wanneer niet? Duidelijk is, dat wanneer de cloud een rol speelt, dit zeker impact heeft op het aspect performance. Sommige risico’s verdwijnen, sommige veranderen en andere risico’s ontstaan juist. In deze blog sta ik hier graag bij stil. Ik zal aan de hand van een aantal performance aspecten de verschillende cloud toepassingen langslopen, waarbij ik een helder beeld schets over de performance risico’s die hierbij verdwijnen, veranderen of juist ontstaan. Om te beginnen doe ik even een recap van een aantal verschillende cloud toepassingen. Naast dat er allerlei leveranciers zijn, zoals bijvoorbeeld Microsoft met Azure, Amazon met AWS of IBM met IBM cloud, zijn er verschillende mogelijkheden om de cloud te gebruiken. De “XaaS” termen geven de verschillende niveaus aan (zoals IaaS, CaaS, PaaS, FaaS of SaaS). In het kader van dit artikel sta ik vooral stil bij IaaS (Infrastructure as a service) en SaaS (Software as a service). Denk bij IaaS aan componenten (virtuele machines, databases en/of netwerkcomponenten) die zelf beheerd worden. Bij SaaS zijn het systemen die meteen gebruikt kunnen worden zoals bijvoorbeeld Office 365 of Salesforce. Performancetesten doen we vooral om risico’s af te dekken op het gebied van niet-functionele eisen (non functional requirements) zoals snelheid, stabiliteit en schaalbaarheid. Binnen het ISO 25010 model voor productkwaliteit zijn categorieën terug te vinden die te maken hebben met performance testen. In het onderstaande plaatje zijn aspecten die je met performance testen kunt afdekken, met rood omrand. Hieronder licht ik hiervan drie willekeurige aspecten uit om te zien wat de impact van de verschillende cloud toepassingen zijn. We beginnen met het aspect Capacity binnen de categorie Performance efficiency. Bij een SaaS-oplossing is de leverancier in controle op het gebied van Capacity. Als afnemer/klant van dit product is het niet mogelijk hierop directe invloed uit te oefenen. Als Office 365 traag is vanwege het vele gebruik, kunnen gebruikers er niet zelf voor zorgen dat er meer servers in de lucht komen om de vertraging minder te maken. Wel is het slim om hierop langdurig te monitoren om mogelijke vertragingen inzichtelijk te krijgen. Zo creëer je inzicht in wanneer er vertragingen optreden. Met dit inzicht kan de leverancier goed onderbouwd worden gewezen op vertragingen. Bij een IaaS oplossing bestaan er mogelijkheden om automatisch (horizontaal) te schalen. Meestal wordt op basis van resourcegebruik bepaald dat er meerdere virtuele machines moeten worden bijgezet. Dit wordt dan zodra het resourcegebruik het toestaat, weer afgebouwd. Een voorbeeld hiervan is “Azure virtual machine scale sets”. Het is wel belangrijk om bij dit soort oplossingen te testen of de applicatie hierop ingericht is en of de gebruikte centrale componenten die niet onder de schaling vallen, hier goed op reageren. Denk hierbij bijvoorbeeld aan een centrale database die alle geschaalde virtuele machines gebruiken. In bovenstaande beschreven SaaS en IaaS oplossingen zien we dat er minder performance-risico zijn dan in traditionele omgevingen, aangezien de schaling door of de leverancier of het systeem geregeld wordt. Wees er wel van bewust dat, wanneer er geen automatische schaling is binnen een IaaS oplossing, het performance-risico op het gebied van Capacity wel degelijk nog bestaat. Een andere categorie die belangrijk is, is stabiliteit. Hier licht ik het aspect Availability (beschikbaarheid) uit. De definitie van Availability is: ‘de mate waarin een systeem, product of component operationeel en toegankelijk is wanneer men het wil gebruiken’. Denk hierbij aan het beschikbaar zijn van systemen maar ook aan backups/restores, mirrored data, meerdere datacenters, maar ook aan recovery-scenario’s. Verder moet er net zoals bij niet-cloud systemen ook bij cloud systemen aandacht zijn voor risico’s op het gebied van resiliance, fail-over en back-up & restore. Resiliance (veerkracht) is de mate waarin het systeem bestand is tegen bepaalde mate van onderbreking. Fail-over gaat over de impact van een verstoring. En bij back-up & restore bedoelen we of na het terugzetten van een back-up inderdaad de juiste gegevens beschikbaar zijn. Afhankelijk van de gekozen oplossing (IaaS of SaaS) wordt dit (deels) door cloudleveranciers opgelost. Bij IaaS geldt dat er vaak ten onrechte uitgegaan wordt dat de cloudleverancier “het wel geregeld heeft”. Let op. Dit is niet een verantwoordelijkheid van de leverancier. Wanneer dit niet goed geregeld is, dan is er grote kans dat dit tot problemen leidt. Bovenstaande risico’s bestaan dus nog bij cloud en dienen dus getest te worden. Daarnaast speelt de snelheid waarmee het systeem weer beschikbaar komt ook nog een rol. Hierbij kan “infrastructure as code” helpen. Wel moet dan geregeld zijn dat de systeemeigen data ook weer beschikbaar komt. Dit is prima te testen. Bij een SaaS-oplossing is beschikbaarheid (meestal) wel een verantwoordelijkheid van de leverancier. Het is belangrijk om de afspraken hieromtrent, bijvoorbeeld in een SLA, goed duidelijk te hebben. Door hier zelf op te monitoren kan je vervolgens in de gaten houden of de leverancier dit doet conform afspraak. Als laatste aspect kijken we naar time behaviour. Dit is de mate waarin transactietijden en doorvoersnelheid van een systeem, tijdens de uitvoer van zijn functies, voldoet aan de wensen. Bij cloud-based systemen draaien de systemen niet op het eigen netwerk. Het kan zelfs zijn dat de systemen op fysiek grote afstand ‘draaien’ van de interne systemen en doordoor vertragingen (latency) introduceren. Bij IaaS oplossingen zijn de oplossingen vaak complexer: er worden veel verschillende componenten uit verschillende categorieën gebruikt. Vooral bij het gebruik van templates (zoals via de marketplace) worden meer componenten gecreëerd dan in eerste instantie gedacht, denk hierbij aan virtual network-componenten, load balancers, extra firewalls en publieke IP-adressen. Soms ook nog met combinatie met niet alleen infrastructuur componenten maar ook CaaS (containers as a service), FaaS (functions as a service) of PaaS (platform as a service, zoals databases). Uiteindelijk is het wel belangrijk om een goed beeld te hebben of al die componenten samen zorgen voor een goede doorvoersnelheid en acceptabele transactietijden. Zelfs bij SaaS is het van belang om te controleren of de beloften van de leverancier wel worden waargemaakt. Een ander belangrijk aspect in de cloud is het kostenaspect. Door allerlei ruime standaardinstellingen van cloudleveranciers is de kans groot dat je meer kosten maakt dan nodig. Het risico dat je (soms exponentioneel) te veel betaald valt prima af te dekken door het doen van performancetesten. Hiermee is het mogelijk om applicaties te tunen zodat minder schaling nodig is, kleinere VM’s in te zetten en andere infrastructuurcomponenten te optimaliseren (zoals loadbalancers). Het gaat in deze blog te ver om hier uitgebreid over te schrijven en maar dit is zeker een interessant onderwerp voor een andere keer. In deze blog heb ik aan de hand van de drie aspecten capacity, availability en time behaviour stilgestaan bij het feit dat performance risico’s veranderen wanneer er gebruik gemaakt wordt van de cloud. Het is duidelijk dat je met andere ogen moet kijken naar welke risico’s er zijn en hoe je deze het best af kan dekken. Het belang van het kijken naar je niet-functionele requirements en naar performancetesten is dus niet veranderd door de cloud. Wel zorgt het dynamische aspect van de cloud er mogelijk voor dat je zaken anders moet aanpakken. Ik ben heel benieuwd naar wat jouw ervaringen zijn met betrekking tot performance en de cloud. Mocht je deze willen delen, heel graag! En ook wanneer je vragen hebt over dit blog, of over performance al dan niet in relatie tot cloud, hoor ik graag van je. We hebben een mooie presentatie klaar staan die we graag komen presenteren. Neem contact op via de website of vindt mij op LinkedIn.

Heb jij weleens een keuze gemaakt voor een tool die achteraf gezien toch niet de verstandigste bleek? Helaas een ervaring die veel IT professionals weleens opdoen. En gezien de tools in de moderne ontwikkelomgevingen niet meer aan te slepen zijn, denk ik dat dit nog weleens vaker het geval gaat zijn.. Als testautomatiseerders hebben wij binnen PerformanceArchitecten veel ervaring met het selecteren van de juiste tool. In deze blog een paar tips die er voor zorgen dat jij blij wordt van je toolkeuze in plaats van je eraan te ergeren! Wanneer je het hebt over test-automatisering gaat het al snel over het gebruik van tools. Er zijn immers vele tientallen, zo niet honderden tools op de markt. Sommige tools zijn breed inzetbaar, maar er zijn ook specialistische tools. Bovendien komen ze met uiteenlopende prijskaartjes, van open-source tot enterprise licenties. Maar hoe kies je nu de tool die het best past bij jouw teams, producten en organisatie? Dat het in de praktijk behoorlijk lastig is, blijkt wel uit de volgende drie situaties die wij in de praktijk vaak tegenkomen als wij bij een organisatie binnenkomen: Er is ooit gekozen voor een tool of suite die gericht is op het geautomatiseerde end-to-end testen. Het benodigde onderhoud is alleen een beetje onderschat.. Technisch blijkt de gekozen tool een schot in de roos, maar bij de selectie zijn toch wat randvoorwaarden over het hoofd gezien.. De ontwikkelaars in het team uiten veel weerstand tegen het gebruik van de door de organisatie voorgeschreven tooling. Herkenbaar? Lees hieronder welke valkuilen hieraan ten grondslag liggen en welke lessen we hieruit kunnen trekken. Tot slot nog een aantal handvatten die van pas kunnen komen wanneer jouw team of organisatie voor een toolselectie staat. Hoewel deze blog toegespitst is op testautomatiseringstools, zullen de genoemde criteria, valkuilen en best practices ook van toepassing zijn op toolselecties in andere vakgebieden. Valkuil 1 - “Testautomatisering = het automatiseren van testen” Allereerst zien we vaak dat men de huidige testaanpak en bijbehorende testgevallen als uitgangspunt nemen wanneer een testautomatiseringsaanpak (met bijbehorende tooling) bepaald wordt. Dat is erg voor de hand liggend, omdat met de bestaande testaanpak ook voldoende inzicht in de kwaliteit van de software verkregen kon worden. Toch kleeft er ook een probleem aan deze aanpak. De bestaande testgevallen worden hoogstwaarschijnlijk met de hand uitgevoerd op de gebruikersinterface van een applicatie. Wanneer je diezelfde handelingen wilt gaan automatiseren, dan wordt de focus van de toolselectie automatisch gericht op front-end of end-to-end testtools. Eigenlijk is de testtool dus al gekozen voordat de testaanpak goed uitgedacht is. Het resultaat kan zijn dat er een geautomatiseerde testset ontstaat die zich voornamelijk in de GUI afspeelt, waardoor de testen relatief traag zijn en lastig onderhoudbaar zijn. In de praktijk uit zich dat vaak in testen die altijd op rood staan en uiteindelijk een oplossing die geen waarde toevoegt voor het team en het ontwikkelproces. Valkuil 2 - “Er zijn meer randvoorwaarden dan de technische fit” Een toolselectie gaat vaak op een organische manier. Er wordt een bepaalde uitdaging ervaren waar vast een oplossing voor is. Hierop wordt een onderzoekje gedaan waarbij gekeken wordt of we iemand kennen die een geschikte tool weet, of er wordt wat gegoogeld en nadat we hebben gecheckt of de technische requirements kloppen doen we on the go een proof of concept. Zeker bij open source tooling iets wat vaak laagdrempelig is. Helaas is het vaak zo dat er verderop in de tijd toch belemmeringen opduiken die vooraf niet waren voorzien. Denk aan ondersteuning die ontbreekt door een te kleine, inactieve community, of later in het ‘project’ benodigde functionaliteiten die er niet zijn. Maar ook aan ontbrekende skills in het team om de oplossing volop te adopteren, of weerstand elders in de organisatie. Uiteindelijk zien we dan dat het initiatief een stille dood sterft en alle moeite voor niets is geweest. Valkuil 3 – “One tool does it all” De derde valkuil die we in de praktijk vaak tegenkomen is dat men probeert alle (typen) geautomatiseerde testen van een team, of zelfs de hele organisatie, onder te brengen in één tool of framework. Op het eerste oog klinkt het ideaal dat je een totaaloplossing hebt voor allerlei testsoorten. Een dergelijke testsuite bestaat doorgaans uit verschillende componenten voor het bouwen, inplannen en analyseren van de geautomatiseerde testen. Deze opzet heeft echter wel een keerzijde. Het blijkt namelijk niet of nauwelijks te integreren in het bestaande ontwikkelproces, waardoor testautomatisering een afgezonderd eilandje wordt. Het resultaat is dan dat een dergelijke oplossing slecht geadopteerd wordt door het ontwikkelteam. Ditzelfde probleem zien we ook geregeld bij “low-code” tools, waarbij de testen begrijpelijk zijn voor “personen uit de business”. Het klinkt ideaal dat de projectmanager of product owner zonder code-kennis zelf testen kan schrijven door middel van hapklare componenten, maar in de praktijk komt daar doorgaans weinig van terecht. Het resulteert echter wel in weerstand bij de teamleden die in hun dagelijkse werk op deze tool aangewezen zijn: de ontwikkelaars of testers. De sleutel tot succes Op de één of andere manier is het lastig voor veel teams om voor de juiste tool te kiezen. Soms terwijl er een complex traject voor is opgezet, maar ook bij laagdrempelige selecties. De sleutel tot succes? Maak in ieder geval gebruik van de volgende handvatten. Bedenk dat een tool alleen maar een hulpmiddel is. Het wordt alleen een succes als eerst goed nagedacht is over de aanpak. Pas daarna is het mogelijk de tool te kiezen die daar het best bij ondersteunt. PerformanceArchitecten ondersteunt hier graag bij! Doe een goede omgevingsanalyse. Beter hier even aandacht aan geven en dit te checken bij je stakeholders, dan er later achter te komen dat het toch niet past. Ik gebruik altijd één van onze checklisten om snel te kunnen checken of we niet iets vergeten. Als je effectief en flexibel wil zijn als team heb je een tool nodig dat goed integreert bij jouw werkzaamheden. Wij onderzoeken daarom altijd of het aansluit bij de werkwijze van iedereen die met de tool werkt. Herken je dit? Of heb je wellicht nog wat aanvullingen? Wij vinden het leuk wanneer je contact opneemt. Ook als je gewoon eens vrijblijvend wil sparren over een toolkeuze bij jou in de organisatie! Mocht je het een leuke blog hebben gevonden, volg ons voor meer in de toekomst!

In deze blog neem ik je graag mee in hoe ik een pipeline heb opgezet in Azure DevOps ten behoeve van de verschillende projecten die wij als team bedienen in mijn huidige opdracht. Handig om te lezen als je hier zelf mee bezig gaat, of gewoon leuk om te lezen als je het een interessant onderwerp vindt. Het is een vervolg op mijn vorige blog waar ik beschreef hoe je een Gatling framework op kan zetten en hoe je daaruit een executable fat jar kon maken die op elke server met java gebruikt kan worden. Dat is ideaal voor het uitvoeren van de testen in een pipeline. Mocht je die nog niet gelezen hebben, dan adviseer ik je die eerst even door te nemen. Heb jij ervaring met performance testen in een andere pipeline? Of binnen Azure DevOps? Ik zie graag jou bevindingen of vragen tegemoet! Repos Een onderdeel van Azure DevOps is Repos (repositories). Ik gebruik een repo om de bestanden van het Gatling framework in op te slaan. Hierdoor kan ik ermee werken in de Azure DevOps pipeline. Build Onder Pipelines in Azure DevOps heb je de keuze tussen Builds en Releases. We kijken eerst naar Builds. Want we moeten een artifact aanmaken die we in de release pipelines kunnen gaan gebruiken. In dit geval is het beoogde artifact de executable fat jar van het Gatling framework. Maak een nieuwe build pipeline aan. Hiervoor moet je een aantal stappen doorlopen: Ik heb de pipeline aangemaakt via de classic editor. Je kan vervolgens aangeven waar de repo zich bevindt (source; Azure Repos Git in mijn geval) en welke repo het precies is. De volgende stap is het selecteren van een template. We kiezen voor Maven. Met de gekozen repo als input worden er 3 stappen uitgevoerd. Een maven commando (default “package”) wordt uitgevoerd om een build te maken. De build wordt geplaatst in de artifact staging directory. De build wordt als artifact gepublished zodat deze gebruikt kan worden in de release pipeline. Nu moeten we nog het e.e.a. in de build pipeline configureren: Selecteer een agent uit de agent pool. Controleer de Maven POM file (ik heb bijv. meerdere modules en dus ook meerdere POM’s). Get sources Ik heb Clean op true gezet en vervolgens bij Clean options gekozen voor All build directories (op deze manier wordt alles netjes opgeruimd voordat de inhoud van de repo op de build agent geplaatst wordt). Maven pom.xml Uitvinken van JUnit Test Results → Publish to Azure Pipelines. Ik heb immers geen JUnit tests t.b.v. het Gatling framework. Copy Files to: $(build.artifactstagingdirectory) Hier hoef je niets aan te passen. Publish Artifact: drop Ook hier hoef je niets aan te passen. Ik wil liever niet de builds handmatig triggeren. Bij tabje Triggers kan je een trigger instellen. Ik heb hier gekozen voor Enable continuous integration. Als er dan een nieuwe commit is op de Azure repo, wordt er een build uitgevoerd. Je kan evt. nog een specifieke branch of path selecteren waar dit voor geldt. Via Save & queue kan je een eerste build uitvoeren en een artifact maken. Release Via de release pipeline kan je het gepublishde artifact gebruiken en een Gatling simulatie uitvoeren. Maak een nieuwe release pipeline. Je kan deze evt. opbouwen m.b.v. een template. Ik heb dit niet gedaan. Voeg als eerste een artifact toe. Onder Source type Build vind je nu je artifact terug. Vervolgens kan je stages toevoegen. In onze omgeving maken we gebruik van specifieke servers die we inzetten als load generators. Dit heeft enkele redenen waaronder de benodigde capaciteit van de servers en instellingen t.b.v. Splunk. Als je de Azure DevOps agent als load generator gebruikt (kan gebruiken), heb je slechts 1 stage nodig waarbij je via een PowerShell task de simulatie kan uitvoeren (Commando kan je terugvinden in mijn vorige blog). Mogelijk dat ook voor anderen geldt dat ze de performance test op een specifieke server moeten uitvoeren. Dus ik ga hier nog wat dieper op in. De pipeline ziet er (minimaal) als volgt uit: Ik heb dus een stage waarin het artifact op de gewenste locatie wordt geplaatst en een stage waarin op de gewenste locatie de Gatling simulatie wordt uitgevoerd. Voor stage 1 gebruiken we task Windows machine file copy. Mijn load generators zijn namelijk windows machines. In deze task kan je het artifact selecteren, de machine naam doorgeven van de load generator, de credentials om mee te connecten en een Destination folder waar het artifact geplaatst moet worden. Voor stage 2 gebruiken we task PowerShell on target machines. Ook hier geef je aan om welke machine het gaat, de credentials om mee te kunnen connecten. Je kan onder Advanced de Working Directory aangeven. Het is handig om hiervoor hetzelfde in te voeren als de Destination folder in stage 1. Verder moet je deze task voorzien van een PowerShell script die de Gatling simulatie uitvoert. De code is het commando voor de fat executable jar zoals in de vorige blog beschreven. Ook voor de release pipeline kan je triggers instellen. Dit kan onder tabje Pipeline bij het artifact: Via de bliksemschicht kan je een continuous deployment trigger of pull request trigger instellen. Onder het artifact heb je een klokje. Hiermee kan je een schedule instellen. Deze gebruik ik voornamelijk. En verder? Momenteel is de pipeline geen onderdeel van de release van de betreffende applicatie waarvoor we de performance test draaien. Dat komt ook doordat er nog geen quality gate in zit. We voeren de performance test uit en de resultaten van de performance test krijgen we ook in Splunk, maar aan het einde van de performance test is er geen evaluatie/analyse van de test. En kunnen we dus o.b.v. de pipeline ook niet oordelen of de applicatie onder load performt volgens de eisen. Ik wil dit nog verder gaan onderzoeken. Ik heb wel een idee hoe ik dit aan kan pakken. Aan de Gatling simulatie (in de scala code) kan je assertions toevoegen. Dit kan op globaal niveau (alle requests), maar ook op request/group niveau. Als je assertions toevoegt dan zal er aan het einde van de simulatie ook een JUnit file (en JSON file) geproduceerd worden. Deze zouden we in theorie dan kunnen gebruiken om de performance te beoordelen in de pipeline. Ik hoop dat ik jullie geïnspireerd heb met deze blog. Ik hoor het graag als jullie nog vragen hebben. En als jullie tips hebben, hoor ik dat helemaal graag natuurlijk! Dat geldt ook voor het toevoegen van een quality gate in de pipeline t.b.v. de Gatling simulatie.

Inleiding We kennen het allemaal: je bent aan het surfen om iets te kopen. Duurt het langer dan 1 à 2 seconden dan haak je al snel af. Desondanks is performance is vaak onderbelicht in web-ontwikkeling. De nadruk ligt vaak op functionaliteit en minder op performance. Dat terwijl een slechte performance behoorlijke impact heeft op ons, tegenwoordig verwende, consumenten. Omdat ik als performance engineer nieuwsgierig was naar de exacte gevolgen, heb ik een onderzoekje gedaan, met toch wel verrassende uitkomsten. Lees snel verder voor de details. Page speed matters De tekst page speed matters is afkomstig uit een blog van Google uit een blog gepubliceerd in juni 2009 waarin het belang van website performance werd beschreven. Inmiddels zijn we ruim 10 jaar verder en is de website page speed nog steeds belangrijk. 10 jaar geleden was de snelheid van de internet verbinding nog vaak een beperkende factor. Tegenwoordig is dit nog steeds van belang vanwege het grote gebruik van mobiele apparaten (always on). Mobiele apparaten hebben beperkte hardware capaciteit en de verbinding is vaak minder snel dan die op een laptop of desktop. Sinds 2016 overtreft het mobiele internetgebruik dat van de laptops en pc’s. Het percentage mobiele gebruikers op het internet was in 2019 63,4% en het percentage mobiele bezoekers van e-commerce websites was zelfs 67,2% van het totaal afkomstig van mobiele apparaten. En dit stijgt alleen maar door. Wanneer is een website traag? Een trage site is een relatief begrip, daarom hanteren wij voor dit moment de richtlijnen die momenteel gelden bij Google. Google gebruikt voor de responstijd een aantal meetmomenten. De belangrijkste meetmomenten zijn: FP: First Paint FCP: First Contentful Paint On-Load: Alle componenten van de pagina zijn geladen, dit is te vergelijken met de traditionele end-to-end responstijdmeting. FID: First Input Delay, dit de tijd van de on-load tot het tijdstip dat componenten zijn verwerkt door de browser en er weer nieuwe input van de gebruiker kan worden verwerkt. Een website met First Contentful Paint tijd van meer dan 3 seconden wordt door Google gezien als traag en dit heeft gevolgen voor de plek die de website krijgt in de zoekresultaten in Google. Let wel Google kijkt hierbij enkel naar de tijd op de mobile devices. Een trage website is niet enkel vervelend voor de bezoekers van deze website er zijn ook nog andere nadelige gevolgen. Uit onderzoek van o.a. Pingdom blijkt dat de bounce rate (vroegtijdig verlaten van een website) begint op te lopen vanaf ongeveer 2 seconden. Conversiedaling Uit andere studies blijkt dat een extra vertraging van 1 seconde op een webpagina een daling in de conversion rate van 7% tot gevolg heeft. De conversion rate is de mate waarin het doel van de website wordt bereikt. Voor een e-commerce website is dit doorgaans wanneer de bezoeker een product of dienst via de website heeft aangekocht. Omzetverlies 1 seconde extra vertraging van de website van een webwinkel met een omzet van 100.000 euro per maand komt dus uit op een omzet verlies van 7.000 euro per maand. Voor grote bedrijven zoals bijvoorbeeld Amazon geeft een extra vertraging van 1 seconde op hun webpagina’s omzetverlies van 1.6 miljard euro per jaar. Test uw eigen site hier: https://www.thinkwithgoogle.com/feature/testmysite/ Klanttevredenheid 79% van de bezoekers die ontevreden zijn over de snelheid van een e-commerce website zullen daar nooit meer aankopen doen. Reputatie 66% van de consumenten geeft aan dat de performance van een website invloed heeft op hun beeld van een bedrijf. 33% van de consumenten geeft aan dat een slechte performance van een website een negatief beeld tot gevolg heeft. Conclusie We weten allemaal dat performance belangrijk is. In deze blog heb ik je hopelijk een beter beeld laten zien over wat goede performance is en de mogelijke impact wanneer de performance niet goed is. Wil jij zeker weten of de performance van jullie websites of webapplicaties goed genoeg zijn of heb je hier vragen over, neem dan gerust contact op. Onderstaand vind je nog de bronnen die ik heb gebruikt voor mijn blog. Dank voor je aandacht. Bronnen https://www.theguardian.com/technology/2016/nov/02/mobile-web-browsing-desktop-smartphones-tablets https://developers.google.com/web/updates/2018/05/first-input-delay?hl=en-US https://developers.google.com/speed/docs/insights/v5/about#categories https://www.machmetrics.com/speed-blog/how-does-page-load-time-affect-your-site-revenue/ https://www.fastcompany.com/1825005/how-one-second-could-cost-amazon-16-billion-sales https://unbounce.com/landing-pages/2019-is-the-year-of-page-speed/

Inleiding Voor mijn huidige project ben ik bezig met het aspect kwaliteit in combinatie met Big Data. In zo’n modern project wordt hierbij ook AI gebruikt. Het inrichten van AI wordt vaak niet gedaan door ontwikkelaars, maar door data scientists die een omgeving nodig hebben wat het AI werk kan doen. De programmeertaal Python is de facto standaard die de data-analisten gebruiken om snel hun modellen op te zetten en uit te proberen. Met dit artikel wil ik graag mijn ervaringen delen over Pytest. Hierin laat ik zien wat het is, hoe je het kan in installeren en hoe je het gebruikt. Introductie in Pytest In veel Python projecten wordt Pytest gebruikt als alternatieve unit test library. Het is veelzijdiger dan Pythons eigen unittest, een greep uit de features: het kan omgaan met de ingebouwde assert statements, met pytest is eenvoudig om code voor en na een test uit te voeren, je kan dynamische testcases creëren en je hebt meer sturing over het uitvoeren van bepaalde testen. Zoals je veel ziet met libraries voor unit testing worden ze niet alleen gebruikt voor unit testen, maar ook voor geautomatiseerde integratie testen, functionele acceptatie testen of zelfs end-to-end testen. Maar je kan pytest ook gebruiken om bijvoorbeeld pass/fail criteria op te stellen voor performance testen in JMeter. Unittest Compatibiliteit Pytest is compatibel met het ingebouwde unittest. Dat betekent dat je de pytest runner kan gebruiken voor beide soorten testen. Mocht je over willen stappen van unittest naar pytest dan kan dat naadloos doordat oude testen nog steeds bruikbaar zijn. Installatie De installatie van pytest is eenvoudig te doen via pip: pip install -U pytest om te kijken of je installatie is gelukt kan je de versie uitvragen: pytest --version Eerste test Voor onze eerste test hebben we een object onder test nodig, laten we een faculteit functie maken: en een test: We hoeven geen imports te gebruiken, na het installeren van pytest met pip werkt het out-of-the-box. Nadat we dit script hebben opgeslagen kunnen we het uitvoeren vanaf de commandline: > pytest pytest01.py collected 1 item pytest01.py . ==== 1 passed in 0.04s ==== Het mooie aan pytest is dat je asserts kan gebruiken. Bij de unittest library moet je assertion libraries importeren en ook de syntax was niet heel intuïtief. De ingebouwde asserts maken het heel overzichtelijk wat je test. Pytest zal bij een gefailde assert ook duidelijk laten zien wat de uitkomst was en wat niet klopte aan de verwachting. Meerdere testen Op dezelfde manier kunnen we meerdere testen toevoegen en uitvoeren: Nu gebeurt er iets interessants, we hebben komen twee fouten tegen: Als we naar beneden scrollen dan kunnen we de details zien en vervolgens de summary: Run Verbose In bovenstaand voorbeeld zie je puntjes voor een geslaagde test en een F voor een Fail. Je komt ook wel eens een E tegen van Exception, hierbij vindt er een exception plaats in de test setup. In verbose mode zie je precies welke test er fout gaat in de output tijdens runtime en niet achteraf. Dat is handig in je CI (Continuous Integration) pipeline als je unit testen langer duren dan enkele seconden. Verbose mode zet je aan met de -v switch: Wil je ook output van print statements zien tijdens runtime, dan kan je de -s switch gebruiken op de commandline. Pytest zal normaal gesproken print output afvangen en alleen in het overzicht tonen als een test gefaald is, met -s wordt deze ook getoond in de output. Er zijn velen command line opties om het leven makkelijker te maken, gebruik pytest -h voor een uitgebreid overzicht. Pytest in de IDE Zelf vind ik het handig om testen uit te kunnen voeren vanuit de IDE in plaats vanaf de commandline. Daarvoor moet je wel aangeven in de bIDE wat de testrunner is, anders worden testen niet herkend: Dit is PyCharm en is vergelijkbaar met IntelliJ. Zonder de ingestelde testrunner zie je geen “play” icoon in de alinea of “Run Pytest for …” context menu optie. Stel de testrunner in via het settings menu: Nu heb je PyTest enabled in de IDE en kan je van shortcut keys gebruik maken. Je kan ook de testen voor een hele .py file of een hele module in een keer starten door een rechtermuis klik op de file of module en Run Pytest for … te selecteren. Pytest Exception testing Wil je compleet zijn in je testen, dan zal je ook een aantal negatieve testen willen maken: hoe gaat de software om met input die niet correct is. In Python geldt het gezegde: "Het is beter te vragen om vergeving vragen dan om toestemming", dus het raisen en afvangen van excepties is wat gebruikelijker dan in bijvoorbeeld talen als C# of Java. In ons factorial voorbeeld verwachten we een TypeError als we een string als argument geven: En inderdaad: Maar nu hebben we een gefaalde test, dat is niet wat we willen. Je zou een try/except kunnen proberen en een assert kunnen doen op de foutmelding: Maar dat is best wel omslachtig. Gelukkig heeft Pytest hiervoor een ingebouwde methode: Deze constructie test of de verwachte exceptie ook daadwerkelijk doorgegeven worden. Als dat zo is dan slaagt de test. Zo niet, dan faalt de test. Conclusie Pytest is een veelzijdige library die vaak wat makkelijker in gebruik is dan de ingebouwde unittest library. Pytest heeft een goede integratie met IDEs als PyCharm, Intellij en VSCode waardoor je elke wijziging direct kan testen. Daarnaast bevat het voor de geavanceerde gebruiker uitgebreide opties te gebruiken die nauwgezette controle bieden tijdens runtime of de mogelijkheid om automatisch testen te genereren vanuit een testcase repository. Pytest is voor mij de de-facto test library om naar te grijpen wanneer ik datapipelines voor machine learning modellen moet productionaliseren. Ik gebruikt het zowel voor het unit testen van transformaties en features, het opzetten van integratie testen als voor het uitvoeren van functionele acceptatie testen.

In mijn vorige blogs heb ik geschreven over Gatling simulaties in een executable jar en Azure DevOps pipeline met Gatling. In het laatste blog had ik al aangegeven dat ik de performancetest onderdeel wilde laten zijn van de CD pipeline door het toevoegen van quality gates. Oftewel, ik wil dat de resultaten van de performance test automatisch beoordeeld worden in de pipeline en dat deze beoordeling verantwoordelijk is voor het wel of niet continueren van de release. Bij mijn vorige opdracht waren we nog niet op dit punt aangekomen, maar ik heb wel al het e.e.a. uitgezocht; deels bij die opdracht en deels met de kennissessies die wij met PerformanceArchitecten maandelijks houden. Gatling assertions In mijn vorige blog had ik al aangegeven gebruik te willen maken van de Gatling assertions functionaliteit. Je kan aan je performancetest script assertions toevoegen. Dit beperkt zich tot assertions op het gebied van aantal transacties en responstijden. Je kan assertions toevoegen op 3 niveaus: global: assertion wordt uitgevoerd op de resultaten van alle requests samen forAll: assertion wordt uitgevoerd op elk request details(path): assertion wordt uitgevoerd op een specifiek request of group (een group kan je om een set met request heen zetten; in LoadRunner wordt dit een transaction genoemd) Voorbeelden: Als je een gatling simulatie uitvoert en je hebt assertions gedefinieerd, dan worden aan het einde van de testrun 2 files gegenereerd: assertions.json assertions.xml (JUnit file) Een belangrijk verschil in deze 2 files, is dat in de JUnit file bij een geslaagde assertion niet de gemeten waarde tijdens de test getoond wordt. Dit is bij de JSON file wel het geval. Dit is bij een op zichzelf staande test niet belangrijk, maar als je verschillende release wil gaan benchmarken is het wel waardevol om ook deze waardes te bewaren. Gatling assertions in de pipeline Hoe werken de assertions nu in combinatie met de Azure DevOps pipeline? Allereerst moet je natuurlijk assertions hebben toegevoegd aan je simulatie. Voorbeeld: Vervolgens moet je in ieder geval 2 taken aanmaken in een Azure DevOps Release pipeline: De eerste taak (PowerShell) voert de performance test uit. Niets meer en niets minder. Als niet aan alle assertions in de Gatling simulatie wordt voldaan, zal de simulatie falen en daardoor ook de PowerShell Task: De oplettende lezer/kijker heeft kunnen zien dat het icoontje voor de taak oranje is (warning) en niet rood (error). Dat komt doordat ik bij de Control Options heb gekozen voor “Continue on error” omdat ik evengoed graag de test resultaten wil publiceren. Daar is de 2e taak voor: Publish Test Results. In deze taak kan je aangeven welke type files je wil publiceren en waar deze staan (Search folder). En hier kan je vervolgens ook aangeven dat de taak moet falen in het geval van “test failures”. En dat gebeurt in dit geval dus ook: Dus op deze manier kan je de Gatling assertions functionaliteit inzetten als quality gate. Als niet wordt voldaan aan de vereiste kwaliteit (assertions) dan faalt de release en wordt deze niet verder uitgevoerd. En door het publiceren van de test resultaten, kan je op een makkelijke manier achterhalen aan welke assertions niet voldaan is: En verder? We hebben nu gezien dat we door assertions aan de Gatling simulatie toe te voegen het resultaat van de uitvoer van de performance test kunnen beïnvloeden. Hiermee maak je het dus ook mogelijk om de flow van een release pipeline te beïnvloeden. Oftewel we kunnen de Gatling assertions als quality gate inzetten. Er zijn nog wel 2 kanttekeningen die ik wil maken: Het beoordelen van de resultaten van een performance test doe je niet enkel o.b.v. requirements voor responstijden en aantal (geslaagde/gefaalde) transacties. Want hoe zit het bijvoorbeeld met de applicatie die getest wordt en evt. backend systemen? Er wordt nu niet gekeken naar zaken zoals CPU en memory gebruik. Dat kan ook waardevolle informatie leveren! Naast het voldoen aan de requirements is het ook goed om te weten hoe de performance van de huidige release zich verhoudt met voorgaande release(s). Om bovenstaande punten weg te nemen, zijn zeker oplossingen te bedenken. Deze liggen buiten de functionaliteit van Gatling (in ieder geval de gratis versie) en ook buiten de scope van dit blog. Ik hoop dat jullie deze blog interessant vonden en dat ik jullie heb geïnspireerd of op ideeën heb gebracht. Ik hoor ook graag jullie ideeën! Er zijn altijd meerdere oplossingen.

Introductie Binnen de Azure omgeving is er veel mogelijk zoals bijvoorbeeld het runnen van pipelines en het creëren van infrastructuur. Maar om van deze mogelijkheden gebruik te kunnen maken zijn er uiteraard resources nodig. Deze resources zijn manueel via de portal aan te maken, maar ook door gebruik te maken van ARM (Azure Resource Manager) templates. Sinds kort is er nu ook een nieuwere manier om resources aan te maken: Bicep. Dit alles om infrastructure as code te implementeren. Naast dat Bicep voor een betere ontwerpervaring zorgt, biedt het ook extra scripting mogelijkheden. Binnen PerformanceArchitecten hebben we eens per maand een kennissessie waar we onder andere nieuwe technieken en tools onder de loep nemen. Deze bijeenkomsten noemen we kennismiddagen. Tijdens de afgelopen Kennismiddag zijn wij gaan kijken naar de mogelijkheden van Bicep en hoe we dit kunnen toepassen. In deze blog zullen we onze bevindingen delen. In de voorbereiding hebben wij een aantal bronnen gevonden die ons goed op weg konden helpen bij het gebruik van Bicep. Introductie Bicep Bicep is een domeinspecifieke taal (DSL) die gemaakt is om Azure-resources te implementeren. Deze DSL wordt gebruikt om de implementatie sneller, eenvoudiger en kwalitatief beter te doen door middel van het gebruik van een beknopte syntax. Het blijkt dat je zelfs met een beknopte syntax uiteindelijk een uitgebreid, en dus complex, document kunt krijgen. Dit document blijft echter nog wel redelijk leesbaar. Bicep is in principe een tussentaal: in plaats van de complexe JSON kan er gebruik gemaakt worden van een meer volledige taal. Omdat het een tussentaal is wordt altijd naar de ARM JSON gecompileerd die dan in Azure kan worden gebruikt. Gelukkig zorgt de toolset van Bicep er voor de conversie onder water gebeurt, niet meer zichtbaar is en je er geen omkijken meer naar hebt. Introductie Video Bron: Understanding and Using Project BICEP – The NEW Azure Deployment Technology John Savill’s Technical Training (https://youtu.be/_yvb6NVx61Y) Dit is een prettige video waarin veel details worden gedeeld. Door de manier van presenteren (via een soort white board) wordt het goed duidelijk gemaakt. Er wordt een goede context gegeven, van installatie tot veel praktische voorbeelden in bijvoorbeeld Visual Studio Code. In de video wordt stapsgewijs verteld hoe je een Bicep file kunt opmaken en hoe je deze vervolgens kan gebruiken. Ook de terminologie wordt goed uitgelegd met daarin de gebruikte Azure componenten. Al met al een goed verhaal waar we veel aan gehad hebben. Tutorial Bron: Getting started with Azure Bicep door Tobias Zimmergren (https://zimmergren.net/getting-started-azure-Bicep/) Van deze pagina hadden we een volledige tutorial verwacht, maar het was meer een write-up van mogelijkheden. Dit was voor ons minder geschikt om te gebruiken. Oefenen met een aantal voorbeelden Op basis van de voorbeelden in de video en de voorbeelden die uit de officiële Microsoft GitHub kwamen (https://github.com/Azure/Bicep/tree/main/docs/examples) zijn we zelf gaan oefenen. Met behulp van deze voorbeelden hebben we praktisch gezien hoe Bicep op een simpele manier gebruikt kan worden om, via Infrastructure as code, resources in Azure aan te maken. Zoals in de introductie is aangehaald, heeft Bicep de mogelijkheid tot “programmeren”. Dit is iets wat niet met de ARM template kan. Bicep heeft veel extra scripting mogelijkheden zoals loops, if’s, string manipulatie etc. Hiervan hebben we kort een aantal bekeken. Hier is nog zoveel in te ontdekken dat we besloten hebben om dit later zeker verder uit te zoeken. Wel hebben we gemerkt dat het echt noodzakelijk is om kennis te hebben van de resources die je aanmaakt. Bijvoorbeeld het aanmaken van een virtuele machine heeft vele parameters nodig. Zonder kennis van de parameters van resources, wordt het lastig om met Bicep te werken. Het einddoel is om deze resources op een goede manier aan te maken, dus zijn de vele parameters wel nodig. Hierdoor kan het Bicep script er snel complex uit zien. Vergeleken met ARM templates biedt Bicep een duidelijk betere en leesbare structuur. Vanuit een decompile actie kan je prima een Bicep aanmaken. Nadeel is dat alle parameters, ook default en genereerde parameters ook weer in de Bicep file gegenereerd worden. Hierdoor ontstaat een bestand dat, net als de ARM template, minder leesbaar is. Advies is dus om na een decompile actie goed te kijken welke parameters echt noodzakelijk zijn en de rest weg te gooien. Hierdoor behoud je een leesbare Bicep file. Pipelines Bron: ‘Bicep in de pipeline’ door (Alex) Oleksandr Chzhen (https://ochzhen.com/blog/deploy-azure-bicep-in-cicd-pipeline) Nadat we gezien hebben hoe we een Bicep file kunnen opmaken en builden om een ARM template te compileren, gaan we nu naar de toepassing hiervan. De blog ‘Bicep in de pipeline’ (zie bron) geeft informatie hoe deze infrastructure-as-code gebruikt kan worden in een Azure DevOps pipeline. Naast een kleine introductie geeft de pagina ‘Bicep in de pipeline’ goede voorbeelden van een basis Bicep file en hoe deze in een pipeline ingebouwd kan worden. Aan de hand van de voorbeelden hebben wij in onze eigen Azure DevOps omgeving een repository aangemaakt. Deze hebben we vervolgens met onze voorbeeld bestanden gevuld. Vervolgens hebben wij de pipeline opgezet en geprobeerd deze aan de praat te krijgen. Na wat issues (zoals het vullen van eigen variabelen) is dit ons gelukt en zijn de resources in Azure aangemaakt. Conclusie Bicep is een krachtig hulpmiddels voor het opzetten van resources in een Azure omgeving. Het is een taal die in goed leesbaar is. Echter, met Bicep kan het snel complex worden maar dat is vooral door de vele parameters en mogelijkheden van de resources. Als gebruiker moet je wel op de hoogte zijn van de parameters die bij elke resource in Azure nodig zijn. De programeermogelijkheden van Bicep lijken potentie te hebben. We hebben hier nog weinig praktijkervaring mee opgedaan en is nog iets wat we verder kunnen uitzoeken. We weten dat Bicep nog in een beginstadium zit (huidige versie 0.4.x), maar het gebruik voelt toch redelijk volledig aan. Qua documentatie kan het nog beter, dit is nog schaars. Maar we voor deze introductie wel voldoen bronnen gevonden om een start te maken. Al met al hebben we een leuke en interessante kennismiddag gehad, waarin we veel kennis van Bicep en het alloceren van resources hebben opgedaan. Voorbeeldcommando’s bicep build “main.bicep” bicep decompile “./virtualmachine.json” New-AzResourceGroupDeployment -TemplateFile "storage.bicep" -ResourceGroupName RG-Bicep-KM New-AzResourceGroupDeployment -TemplateFile "storage.bicep" -ResourceGroupName RG_Bicep_KM -Type 'Standard_LRS' -WhatIf az deployment group what-if -f "storage.bicep" -g RG_Bicep_KM --parameters type=Standard_GRS

We zien bij onze klanten een duidelijke verschuiving van verantwoordelijkheden van centrale teams naar DevOps teams. “You build it, you run it” zorgt ervoor dat teams niet alleen zelf software moeten bouwen, testen en in productie brengen, maar ook verantwoordelijk zijn voor hoe de applicatie in productie draait. Eén van de activiteiten die we zien verschuiven, is het performancetesten. In deze blog willen we onze visie delen m.b.t. het overdragen van performancetesten van een centraal team of CoE (Center of Expertise) naar DevOps teams. De initiële reactie van performancetesters is vaak dat performancetesten een expertise is die niet zomaar overgedragen kan worden. Meestal zijn dit specialisten die al vele jaren met het vak bezig zijn en zij zien deze transitie dus ook als een gevaar. Zowel voor hun eigen rol, maar ook voor de kwaliteit van performancetesten. Door lage kwaliteit performancetesten kunnen problemen verborgen blijven en dit kan grote gevolgen hebben voor de beschikbaarheid van applicaties in productie. Een veel gehoord argument is dat er specifieke kennis nodig is voor het performancetesten. Deze kennis is meestal niet aanwezig bij de teams. Teams hebben al zoveel taken en verantwoordelijkheden en het is simpelweg niet mogelijk om overal specialist in te zijn. En dat is natuurlijk een valide argument. Toch is het (deels) mogelijk om performancetesten succesvol over te dragen aan DevOps teams. Mits aan een aantal voorwaarden wordt voldaan. Deze voorwaarden worden hieronder opgesomd en later verder toegelicht: Automatiseren – Automatiseer het uitvoeren van performancetesten. Korte herhaaldelijke testen – Maak onderscheid in korte testen (voor regressie) en specialistische testen. Specialist behouden – Binnen de organisatie moet een performancetestspecialist beschikbaar zijn voor ondersteuning en kwaliteitscontrole. Affiniteit en basiskennis – Affiniteit met performance en basiskennis van performancetesten (scripting, analyse e.d.) moet binnen het team aanwezig zijn. Tijd en aandacht – Product owner moet adoptie van en overdracht naar het team (onder)steunen en daar tijd voor inplannen. Automatiseren Door het automatiseren van het uitvoeren van performancetesten kan er een flinke versnelling in het opleveren van de performancetestresultaten worden bereikt. Bij het automatiseren moet je denken aan: Het voorbereiden van de test (zoals klaarzetten van testdata en monitoring) Het starten van de simulatie Het verzamelen van monitoringgegevens en de resultaten van de test Het analyseren en rapporten van de testresultaten (inclusief vergelijken met vorige resultaten) Dit bespaart een hoop tijd en voorkomt ook dat de performancetester (of degene die met die taak belast is) herhaaldelijk werk moet doen en zorgt ervoor dat deze zich enkel hoeft te focussen op wijzigingen in scope, volumes en andere requirements. Korte herhaaldelijke testen Er bestaan meerdere type performancetesten die voor verschillende doelen worden ingezet. Door onderscheid te maken tussen eenvoudige herhaalbare testen en specialistische testen is het mogelijk om eenvoudige testen over te dragen naar het team en specialistische testen bij de performancetestspecialisten neer te leggen. Bij korte, herhaaldelijke testen is automatiseren van de uitvoer van performancetesten een prima aanpak maar bij specialistische testen is dit vaak minder bruikbaar. Specialistische testen (zoals duurtest, failover test) worden met minder regelmaat uitgevoerd en het scenario zal vaak anders zijn. Specialist behouden Binnen de organisatie moet een performancetestspecialist beschikbaar zijn voor ondersteuning en kwaliteitscontrole. Bij grotere organisaties zullen dat wellicht meerdere specialisten zijn. De hierboven genoemde specialistische testen kunnen door deze performancetestspecialisten worden uitgevoerd. Door het uitvoeren van kwaliteitscontrole kunnen performancetestspecialisten de teams helpen om de kwaliteit van performancetesten op een goed niveau te houden. Affiniteit en basiskennis Om performancetesten succesvol te kunnen overdragen naar teams moet er wel een zekere basiskennis van performancetesten binnen het team aanwezig zijn. Toolkennis is nodig om het bestaande script te kunnen aanpassen aan de gewijzigde functionaliteit en om analyse van de resultaten te kunnen doen. Naast deze basiskennis zal er in het team ook enige affiniteit met performance moeten zijn. Dit zal het team nodig hebben om regelmatig na te gaan of er nieuwe risico’s op het gebied van performance zijn. Denk hierbij aan responstijd, stabiliteit, capaciteit en andere aspecten van performance. Tijd en aandacht Het overdragen van performancetesten van performancetestspecialisten naar teams zal alleen succesvol zijn als de product owner van het team ook het belang van performancetesten inziet en voldoende tijd zal inruimen in de sprint planning voor de overdracht van performancetesten. Naast de overdracht naar het team is ook de adoptie van performancetesten door het team van belang. Hierbij is het belangrijk dat het niet bij één persoon komt te liggen maar dat het breed gedragen wordt. Anders bestaat het gevaar dat de kennis van performancetesten verdwijnt bij wisseling in het team. Tot slot Hierboven hebben wij onze visie gedeeld over hoe performancetesten overgedragen kan worden naar teams en wat de voorwaarden hiervoor zijn. We horen graag wat jouw ervaring is.

Op dinsdag 14 februari hebben we weer onze maandelijkse kennismiddag gehad. Een kennismiddag biedt ons de mogelijkheid om als collega’s bij elkaar te komen en een of meerdere onderwerpen op te pakken, uit te zoeken en kennis over op te doen. Naast wat andere onderwerpen stond deze middag in het teken van de ontwikkelingen rondom ChatGPT, wie heeft er tegenwoordig nog niet van gehoord. Tijdens deze middag zijn we in tweetallen gaan kijken naar waarbij ChatGPT ons kan ondersteunen in het werk. Er is gekeken of deze blog-post gegenereerd kan worden door ChatGPT. En er is onderzocht of de AI ondersteuning kan geven bij de SEO (Search Engine Optimization) of kan helpen bij het schrijven van (automatisering) scripts. Al deze categorieën kunnen handig zijn bij uitvoering van ons werk, maar helpt het ook echt? Deze blogpost is in ieder geval niet geschreven door ChatGPT! De algemene conclusie is dat ChatGPT een prachtige tool is met verrassende resultaten. Het begin van AI gegenereerde resultaten is er, maar het is nog niet perfect! Er moeten heel specifieke instructies gegeven worden om het juiste te bereiken. Het hoewel ChatGPT de invoer van jou als gebruiker ‘onthoudt’, is het soms wel mogelijk om onjuiste of niet volledige resultaten terug te krijgen. Soms omdat het verkeerde gevraagd wordt, of dat er een maximum aan uitvoer karakters bereikt is. Gelukkig kan je via een ‘undo’- of ‘continue’-commando wel verder blijven werken. Bij de SEO- of scripting-ondersteuning merkten we ook op dat de gegenereerde resultaten een goede eerste opzet zijn, maar wel degelijk verdere input van een gebruiker nodig heeft. Hierbij zal de domein-kennis of vak-expertise nog steeds nodig blijven. Kortom, het is een tool dat veel potentieel heeft en zeker kan helpen in diverse situaties. Maar volledig over op AI kan zeker nog niet! Op naar een volgende Kennismiddag en nieuwe onderwerpen!