Dashboards voor de testautomatisering

Auteur: John Kronenberg ● john.kronenberg@gmail.com

Redactie: Paul Beving

Op de projecten waar ik met testautomatisering aan de slag ga, staat uiteindelijk altijd wel een mooie geautomatiseerde testset in bijvoorbeeld Jenkins op gezette tijden te draaien. Omdat de populaire testautomatiseringsframeworks (bijvoorbeeld Robot Framework en Cucumber) kant en klare rapportages naar de Jenkins server weet te ontsluiten, is er bij mij in het verleden weinig behoefte geweest om eigen dashboards met extra (management)informatie neer te zetten. Onlangs ben ik me hier wat meer in gaan verdiepen. Dit artikel is bedoeld om mijn visie op het belang van extra informatie op projectspecifieke dashboards te geven. Is het mijns inziens de investering waard? Of zijn de out-of-the-box rapportagefaciliteiten van de bekende testautomatiseringsframeworks voldoende?

De huidige situatie

In projecten waar de rapportage-plugins van de frameworks wordt gebruikt is de allesomvattende vraag die prima beantwoord wordt: ‘draaien al mijn testgevallen nog succesvol in de laatste en de vorige x runs’. In een utopische wereld draaien alle testen nu en in het verleden foutloos en daar zou je dan wel de conclusie uit kunnen trekken dat je voldoende informatie over de kwaliteit van de software hebt gekregen en je dus geen behoefte hebt aan nog meer informatie. Maar de praktijk is toch anders. Testen draaien in de tijd niet altijd ‘groen’. De ene keer is de oorzaak een ‘flaky’ test, de andere keer een testfout en een andere keer heb je een softwareregressie-bug te pakken. In die situaties zou je graag wat extra informatie hebben. Die informatie is nodig om patronen te kunnen herkennen. Welke van mijn testgevallen zijn ‘flaky’? Dat is, welke testgevallen worden soms niet en een andere keer wel goed uitgevoerd, waarbij je niets aan het systeem of je omgeving hebt veranderd? In welke functionaliteit worden de regressiebugs gevonden? Is dit te verklaren? Kunnen we regressiebugs op deze functionaliteit op een betere manier in de toekomst voorkomen? En dan heb je nog de testfouten. Kunnen we daar als team van leren?

Mijns inziens kan extra informatie over de (geautomatiseerde) testgevallen voor projecten handig zijn als het patronen in het ontwikkel- en testproces inzichtelijk maakt.

Welke informatie op testautomatiseringsdashboard tonen?

Patronen in testautomatisering herken je dus door te meten, want meten is weten. Als je dan als project besluit om een (uitgebreidere) dashboard voor de testautomatisering op te zetten, dan stel ik voor dat je niet alleen patronen in de testautomatiseringsuitvoer op het dashboard toont, maar ook andere (management)informatie meeneemt. Om een keuze te maken welke informatie je dan op je dashboard gaat tonen, zijn de tien kwaliteitsmetrieken voor testautomatisering die door Johanna South in haar blog voor TestProject is geschreven, een goed vertrekpunt.

Johanna South heeft de volgende tien metrieken beschreven.

1. Automatiseerbare testgevallen metriek: welk percentage van het totaal aantal testgevallen is te automatiseren?
2. Testautomatiseringsscript effectiviteitsmetriek: percentage defects die specifiek door de testautomatisering zijn gevonden.
3. Testautomatisering slagingsgraad metriek: percentage testgevallen dat slaagt. Dit percentage omvat dus ook de flaky testgevallen.
4. Testautomatiseringruns doorlooptijd metriek: hoe lang duurt een testautomatiseringsrun? Hierbij geldt dat hoe sneller de testautomatiseringsruns zijn, des te sneller je ‘iets’ kunt roepen over de kwaliteit van de opgeleverde software. De wens is dus om de doorlooptijd van een run zo laag mogelijk te krijgen en te houden.
5. Testautomatisering testdekking metriek. Het percentage testgevallen dat geautomatiseerd is versus het aantal testgevallen dat nog handmatig uitgevoerd wordt.
6. Testautomatisering stabiliteit metriek. Een getal dat aangeeft hoe stabiel testgevallen zijn (en dus niet flaky).
7. Build stabiliteit metriek. Percentage builds die falen.
8. In-sprint automatisering metriek. Hoeveel van je testgevallen zijn in de sprint waar de user story onderhanden was, geautomatiseerd? Het streven moet zijn zoveel mogelijk van je testgevallen in de sprint waarin je een user story als team oppakt, te automatiseren.
9. Testautomatisering voortgang metriek. Het percentage automatiseerbare testgevallen dat reeds is geautomatiseerd.
10. Testautomatiseringpiramide metriek. Percentage van testgevallen per level van de testautomatiseringspiramide die op dit moment is geautomatiseerd. De testautomatiseringspiramide leert ons dat je lager in de piramide meer testgevallen wilt automatiseren dan op een hogere level. Met deze metriek kun je deze best-practice bewaken.

Deze tien metrieken geven een richting aan voor wat we op een dashboard inzichtelijk moeten maken. De patronen die ik in het vorige hoofdstuk heb beschreven worden met name door de testautomatiseringslagingsgraad metriek, de testautomatiseringstabiliteit metriek en de buildstabiliteit metriek inzichtelijk gemaakt. Echter, de metrieken zijn percentages en voor de eerdergenoemde patroonherkenning niet voldoende. Naast een percentage voor deze drie metrieken is het ook zinvol om de specifieke testgevallen die flaky zijn, waarop testfouten zijn opgetreden en die waarop bugs zijn geconstateerd, afzonderlijk op het dashboard te tonen.

Conclusie

Het is zinvol om extra informatie over de testautomatisering op een dashboard te tonen. En als je dan toch in je team een dashboard opzet, neem dan ook één of meerdere van bovenstaande metrieken mee! Je gaat er als projectteam profijt van hebben. In een volgend artikel zal ik ingaan op welke (open source) tooling je kunt inzetten om dashboards op te zetten en die prima aan bijvoorbeeld Jenkins te koppelen zijn.