Inmiddels draai ik al een flink aantal jaren mee in het non-functional testwereldje. Ik heb bij verschillende klanten diverse vormen van load-, performance tests en monitoring geïmplementeerd. Vaak in waterval setting, soms als individueel project, en de laatste jaren meer en meer in klantomgevingen waar men de agile development lifecycle volgt.
Wat me daarbij opvalt is dat bij veel agile klanten het end-2-end performance testen niet binnen de beschikbare sprint past. Hierdoor komt het performance testen, in combinatie met de deployment, al snel op het kritieke pad te liggen. Dit komt in mijn optiek doordat een agile cycle geen ruimte lijkt te geven voor QA anders dan die van functionaliteit (het “standaard functioneel testen”). En zelfs dáár zie je nog regelmatig dat er problemen ontstaan met het goed, volledig en tijdig uitvoeren van de tests.
Is deze cycle te kort of richten we de cycle verkeerd in? Ik zie 2 duidelijke kenmerken:
- De focus ligt te zwaar op het opleveren van de code (development). Hierdoor raakt het (performance) testen in het nauw.
- Een stabiele versie van de software komt pas aan het einde van de sprint beschikbaar. Op zich logisch natuurlijk, maar om een goede end-2-end performancetest te doen wil je wel een omgeving die dat faciliteert.
Hoe kunnen we dat oplossen?
In principe zijn er 3 oplossingen om dit probleem te tackelen:
- Verminder de development workload in de sprint
Dit is alleen mogelijk in een multidisciplinair team. Developers moeten minder programmeren en hebben dus extra tijd om andere zaken zoals functioneel- en performance testen op te pakken. Dit stelt extra eisen aan de kennis, skills en houding van de developers. De praktijk leert ons dat 5 potige schapen helaas niet bestaan. Resteert de conclusie dat de developers waarschijnlijk dan een deel van de sprint te weinig werk omhanden hebben. - Shift left
Verleg je focus naar performance unit testen. Probeer zo veel mogelijk werk t.a.v. performance testen naar voren te trekken, en koppel op het laatst de individuele onderdelen om het volledige proces door te testen. Het volledig doorlopen van de individuele unittests geeft niet altijd de garantie dat het geheel aan gekoppelde tests ook een positief testresultaat geeft, maar haalt wel een groot deel van de werkzaamheden in een cycle naar voren. Aandachtspunt is dat je een klein risico loopt dat de testdekking niet 100% volledig is. - N-1
Dit is vertragen van de deployment met 1 cycle, of met een vaste periode die benodigd is voor het performance testen. Eén en ander is afhankelijk van de duur van een sprint en de scope van de werkzaamheden. Wat ik hiermee bedoel te zeggen is dat je release eigenlijk een x aantal dagen later plaatsvindt nadat de definitieve code is opgeleverd. In deze extra tijd kun je dan het performance testen, maar ook security- of andere NFR gerelateerde tests uitvoeren. De bevindingen vanuit de performance (of andere NFR tests) worden dan opgevoerd als backlog items voor de nieuwe sprints.
Persoonlijk zie ik de “N-1” versie veel terug komen bij de verschillende opdrachten. het heeft als effect dat er in het begin van een project er één cycle vertraging in de deployment zit, maar je daarna eigenlijk weer de agile cadans aanhoudt qua leveringen. Dit levert je voldoende tijd op om een goede performance test én mogelijke andere NFR gerelateerde tests uit te voeren.
Hoe kijk jij hier tegenaan?
Welke uitdagingen kom of ben je tegen gekomen en hoe ben jij hier mee omgegaan?
