Inpasbaarheid testen met TMAP

Wat is inpasbaarheid nu echt?

Inpasbaarheid wordt soms verward met installability (de vraag of een pakketje wel netjes op een server landt). Maar binnen het TMAP-raamwerk gaan we veel verder.

Inpasbaarheid is de mate waarin de geautomatiseerde software aansluit op de handmatige procedures van de organisatie. Het gaat over de interface tussen de mens en de machine. Je kunt de beste code ter wereld schrijven, maar als die code niet "past" in de dagelijkse routine van de gebruiker, is de software zo goed als waardeloos. Inpasbaarheid dwingt je om verder te kijken dan de knoppen op het scherm. Je kijkt naar de volledige procesketen: van de eerste menselijke handeling tot de uiteindelijke verwerking in het systeem.

User adaption staat centraal

Waarom zou jij je als tester, product owner of developer druk maken over inpasbaarheid? Het antwoord is simpel: User Adoption.

Als software niet inpasbaar is, gebeuren er drie dingen die je project de nek omdraaien:

Workarounds

Gebruikers zijn creatief. Als het systeem hen tegenwerkt, gaan ze eromheen werken. Ze houden schaduwlijstjes bij in Excel of plakken post-its op hun scherm met data die ze later moeten invoeren. Gevolg? Je data-integriteit is weg.

Compliance-risico's

Wanneer de handmatige controlepunten niet logisch aansluiten op de systeemoutput, glippen fouten erdoorheen. Voor je het weet voldoe je niet meer aan de wet- en regelgeving waar het systeem juist voor bedoeld was.

Hogere kosten

Een proces dat op papier sneller lijkt, maar in de praktijk voor frictie zorgt, verhoogt de werkdruk en de foutmarge. De business case die je vooraf had berekend, verdampt waar je bij staat.

Herkenbaarheid van falende infrastructuur

Laten we het concreet maken. Waar gaat het vaak mis met inpasbaarheid?

• De volgorde van informatie: Een callcenter-medewerker moet in het systeem verplicht het BSN-nummer invoeren in het eerste scherm. Maar uit de praktijk blijkt dat klanten dat nummer pas halverwege het gesprek opzoeken. De software dwingt een proces af dat niet matcht met de natuurlijke flow van een telefoongesprek.
• Fysieke beperkingen: Een systeem voor monteurs vereist dat ze na elke reparatie een uitgebreid verslag typen. Maar omdat ze buiten in de regen staan met vieze handen, doen ze dit pas aan het eind van de dag. De 'real-time' rapportage waar het management op rekent, is daardoor nooit actueel.
• De 'gap-analyse': De software doet stap A en stap C perfect, maar voor stap B (bijvoorbeeld een handmatige handtekening van een manager) is geen logische plek in de workflow. Het proces valt hier letterlijk in een gat.

Hoe maak je dit testbaar met TMAP?

Inpasbaarheid testen doe je niet achter je bureau met een testscript in de hand. Het vereist een Shift Left aanpak. Je begint namelijk al met 'testen' voordat er één regel code is geschreven.

1. Beoordeel de User Stories met een proces-bril 

Vraag bij elke nieuwe feature: "Wat doet de gebruiker direct vóór deze handeling, en wat direct erna?" Als die stappen niet in het systeem zitten, wie doet ze dan? En sluit dat aan?

2. Gebruik de Procescyclustest (PCT) 

Dit is een krachtige TMAP-testontwerptechniek. Met de PCT breng je de verschillende paden door een proces in kaart. Door niet alleen de 'happy flow' in het systeem te tekenen, maar ook de handmatige stappen daaromheen, zie je direct waar de frictie ontstaat.

3. Test de 'fysieke' inpasbaarheid 

Ga naar de werkplek. Als je software ontwikkelt voor een fabriek, ga dan de werkvloer op. Test je een app voor onderweg? Ga de trein in. Alleen daar ontdek je of de inpasbaarheid standhoudt onder druk, omgevingslawaai of wisselende connectiviteit.

Inpasbaarheid als teamprestatie: De 'Whole Team Approach'

In een Agile- of DevOps-omgeving is kwaliteit niet meer het exclusieve feestje van de tester. Dat geldt zeker voor inpasbaarheid. Omdat dit attribuut precies op de grens ligt van techniek en business, heb je het hele team nodig om het goed te krijgen.

• De developer: Bouwt met de context in het achterhoofd. Als een developer weet dat de software wordt gebruikt in een lawaaierige fabriekshal, kiest hij voor visuele signalen in plaats van subtiele geluidsmeldingen.
• De product owner (PO): Is de bewaker van de proces-fit. De PO moet durven zeggen: "Deze feature is technisch briljant, maar het sluit niet aan bij hoe onze klantenservice werkt. We gaan het versimpelen."
• De Scrum Master: Faciliteert de communicatie met de eindgebruikers. Hij of zij zorgt dat de feedback uit de 'field tests' ook daadwerkelijk de sprint backlog haalt.

Wanneer je als cross-functional team inpasbaarheid serieus neemt, voorkom je dat je een technisch hoogstandje bouwt waar de organisatie in de praktijk over struikelt.

Hoe meet je inpasbaarheid?

Je kunt inpasbaarheid niet simpelweg vangen in een 'pass/fail' percentage. Het is vaak kwalitatief, maar je kunt het wel degelijk concreet maken met de juiste indicatoren:

1. Time-to-complete (Manual vs. Auto): Hoe lang duurt het totale proces (inclusief handmatige stappen) mét de nieuwe software vergeleken met de oude situatie? Als de totale doorlooptijd stijgt door systeemfrictie, is je inpasbaarheid laag.
2. Support-tickets 'Procesvragen': Krijgt de helpdesk veel vragen in de trant van "Hoe moet ik dit afhandelen in het systeem als X gebeurt?" Dan sluit de software niet aan op de uitzonderingen in de praktijk.
3. Observatie-score: Kijk mee met vijf gebruikers. Hoe vaak moeten ze het systeem verlaten (om iets op te zoeken, te bellen of te overleggen) om één transactie af te ronden?

Van 'checklist' naar intuïtie

Het mooie aan de TMAP-filosofie is dat kwaliteitsattributen zoals inpasbaarheid na verloop van tijd in het DNA van je team gaan zitten. Je hoeft dan niet meer bij elke story een dik boekwerk open te slaan. Je leert de juiste vragen te stellen op het juiste moment.

Je stopt met het bouwen van functies en begint met het bouwen van oplossingen die écht werken in de handen van de mensen voor wie ze bedoeld zijn. Dat is het verschil tussen een IT-project dat 'af' is en een IT-oplossing die waarde toevoegt.

Structureel beter worden in softwarekwaliteit?

Inpasbaarheid is slechts één van de puzzelstukken binnen het TMAP-raamwerk. In een wereld waar software steeds complexer wordt en de scheiding tussen 'de business' en 'IT' vervaagt, is een gedeelde taal over kwaliteit onmisbaar. Wil jij (en je team) leren hoe je kwaliteitsattributen zoals inpasbaarheid, performance en bruikbaarheid vanaf de eerste dag in je ontwikkelproces integreert? Volg de e-learning TMAP: Quality for Cross-Functional Teams om te leren hoe je kkaliteit vertaalt naar concrete, testbare scenario's, de juiste testontwerptechnieken (zoals PCT) inzet voor maximale dekking en als team verantwoordelijkheid neemt voor de eindgebruiker.