Es ist leicht, standortbezogene Software vollständig anhand bequemer, sauberer Beispiele zu entwickeln und zu testen: eine saubere Adresse in einer Großstadt, eine private Breitband-IP-Adresse, ein Ort, der weit von jeder Grenze oder Zeitzonengrenze entfernt liegt. Jeder dieser Tests wird zuverlässig bestehen, und jeder davon sagt Ihnen fast nichts darüber, wie sich Ihr System in den Situationen verhält, die am ehesten ein Problem verursachen, sobald es in der Produktion auf echte, unordentlichere Daten trifft.
Eine wirklich nützliche Testsuite für Standortsoftware muss gezielt die schwierigeren Fälle enthalten, die diese Serie einzeln behandelt hat: eine Adresse in einem Land ohne herkömmliche Hausnummerierung, eine Abfrage für einen Ort extrem nahe an einer Staatsgrenze, einen Zeitstempel, der genau in eine Sommerzeitumstellung fällt, eine IP-Adresse, die bekanntermaßen zum CGNAT-Pool eines Mobilfunkanbieters oder zu einem Satelliten-Internetanbieter gehört, eine Koordinate nahe den Polen, wo auf dem Längengrad beruhende Annahmen zu versagen beginnen, und eine Postleitzahl aus einem Land mit vergleichsweise groben Postdaten statt aus einem Land mit ungewöhnlich detaillierten Referenzdaten.
Keines davon ist ein exotisches, unwahrscheinliches Szenario, das nur der Gründlichkeit halber erfunden wurde. Jedes steht für eine reale, wiederkehrende Kategorie von Eingaben, die jede ausreichend große, wirklich globale Nutzerbasis früher oder später und vorhersehbar an Sie senden wird, oft früher als erwartet. Ein System, das nie dagegen getestet wurde, wird nicht laut und offensichtlich auf leicht diagnostizierbare Weise scheitern. Meistens scheitert es leise und liefert ein plausibel wirkendes, aber subtil falsches Ergebnis, das jede oberflächliche Prüfung besteht und erst viel später als echtes Problem auftaucht, meist als verwirrendes Support-Ticket oder als unerklärliche Geschäftskennzahl, die nicht aufgeht. Zu diesem Zeitpunkt ist es erheblich schwieriger, das Problem bis zu seiner eigentlichen Ursache zurückzuverfolgen.
Der Aufbau eines solchen Testsets folgt derselben Disziplin, die weiter oben für die Messung von Genauigkeit und Abdeckung beschrieben wurde: eine feste, bewusst vielfältige, wiederverwendbare Sammlung von Testeingaben, die nicht nur darauf geprüft wird, ob überhaupt eine plausible Antwort zurückkommt, sondern gezielt darauf, ob sich die Felder precision und confidence in dieser Antwort angesichts der tatsächlichen Schwierigkeit der jeweiligen Eingabe sinnvoll und konsistent verhalten. Ein Ergebnis mit niedriger Konfidenz und grober Präzision für einen wirklich schwierigen Fall ist ein korrektes, ehrliches Resultat und sollte als bestanden gelten. Ein selbstbewusst falsches Ergebnis oder ein unbehandelter Fehler ist das eigentliche Versagen, das Sie erkennen sollten, bevor Ihre Nutzer es für Sie finden.
Unsere Dokumentation beschreibt die genauen Felder und das zu erwartende Verhalten jedes Endpunkts. Sie ist der richtige Ausgangspunkt, um ein solches bewusst herausforderndes Testset für die Grenzfälle aufzubauen, die für Ihre eigene Anwendung und deren Nutzer am wichtigsten sind.