Altersprüfung testen: Grenzen, Schwellen und Schalttage

Altersprüfung testen ist die Disziplin, zu prüfen, dass eine Schranke für die Richtigen aufgeht und für die Übrigen geschlossen bleibt — und das ist schwerer, als es aussieht, denn die Schranke ist ein Vergleich gegen eine Schwelle aus einer Regel, die anderswo geschrieben wurde, angewandt auf ein Geburtsdatum, das womöglich in einem anderen Kalender erfasst wurde.

Dieser Artikel betrachtet, woher die üblichen Schwellen stammen, was selbst erklärte Geburtsdaten belegen können und was nicht, welche Grenzwerte einen Test verdienen und wie man mit den Personen umgeht, für die die Arithmetik nicht wie erwartet aufgeht.

Woher kommen die verschiedenen Altersschwellen?

Sie stammen aus verschiedenen Regeln mit verschiedenen Zwecken, weshalb es keine einzige Zahl zu implementieren gibt.

Die wichtige Beobachtung ist, dass dies keine vier Punkte auf einer Skala sind. Eine Plattform kann in einem Alter eine Pflicht zum Schutz von Kindern haben, in einem anderen eine nachgewiesene Einwilligung brauchen und in einem dritten von einem Dienst ausgeschlossen sein. Jede Schranke sollte als eigene Regel mit eigener Quelle umgesetzt werden, und das Profil, das sie steuert, sollte im Code genannt und nicht aus einer einzigen gespeicherten Zahl abgeleitet werden.

Daraus folgen zwei Faustregeln. Verwenden Sie nie eine Schwelle wieder, nur weil eine andere anderswo im Produkt existiert, und behandeln Sie nie das höchste anwendbare Alter als sicheren Standard für alle Funktionen, weil das still Menschen ausschließt, die den Dienst nutzen dürfen.

Was kann ein selbst erklärtes Geburtsdatum belegen?

Sehr wenig über die Tatsache hinaus, dass jemand es eingetippt hat. Ein ohne weitere Prüfung in ein Formular eingegebenes Datum hält eine Behauptung fest, keine Tatsache, und sein einziger echter Wert ist, dass es versehentlichen Missbrauch verhindert und dem System etwas gibt, wogegen es später vergleichen kann.

Das ist kein Grund, das Feld zu überspringen, aber ein Grund, genau zu sein, wofür es da ist. Ein selbst erklärtes Datum trägt eine Schranke auf Vertrauensbasis: Die Nutzerin wird gefragt, die Antwort wird festgehalten, und das Produkt verlässt sich darauf, dass die Antwort wahrheitsgemäß ist. Eine stärkere Schranke braucht irgendeinen Beleg, praktisch also den Vergleich mit einem Dokument oder einer Datenbank statt mit einem eingetippten Datum.

Beide sollten verschieden modelliert werden, weil sie verschieden scheitern. Ein selbst erklärtes Datum kann durch Nachlässigkeit oder durch bewusste Falschangabe falsch sein, und keine Prüfung im Formular kann die beiden unterscheiden. Eine dokumentgestützte Prüfung kann scheitern, weil das Dokument ungültig ist, weil die Arithmetik abweicht oder weil die Prüfung im Moment des Bedarfs nicht verfügbar ist. Festzuhalten, welche Art von Schranke eine Entscheidung erzeugt hat, macht die Entscheidung später prüfbar.

Unter dreizehn ist die Lage wieder anders: Einwilligungs- und Erhebungsregeln greifen, was eine Compliance-Frage und keine Verifikationsfrage ist und außerhalb dessen liegt, was eine Formularprüfung klären kann. Was das Produkt hier tut, sollte eine dokumentierte Entscheidung sein und kein Standard, der aus einer Prüfregel entstanden ist.

Wie sollten Grenzwerte geprüft werden?

Grenzwerttests für diese Art Regel bedeuten, das Datum zu wählen und nicht die Person. Fixieren Sie das Bezugsdatum, das das System verwendet, konstruieren Sie dann Geburtsdaten auf beiden Seiten jeder Schwelle und sichern Sie das exakte Ergebnis zu.

• Das Geburtsdatum, das die Person am Bezugsdatum genau in der Schwelle alt macht, was nach der üblichen Konvention bestehen muss, dass der Geburtstag selbst zählt.
• Das Geburtsdatum einen Tag später, das sie einen Tag zu jung macht und scheitern muss.
• Das Geburtsdatum einen Tag früher, das sie einen Tag über die Schwelle setzt und bestehen muss.
• Ein Geburtsdatum an einem Schalttag, mit dem Bezugsdatum in einem Nicht-Schaltjahr, wo die Vergleichsregel zählt.
• Ein Geburtsdatum am äußersten Ende des plausiblen Bereichs, um Arithmetik zu fangen, die eine enge Altersspanne annimmt.

Die ersten drei fangen fast alles, und der vierte fängt die Implementierungen, die still entscheiden, ein Schalttagsgeburtstag sei in manchen Jahren auf den ersten März gerutscht. Alle fünf brauchen ein festes Bezugsdatum; ein Test, der die aktuelle Uhr liest, besteht heute und scheitert rund um einen Geburtstag, und der Fehler landet an jemandes Freigabetag.

Den Vergleich in der Richtung durchzuführen, die den Rand am kleinsten macht, ist ausdrücklich zu nennen: Ist die Person mindestens so alt, statt: Ist dieses Datum jünger als jenes. Eine Regel als Vergleich zweier Daten zu formulieren, lädt zu umgekehrten Vorzeichen ein, und ein umgekehrtes Vorzeichen an einer Schwelle macht aus einer Schranke ihr Gegenteil.

Wie ändern Zeitzonen die Antwort?

Die Schwelle wird zu einem Zeitpunkt bewertet, das Geburtsdatum nicht. Wird das aktuelle Datum von einem Server in einer Zeitzone genommen, während die Nutzerin in einer anderen ist, sind sich die beiden für einige Stunden am Tag uneinig darüber, welcher Tag heute ist. Wer an diesem Tag Geburtstag hat, wird womöglich einen Tag jünger oder einen Tag älter behandelt, je nachdem, welche Uhr befragt wurde.

Für eine interaktive Prüfung ist meist das lokale Datum der Nutzerin das richtige Bezugsdatum, weil sie weiß, welcher Tag dort ist, wo sie ist. Für eine geplante oder stapelweise Prüfung ist meist ein einziges festes Bezugsdatum richtig, weil das Ergebnis wiederholbar sein muss. Was nicht geschehen darf, ist eine Mischung: ein Teil des Systems mit dem lokalen Datum und ein anderer mit dem des Servers, was Datensätze erzeugt, die nur an den meisten Tagen mit sich selbst übereinstimmen.

Eine verwandte Doppeldeutigkeit betrifft Geburtsdaten, die ohne Uhrzeitanteil erfasst sind. Speichern Sie ein reines Kalenderdatum und hängen Sie nie eine Zeitzone daran, sonst bedeutet derselbe Datensatz in verschiedenen Systemen verschiedene Tage.

Was ist mit Menschen, die an einem Schalttag geboren sind?

Ihr Geburtstag fällt nach den meisten Konventionen im Nicht-Schaltjahr auf den ersten März oder auf den letzten Februartag — und verschiedene Rechtsordnungen und Systeme antworten darauf verschieden. Für eine Altersschranke folgt daraus ein Fenster von höchstens einem Tag, in dem die beiden Konventionen uneinig darüber sind, ob jemand eine Schwelle erreicht hat.

Die praktische Antwort ist nicht, eine Seite zu wählen und sie zu vergessen, sondern bewusst zu wählen und die Wahl prüfbar zu machen. Welche Konvention das Produkt auch annimmt, sie sollte dort stehen, wo das Alter berechnet wird, und von einer Fixture abgedeckt sein, damit eine spätere Änderung an einer Datumsbibliothek sie nicht still umkehrt. Bei einer Schwelle mit echten Folgen ist eine Uneinigkeit von einem Tag genau die Art Sache, die einen Widerspruch erzeugt, und ein Widerspruch ist leichter zu beantworten, wenn die Konvention dokumentiert ist.

Werte, die für diese Art des Testens erzeugt werden, sind synthetisch und existieren nur, um die Schranke durchzuspielen; sie sind keine echten Geburtsdaten, und sie können keine echte Alters- oder Identitätsprüfung bestehen. Der Identitätsdatensatz-Erzeuger liefert Geburtsdaten über einen weiten Jahresbereich bei festem Identitätsschlüssel, was es einfach macht, einen Grenzsatz zusammenzustellen und ihn auf Abruf zu wiederholen.

Für Entwickler: Schwellen konfigurierbar machen

Lesen Sie jede Schwelle aus der Konfiguration, statt sie fest zu verdrahten. Schwellen ändern sich, manchmal für eine einzelne Rechtsordnung, und eine in eine Bedingung vergrabene Zahl ist eine Freigabe von einer Compliance-Lücke entfernt. Benennen Sie jede Regel nach der Pflicht, die sie umsetzt, damit eine Leserin erkennt, warum die Schranke existiert, und nicht nur, dass sie existiert.

Halten Sie die Altersberechnung an einer Stelle und rufen Sie sie von überall auf. Zwei Implementierungen derselben Regel driften auseinander, und die abweichende ist immer die auf dem Pfad, den niemand erneut liest. Nehmen Sie das Bezugsdatum als Parameter, statt die Uhr innerhalb der Funktion zu lesen, damit Tests es festnageln und Stapelläufe ein eigenes festes Datum übergeben können.

Speichern Sie das Geburtsdatum, nie das Alter. Ein Alter ist ein abgeleiteter Wert, der nach eigenem Zeitplan falsch wird, und ein gespeichertes ist am Tag nach dem Schreiben für jeden Datensatz in der Tabelle falsch. Kennzeichnen Sie den abgeleiteten Wert überall, wo er sichtbar wird, als abgeleitet, damit niemand beginnt, ihn als gespeicherte Tatsache zu behandeln.

Lassen Sie schließlich den Fixture-Satz die Grenzen belegen. Vier Datensätze — genau an der Schwelle, einen Tag zu jung, einen Tag darüber und ein Schalttag —, gegen ein festes Datum zugesichert, fangen die große Mehrheit der Defekte in diesem Bereich, und sie funktionieren jahrelang weiter, weil das Bezugsdatum vorgegeben und nicht beobachtet wird.

Nächste Schritte

Wählen Sie die folgenreichste Altersschranke in Ihrem Produkt und schreiben Sie auf, aus welcher Regel sie stammt; kann es niemand sagen, ist das der Befund. Bauen Sie dann die vier Grenzdatensätze, nageln Sie das Bezugsdatum fest und lassen Sie sie laufen — alles, was vom erwarteten Ergebnis abweicht, ist ein Fehler im Vergleich und nicht im Formular. Der Leitfaden zu den Randfällen beim Geburtsdatum behandelt die Kalenderprobleme darunter, und der Identitätsdatensatz-Erzeuger liefert die breitere Streuung von Geburtsdaten, die Grenzwerttests nicht erreichen.