De focus ligt vaak op de verkeerde problemen
Testautomatisering wordt vaak gepresenteerd als een logische stap in de volwassenwording van softwareontwikkeling. Organisaties willen sneller releasen, de kwaliteit verhogen en de afhankelijkheid van handmatig testen verminderen. De voordelen lijken vanzelfsprekend. Toch zijn er nog steeds veel initiatieven die na een veelbelovende start hun doel voorbijschieten.
De eerste reactie is vaak om naar de techniek te kijken. Was de keuze voor het framework wel de juiste? Zijn de tests goed ontworpen? Is de CI/CD-pipeline optimaal ingericht?
De techniek krijgt daarbij vaak de schuld. In de praktijk blijkt techniek zelden de beperkende factor.
Hoewel dit relevante vragen zijn, zie ik na jaren in het vakgebied steeds hetzelfde patroon terug:
De meeste testautomatiseringsprojecten mislukken niet door techniek, maar door cultuur.
Met cultuur bedoel ik in dit geval niet bedrijfswaarden aan de muur, maar de dagelijkse keuzes die teams maken rondom eigenaarschap, samenwerking en verantwoordelijkheid voor kwaliteit.
De focus ligt vaak op de verkeerde problemen
Wanneer een organisatie besluit te investeren in testautomatisering, gaat veel aandacht uit naar tooling en architectuur. Er worden frameworks geselecteerd, pipelines ingericht en dashboards gebouwd. Er worden discussies gevoerd over programmeertalen, teststrategieën en rapportages.
Dat zijn belangrijke onderwerpen. Zonder solide technische basis is duurzame testautomatisering onmogelijk. Toch ontstaat er op dat moment vaak een fundamenteel misverstand. Er wordt aangenomen dat testautomatisering vooral een technisch vraagstuk is, terwijl de grootste succesfactor vaak organisatorisch van aard blijkt te zijn.
In organisaties waar testautomatisering uiteindelijk vastloopt, zie je vaak dezelfde patronen terug:
- Developers zien kwaliteit vooral als een verantwoordelijkheid van testers.
- Testautomatisering wordt ondergebracht bij een gespecialiseerd team.
- Management kijkt vooral naar kostenbesparing en snelheid.
- Succes wordt gemeten aan het aantal geautomatiseerde tests.
- Kwaliteit wordt pas onderwerp van gesprek nadat functionaliteit is ontwikkeld.
Onder deze omstandigheden kan zelfs de beste technische oplossing de verwachtingen niet waarmaken.
Wanneer testautomatisering de verkeerde problemen probeert op te lossen
In de beginfase lijkt een testautomatiseringsinitiatief vaak succesvol. Er worden steeds meer tests toegevoegd, de eerste resultaten zijn zichtbaar en stakeholders zien dashboards vollopen met groene vinkjes. Maar na verloop van tijd ontstaan de eerste scheuren. De onderhoudslast groeit sneller dan verwacht. Tests worden instabiel. Doorlooptijden lopen op. Teams verliezen vertrouwen in de resultaten. Uiteindelijk wordt testautomatisering gezien als iets dat tijd kost, in plaats van iets dat waarde toevoegt. Dat is meestal geen probleem van de tool.
- Een framework kan geen onduidelijke requirements corrigeren.
- Een pipeline kan geen gebrek aan eigenaarschap oplossen.
- Een testsuite kan geen kwaliteitscultuur creëren.
- Wat testautomatisering wel doet, is de sterke en zwakke plekken in de kwaliteitsaanpak blootleggen.
In die zin werkt testautomatisering als een vergrootglas. Organisaties met een sterke kwaliteitscultuur halen meer waarde uit testautomatisering. Organisaties met structurele kwaliteitsproblemen maken die problemen vooral sneller zichtbaar.
De misvatting dat kwaliteit ontstaat tijdens het testen
Een van de hardnekkigste misverstanden binnen softwareontwikkeling is het idee dat kwaliteit ontstaat tijdens de testfase. Dat is begrijpelijk. Testen is immers het moment waarop fouten zichtbaar worden. Maar het ontdekken van een probleem is iets anders dan het creëren van kwaliteit. Kwaliteit ontstaat veel eerder: wanneer requirements worden besproken en aangescherpt, wanneer risico’s expliciet worden gemaakt, wanneer ontwerpkeuzes worden gemaakt en wanneer teams nadenken over testbaarheid, onderhoudbaarheid en gebruikservaring. Met andere woorden: kwaliteit ontstaat tijdens het maken van keuzes.
Testen en testautomatisering spelen daarbij een cruciale rol, maar ze voegen geen kwaliteit toe die eerder in het proces nooit aanwezig was. Ze geven inzicht in de kwaliteit die al dan niet is opgebouwd.
Wat succesvolle organisaties anders doen
Wanneer we kijken naar organisaties die wel succesvol zijn met testautomatisering, zien we opvallend vaak dezelfde kenmerken terug.
Ten eerste behandelen zij kwaliteit niet als een afzonderlijke activiteit, maar als een gedeelde verantwoordelijkheid binnen het team. Developers, testers, product owners en andere stakeholders dragen gezamenlijk verantwoordelijkheid voor het eindresultaat.
Daarnaast wordt kwaliteit vroeg in het proces besproken. Niet pas tijdens acceptatietesten, maar al tijdens refinements, ontwerpen en technische besluitvorming.
Ook wordt testautomatisering gezien als een middel en niet als een doel. Het doel is niet om zoveel mogelijk tests te automatiseren. Het doel is om sneller feedback te krijgen, risico’s beter beheersbaar te maken en met meer vertrouwen software te leveren.
Dat vraagt om een andere manier van denken. De vraag verschuift van:
“Hoe kunnen we meer automatiseren?” naar: “Hoe kunnen we kwaliteit structureel onderdeel maken van softwareontwikkeling?”
Die verschuiving sluit aan op de bredere beweging van testen naar quality engineering. De aandacht verschuift daarbij van het opsporen van fouten naar het creëren van omstandigheden waarin kwaliteit vanaf het begin kan ontstaan.
Cultuur bepaalt het rendement van techniek
Technologie blijft belangrijk. Moderne tooling maakt het mogelijk om sneller te ontwikkelen, eerder feedback te krijgen en risico’s beter te beheersen. Maar technologie is zelden de beperkende factor. De echte vraag is niet of een organisatie het juiste framework heeft gekozen. De echte vraag is of de manier waarop de organisatie naar kwaliteit kijkt, een framework überhaupt kans van slagen geeft.
Zolang kwaliteit wordt gezien als iets dat door een beperkte groep specialisten moet worden bewaakt, blijven de resultaten van testautomatisering achter bij de verwachtingen. Wanneer kwaliteit daarentegen een verantwoordelijkheid van het hele team wordt, ontstaat een omgeving waarin testautomatisering daadwerkelijk zijn waarde kan bewijzen.
Conclusie
Veel organisaties starten een testautomatiseringstraject in de verwachting dat technologie hun kwaliteitsproblemen zal oplossen. In de praktijk blijkt het tegenovergestelde vaak waar: testautomatisering maakt zichtbaar welke kwaliteitsproblemen al aanwezig waren. Dat is geen zwakte van testautomatisering. Het is juist de kracht ervan.
De belangrijkste les die het vakgebied de afgelopen jaren heeft geleerd, is misschien wel deze:
Kwaliteit ontstaat niet tijdens het testen.
Kwaliteit ontstaat tijdens het maken van keuzes.
Wie duurzaam succesvol wil zijn met testautomatisering, moet daarom verder kijken dan frameworks, pipelines en dashboards.
Uiteindelijk bepaalt techniek hoe je automatiseert. Cultuur bepaalt of het werkt.
Jeroen Mengerink
R&D Manager, Test Architect en Trainer bij Polteq
