Een organisatie die over is naar DevOps wil dat het performancetesten per DevOps team wordt opgepakt in plaats van dat dit door een overkoepelend en apart performancetest team gedaan wordt. Dit zou ervoor moeten zorgen dat de doorlooptijd van het live brengen van een release sneller gaat en van hetzelfde kwalitatieve niveau is. Teams hebben een eigen verantwoording voor hun releases en kunnen op deze manier de performancetesten naar eigen visie opzetten en uitvoeren. Werkt dit in de praktijk ook echt zo? Wat zijn de sterke en zwakke kanten van deze manier van werken?
Kennis en ervaring
Het idee achter verschillende kleinere DevOps teams is dat elk team zijn eigen applicatie(s) heeft waar die aan kan werken. De teams bepalen zelf hoe ze werken en welke methoden ze gebruiken om tot het gewenste eindresultaat te komen: een release live brengen. Hierbij is het team ook verantwoordelijk voor het waarborgen van de kwaliteit van elke release. De opzet is dat elk team gezamenlijk alle disciplines bevat die nodig zijn. Deze disciplines waren voorheen gebundeld in aparte teams met hun eigen specialisme. Zoals een performancetestteam, die de kwaliteit van de performance van alle applicaties en de omgeving bewaakte. De medewerkers uit deze teams zijn dus verdeeld over de verschillende DevOps teams, met als resultaat dat de mate van ervaring van bepaalde disciplines sterk verdeeld is per team. Door van elkaar te leren zouden alle teams op een gegeven moment dezelfde mate van kennis hebben van alle nodige disciplines. Voor sommige disciplines is dit haalbaar, maar voor andere, zoals performancetesten, is dit erg lastig.
De sterke kanten
Vanuit het oogpunt van een ervaren performancetester zijn er sterke kanten aan het werken binnen DevOps teams. Eén van de grootste pluspunten is dat je samen met ontwikkelaars en functioneel testers in het team zit. Hierdoor zijn de lijntjes erg kort en kan er makkelijk en snel geschakeld worden. Tijdens het ontwikkelproces van een release heeft een performancetester er baat bij om al te sparren met ontwikkelaars. Zo kunnen tijdens het ontwikkelen al over bepaalde performanceaspecten nagedacht worden. Dit zorgt ervoor dat tijdens het uitvoeren van performancetesten er potentieel minder issues overblijven die getackeld moeten worden. Tijdens en na performance testen kunnen issues ook makkelijk besproken worden met de ontwikkelaars. Het aanpassen van de applicaties gaat snel en een nieuwe versie is snel beschikbaar om weer te kunnen performancetesten.
Het maken van scripts gaat ook sneller doordat er vaak en snel gespard kan worden met de functioneel tester. Hierdoor wordt het voor de performancetester bijvoorbeeld makkelijker om te weten welke (klik)paden belangrijk zijn, hoe deze werken en welke mogelijke variaties er zijn. Vervolgens kan ook al in een eerder stadium aangegeven worden welke testdata nodig is en kan het regelen hiervan al in gang worden gezet.
Doordat performancetesters over het algemeen alleen met de applicaties bezig zijn van hun team, neemt de kennis van hoe deze applicaties in elkaar steken ook flink toe. Ze kennen de applicaties door en door en kunnen hierdoor steeds beter pinpointen waar mogelijk performance gewonnen kan worden en dit duidelijk maken aan de rest van het team. Hierdoor wordt het nut en inzicht van performance van de applicaties bij de rest van het team steeds duidelijker en belangrijker.
De zwakke kanten
Hoe mooi het ook allemaal klinkt, in de praktijk werkt het toch niet zoals men aan het begin gedacht had. Het niveau van kennis van performancetesten kan flink verschillen per team. Performancetesten is een erg specialistische discipline die niet binnen een paar weken of zelfs maanden onder de knie te krijgen is. Je moet gedurende een geruime tijd er dagelijks mee bezig zijn wil je de nodige kennis krijgen. Het op doen van de nodige ervaring neemt ook veel meer tijd in beslag dan gedacht. Door te weinig kennis en ervaring kunnen er bijvoorbeeld tijdens de analyse bepaalde issues over het hoofd gezien worden of worden resultaten op een verkeerde manier geïnterpreteerd. Het gevaarlijke hieraan is dat onervaren performance testers een ‘akkoord’ geven aan de livegang van een release, terwijl dit eigenlijk niet had gemogen. Het resultaat is dat er productieproblemen ontstaan en het oplossen hiervan ook de nodige tijd in beslag neemt. Het had allemaal voorkomen kunnen worden als iemand met de juiste kennis en ervaring erbij was betrokken.
Een ander gevaar wat op de loer ligt, zijn de releases van overkoepelende onderdelen op een omgeving. Deze niet-applicatie specifieke releases kunnen changes zijn in het achterland, op hardware niveau of netwerk niveau. Deze ‘horen’ niet bij een specifiek DevOps team en kan het zijn dat niemand zich verantwoordelijk voelt voor het performancetesten hiervan. Het ‘hoort’ immers niet bij een applicatie of onderdeel van het team. Productieproblemen kunnen voorkomen worden, door dit soort releases goed in de gaten te houden en deze door ervaren performancetesters te laten beoordelen. De performancetesters kunnen vervolgens aangeven wat de benodigde tijd en kwaliteit er nodig is voor het opzetten, uitvoeren en analyseren van resultaten van de uit te voeren testen.
Conclusie
Zoals bij elke manier van werken zijn er sterke en zwakke punten. Dit is voor het werken op de DevOps manier niet anders. Wat men vooral in gedachte moet houden is dat het niet realistisch is om over te gaan op DevOps en te verwachten dat elk team binnen dezelfde tijd hetzelfde niveau aan kennis heeft van alle disciplines. De ene discipline is snel op te pakken door de medewerkers binnen een team, maar een discipline als performancetesten vergt veel tijd om goed onder de knie te krijgen.
Het zou verder goed zijn om een ervaren performancetester te hebben als ondersteuning voor meerdere teams. Op deze manier kunnen medewerkers de tijd nemen om performancetesten onder de knie te krijgen binnen hun team en blijft de kwaliteit gewaarborgd door de ervaren performancetester.
Tot slot zou een overkoepelend team of community van ervaren performancetesters in stand moeten blijven. Dit kunnen testers zijn die in eigen teams zitten, maar vaak samenkomen om meningen en ervaringen te delen en te bespreken. Door dit in stand te houden blijft de kennis van performancetesten binnen de organisatie op een gewenst niveau.