Nu SCRUM en DevOps steeds meer hun intrede doen voor ontwikkelteams en het bewustzijn van het belang van goede performance steeds groter wordt, zie je dat hier en daar gezocht wordt naar een plaats voor performance-testen daarbinnen. Betrek je een performance-test-specialist in het team? Laat je testen door ontwikkelaars? Of zijn er andere manieren om dit een plaats te geven? En hoe sluit het Performance Assurance-concept van Computest hierop aan?
Opkomend bewustzijn belang van presteren
In een tijd waarin systemen sneller zijn, applicaties complexer en mensen steeds maar ongeduldiger worden (zowel de Business die alles sneller opgeleverd wil zien, als de consument die steeds minder lang wil wachten) blijkt dat performance ook steeds belangrijker wordt.
DevOps verkort communicatielijnen door verantwoordelijkheden en specialismen te bundelen in een team, wat aansluiting vindt bij een SCRUM-ontwikkelteam. Die SCRUM-ontwikkelmethode richt zich op het live-brengen van nieuwe of verbeterde functionaliteit in korte cycli. Deze principes, samen met het eerder genoemde bewustzijn zorgen er dan ook voor dat men in een vroeg stadium wil testen. Performance-specialisten hameren daar al langere tijd op om tijdsdruk, budgetsdruk en de bijkomende stress en frustraties tegen te gaan, wanneer in die laatste ronde, aan het eind van een lange cyclus, bij een omvangrijke ketentesten wordt geconstateerd dat er nog veel voor verbetering vatbaar is. Dat er dus gekeken wordt naar de plaats van performance-testen binnen SCRUM of DevOps betekent dat men heeft begrepen dat er risico’s verbonden zijn aan een slecht presterend product en dat daarop getest moet worden. Een flinke stap voorwaarts. Maar hoe pas je performance-testen dan in?
Voor DevOps hebben Michael Bruce en Jaap Ottenkamp interessante blogs geschreven.
Specialisme of taak?
Specialisten zullen zeggen dat performance-testen een specialisme is en ze hebben een punt; zie ook het blog van Jos Esten, maar elk specialisme bestaat wel degelijk uit taken… Wat men kan met de resultaten vanuit een taak maakt iemand uitvoerend of specialist.
De performance testen: de taken
Het lijkt logisch om het testen op performance-requirements als taak op te nemen binnen de teams, omdat zij verantwoordelijk zijn voor wat aan het eind van de sprint naar productie moet kunnen. Met name dat laatste betekent dat ook de non-functionele eisen zoals de performance-requirements aan het eind van de sprint gedekt moeten zijn. De taken die iedereen zou moeten kunnen uitvoeren zijn: het draaien van een test, volgens een vooropgezette werkwijze en het met duidelijk herleidbare requirements rapporteren over de resultaten die van belang zijn.
Zie ook http://www.computest.nl/blog/performance-test-rapportage-wat-mag-je-verwachten/
Het performance-testen: het specialisme
Het is zeker verstandig om het eindresultaat door een specialist te laten beoordelen, maar ook het maken (en onderhouden) van de testscripts neigt al meer naar specialisme, i.v.m. de werking van de test-tools. Iedereen kan een opname maken van een gebruiksscenario, maar die opname kan meestal niet één-op-één gebruikt worden in een test; om correcte transactie-responstijden te meten, sessieduur representatief te houden en zeker te zijn dat de verwachtte antwoorden terugkomen op de server-requests is er nog wat werk aan de winkel. Zonder dat kan het bijvoorbeeld lijken alsof je systeem als een zonnetje draait, terwijl het eigenlijk niets doet en je verzoeken ongemerkt fout lopen.
Ook is opzet, of testsamenstelling (cases, load, scenario’s, strategie) wel degelijk een specialisme.
Zie hierbij ook de blogs van Joerek van Gaalen: http://www.computest.nl/blog/valkuilen-performancetesten-1/; mijn eerste blog: http://www.computest.nl/blog/performance-test-scope/; en die van Nico Welmer: http://www.computest.nl/blog/je-testscripts-zijn-zo-goed-als-je-requirements/
Één specialist voor meerdere teams…
Zelf ben ik als performance-specialist actief geweest in drie SCRUM-teams tegelijk. In theorie kan dit, omdat de taken niet gedurende de hele sprint nodig zijn. Maar in praktijk kenden deze teams dezelfde sprint-doorloop, waardoor het verschil in werkdruk sterk varieerde: laag aan het begin van de sprints, hoog tegen het eind. Ook is het betrokkenheidsgevoel bij de teams niet zoals dat gewenst is binnen SCRUM, omdat de aandacht verdeeld moet worden. Daarnaast moet je er niet aan denken om alle, binnen SCRUM gedefinieerde meetings te moeten bijwonen: dan blijft er helemaal geen tijd meer over voor het echte werk. Daarnaast wordt een specialist betaald voor wat hen specialist maakt.
Lees ook het blog van Joerek van Gaalen: http://www.computest.nl/blog/uitdagingen-bij-performancetesten-een-agile-omgeving/
Automatiseren en Continuous Delivery
Zo komt ook Continuous Delivery in beeld, met een test-straat opgezet en onderhouden door testspecialisten. De ontwikkelteams leveren tegen het eind van hun sprint het product aan, dit wordt volgens Continuous Delivery getest in verschillende test-fasen, waarvan de resultaten vervolgens door specialisten worden gecontroleerd. Daarna kan, bij goed resultaat, het product doorgezet worden naar productie.
Dat maakt de weg vrij om specialisten in te zetten waar ze nodig zijn: de knopen uit die rode lijn te halen en die lijn strak te trekken door de organisatie: efficiëntieslagen maken in bestaande processen. Van performancetesten naar Performance Assurance.
Performance-requirements vanuit performance-specialisten?
Tijdens het TestNet-event op 30 oktober 2014 gaf mijn collega Joerek een presentatie over het Performance Assurance-concept van Computest. Onder testmanagers en anderen waren veel van de toehoorders zelf performance-test-specialist. Ook was er een aantal ontwikkelaars bij die performance-testen als extra taak hadden in een SCRUM-ontwikkelteam.
Al snel werd het inhaken van performance-specialisten gedurende de hele cyclus benoemd, met als een van de eerste punten: het (ondersteunen bij het) opstellen van performance-requirements. Dit bracht een discussie teweeg die het verschil aangeeft tussen performance-specialisten en ontwikkelaars die op performance testen: de ontwikkelaars kunnen zich niet bezig houden met het specificeren van deze non-functional requirements die vanuit de business moeten komen. Performance-specialisten stellen echter vragen bij afwezigheid of onduidelijkheid van requirements, waarvan zij uit ervaring weten dat daar vaak performance-risico’s liggen. Ze kunnen de business helpen bij het opstellen van betekenisvolle performance-requirements en ervoor zorgen dat de juiste monitoring aanwezigheid is om die vinger op de zere plek te kunnen leggen.
Bijvoorbeeld: http://www.computest.nl/blog/client-rendering-wie-meet-dat/? Niet slechts een regressietest nu-straks, maar de trend: verleden-nu-straks…-toekomst?
Dit is slechts het tipje van de sluier van de inzet van Performance Assurance… Een laatste voorbeeld: die link met Capacity Management: http://www.computest.nl/blog/het-belang-van-service-management-voor-performancetesten-en-vice-versa-13/