Portabiliteit testen met TMAP

Wat is portabiliteit nu echt?

In de officiële TMAP-woordenlijst staat een strakke definitie voor dit begrip. Het is de mate waarin een systeem, product of component effectief en efficiënt overgezet kan worden van de ene hardware, software of andere operationele of gebruiksomgeving naar een andere. Kortom: het is een officieel ISO 25010 product kwaliteitsattribuut.

Als we dit vertalen naar gewone mensentaal, dan hebben we het simpelweg over de overdraagbaarheid of de verhuisbaarheid van jouw software. Het betekent dat een applicatie niet kieskeurig is. De software moet net zo makkelijk draaien op een lokale Windows-laptop van een ontwikkelaar, als in een Linux-container in de AWS-cloud, of op de smartphone van een eindgebruiker. Het kwaliteitsattribuut kijkt dus naar hoe flexibel de software omgaat met een verandering van de ondergrond waarop het leeft.

Waarom is overdraagbaarheid belangrijk?

Je vraagt je misschien af waarom je hier extra tijd aan zou besteden. De software werkt nu toch gewoon in de cloud? Nou en? Als je hier niet vanaf het begin over nadenkt, loop je later keihard tegen de lamp. Dit attribuut is om drie grote redenen onmisbaar voor elk modern IT-team:

1. Snelheid in je deployment pipeline (Velocity)

In een Agile- of DevOps-omgeving wil je code continu integreren en live zetten (CI/CD). Als software een lage verhuisbaarheid heeft, betekent dit dat je bij elke stap naar een nieuwe omgeving handmatig instellingen moet aanpassen. De testers moeten wachten, de pipeline loopt vast en de release vertraagt. Software die een hoge mate van omgevingsonafhankelijkheid heeft, stroomt zonder drempels door de pipeline heen.

2. Flexibiliteit en kostenbesparing

Infrastructuur verandert snel. Vandaag draait je applicatie misschien op een eigen server op kantoor, maar morgen besluit het management dat alles naar Microsoft Azure moet verhuizen. Als je applicatie vastgeroest zit aan specifieke hardware-eigenschappen, kost zo'n migratie maanden aan werk en kapitalen aan budget. Software die makkelijk overdraagbaar is, maakt je organisatie flexibel. Je kunt overstappen van leverancier of cloudprovider wanneer je wilt, zonder dat je de hele applicatie opnieuw hoeft te bouwen.

3. Minder vage meldingen bij de supportafdeling

Eindgebruikers doen altijd iets anders dan het team verwacht. Ze gebruiken verouderde browsers, net iets andere schermformaten of een specifiek besturingssysteem dat net op de markt is. Wanneer de flexibiliteit van de softwareomgeving laag is, ontstaan er detailfouten die je in je testomgeving nooit had kunnen voorspellen. De helpdesk krijgt vervolgens de ellende over zich heen van functies die weigeren te laden. Door vooraf te testen op overdraagbaarheid, vang je deze problemen op voordat de klant er last van heeft.

Praktijksituaties: Waar gaat het vaak mis?

Om portabiliteit tastbaar te maken, kijken we naar een paar situaties die je waarschijnlijk herkent uit je dagelijkse werk.

De verborgen database-afhankelijkheid

Een team bouwt een nieuwe applicatie. Op de laptops van de ontwikkelaars draait een lokale database (bijvoorbeeld PostgreSQL versie 15). Alles werkt als een zonnetje. De acceptatie-omgeving maakt echter gebruik van PostgreSQL versie 14, omdat de systeembeheerders die versie centraal up-to-date houden. Tijdens de testfase blijkt ineens dat een specifieke zoekfunctie niet werkt, omdat versie 14 een bepaalde databasecode niet ondersteunt. Dit is een typisch voorbeeld van een gebrek aan portabiliteit door een verborgen afhankelijkheid.

Hardcoded bestandspaden

Dit is een klassieke fout die nog verrassend vaak voorkomt. In de code staat ergens een verwijzing naar een bestandspad geschreven, zoals C:\Applicatie\Data\Uploads. Dit werkt perfect zolang de software op een Windows-server draait. Maar wanneer het bedrijf overgaat op cloud-containers die op Linux werken, kent het systeem dit mappensysteem helemaal niet. De applicatie loopt direct vast bij de eerste de beste bestandsupload.

De rol van Docker en Infrastructure as Code (IaC)

Veel teams denken dat ze dit probleem volledig hebben opgelost door Docker-containers en Infrastructure as Code (IaC) te gebruiken. Hiermee verpak je de software en de omgeving immers samen in een pakketje. Dat helpt enorm, maar het is geen wondermiddel. Want hoe gedraagt die container zich als hij ineens op een server met een heel andere processor-architectuur (zoals een ARM-chip in plaats van een Intel-chip) moet draaien? En wat gebeurt er als de netwerkinstellingen in de cloud net iets strenger zijn dan op je eigen laptop? De tools lossen de overdraagbaarheid niet automatisch voor je op; je moet het nog steeds bewust controleren.

Hoe maak je portabiliteit concreet en testbaar met TMAP?

Binnen de filosofie van TMAP: Quality for Cross-Functional Teams is kwaliteit geen taak die je pas achteraf over de schutting gooit bij een tester. Het is een gezamenlijke verantwoordelijkheid van het hele team. Hoe pak je het testen van deze verhuisbaarheid concreet aan?

Neem het mee in de productrisicoanalyse (PRA)

Voordat je begint met bouwen, komt het cross-functional team bij elkaar voor een productrisicoanalyse. Hierin bespreek je welke kwaliteitsattributen belangrijk zijn voor het product. Vraag aan de product owner en de operations engineer: op welke platformen moet dit minimaal draaien? Welke migraties verwachten we in de toekomst? Als de overdraagbaarheid een hoog risico heeft, geef je dit een prominente plek in je testaanpak.

Testen als niet-functionele variëteit

Portabiliteitstesten vallen onder de niet-functionele testvariëteiten. Je kijkt hierbij niet of de knop functioneel doet wat hij moet doen, maar hoe de software reageert op de verhuizing zelf. TMAP adviseert om hierbij specifiek te letten op drie subkenmerken:

• Aanpasbaarheid (Adaptability): Kan de software zich zonder problemen aanpassen aan verschillende systemen of apparaten?
• Installeerbaarheid (Installability): Hoe makkelijk en foutloos laat de software zich installeren of uitrollen in een nieuwe omgeving?
• Vervangbaarheid (Replaceability): Kan deze software makkelijk een ander component vervangen in dezelfde omgeving?

Zet exploratory testing slim in

Een gestructureerde manier om dit te testen is het gebruik van exploratory testing (ervaringsgericht testen) in verschillende contexten. Een tester, developer en operations engineer kunnen samen een 'test-charter' opstellen. Hierin spreken ze af om de applicatie binnen een uur tijd bewust te installeren en te gebruiken op drie heel verschillende configuraties. Bouw teams op basis van aannames, of kies je voor expliciete scenario's? Door deze variatie in de praktijk te brengen, vallen misverstanden over multi-interpretabele requirements direct op.

Bouw aan ingebouwde kwaliteit met Testlearning

Het voorkomen van omgevingsfouten vraagt om een brede blik van het hele team. Je moet als IT-professional begrijpen hoe softwarekwaliteit verweven zit in de hele levenscyclus van een applicatie, vanaf het eerste idee tot het beheer in productie. Als je pas gaat testen wanneer de code al klaar staat voor productie, ben je te laat en kost het herstellen van fouten bakken met tijd.

In de e-learning TMAP: Quality for Cross-Functional Teams leer je precies hoe je kwaliteitsattributen zoals portabiliteit vanaf de start bespreekbaar en meetbaar maakt binnen je Agile- of DevOps-team. Je krijgt praktische handvatten om samen met je team de juiste teststrategie op te zetten. Geen droge, theoretische opsommingen, maar herkenbare praktijklessen die je direct kunt toepassen in je eigen projecten. Hiermee help je jouw team om software te leveren die écht overal stabiel en soepel draait.

Klaar voor de volgende stap?

Wil jij met jouw team de stap zetten van achteraf brandjes blussen naar ingebouwde kwaliteit vanaf het allereerste begin? Zorg dat iedereen in het team dezelfde taal spreekt en de juiste testvaardigheden bezit. Bekijk direct de elearning van TMAP: Quality for Cross-Functional Teams en ontdek hoe onze e-learning jouw team helpt naar een hoger niveau van softwarekwaliteit.