Stel dat je een reservering vergelijkt. Je opent een tweede tabblad, bekijkt een ander tijdstip en krijgt tussendoor een telefoontje. Als je terugkomt, staat het eerste scherm nog keurig klaar, maar je weet niet meer welke keuze daar ook alweer in stond.
Een edge case is een situatie buiten de meest voor de hand liggende route, maar wel eentje die in het dagelijks gebruik gewoon voorkomt. Voor edge cases testen hoef je dus geen vreemde handelingen te bedenken. Een tabblad, een onderbreking en een beetje twijfel zijn vaak al genoeg.
De gebruiker probeert gewoon iets af te maken, met de aandacht die op dat moment beschikbaar is. Dat maakt die gebruiker niet lastig. Het maakt een aanname zichtbaar. De test ging ervan uit dat iemand de taak in één keer en in de gekozen volgorde zou uitvoeren. Welke andere aannames neem je ongemerkt mee?
Twee tabbladen, twee versies van de waarheid
Bij die reservering is vergelijken een logische stap. In het ene tabblad staat dinsdag, in het andere donderdag. Misschien verandert een keuze meteen in het account. Misschien gebeurt dat pas bij bevestigen. Zonder die afspraak weet je nog niet welk gedrag fout is.
Kies daarom eerst wat de gebruiker mag verwachten. Blijft ieder tabblad een eigen concept, of delen ze dezelfde reservering? Voer daarna in één tabblad een wijziging uit en ga terug naar het andere scherm. Vergelijk wat je ziet met wat echt is opgeslagen.
Alleen controleren of beide pagina's openen is te weinig. Het wordt pas interessant als het systeem nog verouderde informatie toont. Een tester maakt dat verschil zichtbaar. Daarna kan het team kiezen voor verversen, waarschuwen of opnieuw bevestigen. Welke oplossing past, hangt van de taak af.
De koffie was niet onderdeel van de testcase
In de praktijk zien we vaak dat testscripts uitgaan van één rustige sessie, van begin tot eind. Zo werkt bijna niemand. Neem iemand die een declaratie invult en halverwege wordt weggeroepen. Bij terugkomst is de sessie verlopen. Dat kan passen bij de beveiligingsafspraken, maar wat gebeurt er met het werk dat al was gedaan?
Houd twee vragen uit elkaar. Mag iemand verder zonder opnieuw in te loggen? En begrijpt die persoon wat er met de invoer is gebeurd? Een systeem kan de eerste vraag netjes afhandelen en bij de tweede toch verwarring veroorzaken.
Onderzoek daarom het hervatten én de uitleg op het scherm. Bewaren is niet altijd de juiste keuze. Gevoelige gegevens vragen om bewuste afspraken. Maar een lege pagina zonder uitleg? Daar heeft niemand iets aan.
Dus: zoek met de ontwikkelaar of beheerder uit wanneer de sessie-timeout volgens de instellingen ingaat. Test vlak vóór die grens. En vlak erna. Noteer wat behouden hoort te blijven en controleer of de invoer en de melding daarbij passen. Met een willekeurige pauze mis je de sessie-timeout misschien volledig.
Plakken is ook invoeren
Een telefoonnummer overnemen gaat gemakkelijk met kopiëren en plakken. Daarbij kunnen spaties of scheidingstekens meekomen. De gebruiker ziet een herkenbaar nummer. Het formulier ziet misschien iets wat niet aan het ingestelde patroon voldoet.
De W3C-richtlijn over inputvalidatie adviseert om waar passend verschillende gebruikelijke notaties te ondersteunen. Dat betekent niet dat iedere invoer geldig is. Wel dat een technisch gekozen vorm niet automatisch gelijkstaat aan wat mensen begrijpen.
Probeer dus naast handmatig typen ook plakken vanuit een realistische bron. Verwerkt het systeem de waarde goed, of krijgt iemand begrijpelijke uitleg? Let er ook op dat het systeem je invoer niet stilletjes aanpast om de controle te laten slagen. Je onderzoekt een bruikbare route, geen wedstrijd om zoveel mogelijk rare tekens te verzamelen.
De terugknop betekent niet altijd annuleren
Stel dat je een abonnement vergelijkt en de terugknop gebruikt om een voorwaarde nog eens te lezen. Je hebt nog geen beslissing genomen. Toch kan de toepassing doen alsof je opnieuw begint, of juist een eerdere keuze blijven onthouden.
Daar zit een goede testvraag: welke keuze geldt wanneer je weer vooruitgaat? Kijk naar de getoonde prijs, de gekozen optie en de uitleg bij de volgende stap. Een vinkje dat blijft staan is alleen handig als duidelijk is waarvoor het geldt.
Dit soort alledaags gebruikersgedrag kan een vertrekpunt zijn voor gebruikersscenario's bij UAT. Beschrijf eerst de bedoeling, zoals voorwaarden vergelijken. Leg daarna pas de klikvolgorde vast. Anders test je vooral of iemand jouw route kan nadoen.
De muis blijft even liggen
Iemand werkt met het toetsenbord omdat dat prettig is, omdat de muis niet beschikbaar is of omdat bedienen met een muis lastig gaat. Dat is geen rare omweg. Toch mist een test met steeds dezelfde muisklikken dit perspectief makkelijk.
Probeer een relevante taak met het toetsenbord. Kun je zien waar de focus op het scherm staat? Bereik je de actie die nodig is? En kom je daarna op een begrijpelijke plek terecht? Alleen ergens op Enter drukken vertelt nog niet of de hele taak te volgen is.
Test je ook in meerdere browsers? Dan merk je dat focus en toetsenbordgedrag best wel verschillen. Kies combinaties die bij de doelgroep passen. Eén geslaagde route bewijst geen volledige toegankelijkheid.
Eerst lezen, dan pas kiezen
Een gebruiker hoeft niet te beginnen bij het opvallendste vak op een pagina. Misschien wil iemand eerst weten wat een dienst kost, welke gegevens nodig zijn of hoe een keuze later gewijzigd kan worden.
Observeer daarom niet alleen waar iemand klikt. Vraag ook wat die persoon probeert te begrijpen. Bij gebruikerservaring testen is die bedoeling belangrijk. Een technisch bereikbare knop kan nog steeds op een onlogisch moment komen. Een waarneming bij één persoon is een aanwijzing om verder te onderzoeken, geen uitspraak over alle gebruikers.
We zien edge cases vaak pas als we gewoon gedrag terugbrengen tot een controleerbare verwachting. Wat wilde iemand doen? Welke aanname bleek niet te kloppen? En welk resultaat moet begrijpelijk blijven? Zo voorkom je dat een test verandert in een verzameling losse afwijkingen.
Pak één route die je deze week test. Welke gewone onderbreking of omweg heb je daarin nog niet meegenomen?
Wil je weten welke edge cases in het gebruikersgedrag van jouw belangrijkste routes nog buiten beeld blijven?
