Grundlagen: den Verifizierungsnachweis eines Builds lesen

Vor drei Wochen habe ich für eine Freundin, die ein Yoga-Studio betreibt, ein Buchungs-Widget gebaut — ein Chat, ein Plan, den ich schnell genehmigt habe, weil ich gerade mit etwas anderem beschäftigt war, ein Durchlauf, und dann eine Versionskarte mit einem grünen Häkchen, das ich kurz angesehen und dann übergangen habe. Am Dienstag schrieb sie mir und fragte, ob ein zweites Studio die Website desselben Builds ebenfalls nutzen könne. Bevor ich Ja sagte, schaute ich mir noch einmal an, was „verifiziert“ drei Wochen zuvor eigentlich bedeutet hatte, und da habe ich zum ersten Mal eines dieser Protokolle wirklich gelesen, statt einfach dem Häkchen zu vertrauen.

Es befindet sich direkt auf der Versionskarte, neben der Vorschau und den Code-Aktionen — an derselben Stelle, an der man auch erneut bereitstellt oder zurücksetzt. Das Erste, was mir auffiel: Es bezieht sich nur auf diese eine Version, nicht auf die gesamte Unterhaltung. Ich hatte an diesem Build fünf Iterationen vorgenommen, um einen fehlerhaften Datumsauswähler zu beheben, und ich hatte halb erwartet, dass mir das Protokoll den gesamten Verlauf erzählt. Tut es nicht. Das Protokoll von Version 4 beschreibt nur Version 4. Es weiß nicht, dass Version 2 mit einem Login-Formular ausgeliefert wurde, das stillschweigend fehlschlug, und es sagt mir nicht, dass Version 5 unauffällig etwas behoben hat, das Version 3 kaputt gemacht hatte. Jedes Protokoll ist eine Momentaufnahme, kein Diff und kein Änderungsprotokoll — wenn ich die Historie dessen sehen will, was sich von Release zu Release geändert hat, brauche ich eine ganz andere Ansicht. Diese hier beantwortet nur: „Ist diese eine Version in Ordnung.“

Scrollt man weiter nach unten, gliedert sich das Protokoll in sechs Zeilen:

Alle sechs waren grün, und mein erster Impuls war derselbe falsche Impuls, den vermutlich die meisten Leute hätten: Sicherheit bestanden, also sicher; Barrierefreiheit bestanden, also barrierefrei. Keine dieser Lesarten hält der Realität dessen stand, was die Prüfungen tatsächlich tun. Die Sicherheitsprüfung bedeutet, dass oberflächliche Probleme — String-Verkettung in einer Abfrage, ein API-Schlüssel offen im Client-Bundle, ein eval auf etwas vom Nutzer Eingegebenem — nicht aufgetaucht sind. Es ist kein Tag mit einem Penetrationstester. Das Studio meiner Freundin nimmt über dieses Widget keine Zahlungen entgegen, nur Namen und Zeitfenster, also passte die Grundabsicherung für sie. Wäre es ein Checkout-Prozess gewesen, hätte ich mehr als nur die Grundabsicherung erwartet.

Barrierefreiheit war die Zeile, bei der ich tatsächlich innehielt und etwas nachschlug, denn „axe bestanden“ klingt erschöpfend, ist es aber nicht. Axe — die automatisierte Engine im Hintergrund — erfasst zuverlässig etwa ein Drittel bis die Hälfte der WCAG-Erfolgskriterien: fehlender Alt-Text, schlechte Kontrastverhältnisse, unbeschriftete Formularfelder, offensichtliche Fehler bei ARIA. Es kann nicht sagen, ob der individuelle Datumsauswähler, den ich angefordert hatte, mit einem Screenreader nutzbar ist, ob das Tabben durch den mehrstufigen Buchungsprozess den Fokus an einer sinnvollen Stelle platziert oder ob der von mir grün und gelb eingefärbte Status „bestätigt“ vs. „ausstehend“ für jemanden mit Rot-Grün-Sehschwäche ein Problem darstellt. Dafür braucht es einen Menschen, der den Build mit den Hilfsmitteln durchgeht, auf die Nutzer mit Behinderungen tatsächlich angewiesen sind. Axe liefert echtes Signal, nicht nichts — es ist die Rechtschreibprüfung der Barrierefreiheit, nicht das Lektorat.

Konformität war die Zeile, die ich fast übersprungen hätte, weil sie bürokratisch klingt — „enthält, was der Plan versprochen hat“ —, bis mir einfiel, dass ich den Plan, den ich genehmigt hatte, abgelenkt gelesen hatte und mich wirklich nicht erinnern konnte, ob ich E-Mail-Bestätigungen oder nur SMS angefordert hatte. Diese Ebene prüft den Build gegen den Plan, nicht gegen meine tatsächliche Absicht, und sie wurde bestanden, was mir sagte, dass der Build dem entsprach, dem ich zugestimmt hatte — nicht unbedingt dem, was ich gemeint hatte. Ich habe von Builds gehört, die funktional solide und sicher waren und trotzdem an dieser Ebene scheiterten, weil unter Zeitdruck stillschweigend eine Funktion weggelassen wurde. Es ist die Ebene, die einen Build ehrlich zur Unterhaltung hält, aus der er entstanden ist, selbst wenn die Unterhaltung selbst etwas nachlässig war.

Unter den sechs Zeilen befand sich eine längere Liste, unterteilt in zwei Bereiche, und hier habe ich die meiste Zeit verbracht. Muss-behoben-Einträge sind keine aktuell bestehenden Probleme des Builds — sie sind Belege. Eine Zeile besagte, dass die Review-Ebene einen Fall gemeldet hatte, in dem ein Datumsstring direkt in eine Abfrage eingefügt wurde, und dass dies bereits behoben worden war, bevor diese Version als abgeschlossen markiert wurde. Ich betrachtete keine offene Wunde; ich betrachtete eine Narbe. Diese Unterscheidung ist wichtig, denn wer einen Muss-behoben-Eintrag als aktuelle Warnung liest, verschwendet Zeit mit der Sorge um etwas, das bereits erledigt ist.

Die Hinweisliste war länger und bestand größtenteils aus Dingen, die ich selbst gesagt hätte, würde ich den Code eines Kollegen prüfen, ohne den Merge blockieren zu wollen: „Erwägen Sie, den wiederholten Block zur Slot-Darstellung in eine gemeinsame Komponente auszulagern“, „dieser Endpunkt hat kein Rate-Limiting, was für ein internes Buchungstool in Ordnung ist, aber überdacht werden sollte, falls es öffentlich geht.“ Nichts auf dieser Liste war ein Mangel. Es waren Ermessensentscheidungen, die ein Prüfer nur anhand von Plan und Code getroffen hat, und für den internen Terminplaner eines Yoga-Studios lagen alle diese Einschätzungen auf der vernünftigen Seite. Wäre das Studio meiner Freundin eine Franchise mit dem Widget auf fünfzig Standortseiten gewesen, hätte ich beim Rate-Limiting-Punkt widersprochen — die Einstufung hängt von Kontext ab, den der Prüfer nur erraten kann, und wenn eine Vermutung Ihnen falsch erscheint, ist die richtige Reaktion, dies im Chat zu sagen, nicht davon auszugehen, dass die Kennzeichnung endgültig ist.

Was mir auffiel, als ich eine ziemlich lange Hinweisliste neben einer sauberen Muss-behoben-Spalte betrachtete: Ich hätte die Länge fast als schlechtes Zeichen gelesen. Ist sie nicht. Ein Build ohne Hinweiseinträge hat entweder nur eine oberflächliche Prüfung bekommen oder Glück gehabt; ein Build mit einem Stapel von „Erwägen Sie“-Einträgen und nichts Offenem in der Muss-behoben-Spalte wurde tatsächlich sorgfältig geprüft. Die Hinweisspalte ist das, was übrig bleiben soll, sobald die echten Probleme beseitigt sind.

Das andere, wozu ich mich selbst gezwungen habe, da dieser Datensatz bereits drei Wochen alt war, war zu prüfen, welche Ebenen tatsächlich ausgeführt wurden, bevor ich den Ergebnissen überhaupt vertraute. In diesem Fall waren alle sechs vorhanden, aber ich habe inzwischen einen Build gesehen, bei dem Barrierefreiheit einfach nicht in der Liste auftauchte, statt als bestanden oder fehlgeschlagen markiert zu sein — das ist nicht dasselbe wie ein als unwichtig übersprungener Punkt, sondern ein Zeichen dafür, dass die Prüfung für diesen bestimmten Site-Typ oder diese Flag-Konfiguration gar nicht ausgeführt wurde. Ein Fehlen als stillschweigendes Bestehen zu deuten, ist genau der Fehler, zu dem dieses Format verleitet, wenn man nur überfliegt.

Nichts davon hat mir verraten, ob der Buchungsablauf des Yoga-Studios tatsächlich konvertiert, ob Leute beim Zeitfenster-Schritt abspringen oder ob die Grundidee eines eigenen Widgets statt einer einfachen Verlinkung zu Calendly überhaupt die richtige Entscheidung war. Verifikation beweist, dass ein Build wie versprochen funktioniert – nicht, dass das Versprechen das richtige war. Das sind zwei getrennte Fragen, und ich habe schon Builds erlebt, die jede Ebene sauber durchlaufen haben und bei echten Nutzern trotzdem gefloppt sind, weil „funktioniert korrekt“ und „löst das richtige Problem“ sich weniger überschneiden, als man hoffen würde. Die Hälfte, die tatsächlich die zweite Frage beantwortet, ist die Messschleife, und beide sind dazu gedacht, zusammen gelesen zu werden. Ein sauberer Verifikationsnachweis für ein Feature, das niemand bucht, ist immer noch ein Feature, das niemand bucht.