Leeftijdsverificatie testen is de discipline van controleren dat een poort opengaat voor de juiste mensen en sluit voor de rest — en het is moeilijker dan het lijkt, want de poort is een vergelijking met een drempel die uit een elders geschreven regel komt, toegepast op een geboortedatum die zelf in een andere kalender kan zijn vastgelegd.
Dit artikel bekijkt waar de gangbare drempels vandaan komen, wat zelfverklaarde geboortedatums wel en niet kunnen vaststellen, welke grenswaarden een test verdienen, en hoe om te gaan met de mensen voor wie de rekenkunde niet werkt zoals verwacht.
Waar komen de verschillende leeftijdsdrempels vandaan?
Ze komen uit verschillende regels met verschillende doelen, wat de reden is waarom er geen enkel getal is om te implementeren.
| Drempel | Waar die doorgaans verschijnt |
|---|---|
| 13 | Regels voor online privacy van kinderen in de Verenigde Staten, die de gegevensverzameling van jonge gebruikers beheersen |
| 16 | De standaardtoestemmingsleeftijd voor diensten van de informatiemaatschappij onder Europese gegevensbeschermingsregels, die lidstaten binnen een bereik mogen aanpassen |
| 18 | De meerderjarigheidsleeftijd in de meeste landen, en de poort voor een breed scala aan contracten en diensten |
| 21 | Een hogere limiet die sommige rechtsgebieden gebruiken voor alcohol en enkele andere gereguleerde activiteiten |
De belangrijke observatie is dat dit geen vier punten op één schaal zijn. Een platform kan op de ene leeftijd een op kinderen gerichte privacyverplichting hebben, op een andere geverifieerde toestemming nodig hebben, en op een derde van een dienst uitgesloten zijn. Elke poort moet als een eigen regel met een eigen bron worden geïmplementeerd, en het profiel dat die beheerst moet in de code worden vermeld in plaats van te worden afgeleid uit één opgeslagen getal.
Twee vuistregels volgen. Hergebruik nooit de ene drempel omdat een andere elders in het product bestaat, en behandel nooit de hoogste toepasselijke leeftijd als een veilige standaard voor elke functie, want dat sluit stilletjes mensen uit die recht hebben op het gebruik van de dienst.
Wat kan een zelfverklaarde geboortedatum vaststellen?
Heel weinig buiten het feit dat iemand hem heeft getypt. Een datum die in een formulier wordt ingevoerd zonder andere controle, legt een bewering vast, geen feit, en de enige echte waarde is dat het accidenteel misbruik voorkomt en het systeem iets geeft om later mee te vergelijken.
Dat is geen reden om het veld over te slaan, maar het is een reden om precies te zijn over waarvoor het dient. Een zelfverklaarde datum ondersteunt een op eerlijkheid gebaseerde poort: de gebruiker wordt gevraagd, het antwoord wordt vastgelegd, en het product vertrouwt erop dat het antwoord waarheidsgetrouw is. Een sterkere poort heeft een of ander bewijs nodig, wat in de praktijk betekent vergelijken met een document of een database in plaats van een getypte datum.
De twee moeten anders worden gemodelleerd, omdat ze anders falen. Een zelfverklaarde datum kan fout zijn door onzorgvuldigheid of door bewuste onjuiste opgave, en geen enkele validatie op het formulier kan de twee onderscheiden. Een documentgesteunde controle kan falen omdat het document ongeldig is, omdat de rekenkunde verschilt, of omdat de controle niet beschikbaar is op het moment dat de gebruiker die nodig heeft. Vastleggen welk soort poort een beslissing opleverde, is wat de beslissing later controleerbaar maakt.
Onder dertien is de situatie weer anders: toestemmings- en gegevensverzamelingsregels treden in werking, wat een compliancevraag is in plaats van een verificatievraag, en het valt buiten wat enige formuliervalidatie kan beslechten. Wat het product hier ook doet, moet een gedocumenteerde beslissing zijn, niet een standaard die uit een validatieregel is voortgekomen.
Hoe moeten grenswaarden worden getest?
Grenswaarden testen voor dit soort regel betekent de datum kiezen, niet de persoon. Zet de referentiedatum vast die het systeem zal gebruiken, construeer dan geboortedatums aan beide zijden van elke drempel en assert de exacte uitkomst.
- De geboortedatum die de persoon op de referentiedatum precies de drempelleeftijd maakt, die moet slagen onder de gebruikelijke conventie dat de verjaardag zelf telt.
- De geboortedatum één dag later, die de persoon een dag tekort laat schieten en moet falen.
- De geboortedatum één dag eerder, die de persoon een dag voorbij de drempel plaatst en moet slagen.
- Een geboortedatum op een schrikkeldag, met de referentiedatum in een niet-schrikkeljaar, waar de vergelijkingsregel ertoe doet.
- Een geboortedatum aan het uiterste einde van het plausibele bereik, om rekenkunde op te vangen die een nauwe spreiding van leeftijden aanneemt.
De eerste drie vangen bijna alles, en de vierde vangt de implementaties die stilletjes besluiten dat een verjaardag op een schrikkeldag in sommige jaren naar de eerste maart is verschoven. Alle vijf hebben een vaste referentiedatum nodig; een test die de huidige klok leest, slaagt vandaag en faalt rond een verjaardag, en de fout zal op iemands releasedag landen.
De vergelijking uitvoeren in de richting die de rand het kleinste maakt, is het vermelden waard: is de persoon minstens zo oud, in plaats van is deze datum jonger dan die. De regel formuleren als een vergelijking tussen datums nodigt uit tot omgekeerde tekens, en een omgekeerd teken op een drempel verandert een poort in het tegenovergestelde.
Hoe veranderen tijdzones het antwoord?
De drempel wordt op een tijdstip geëvalueerd, en de geboortedatum niet. Als de huidige datum wordt gehaald uit een server in de ene tijdzone terwijl de gebruiker in een andere is, dan zijn de twee het gedurende een paar uur per dag oneens over wat vandaag is. Iemand die jarig is, kan als een dag jonger of een dag ouder worden behandeld, afhankelijk van welke klok is geraadpleegd.
Voor een interactieve controle is de eigen lokale datum van de gebruiker meestal de juiste referentie, omdat de gebruiker degene is die weet welke dag het is waar hij is. Voor een geplande of batchcontrole is één vaste referentiedatum meestal juist, omdat het resultaat reproduceerbaar moet zijn. Wat niet mag gebeuren, is een mengeling: het ene deel van het systeem dat de lokale datum gebruikt en een ander dat die van de server gebruikt, wat records oplevert die het alleen op de meeste dagen met zichzelf eens zijn.
Een gerelateerde dubbelzinnigheid betreft geboortedatums die zonder tijdcomponent zijn vastgelegd. Sla een gewone kalenderdatum op en hang er nooit een tijdzone aan, anders betekent hetzelfde record verschillende dagen in verschillende systemen.
Hoe zit het met mensen geboren op een schrikkeldag?
Hun verjaardag valt volgens de meeste conventies op de eerste maart in een niet-schrikkeljaar, of op de laatste dag van februari — en verschillende rechtsgebieden en systemen antwoorden hier verschillend op. De consequentie voor een leeftijdspoort is een venster van hoogstens één dag waarin de twee conventies het oneens zijn over de vraag of iemand een drempel heeft bereikt.
De praktische reactie is niet een kant kiezen en het vergeten, maar bewust kiezen en de keuze testbaar maken. Welke conventie het product ook aanneemt, moet worden geschreven waar de leeftijd wordt berekend en gedekt door een fixture, zodat een latere wijziging aan een datum-bibliotheek die niet stilletjes omkeert. Voor een drempel met echte consequenties is een meningsverschil van één dag precies het soort ding dat een bezwaar oplevert, en een bezwaar is makkelijker te beantwoorden wanneer de conventie is gedocumenteerd.
Waarden die voor dit soort testen worden gegenereerd, zijn synthetisch en bestaan alleen om de poort te beproeven; het zijn geen echte geboortedatums van mensen, en ze kunnen niet worden gebruikt om enige echte leeftijds- of identiteitscontrole te doorstaan. De generator voor identiteits- en testgegevens produceert geboortedatums over een breed bereik van jaren met een vaste identiteitssleutel, wat het eenvoudig maakt om een grensset samen te stellen en op aanvraag te reproduceren.
Voor ontwikkelaars: drempels configureerbaar maken
Lees elke drempel uit configuratie in plaats van die hard te coderen. Drempels veranderen, soms voor één rechtsgebied, en een getal dat in een voorwaarde begraven zit, is één release verwijderd van een compliancegat. Noem elke regel naar de verplichting die hij implementeert, zodat een lezer kan zien waarom de poort bestaat, niet slechts dat die bestaat.
Houd de leeftijdsberekening op één plek en roep die overal vandaan aan. Twee implementaties van dezelfde regel gaan afwijken, en degene die afwijkt is altijd degene op het pad dat niemand opnieuw leest. Neem de referentiedatum als parameter in plaats van de klok binnen de functie te lezen, zodat tests die kunnen vastpinnen en batchtaken een eigen vaste datum kunnen doorgeven.
Sla de geboortedatum op, nooit een leeftijd. Een leeftijd is een afgeleide waarde die volgens een eigen schema onjuist wordt, en een opgeslagen leeftijd is de dag nadat die is geschreven onjuist voor elk record in de tabel. Markeer de afgeleide waarde als afgeleid waar die ook wordt blootgesteld, zodat niemand die als opgeslagen feit gaat vertrouwen.
Laat ten slotte de fixtuurset de grenzen bewijzen. Vier records — precies op de drempel, één dag tekort, één dag te ver, en een schrikkeldag — geassert tegen een vaste datum vangen de grote meerderheid van defecten op dit gebied, en ze blijven jarenlang werken omdat de referentiedatum wordt gegeven in plaats van waargenomen.
Volgende stappen
Kies de leeftijdspoort met de hoogste consequenties in uw product en schrijf op uit welke regel die voortkomt; als niemand dat kan zeggen, is dat de bevinding. Bouw dan de vier grensrecords, pin de referentiedatum vast, en voer ze uit — alles wat het oneens is met de verwachte uitkomst is een bug in de vergelijking en niet in het formulier. De gids over randgevallen van geboortedatums behandelt de kalenderproblemen eronder, en de identiteitsgenerator levert de bredere spreiding van geboortedatums die grenswaardetests niet bereiken.