Maak de juiste afweging tussen kwaliteit, tijd en kosten

Een belangrijk deel van de tijd- en kwaliteitswinst die CI/CD belooft, wordt geboekt met testautomatisering. En ja, unittesten en regressietesten kun je in de regel ook prima automatiseren. Want doordat ontwikkelaars geen tijd meer verspillen met handmatig testen, kun je veel meer scripts inzetten. Je kunt de vrijgevallen testcapaciteit bovendien inzetten voor hoogwaardiger werk, wat waarschijnlijk een nog verdere kwaliteitsverbetering van de software tot gevolg heeft.

Acceptatietesten door medewerkers

Tot zover de theorie. Want de praktijk is dat je nooit alle software, en zeker niet de complexe interfaces, volledig geautomatiseerd kunt testen. Neem bijvoorbeeld de acceptatietesten. Je zou weliswaar automatische testscripts kunnen ontwikkelen die het gedrag van gebruikers nabootsen, maar medewerkers willen in de regel zelf zien of het werkt. Daarom vinden acceptatietesten in de regel handmatig plaats.

Hoe ga je om met complexiteit?

En ander type test dat lastig te automatiseren is, zijn de testen van hele complexe integratieservices, denk bijvoorbeeld aan integraties tussen een legacy back-end systeem en meerdere moderne front-end apps. Ook ketentesten zijn vaak dermate complex en veelomvattend dat je nooit alle testen in zo’n keten volledig kunt automatiseren.

Unittesten en regressietesten zijn wel eenvoudig te automatiseren. Maar als je met containers gaat werken die om de beurt worden uitgerold, is het een uitdaging om de boel gesynchroniseerd te houden, tenzij de oude en nieuwe interfaces compatible met elkaar zijn. Dit probleem speelt ook als je een databasewijziging doorvoert.

Sta ook stil bij de non-functionals

Naast deze functionele testen zijn er ook nog de non-functionals die getest moeten worden, denk bijvoorbeeld aan load testen. Als je deze tests wilt automatiseren, dan moet je de volledige productieomgeving van een bedrijf simuleren, wat vrijwel onmogelijk is. Daarom wordt er in de praktijk vaak geen test gedaan, maar een inschatting gemaakt: als er zoveel berichten per minuut verzonden worden tussen deze twee applicaties, dan hebben we ongeveer deze bandbreedte en deze rekencapaciteit nodig. Kortom, met extrapolatie kun je een redelijke inschatting maken. Immers, als je op een vrijwel lege machine de responstijden niet haalt, dan weet je zeker dat het op een volle helemaal niet gaat lukken.

Onderhoud je testscripts 

Toch zul je, wil de vruchten plukken van CI/CD, zoveel mogelijk testen moeten automatiseren. Daar wordt vaak makkelijk over gedacht: we schrijven wat scripts en klaar is kees. Zo eenvoudig is het niet. Het schrijven van goede geautomatiseerde testscripts kost initieel zeker twee tot drie keer zoveel tijd. Bovendien zullen de testsets ook onderhouden moeten worden. Je zult dus een governancestructuur moeten opzetten om te beoordelen wat de status is van de automatische testscripts.

Bovendien moet je je realiseren dat je er niet bent nadat een interface live is gegaan. Je zult met actieve monitoring het gedrag van applicaties moeten meten en moeten bekijken of het proces zo loopt als je vooraf hebt uitgedacht. Misschien constateer je wel dat de data-uitwisseling perfect verloopt, maar dat een van beide applicaties ineens een stuk trager is geworden.

Zie testautomatisering niet als trucje

Kortom, pas op dat je CI/CD, en met name de testautomatisering, niet ziet als een trucje waarbij je netjes alle stappen zet, zonder te letten op de kwaliteit van die stappen. Want ja, testautomatisering is belangrijk, maar niet zonder dat je vooraf nadenkt over welke testen je wel en niet kunt automatiseren en hoe je de governance opzet zodat je zeker weet dat je testscripts up-to-date zijn. De valkuil van verregaande automatisering is immers dat je niet goed meer ziet wat er gebeurt, waardoor er makkelijk fouten kunnen ontstaan. Als je geen goede methode hebt om die fouten op te sporen, leidt testautomatisering natuurlijk alleen maar tot een slechtere kwaliteit van software.