Twee maanden geleden bevond het M2Q Agile team zich in een situatie waarin de meeste van de geautomatiseerde testen op non-actief werden gezet omdat ze te veel tijd in beslag namen bij de uitvoering ervan. Nochtans waren die noodzakelijk om uitgevoerd te worden bij iedere build.

Na een zeer intensieve retrospective besloten we om een korte sprint te wijden aan het versnellen van onze testen, want hoe sneller de testen zijn, hoe vaker ze zullen worden uitgevoerd.

De testen die niet worden uitgevoerd vangen geen problemen op, en hoe minder vaak ze worden uitgevoerd, hoe verwarrender het is om te begrijpen wat er mis is. Snelle testen worden vaak gedraaid, en dat helpt ons om in kleinere, veiligere stappen te werken.

Het eerste wat we hebben gedaan is een kijkje nemen naar wat de testen eigenlijk doen. Een goede vuistregel is dat elke test precies één ding moet doen, tenzij anders gerechtvaardigd. Dit atomaire karakter is de sleutel tot het maken van unit testen, maar het is net zo belangrijk voor integratie of end-to-end testen. Het komt vaak voor dat minder performante testen overbelast zijn omdat er te veel zaken tegelijkertijd lopen. Door het aantal stappen, dat elke test moet uitvoeren, te beperken daalt de totale tijd voor elke test. Het kan zijn dat het uitvoeren van meerdere testen met één doel sneller is dan het uitvoeren van één overbelaste test.

Zodra we minder performante testen hadden geïdentificeerd en er geen duidelijk knelpunt was, draaiden we de test met een monitoring tool om te zien waarom dat die test zo lang duurde bij uitvoering. Met die informatie konden we de knelpunten identificeren en konden we nadenken over oplossingen om de performantie te verhogen.

Zo kun je de Time To Market verkleinen:

• Voer minder vaak testen uit met een lage waarde(prioriteit). De waarde wordt berekend door de kans op falen te koppelen aan de prioriteit van een bug die door een fout wordt gevonden. Als een test nooit faalt of alleen bugs van lage prioriteit vindt (of overbodig is met een andere test), voeren we hem minder vaak uit, misschien ’s nachts of wekelijks.
• Verwijder “sleep-time” in je testware. Ze verspillen tijd, en ze zijn een indicatie van een slechte test. (testen zijn van slechte kwaliteit, als ze een schijnbaar willekeurig resultaat laten zien ondanks dat ze code testen die niet veranderd is). De tester weet niet echt waar hij op moet wachten en wacht uiteindelijk een lange tijd. Als de test belangrijk is, zijn er manieren om vaker te controleren of de vereiste data er al is(pollen) zodat de test eerder hervat kan worden.
• De testen lager in de piramide plaatsen: ruil integratie in voor snelheid. Kan een systeemtest een integratietest worden? Kan de integratietest vervangen worden door een paar goede unit testen? Hoe lager het niveau van de test, hoe sneller hij meestal is.
• Doe de setup van de applicatie en alle ondersteunende service maar één keer, niet bij elke testcase.
• Gebruik, waar mogelijk, data die in het geheugen kan blijven staan(databases) en kleine datasets.

Na het bekijken en het invoeren van bovenstaande tips  waren onze testen niet langer een bottleneck voor het project. We konden terug sneller gaan testen.

Maar zoals een collega tester eens zei, de bottleneck zijn is niet noodzakelijk een slechte zaak. Bvb. : Beveiliging is steeds een knelpunt op luchthavens. Soms moet je lang aanschuiven om voorbij het security checkpoint te komen. Maar er is niemand die zich uitlaat om te zeggen  “Laten we de beveiliging afschaffen omdat ik 15 minuten wil besparen”?

Mensen die oordelen over de snelheid van testen hebben misschien niet nagedacht over de waarde van het proces. Testen is als verzekeren, in de zin dat je geen verzekering neemt omdat je hoopt winst te maken. Je sluit een verzekering af als bescherming tegen verlies. Testen heeft een prijs in ruil voor die investering en tijd.

We krijgen een kans om belangrijke en ontwijkende problemen te ontdekken en daar ligt de waarde van het testen.

Auteur: Oana