De afgelopen jaren heeft het testen van software een vlucht genomen. Steeds meer bedrijven zien het nut en de noodzaak van software die niet alleen goed gebouwd is, maar ook goed getest. En zoals zo vaak in de ICT gaan de ontwikkelingen dan ineens hard. Hoewel het proces van handmatig testen nauwelijks volwassen is, lijkt het ultieme doel om nieuwe code overal en altijd geautomatiseerd te kunnen testen hijgerig nagejaagd te worden.

Maar is dat doel wel zo heilig? Ik denk van wel. Een goed doordachte geautomatiseerde regressietest kan organisaties helpen om sneller en kwalitatief betere software op te leveren. Maar er zijn wel een aantal zaken die voor alle betrokkenen helder moeten zijn, wil je overgaan tot het automatiseren van de tests.

Waarom, wat, wie en wanneer?

Als de opdrachtgever op deze vragen geen duidelijk antwoord kan geven: doe het dan vooral niet. In de praktijk trek je dan aan een dood paard en zal je als tester een ware Don Quichote zijn, hoe leuk het proces en het eindresultaat ook kunnen zijn. Als niemand echt belang hecht aan wat je hebt gebouwd, wint uiteindelijk de frustratie.

De ‘waarom’ vraag is misschien wel de belangrijkste. Als in een gesprek met de opdrachtgever tests automatiseren op tafel komt en hij of zij heeft hier een duidelijk verhaal bij, ben je al halverwege een succesvol traject. De klant heeft immers een doel voor ogen en zoekt waarschijnlijk bevestiging en meer kennis om dat te realiseren.

De kosten en de baten

Zelfs als de antwoorden op de meest basale vragen duidelijk zijn, is een geautomatiseerde test niet vanzelfsprekend. Als de test bijvoorbeeld veel onderhoud vraagt, en helaas is dat vaak zo, kan het ten koste gaan van de kwaliteit van testen in brede zin. De tester is dan veel meer bezig met bijvoorbeeld ID’s van objecten aanpassen en testdata updaten dan met het testen zelf.

Als vervolgens de beslissing om testen te automatiseren valt terwijl de trein van een project al lang is vertrokken, kunnen de kosten enorm zijn. Een belangrijke keuze daarbij is of de tester binnen het team gaat automatiseren of dat de automatisering buiten het team wordt gedaan.

Tot slot bestaan veel geautomatiseerde regressietests uit de standaard paden van een proces. De uitzonderingen en error flows moeten dan nog steeds met de hand getest worden. Geautomatiseerd testen moet in ieder geval een tijdwinst en een verbetering van de kwaliteit door een hoge dekkingsgraad van het totale testproces opleveren. Het bespaart zelden op de kosten. Sterker nog: het kost meestal extra geld.

Stap voor stap

Hoewel het meest tot de verbeelding sprekend, is het niet verstandig om direct de UI in een geautomatiseerd script te gieten. De basis moet goed zijn. Daarom vind ik dat unit- en integratie testen als eerste aan de beurt zijn. Als dat goed loopt, volgt de volgende stap. Als de UI is gedaan, kan je ook nog gaan nadenken over het automatiseren van performance- en loadtesten.

Deze manier van werken heeft een bijkomend voordeel. Het maakt dat, in het geval agile werken, het hele team zich verantwoordelijk voelt en het geen ‘hobby’ van de tester is. Ik heb inmiddels heel wat trajecten zien stuklopen omdat het automatiseren een solo actie bleek. Arme Don Quichotes…

Dus…

Wie mijn stuk leest als een pleidooi tegen test automatiseren, heeft het mis. Geautomatiseerd testen kan bedrijven enorm helpen. Maar zonder de geschetste (en wellicht andere) randvoorwaarden zal het niet snel goed gaan. De praktijk is mijn getuige. Bezint eer ge begint. Het klinkt als iets uit een ver verleden. Het klinkt mij echter heel actueel in de oren. Zeker als het gaat om test automatisering.

Martin Heining is als testconsultant werkzaam bij PTWEE. Hij heeft voor uiteenlopende bedrijven, waaronder Ahold, KPN, en Heineken, rollen vervuld als test coördinator, scrum master en testconsultant.

‍