Zijn geautomatiseerde tests wel betrouwbaar?

In de software development-wereld moet tegenwoordig alles sneller en wendbaarder. Waar je voorheen nog wel wegkwam met een paar releases per jaar, willen klanten en gebruikers tegenwoordig steeds eerder nieuwe functionaliteit en oplossingen voor bestaande problemen terugzien in je product. Methoden zoals Agile, DevOps en Continuous Integration / Continuous Delivery (CI/CD) helpen teams en organisaties om kortcyclischer te kunnen releasen en daarmee wendbaarder te worden.

Uiteraard blijft er de behoefte aan opleveren van kwaliteit, dus moet elke nieuwe (potentiële) release ook grondig worden getest. Echter naarmate er minder tijd is om te testen (we willen nu eenmaal steeds sneller kunnen opleveren), wordt er meer en meer gebruik gemaakt van testautomatisering om specifieke testactiviteiten efficiënter uit te kunnen voeren, en zo de feedback-loop te verkorten door sneller de gewenste informatie over de kwaliteit naar boven te halen. Die informatie kan dan weer gebruikt worden om te beslissen of een release bijvoorbeeld naar productie gebracht kan worden, en steeds meer teams en organisaties doen ook dit volledig geautomatiseerd (Continuous Deployment).

Om dit met vertrouwen te kunnen doen, moet de informatie die de geautomatiseerde tests opleveren wel betrouwbaar zijn. Als het hele proces van machine van een developer tot productieomgeving geautomatiseerd is, is de testautomatisering de enige controle van de kwaliteit van wat er wordt opgeleverd. De kwaliteit daarvan(de geautomatiseerde tests en testcode) is dus heel belangrijk, zou je zeggen.. Maar toch zie ik weinig teams echt actief bezig zijn met de kwaliteit van hun testautomatisering en de betrouwbaarheid van de informatie die die tests opleveren.

Testautomatisering is software development. Testers zullen er nooit zomaar op vertrouwen dat de kwaliteit van software die door een developer wordt opgeleverd voldoende is om naar productie te gaan. Waarom zouden we dat dan wel doen met onze geautomatiseerde tests? Waarom zouden we geen aandacht besteden aan de kwaliteit daarvan, en er gewoon van uit gaan dat ze werken? Dat ze de juiste informatie geven, en nog belangrijker, dat ze ons niet misleiden? Waarom zouden we onze geautomatiseerde tests zonder meer vertrouwen?

Geautomatiseerde tests kunnen je op twee verschillende manieren misleiden:

False positives zijn die tests die constant melden dat ze zijn gefaald, terwijl er niets aan de hand is met de applicatie die je aan het testen bent. Foutmeldingen worden veroorzaakt door bijvoorbeeld niet aanwezige testdata waarvan de test gebruik maakt, een externe component die even offline is, of het niet lang genoeg wachten tot een pagina of component is geladen voordat je er gebruik van probeert te maken in je test. False positives zijn vervelend, want ze creëren onnodige ruis en blokkeren de CI/CD proces.

False negatives zijn tests die blijven melden dat ze zijn geslaagd terwijl ze eigenlijk zouden moeten falen, omdat er wel iets aan de hand is in de applicatie die je aan het testen bent. Deze worden bijvoorbeeld veroorzaakt door aanpassingen in de applicatie zonder de daarbij horende tests bij te werken (“oh, ze zijn nog steeds ‘groen’, het zal wel goed zijn”) en door überhaupt je tests niet te testen voordat je ze gaat gebruiken. Kunnen je tests eigenlijk wel falen? Wat ik vaak zeg: ‘never trust a test you haven’t seen fail’.

Wanneer teams en organisaties dan aandacht (denken te) spenderen aan de kwaliteit van hun tests, gebruiken ze daarvoor vaak metrieken als code- of feature coverage(dekking). Hoewel coverage een aardig begin is, geeft het eigenlijk alleen inzicht in wat er wel en nog niet geautomatiseerd getest wordt.Het zegt helemaal niets over de kwaliteit van die tests zelf. Om een gechargeerd voorbeeld te geven: het is prima mogelijk om volledige coverage (100%) te halen met een suite van (geautomatiseerde-)tests zonder een enkele controle (check, assertion) erin.. Zou jij een dergelijke testsuite vertrouwen en de rol toebedelen als enige poortwachter tussen een lokale development-omgeving en productie?

Om echt vertrouwen te krijgen en te houden in de toegepaste testautomatisering, zul je met enige regelmaat aandacht moeten besteden aan de kwaliteit van de tests:

Wanneer je een nieuwe test schrijft, controleer dan of deze ook kan falen, en of de informatie die je in dat geval krijgt helder en eenduidig is.
Pas code reviews toe op je testcode, net zoals je dat met je applicatiecode doet.
Blijf je testcode onderhouden net zoals je dat doet met je applicatiecode.
Ga met enige regelmaat met de stofkam door je testsuite. Zijn alle tests in je suite nog waardevol? Kunnen ze nog steeds falen wanneer het moet, en geven ze informatie waar je iets aan hebt? Wees niet bang om tests weg te gooien die aan het einde van hun levensduur zijn gekomen!

Een techniek als mutation testing kan je helpen om geautomatiseerd beter inzicht krijgen in de kwaliteit van je (unit) tests. Uiteraard is ook dit geen oplossing voor alles, maar zeker de moeite van het bestuderen waard.

Kun jij je geautomatiseerde tests vertrouwen?