Infrastructuur testen met TMAP
De deployment is afgerond, de build staat live en iedereen haalt even adem. Totdat blijkt dat de software zich anders gedraagt dan verwacht. Functionaliteit die in test probleemloos werkte, geeft in productie fouten. Issues zijn lastig te reproduceren, logs vertellen niet het hele verhaal en al snel valt het bekende zinnetje: “maar op test werkte het prima”. Wat voelt als een technisch incident, is in werkelijkheid een kwaliteitsprobleem dat dieper zit. De software doet functioneel wat hij moet doen, maar blijkt niet geschikt voor de infrastructuur waarin hij nu draait. Binnen TMAP is dat geen detail, maar een expliciet kwaliteitsattribuut.
Wat bedoelt TMAP met infrastructuur?
Infrastructuur klinkt zwaar en technisch, maar binnen TMAP gaat het vooral om de omgeving waarin software moet functioneren. Denk aan besturingssystemen, cloudplatformen, containers, databases, middleware en netwerken. Dit is niet omdat TMAP iets wil zeggen over hoe je deze infrastructuur ontwerpt, maar omdat al deze componenten invloed hebben op het gedrag van de software.
De kernvraag is eenvoudig maar scherp: kan deze software zonder aanpassing betrouwbaar functioneren in de beoogde omgeving? Het gaat dus niet om infrastructuur op zichzelf, maar om de afhankelijkheid ervan. Zodra die afhankelijkheid impliciet blijft, ontstaat risico.
Waarom infrastructuur zo vaak een verborgen kwaliteitsrisico is
In veel teams worden infrastructuur keuzes nauwelijks besproken. Configuraties verschillen een beetje per omgeving, versies lopen langzaam uiteen en aannames over beschikbaarheid, performance of schaalbaarheid worden zelden expliciet vastgelegd. Tegelijkertijd richt testen zich vooral op functionele correctheid binnen één context. Dat werkt, totdat de context verandert. Dan blijkt dat software wel klopt, maar alleen onder specifieke omstandigheden.
Fouten worden lastig reproduceerbaar, discussies verschuiven richting “omgeving versus code” en kwaliteit komt pas ter sprake als het al misgaat. Als infrastructuur niet expliciet wordt meegenomen in kwaliteitsdenken, test je feitelijk maar een deel van het systeem, hoe grondig de tests verder ook zijn.
Herkenbare praktijksituaties uit de praktijk
De meeste infrastructuurproblemen zijn niet spectaculair, maar juist alledaags. Een applicatie blijkt afhankelijk van lokale bestandspaden die in productie niet bestaan. Netwerkvertraging zorgt voor time-outs die in test nooit optraden. Een andere databaseversie introduceert subtiele verschillen in query-gedrag. Containers gedragen zich onder productiebelasting anders dan verwacht, of logging ontbreekt precies op het moment dat analyse nodig is. Functioneel lijkt alles correct, maar operationeel is het gedrag onvoorspelbaar. Dat maakt het systeem kwetsbaar, ook al is er niets “kapot” in de code.
Infrastructuurgeschiktheid testen met TMAP
TMAP benadert infrastructuur niet als iets dat je los moet testen, maar als context waarin kwaliteit moet bestaan. De focus ligt op het stellen van vragen die vaak te laat worden gesteld. In welke omgevingen moet dit systeem draaien? Welke infrastructuur afhankelijkheden beïnvloeden het gedrag? Gedraagt de software zich voorspelbaar over omgevingen heen? Wat gebeurt er als resources schaars worden, belasting toeneemt of configuraties wijzigen?
Dit zijn geen infrastructuurtests in klassieke zin, maar kwaliteitstests waarbij infrastructuur expliciet wordt meegenomen als risicofactor. Precies daar helpt TMAP teams om impliciete aannames expliciet te maken, voordat ze zich vertalen naar productieproblemen.
De samenhang met andere kwaliteitsattributen
Infrastructuur staat nooit op zichzelf. Onbetrouwbare infrastructuur ondermijnt continuïteit. Onvoorspelbaar omgevingsgedrag raakt performance. Onduidelijke infrastructuur maakt beheerbaarheid lastiger en verschillen tussen omgevingen vergroten beveiligingsrisico’s. Wanneer infrastructuurgeschiktheid ontbreekt, trekken andere kwaliteitsattributen automatisch mee onderuit, zelfs als ze afzonderlijk zorgvuldig zijn ontworpen. Daarom behandelt TMAP infrastructuur niet als een technisch randgebied, maar als een dragend onderdeel van kwaliteit.
Wat je hierover leert bij Testlearning
In de e-learning TMAP: Quality for Cross-Functional Teams leer je infrastructuur benaderen als vast onderdeel van kwaliteitsdenken. Je leert hoe omgevingsafhankelijkheden kwaliteitsrisico’s vormen, hoe je die risico’s bespreekbaar maakt en hoe je gezamenlijk verantwoordelijkheid neemt voor voorspelbaar gedrag over omgevingen heen. Niet door extra processen of tooling toe te voegen, maar door beter te kijken, gerichter vragen te stellen en kwaliteit eerder in het gesprek te brengen.
Test vooraf de infrastructuur van je software
De vraag is uiteindelijk niet of je software werkt, maar waar en onder welke omstandigheden. Draait jouw software overal waar hij moet draaien, of alleen daar waar hij is gebouwd? Infrastructuurgeschiktheid ontdek je niet bij livegang. Die borg je vooraf, door kwaliteit te beoordelen in de context waarin die kwaliteit moet bestaan.